<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div>Paxton do door entry systems that are cross compatible with a large number of existing devices, some of their hardware will also work work with a number of Voip devises, even smartphone apps.</div>
<div><br>
</div>
<div>When I did a installation training course on Paxton they said a smartphone with a Voip app will also run over 3G allowing someone who is not on site to buzz people it.</div>
<div><br>
</div>
<span class="Apple-style-span" style="font-size: 8px; ">No animals were harmed in the making of this email. However, several thousand electrons were severely inconvenienced.</span><br>
<br>
<div>-------- Original message --------</div>
<div>From: Emyr Morris <em@preseli.com></div>
<div>Date:05/11/2014 10:06 (GMT+00:00) </div>
<div>To: Swansea Hackspace <hackspace@swansea.hackspace.org.uk></div>
<div>Subject: Re: [Swansea Hackspace] TechHub Buzzer/Access Project </div>
<div><br>
</div>
<div>
<div dir="ltr">
<div>
<div>
<div>
<div>
<div>
<div>
<div>the existing buzzer system is very clever. There is a buzzer on the outside gate, and a second buzzer on the inside door.
<br>
<br>
</div>
The victim pushes the button for the floor he wants, and the handset that is picked up will then know which door release to activate.... the handset has to be put down to accept the call from the next buzzer at the next portal.<br>
<br>
</div>
The audio is fairly crucial as people could be pushing the wrong button for the wrong floor... and as there are thousands of people passing that green gate every day, you don't want to buzz anybody through.<br>
<br>
</div>
The important thing in what I have to say is the putting the device back 'on hook' is very important, and if not done properly, it will impede on the passage of the victim through the portals and onto into the inner sanctum.<br>
<br>
</div>
A VERY easy way over the problem would be a big amplified loudspeaker attached to the handset, so when the device is brought off-hook, everybody in the tech hub could hear whoever is announcing himself... so as Justin suggests, some predefined messages could
actually work really well here.<br>
<br>
</div>
Devices goes 'off-hook' - pre defined message 'who's there please' - loudpeaker is activated - and the voice booms across the room deafening everybody in the room and disturbs anybody who was trying to concentrate on their work... I'm beginning to prefer the
RTP streaming audio server solution... trouble with that is opening a client to monitor the stream can take some time to establish the connection.<br>
<br>
</div>
Aren't there existing modules to link these door release systems into existing telephone exchange systems?<br>
<br>
</div>
Looking at the specs of these Door systems, most of them have a POTS interface built in allowing a DECT phone or similar to be used<br>
</div>
<div class="x_gmail_extra"><br>
<div class="x_gmail_quote">On 4 November 2014 20:59, Justin Mitchell <span dir="ltr">
<<a href="mailto:justin@discordia.org.uk" target="_blank">justin@discordia.org.uk</a>></span> wrote:<br>
<blockquote class="x_gmail_quote" style="margin:0 0 0 .8ex; border-left:1px #ccc solid; padding-left:1ex">
<span class="">On Tue, 2014-11-04 at 18:49 +0000, Paul Harwood wrote:<br>
> What about <a href="http://proto-pic.co.uk/categories/wireless/xbee.html" target="_blank">
http://proto-pic.co.uk/categories/wireless/xbee.html</a><br>
><br>
><br>
> mentioned here:<br>
<br>
</span>XBee sell two main kinds of module afaics<br>
<br>
ZigBee 10-100m low power modules.<br>
WiFi modules.<br>
<br>
neither help with the audio capture/playback part, which that article<br>
seems to skip over the detail of, they just talk about saving power by<br>
shutting down the wireless data when theres no audio to send<br>
<br>
List of problems with possible answers<br>
<br>
1. sense buzzer/call, activate door release<br>
1a. easy, any I/O capable board will do; Arduino, RPi, Spark.io, etc<br>
<br>
2. capture audio, and play audio to the wired connection<br>
2a. an RPi with a USB sound card type device<br>
2b. A2D and D2A convertors connected to a your favourite microcontroller<br>
2c. A dedicated VOIP convertor device<br>
<br>
3. Digitise the audio<br>
3a. The audio will need to be in a suitable format such as RTP used by<br>
VOIP systems, audio compression/decompression is not trivial, neither is<br>
the RTP protocol, but there are libraries to help<br>
<br>
4. Transmit audio and control data<br>
4a. Zigbee and bluetooth are too short range<br>
4b. unlicensed radio bands need more specialist transceivers and tend to<br>
also be fairly limited range indoors<br>
4c. wifi at least is ubiquitous and roaming is easy<br>
<br>
5. mobile handset<br>
4a. build more or less a mirror of the base station end, ugly<br>
4b. use a smart phone or tablet, pretty but more coding<br>
<div class="x_HOEnZb">
<div class="x_h5"><br>
<br>
<br>
_______________________________________________<br>
Hackspace mailing list<br>
<a href="mailto:Hackspace@swansea.hackspace.org.uk">Hackspace@swansea.hackspace.org.uk</a><br>
<a href="http://swansea.hackspace.org.uk/mailman/listinfo/hackspace" target="_blank">http://swansea.hackspace.org.uk/mailman/listinfo/hackspace</a><br>
</div>
</div>
</blockquote>
</div>
<br>
<br clear="all">
<br>
-- <br>
<div class="x_gmail_signature">Mob: 07836 267426<br>
<br>
This e-mail and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed.<br>
<br>
Mae'r e-bost hwn ac unrhyw ffeiliau a drosglwyddir gydag ef yn gyfrinachol ac at ddefnydd yr unigolyn neu'r corff y cyfeiriwyd hwy atynt yn unig.</div>
</div>
</div>
</body>
</html>