Madmac Posted January 29, 2015 Share Posted January 29, 2015 Some 3 or 4 years ago ChamSys sponsored a number of students at Southampton University for a group project in their course work.In a meeting with them I suggested doing an IP Intercom, among other projects suggested by our staff. The students choose the IP Intercomwith the tutors concern that ...in the time scale doing hardware design and software was ambitious and that the hardware may be too complex for thisproject. I offered to design a hardware solution that they could customise. I bashed out a design in two evenings based around an 80MHz PIC32 and a 3 portEthernet switch. The belt pack had an unusual PoE system in that it would be a powered device on the network in and able to supply power on the network out to downstream devices. As each belt packdrops a certain amount of voltage it would limit how many could be daisy chained on one Ethernet cable. Four may be five belt packs should be OK The students completed their project with a few working belt packs and software that would mix multiple audio streams. This allows more than one speaker at a time to be listened to.Due to ChamSys usual state of being disorganised the results of their efforts were never obtained and the hardware design has sat on my server ever since.I did upgrade the hardware design about 9 months ago to use one of the newer 200MHz PIC32's (when they finally ship) and laid out a PCB and had a few made but never built up. ChamSys will never use this design, andit seems a waste to not use it for something. It is hard to beat the standard analogue intercom but the IP version can have a few advantages. Gets rid of a cable if network is already in use. It is easy to have as many circuits as needed. Audio filescan be streamed in a cue stack to automate calling cues (MagicQ can play an audio file that could be sent to an intercom system with a suitably modified system and every user hears every bodies cues.... the IPversion can send different cues to specific belt packs). The user interface was a small OLED display and this doubled as the call light by flashing white at full brightness. There is also provision to add akeyboard so that a text message can be sent and displayed if the operator is not always using the unit. The unit could easily be expanded into a stage management cue /comms system. Attached is the circuit of the original design released under CERN OHL (CERN open hardware license http://www.ohwr.org/ ) and if anybody or group of programmers want to do an open source project then I will post the updated design with BOM and PCB stuff and the hardware can be hacked as well. I also did a 5 port Ethernet switch with 4 PoE outputs to power up to 20 belt packs.......if there is reasonable interest then I willadd this as an open source project. I have to say that the level of hardware is small surface mount but can be assembled by hand quite easily. (just practice your soldering). Attached is....pdf of schematic with licensehttps://www.dropbox.com/s/ytl7omeqfv4l2kt/CH423A_V1_Issue1.pdf?dl=0photo of power supply / switchhttps://www.dropbox.com/s/jslgohoe615qjz9/IMAG0585.jpg?dl=0 Edit.. added linksJust discoved you cannot add these on the Blue Rooms....will find somewhere to upload if there is a bit of interest George McDuffChamSys Link to comment Share on other sites More sharing options...
pjb304 Posted January 29, 2015 Share Posted January 29, 2015 Out of curiosity who was it you worked with at the uni? I'm guessing this was a GDP in ECS? Link to comment Share on other sites More sharing options...
Madmac Posted January 29, 2015 Author Share Posted January 29, 2015 Out of curiosity who was it you worked with at the uni? I'm guessing this was a GDP in ECS? The only contact I had was the one meeting to decide on a project. Two of our guys were students there and they took more interest in it. G Link to comment Share on other sites More sharing options...
dbuckley Posted January 29, 2015 Share Posted January 29, 2015 The students completed their project with a few working belt packs and software that would mix multiple audio streams.Do we know what happened to this software? Link to comment Share on other sites More sharing options...
Madmac Posted January 30, 2015 Author Share Posted January 30, 2015 The students completed their project with a few working belt packs and software that would mix multiple audio streams.Do we know what happened to this software? I guess if it still exists that it is on a server at Southampton Uni somewhere. From memory they used the Microchip libaries for network stack and audio. Link to comment Share on other sites More sharing options...
cedd Posted January 30, 2015 Share Posted January 30, 2015 I've been looking in to the idea of using multiple Raspberry Pi's on a wireless network to deliver a wireless intercom system. Didn't get very far due to a mixture of busyness and stupidity when it comes to networking. I came across Mumble though, which looked like a decent solution. It's designed for online gamers and provides them with an intercom system when playing as a team. Apparently it'll work with a local server on a LAN, though most people join an internet server if they're gamers. My thoughts were - Raspberry Pi beltpack running Mumble (they have a Linux version) with Bluetooth headset paired via a USB dongle. Wifi connection (I'd wondered about 5GHz to keep away from wireless DMX etc.) to a central Mumble server, and then away you go! I haven't got enough time to look at it again, and am definitely not the man for the job, but thought I'd share my findings about Mumble. It looks pretty useful. I think the server software Is called Murmur. It's very easy to set up and get working if you use a web based server, but LAN off-line looks a little more complicated. You could then use some kind of USB HID device like the U-HID Nano from Ultimarc to give you push to talk etc. and the Bluetooth headset would handle all the audio side of things. It COULD be possible to build a wireless beltpack for less than £100. Powering the thing might be the most complicated part. Might need some modern battery technology to power the thing for 5 or 6 hours reliably. Link to comment Share on other sites More sharing options...
henny Posted January 30, 2015 Share Posted January 30, 2015 Would going down the VoIP route be an idea ? Run an asterisk server on a Rpi gives plenty of compatibility with other systems and soft phones on smart phones ect Link to comment Share on other sites More sharing options...
Madmac Posted January 30, 2015 Author Share Posted January 30, 2015 Would going down the VoIP route be an idea ? Run an asterisk server on a Rpi gives plenty of compatibility with other systems and soft phones on smart phones ect The original idea was to keep the simplicity of an analogue system.......plug two together and into a power injector and it will work.If you want a complex system then each station can talk to a server via a network switch. It is just as easy to use WiFi if needed.The advantage of a software defined unit is you can change its function easily. George McDuff Link to comment Share on other sites More sharing options...
richardash1981 Posted February 8, 2015 Share Posted February 8, 2015 The original idea was to keep the simplicity of an analogue system.......plug two together and into a power injector and it will work. I had been (idly) wondering if it would be possible (using a low bit rate, low latency code like Ogg Opus) to run an IP intercom over multi-drop RS485, with the idea that it could use the same cabling as RDM-enabled DMX. A bridge to other (e.g. Ethernet) networking would obviously be possible.As DMX runs at 250kbaud (and the Raspberry Pi UART will do this), there should be ~ 128kbit/second of bandwidth available, which could allow 4 talkers @ 32kbit/sec each?I suspect the hard work bit would be IP over half-duplex RS485, because you would end emulating a 10base5/2 Ethernet card in software ... The PoE stuff is certainly a clever trick to pull, and not being dependent on a single server for continued operation is attractive! Link to comment Share on other sites More sharing options...
Madmac Posted February 15, 2015 Author Share Posted February 15, 2015 Using the 250Kbit/sec and then using IP to package up the data would add quite an overhead. A custom protocol would be far better with relatively small packets.If telcom quality is suitable then sampling at 8K with a uLaw codec (non linear conversion) would give a low data rate increasing the number of active talkers.Any bridge can easily convert from one format to another as long as it has the required hardware interfaces...just a bit of firmware. As the RS485 interface normally carries standard async in a DMX system either of the two standards for encapsulation of IP over serial could be used.Those of us old enough to remember phone modems to dial up and connect will probably remember PPP (Point to Point Protocol) and SLIP (Serial Line Internet Protocol) George McDuff Link to comment Share on other sites More sharing options...
Recommended Posts
Archived
This topic is now archived and is closed to further replies.