Digital audio protocol for 100M copper

[mc73]

 I've been tasked with updating an audio communication system used in the fast food industry for drive ins (e.g. 3 order takers to 30-60 order stalls). We're converting an old simplex analog audio system to duplex. There are long runs of conduit with multiple wires. We're moving to digital to avoid crosstalk and interference that was previously avoided by the simplex communication. On the PCB we'll be working with I2S, AKM DSPs and TI PurePath ICs.  Ideally it needs to run over copper, typically cat 5e or 6 in runs of up to 100m. Wireless is not an option to the stalls. In general signal robustness is more important than quality. We frequently deal with poor wire termination, etc.

I don't have any experience with long distance digital audio protocols and am hoping someone might a have a recommendation.

Thanks in advance for any advice.

[coppice]

If you need to send something 100m over CAT5e just use ethernet. There are cheap devices for it, and making the link robust and reliable is a well established practice.

[T3sl4co1l]

Yeh, what bandwidth?

Are these links point-to-point or multi-drop?  Any clue about signal quality?  (If it's just telephone cord in conduit, and probably some low-voltage power lines or switches or lights or such signals, it's probably not too horrible.  If it's a spaghetti mess with multiple terminal blocks along the way, ehh...)

RS-485 is probably good enough over that distance, assuming typical bandwidth for audio (22kHz 8-bit PCM would be overkill?).

As mentioned, Ethernet is rather good, although using the full Ethernet stack is really heavy weight here.  That said, if you can leverage standard products, it may be enticingly easy to install (just put modular plugs on all the ends, an off-the-shelf router/switch at the central hub, and some kind of audio/intercom device at the end -- I've got to imagine these exist already..?)

Although one downside is, 10/100 Ethernet is half-duplex, i.e. two pairs are needed.  If you only have one pair down the conduit, you'll need something a bit different.  (Are there full duplex converter dongles out there?  This also seems like a common enough problem that a solution exists, hmm.)

Tim

[Jeroen3]

Is this for one establishment, or an entire chain?
If for one site, what are the motivations to developing something custom? Aren't there some vandal-proof screens and speaker/microphone units you can use?
A small industrial fanless PC running some software seems a lot easier to replace then a broken custom board.

Also, why don't drive trough work with your smartphone yet?

Otherwise, nothing beats ethernet for available parts or software.

[mc73]

It's voice communication so we can limit to about 300Hz to 3400Hz.

The previous system utilizes a punch block for all the stalls. The order taker selects a stall number, and relays isolate that connection.

The system is being designed for 3000+ stores. We're designing from the ground up. The system will also handle signalling in for service, blinking button lights, etc. Off the shelf is not an option feature or cost wise. We'd prefer not to use the full ethernet stack. The systems needs to be robust and isolated. If the system goes down it essentially shuts the store down. Reliability was the primary selling point of our old analog simplex system which has been in stores for about 20 years now. Our customers have tried some ethernet products and had reliability and latency issues.

We can have as many pairs of wire as needed. Pulling wire will be part of the install.

I'll look into PCM over RS-485.

Thanks Tim.

[mc73]

Jeroen3...

It's for a chain. There are 30+ stalls per store. PCs are expensive and often unreliable. They sometimes also have terrible latency depending on whats running on them. Customs boards are much cheaper in quantity and we have a lot of experience with building robust electronics specific to this industry, user serviceable parts and supply chain.

Thanks.

[ogden]

I would use just LAN infrastructure because audio does not need much bandwidth, most modern Ethernet switches allows bandwidth reservation as well. Protocol: RTSP, RTP. Just one of possible hardware choices: http://www.ip-audio.com/audio/ipaudio.php

[ejeffrey]

When you say "ideally it runs over coppery, typically cat5/5e up to 100 m" is that the existing wiring or do you plan on replacing the wiring?  If the wiring actually meets cat5 specifications, I would be pretty hard pressed to recommend anything other than ethernet.  Plenty of bandwidth, commodity switches are easily available, and when you hire someone to install ethernet, they will fluke it and verify that it meets the specifications.  If you actually want to run over existing wiring that says "cat5" but was only intended for analog voice audio, you may be in more trouble.

IP to audio adapters are easily available, but you could also roll your own quite easily with an extremely simple/dumb controller at the customer side and a standard PC at the operator side.

[ajb]

A crude but fast to develop solution could be to use 3-4 pairs of RS485.  Two to carry audio (one in each direction), and one or two for half- or full-duplex control data.  The base station would be a giant digital mux that routes the digitized audio streams between operators and stalls as needed.  The audio encoding/decoding at each end can pretty much just be a pair of DMA streams between UART and I2S, or even built-in ADCs/DACs.  The control link could be an off-the-shelf protocol or something you create yourself depending on requirements.  All of the wiring can still be Cat5 done by any decent telecom contractor, that works great for RS485.

[ehughes]

Balanced line (transformer coupled) AES3 will work:


http://www.ti.com/lit/ds/symlink/dit4192.pdf

https://www.cirrus.com/products/cs8406/


I have used it for something similar and it worked fine without the hassle of PCs,  network or ethernet.  (I used CAT 5e cable)

[Doctorandus_P]

I've had success with tying the output of an S/Pdif transmitter directly to an RS-485 driver.
Bitrate of S/Pdif is about 1.5Mbits/s and Cat 5 is perfecty suited for long runs of wire with an  RS-485 driver.
On the other end of the wire, the signal gets picked up by 2 RS 485 transceivers.
One RS-485 transceiver picks up the (possibly degraded) signal from the wire and outputs a logic signal. The third RS-485 transceiver is used to send the signal to the S/Pdif transformer in the remote equipment.
I actually use this with a distributed system, where the same S/Pdif data is send to multiple remote nodes. RS-485 is perfecty suited for that. There are no delays added to the signal, except for the length of run or cable, and propagation delays through the drivers, which can all be safely neglected. (Grace Hopper said that a ns is about 30 cm long). You can distribute high quality audio through a house with multiple taps and no chance of stuff ever getting out of sync.

This works very well, but it has to be designed properly. A wrong cable termination can completely demolish your signal.

But for you standard Ethernet is probably better suited.
You can use microcontrollers with chips like the Wizznet W5500, but you have to do some calculations if the whole chain can manage the bitrate for the audio quality you need.

Nowadays it is also common to have microcontrollers with built in Ethernet. Some of the STM32F400 series have built in Ethernet.
Ethenet does add some latency. This is in the order of ms, and unlikely to be an issue for you. But if you have a system in which audio and video are combined you may loose lip sync if you send the audio over ethernet.
Talking mouths with no sound or speach after the actor shut his mouth is annoying and destroys the movie experience. Using a uC with Ethernet also gives you a lot of design flexibility. You can add compression / encryption if required (maybe your next customer requires it). You can also add other features, such as call buttons, blinking led's or add a camera with motion detection and have it signal when someone starts walking in the direction of the front door or cars drive into a drive-in.
You also get the use of standard switches and routers to maintain signal integrity.
Part of Ethernet is signal tuning to match driver and receiver and compensate for cable influences.
Ethernet also reduces the probablility of single point of failure. If in the RS-485 system the cable is shorted anywhere, or even if it is open, you get impedance mismatches and the whole system collapses.

With ethernet and uC's you can also easily add diagnostics data to your protocol. Plug in a cable and the box gives instant feedback if the remote audio node is connected and if it works.

If you want to design a system with a total installed base of 3000 nodes, you want reliability. You do want one of your customers calling you every week with problems. With 3000 nodes development costs are also not so much of an issue. Lots of vendors for the bigger uC's have software stacks available for using the Ethernet controllers on their chips and for audio compression. Some are free, others have commercial licenses.
With Ethernet you can also add remote diagnostics. You can talk to the customers hardware instead of to a frustraded customer over the phone.

[nctnico]

Before Voip large telephone systems often use a so called ping-pong system over a balanced link between the telephone switch and the telephones. Audio (ulaw or alaw encoded) + data are transmitted in packets using an NRZ modulation scheme. The master sends a packet and the slave responds with a similar packet. Buttons and indicators can be mapped directly onto bits inside the packets which greatly simplifies the slave (telephone side). You could use a simple CPLD and a codec at the stall to implement this. A fast microcontroller should also be able to handle this. This scheme is extremely simple, resillient and reliable.

Ethernet may sound nice but when I read that bad wiring is part of the environment ethernet just isn't a good choice.

[mikeselectricstuff]

Seems to me Ethernet is going to be the most flexible in terms of hardware - maybe running a  very lightweight protocol, raw frames rather that TCP/IP.
There are plenty of MCUs that have onboard ethernet MACs and sometimes PHYs as well Maybe look at the PIC32MZ, as it also has I2S support for audio,.
 I probably wouldn't go with W5500 as you may struggle with bandwidth, and it has limited onboard buffer. It also doesn't support larger frames or fragmentation, though having said that, for a simple one-channel audio in or out node, it could be a pretty low-cost, low-learning-curve solution coupled with a cheap 32 bit MCU with I2S support.
Making it be a digital network means you can easily adapt to various permutations needed at different sites and in future, and you can easily find local cable installers that know how to install & test ethernet cabling.
You also have plenty of off-the -shelf kit, so, for example could do fibre if you have the occasional very long run, or use PoE to power some remote kit. 
 

[mikeselectricstuff]

If in the RS-485 system the cable is shorted anywhere, or even if it is open, you get impedance mismatches and the whole system collapses.

It can be worse than that - with RS485, opens and shorts can make the system sort-of-work, some of the time, so faultfinding can be tricky.

Another important thing to consider is that for long runs you want isolation, which comes as standard with ethernet, but adds not insignificant cost for RS485 at the sort of speeds you'd be looking at.

Unless you're taking literally single-point to single-point, ethernet looks like a no-brainer, the only question being what protocol you run over it. Personally I'd avoid any unnecessary protocol layers and software stacks - keep it simple, but think about and allow for future expansion.

[tooki]

Why not just off-the-shelf SIP (VoIP) intercom hardware like this? https://www.digitalacoustics.com/product/full-duplex-ip-intercom/

[ejeffrey]

Unless you're taking literally single-point to single-point, ethernet looks like a no-brainer, the only question being what protocol you run over it. Personally I'd avoid any unnecessary protocol layers and software stacks - keep it simple, but think about and allow for future expansion.

That's also a really compelling advantage of ethernet.  You have multiple existing nice streaming protocols to choose from with both TCP and UDP options, and you can change with a relatively simple software update.  You can also roll your own which should be unnecessary but is also relatively easy for such a simple application.

[jbb]

Whichever scheme you go with, there is a fundamental question: will you do a star, a daisy chain or a full loop?

If reliability (eg uptime) is cucial and space allows for all the canes, I recommend star. That way one broken wire (or dead node) doesn’t bring it all down.

Isolation is a good idea - helps with (some kinds of) noise and should present nasty surprises.

How are you powering the nodes? I ask because Power over Ethernet (PoE) can practically deliver 20W per node (remember the power converters have lossses...) and that could help your overall solution.  Also, PoE could be applied to pretty much any scheme which uses coupling transformers and two twisted pairs (eg RS485 with some coding for DC balance).

Regarding RS485:
- assume 16b mono audio @ 48 kSamples
- assume 80% coding efficiency
- get basically 1 Mbit/s per audio stream
- if duplex is desired, need 2 Mbit/s
- could be trouble for 100m cable runs
- trying to get 30 booths’ worth would be 60 Mbit/s, which is a lot for RS485 and definitely won’t go 100m

[mikeselectricstuff]

Regarding RS485:
- assume 16b mono audio @ 48 kSamples
- assume 80% coding efficiency
- get basically 1 Mbit/s per audio stream
- if duplex is desired, need 2 Mbit/s
- could be trouble for 100m cable runs
- trying to get 30 booths’ worth would be 60 Mbit/s, which is a lot for RS485 and definitely won’t go 100m

4MBaud over 100m of Cat6 is no problem. If you are running multiple pairs in one cable you do need cat6, as crosstalk is the first problem you hit with cat5
For this system, 485 is probably too close to the limit for what you need - Ethernet will have so much headroom you can get something up & running without worrying about compression, and once working can look at optimisation if necessary.
And you have the option to go to gigabit in future if you need it.

 

[mariush]

I'd say just get a microcontroller/processor  powerful enough to encode and decode FLAC or OPUS  (open source both)

FLAC decoding is as far as I know integer only so it will work even on lower frequency microcontrollers.... if you "optimize" the opus library to encode just mono for example it may also be not that much cpu intensive.

from stall to server, you could send  mono 22khz which would take something like 200-400kbps in FLAC and around 48-64 kbps for perfectly good OPUS (in music mode, it can do something like 10-15kbps for voice only)
from server to stall, if you want stereo 16bit 48khz ... could be as much as 500kbps -1mbps (this could be a single stream broadcast to all 30+ stalls using udp, and the stall thing just mutes it when connection is not created (by pushing a button, answering on other end etc) or the shoutcast server could be configured to continuously stream blank flac/opus audio to the stall and keep connections opened non-stop.

Latency can be tweaked to be under half a second, by having very small buffers.

You could use some custom shoutcast  server  (each stall thing connects to a stream on shoutcast to read the operator's voice and uploads its own recording to the shoutcast server as another stream )

[mikeselectricstuff]

I'd say just get a microcontroller/processor  powerful enough to encode and decode FLAC or OPUS  (open source both)

FLAC decoding is as far as I know integer only so it will work even on lower frequency microcontrollers.... if you "optimize" the opus library to encode just mono for example it may also be not that much cpu intensive.

from stall to server, you could send  mono 22khz which would take something like 200-400kbps in FLAC and around 48-64 kbps for perfectly good OPUS (in music mode, it can do something like 10-15kbps for voice only)
from server to stall, if you want stereo 16bit 48khz ... could be as much as 500kbps -1mbps (this could be a single stream broadcast to all 30+ stalls using udp, and the stall thing just mutes it when connection is not created (by pushing a button, answering on other end etc) or the shoutcast server could be configured to continuously stream blank flac/opus audio to the stall and keep connections opened non-stop.

Latency can be tweaked to be under half a second, by having very small buffers.

You could use some custom shoutcast  server  (each stall thing connects to a stream on shoutcast to read the operator's voice and uploads its own recording to the shoutcast server as another stream )

Using any compression that takes appreciable comprless/decompress time adds latency and complexity, and just isn't necessary if you have 100Mbit ethernet.
It's probably going to be much cheaper and easier to just throw bandwidth at it and use little or no data compression.

[Ice-Tea]

Allow me to add another vote for ethernet. No need to reinvent the wheel.

[Jeroen3]

It's for a chain. There are 30+ stalls per store. PCs are expensive and often unreliable. They sometimes also have terrible latency depending on whats running on them. Customs boards are much cheaper in quantity and we have a lot of experience with building robust electronics specific to this industry, user serviceable parts and supply chain.

If you have to compromise some features to fit a standard fanless box pc for this many unit, I can understand the wish for custom boards. Although, the PC's are not that expensive. For sub 500$ you have one, maybe some discount for quantity, but I guess you can't go that low.

We'd prefer not to use the full ethernet stack. The systems needs to be robust and isolated.

Ethernet (IEEE 802.3) is layer two. The "full stack", with layers 3 and above (TCP/IP) is not mandatory to follow as in "the internet", although useful for off the shelf software/hardware compatibility.
You should be able to use ethernet switches for networks that do not follow TCP/IP. I believe there are some Audio over Ethernet products for the entertainment industry, since the cabling is cheap and has a high bandwidth.

[coppice]

I'd say just get a microcontroller/processor  powerful enough to encode and decode FLAC or OPUS  (open source both)

FLAC decoding is as far as I know integer only so it will work even on lower frequency microcontrollers.... if you "optimize" the opus library to encode just mono for example it may also be not that much cpu intensive.

I think the original poster is looking for an interactive solution. FLAC is a disaster for this, as it has massive algorithmic latency. OPUS is specifically designed for low latency applications, and would be a good choice if compression is actually necessary.

[mariush]

It's for a chain. There are 30+ stalls per store. PCs are expensive and often unreliable. They sometimes also have terrible latency depending on whats running on them. Customs boards are much cheaper in quantity and we have a lot of experience with building robust electronics specific to this industry, user serviceable parts and supply chain.

If you have to compromise some features to fit a standard fanless box pc for this many unit, I can understand the wish for custom boards. Although, the PC's are not that expensive. For sub 500$ you have one, maybe some discount for quantity, but I guess you can't go that low.

I don't see how computers are expensive... there's boards with soldered cpu like this one for example at 60$: https://www.newegg.com/Product/Product.aspx?Item=N82E16813157730&ignorebbr=1
Add 40$ for 4gb ddr3 and a ssd and you'll only need a psu to power it.  but there's such boards with 12v or 18.5v dc in jacks
See Asus H110T for example: https://www.amazon.com/H110T-CSM-LGA1151-Mini-ITX-Motherboard/dp/B01EZGYSGG

[mikeselectricstuff]

It's for a chain. There are 30+ stalls per store. PCs are expensive and often unreliable. They sometimes also have terrible latency depending on whats running on them. Customs boards are much cheaper in quantity and we have a lot of experience with building robust electronics specific to this industry, user serviceable parts and supply chain.

If you have to compromise some features to fit a standard fanless box pc for this many unit, I can understand the wish for custom boards. Although, the PC's are not that expensive. For sub 500$ you have one, maybe some discount for quantity, but I guess you can't go that low.

I don't see how computers are expensive... there's boards with soldered cpu like this one for example at 60$: https://www.newegg.com/Product/Product.aspx?Item=N82E16813157730&ignorebbr=1
Add 40$ for 4gb ddr3 and a ssd and you'll only need a psu to power it.  but there's such boards with 12v or 18.5v dc in jacks
See Asus H110T for example: https://www.amazon.com/H110T-CSM-LGA1151-Mini-ITX-Motherboard/dp/B01EZGYSGG

It would be insane to use anything as complex and overpowered as a PC for something like this.