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.

[LapTop006]

Balanced line (transformer coupled) AES3 will work

Yep, if you weren't going with Ethernet I'd go with that. Also works fine over coax. Except for a few bit flips that almost nothing cares about it's the same thing as S/PDIF, but worth knowing that the pro audio world often just call them "AES" inputs or "AES/EBU"

[dmills]

If I were doing this I would want CAT5 cables (it is all kinds of cheap to get installed and terminated) and POE so the end devices do not need separate power. I would also be looking HARD for cots gear, there is little here that needs reinventing. Do not underestimate the wiring costs, I would expect the cabling to come in at the same order of cost as the end box.

Audinate for example have the Dante Ultimo chipset that IME just works and gives you access to a huge range of Dante audio boxes that do all kinds of interesting things, I would bet there is an Dante intercom controller you can just buy.

Dante feels heavyweight, but I think the flexibility it gets you is probably worth it. For example, hook a PC up to the network and run a $30 virtual sound card and the supervisor can now record the interactions with customers, useful for dealing with complaints...

You could go AES3 over two pairs and it would probably be fine, but then you are having to build a custom central control box which is a bit of a pain, and is a nasty single point of failure, with AES67 or Dante you just use an off the shelf POE switch as the central controller and that is available from any computer bits place.

There are two key things about this sort of project, reliability and usability, think hard about the environment the control positions are used in, heavy duty membrane keyboards and sealed boxes might turn out to be a very good thing for surviving the deep cleaning crew.

Regards, Dan.

[NiHaoMike]

If there's going to be a dedicated line to each stall, keep it simple and have the stall unit be just a passive speaker and a microphone with bias powered preamp. The central unit will have all the signal processing circuits. Keep the signal voltages high and there will be little interference.

[LapTop006]

Audinate for example have the Dante Ultimo chipset

Random fact, that chipset is named for the suburb of Sydney their office is in, just a few blocks from my apartment, has a cafe downstairs that does a lovely Korean-style steak sandwich.

[nctnico]

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

The problem is not in the hardware but in the software to run it. For that you'll suddenly need IT maintenance people in an organisation which likely doesn't have any.

[Marco]

There are long runs of conduit with multiple wires.

What kind of wires? Just a single wire per booth with shared ground, or some phone wire to each booth? Because if it's phone wire, just reuse it with differential signalling. If it's point to point, your hardware will always be connected to the wire, so it will always be correctly terminated.

Not having to rewire saves a ton of money and as ADSL has proven, you can stretch the performance of existing copper a lot.

We'd prefer not to use the full ethernet stack.

It's a connectionless protocol. Your software might fail, but if it's going to fail it's not going to be because you used ethernet. Some unmanaged switch is highly unlikely to be a common point of failure either, but you can actually buy them cheaply unlike for any alternative wire protocol

[mc73]

Thanks everyone for the input. Here some answers to many of the questions that have been asked.


My budget per stall is probably $40 max,  (30 stalls per store) and $300 per inside unit (2-3 inside units). These are per 500-1000 piece orders.

No PCs or IT infrastructure that requires maintenance. The most we'll get is a power reset. No 6 min reboots either....max 10s.

We have independent wiring per stall to a central punchblock. The stall is selected by the user on the inside unit, typically on a membrane keypad.

We usually work with ATSAMD21s, ATSAMD51s and Wiznet 5500 for our monitoring and control systems.

We've been trying to find an on chip hardware controlled protocol so we're just dealing with signals and not software encoding. Seems like RS-485 might be a bit too delicate for our purpose though.

Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?

-Thanks again.

[ajb]

My budget per stall is probably $40 max,  (30 stalls per store) and $300 per inside unit (2-3 inside units). These are per 500-1000 piece orders.

  Is that your target BOM cost, or CM price?  As a BOM it's not bad, as a CM price. . .

We've been trying to find an on chip hardware controlled protocol so we're just dealing with signals and not software encoding.
Seems like RS-485 might be a bit too delicate for our purpose though.

Hardly!  It's used in industrial environments all the time, and while it takes some care to design (including protection) and install, it's not particularly fragile.  As with any physical link, it's prudent to include some sort of error detection at the protocol level.

Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?

  If you're using a dedicated network, the protocol hardly matters, and for voice your probably don't even need to worry about compression.  Ethernet gives you a frame check sequence that you can rely on for error detection, so at that point you can simply stuff audio samples into a datagram with a rudimentary header (something to identify it as an audio packet, and a sequence number) and kick it onto the network.  The stalls just have to listen for datagrams addressed to them and maybe make sure the sequence number is larger than the last one they received and shove the data out to their audio DACs.

You can use other simple datagram structures for whatever control get/set commands you need for lights and buttons and whatever.

One thing to keep in mind is you need a way to identify the stall on the network.  Since you have a limited number of nodes on the network, the simplest solution might be to have some DIP switches to set the last octet of the IP address to the stall number.  Unicasting the outgoing packets to the particular node that needs them will reduce the network processing overhead for the stall nodes. 

[Jeroen3]

[..]
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 foolish to use consumer motherboards to build something like this. That's how you get unreliable.
I meant something like this, a low power small pc that mounts on your DIN rail. https://www.logicsupply.com/cl210g-10/ (still requires heated cabinet though)

But one very important number has not been given. How long do they have to last. If you deploy pc's windows Windows 10 LTSB now, it ends support in 2026, that is only 8 years from now. I can imagine this is not long enough.

[nctnico]

Thanks everyone for the input. Here some answers to many of the questions that have been asked.


My budget per stall is probably $40 max,  (30 stalls per store) and $300 per inside unit (2-3 inside units). These are per 500-1000 piece orders.

No PCs or IT infrastructure that requires maintenance. The most we'll get is a power reset. No 6 min reboots either....max 10s.

We have independent wiring per stall to a central punchblock. The stall is selected by the user on the inside unit, typically on a membrane keypad.

We usually work with ATSAMD21s, ATSAMD51s and Wiznet 5500 for our monitoring and control systems.

We've been trying to find an on chip hardware controlled protocol so we're just dealing with signals and not software encoding. Seems like RS-485 might be a bit too delicate for our purpose though.

RS485 is fine. The resilience depends on the chip, speed and external overvoltage protection you add. An RS485 driver can be used with a transformer too and if the bitrates aren't too high then any cheap ethernet transformer or telecom transformer will do. Unfortunately ISDN and many other analog telephone chips which where real gems for these kind of systems are obsolete so I think you have to roll your own. But it doesn't have to be complicated. A small CPLD capable of detecting a pre-amble, shift in 16 bits (8 bit ulaw/alaw audio, 8 bit digital I/O) and do a CRC check and a codec chip is all you need.

[Bassman59]

 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.

Look into Dante (http://www.audinate.com/) or AVB, both do multichannel digital audio over standard Ethernet.

[ogden]

RS485 is fine. The resilience depends on the chip, speed and external overvoltage protection you add. An RS485 driver can be used with a transformer too and if the bitrates aren't too high then any cheap ethernet transformer or telecom transformer will do. Unfortunately ISDN and many other analog telephone chips which where real gems for these kind of systems are obsolete so I think you have to roll your own. But it doesn't have to be complicated. A small CPLD capable of detecting a pre-amble, shift in 16 bits (8 bit ulaw/alaw audio, 8 bit digital I/O) and do a CRC check and a codec chip is all you need.

No need to invent anything new here. Perfect match is AES/EBU balanced digital audio interface. Low cost version would be S/PDIF over twisted pair. I would use S/PDIF peripheral SPDIFRX of STM32F4/F7/H7 Series microcontroller with RS422 transceivers. Further info: ST application note AN5073

[ejeffrey]

Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?

If you are going to use a microcontroller for the customer endpoint, you will want something pretty simple.  Luckily you don't need much.  You are on a dedicate LAN so it will be almost impossible to screw up.  Since you are using voice, uncompressed mono 16 kHz audio is more than enough.  You can even use an 8-bit ulaw encoding to cut the data rate further.  A network can transmit uncompressed CD audio no problem, but using the lower bitrate reduces the burden on the processors at both ends.  I think the easiest thing here is to use a simple custom UDP datagram protocol like ajb suggested.  This would not really be adequate for transmitting over the public internet, but perfectly fine on a isolated LAN.

[mikeselectricstuff]

Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?

If you are going to use a microcontroller for the customer endpoint, you will want something pretty simple.  Luckily you don't need much.  You are on a dedicate LAN so it will be almost impossible to screw up.  Since you are using voice, uncompressed mono 16 kHz audio is more than enough.  You can even use an 8-bit ulaw encoding to cut the data rate further.  A network can transmit uncompressed CD audio no problem, but using the lower bitrate reduces the burden on the processors at both ends.  I think the easiest thing here is to use a simple custom UDP datagram protocol like ajb suggested.  This would not really be adequate for transmitting over the public internet, but perfectly fine on a isolated LAN.

Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses. 

[ejeffrey]

Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?

If you are going to use a microcontroller for the customer endpoint, you will want something pretty simple.  Luckily you don't need much.  You are on a dedicate LAN so it will be almost impossible to screw up.  Since you are using voice, uncompressed mono 16 kHz audio is more than enough.  You can even use an 8-bit ulaw encoding to cut the data rate further.  A network can transmit uncompressed CD audio no problem, but using the lower bitrate reduces the burden on the processors at both ends.  I think the easiest thing here is to use a simple custom UDP datagram protocol like ajb suggested.  This would not really be adequate for transmitting over the public internet, but perfectly fine on a isolated LAN.

Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses.

I would go with UDP.  The extra overhead is basically nothing -- 8 bytes per packet on top of the 20 byte IP header and 18-24 byte ethernet frame fields, and it gets you a fair bit of extra flexibility.  You can separate IP from MAC address -- IP addresses can be assigned by stall irrespective of the hardware.  You can use the port number to distinguish between e.g., audio stream vs. control commands.  If you have to end up going through a router you can although that opens up the possibility of more latency and dropped packets.  Possibly most importantly, the operator side is presumably going to be a general purpose PC running a full OS.  By using UDP you can use simple socket commands rather than raw sockets and libpcap.

Presumably you are going to use an off the shelf network stack, so you get all that stuff "for free", rather than having to implement your own addressing protocol.

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.  The only reason I don't recommend that is that the kind of dumb microcontroller you probably want to use for this application doesn't really have enough RAM to implement a good TCP stack.  I would rather use UDP than a crappy TCP stack.

[mikeselectricstuff]

Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?

If you are going to use a microcontroller for the customer endpoint, you will want something pretty simple.  Luckily you don't need much.  You are on a dedicate LAN so it will be almost impossible to screw up.  Since you are using voice, uncompressed mono 16 kHz audio is more than enough.  You can even use an 8-bit ulaw encoding to cut the data rate further.  A network can transmit uncompressed CD audio no problem, but using the lower bitrate reduces the burden on the processors at both ends.  I think the easiest thing here is to use a simple custom UDP datagram protocol like ajb suggested.  This would not really be adequate for transmitting over the public internet, but perfectly fine on a isolated LAN.

Even UDP may be overkill as you're sending unnecessary data - raw frames with an ARP-like scheme to determine the MAC addresses.

I would go with UDP.  The extra overhead is basically nothing -- 8 bytes per packet on top of the 20 byte IP header and 18-24 byte ethernet frame fields, and it gets you a fair bit of extra flexibility.  You can separate IP from MAC address -- IP addresses can be assigned by stall irrespective of the hardware.  You can use the port number to distinguish between e.g., audio stream vs. control commands.  If you have to end up going through a router you can although that opens up the possibility of more latency and dropped packets.  Possibly most importantly, the operator side is presumably going to be a general purpose PC running a full OS.  By using UDP you can use simple socket commands rather than raw sockets and libpcap.

Presumably you are going to use an off the shelf network stack, so you get all that stuff "for free", rather than having to implement your own addressing protocol.

But if you don't need PC interoperability, by using raw frames you don't need a network stack at all, so no learning curve and unnecessary features (and bugs) you won't use.  Could be an issue if implementing on a resource-limited MCU.
ARP-like functionality to map logical addresses to MACs, ports etc. would be very easy to implement.

[jbb]

I too would start by considering an Ethernet solution using, e.g. uncompressed audio over UDP. Latency should be some milliseconds.

Given that it may well be possible to manage all the audio uncompressed with reasonable bandwidth, I suggest avoiding the complexity of audio compression for now.

Using an ARM Cortex something with a small RTOS will improve consistency versus a ‘desktop’ OS like a standard Linux distribution and should also be a lot tougher with respect to temperature and power supply glitches (which tend to mess up file systems and brick computers).

Ethernet delivers a second benefit in that it happily lets you send packets to specific addresses, which will help with routing booths to staff.

To maintain predictable performance, use a dedicated high quality Ethernet switch for the backbone. Keep it separate from the general IT infrastructure in the building to
- maintain consistent performance (ie audio doesn’t get laggy because the manager is streaming a training video from Corporate)
- segregate networks for security (the attackers carried out the big Target hack a few years ago via the air conditioning equipment)

At this point I would like to flag a privacy concern. Is it an issue if the booths have live mics at all times? For a drive-through that would be expected. For a sit-down restaurant it would be a problem. Is it appropriate to include some kind of live mic warning indicator?

[Twoflower]

Because you can use lots of the shelf HW I would also consider Audio over Ethernet. And I would see that most of the protocol is along some standards as well. Even if you waste some bandwidth or CPU power. The debugging will be much easier if you can hook up a PC with standard tools. One additional point is the insulation of Ethernet. With 100m cable there's a good chance that you can create a nice ground-loop that could ruin your day. I would think to use a industrial kind of connectors and not the normal Ethernet one, just to reduce the risk that some genius connect that system to the intra-/Internet.

If the $40 is per Stall I would say that will be very challenging. Consider that you need a PSU, speaker, microphone, amplifier, some kind of processing, housing (potential custom made; at least holes for the connectors/cables), connectors, full PCB production plus putting the things together. Any that probably weather-prove, vandalism-prove and reliable. Not impossible but you should check if you can met that price-point.

[mikeselectricstuff]

Another approach to addressing is have the MAC addresses set by DIP switches on the units to code the location. A big advantage of DIP switches is that replacement for maintainance is easy - just set switches same on the replacement unit, no configuration, programming etc. 

[nctnico]

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

No. TCP is unsuitable for streaming because it does resend and so on. Every streaming solution uses UDP. When a packet is lost, the content of the previous packet is replayed. By the time TCP does a resend the contents of the packet is meaningless.

[nctnico]

RS485 is fine. The resilience depends on the chip, speed and external overvoltage protection you add. An RS485 driver can be used with a transformer too and if the bitrates aren't too high then any cheap ethernet transformer or telecom transformer will do. Unfortunately ISDN and many other analog telephone chips which where real gems for these kind of systems are obsolete so I think you have to roll your own. But it doesn't have to be complicated. A small CPLD capable of detecting a pre-amble, shift in 16 bits (8 bit ulaw/alaw audio, 8 bit digital I/O) and do a CRC check and a codec chip is all you need.

No need to invent anything new here. Perfect match is AES/EBU balanced digital audio interface. Low cost version would be S/PDIF over twisted pair. I would use S/PDIF peripheral SPDIFRX of STM32F4/F7/H7 Series microcontroller with RS422 transceivers. Further info: ST application note AN5073

But is there room for digital I/O in such a stream? If yes, then it would be a good solution for the OP's system indeed.

[nfmax]

This application sounds almost like a network of Door Entry phones. Loud speaking, weather-resistant VoIP entry phones are commercially available - would it be possible to base a solution on their use? Then your CAT5 would be running plain old TCP/IP over Ethernet. Plenty of bandwidth for audio with enough left over for control. You could even put a tablet display at each outstation if you really want, running a browser in kiosk mode. Upsell!

[T3sl4co1l]

The other robust option would be any industrial network: CAN, LIN, Modbus, Profibus, etc. (several of which are a protocol layer that runs on any physical layer, or can tunnel through another..).

CAN is a multidrop network, which would be nice, but it would have to run damn fast (way faster than practical) to serve even a few boxes at once.  And they're not described as chained (though that might make installation easier, if changing the topology is an option?), so that's no help.

RS-485 is quite robust, but you may need to provide isolation, and that drives up the cost.

Ethernet would then be the cheapest isolated option, and again, you can use it on a pretty low level, no PC needed -- it may not be as well supported at this level in terms of available tools to work with it (e.g., if you aren't using IP, then you aren't going to get anything into a PC expecting an IP address..), but that's really not much different from RS-485 where you're building your own protocol and stack completely from scratch!

And as Mike's shown, low level Ethernet is quite accessible.

Tim

[tooki]

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

No. TCP is unsuitable for streaming because it does resend and so on. Every streaming solution uses UDP. When a packet is lost, the content of the previous packet is replayed. By the time TCP does a resend the contents of the packet is meaningless.

Over the internet perhaps. On a wired LAN that isn’t suffering from horrific packet loss, this retransmission happens in milliseconds, more than good enough for audio. (Uncompressed stereo CD-quality audio is about 1.5Mbps, a tiny, tiny fraction of a modern gigabit LAN or even of now-basic 100Mbps Ethernet.)

Granted, there’s no significant downside to using UDP for this application on a LAN, either. But just saying that calling TCP “unsuitable for streaming” in a wholesale fashion just isn’t true.

Heck, I occasionally do wildly inefficient TCP-based video streaming on my LAN (even WiFi!) when playing video files over file sharing (SMB). A mounted file system has tons of overhead and zero tolerance for lost packets. It works totally fine. (Over the Internet would be a different matter.)

[nctnico]

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

No. TCP is unsuitable for streaming because it does resend and so on. Every streaming solution uses UDP. When a packet is lost, the content of the previous packet is replayed. By the time TCP does a resend the contents of the packet is meaningless.

Over the internet perhaps. On a wired LAN that isn’t suffering from horrific packet loss, this retransmission happens in milliseconds, more than good enough for audio. (Uncompressed stereo CD-quality audio is about 1.5Mbps, a tiny, tiny fraction of a modern gigabit LAN or even of now-basic 100Mbps Ethernet.)

Granted, there’s no significant downside to using UDP for this application on a LAN, either. But just saying that calling TCP “unsuitable for streaming” in a wholesale fashion just isn’t true.

Heck, I occasionally do wildly inefficient TCP-based video streaming on my LAN (even WiFi!) when playing video files over file sharing (SMB). A mounted file system has tons of overhead and zero tolerance for lost packets. It works totally fine. (Over the Internet would be a different matter.)

But that is not realtime streaming which is what this topic is about! Look at home much buffering goes on under the hood. Your video player is likely buffering several seconds of data to make sure it doesn't run out. Streaming video and audio realtime is a completely different ballgame. Add a couple of seconds of delay to a conversation and see how that pans out. Also if there is acoustic echo cancellation involved it helps to have as little delay as possible because then the echo canceller can also kill (or mask) the far-end echoes.

[ejeffrey]

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

No. TCP is unsuitable for streaming because it does resend and so on. Every streaming solution uses UDP. When a packet is lost, the content of the previous packet is replayed. By the time TCP does a resend the contents of the packet is meaningless.

Basically on a dedicated LAN, packet loss will be zero or next to it and in the rare case the retransmit latency is so low that it won't be an issue (this is a drivethrough order system, not a real time game).  A 50 millisecond audio buffer is irrelevant and is dozens of round-trip-times.  In this application UDP vs. TCP won't matter.  On a bigger network you are right, but then a simple raw UDP solution isn't great either, and you want to look at one of the well designed streaming protocols.

[tooki]

But that is not realtime streaming which is what this topic is about! Look at home much buffering goes on under the hood. Your video player is likely buffering several seconds of data to make sure it doesn't run out. Streaming video and audio realtime is a completely different ballgame. Add a couple of seconds of delay to a conversation and see how that pans out. Also if there is acoustic echo cancellation involved it helps to have as little delay as possible because then the echo canceller can also kill (or mask) the far-end echoes.

As ejeffrey agreed, it just doesn’t matter in this application. Whether 100 or 1000 Mbps, on a dedicated LAN like proposed here, packet loss just isn’t an issue.

To repeat: I’m not saying that TCP is necessarily superior here, just that it’s not categorically unusable as you seem to think. The bandwidth of a modern Ethernet LAN is so enormous compared to the data stream in question, and latency and packet loss so low, that it’d work fine.

[Jeroen3]

When you're using TCP, you still need the buffer to keep un-acked packets. If bitrate is high, this buffer is large. For UDP you do not need this buffer.
Another advantage of ethernet is that it is indeed rather simple to run a browser over it, as mentioned earlier.
And, if the customer asks "can you also install a camera?", then you can. Since there is plenty of bandwidth.

[Marco]

For a point to point connection it just doesn't make sense, there is no congestion, there are unlikely to be really spikey packetloss.

Just do some ad-hoc half duplex protocol with forward error correction over the existing wires with RS485.

[nick_d]

I was surprised to have to read to reply #47 before T3sl4co1l suggested CAN bus. I have been working on a CAN bus system for a client throughout this year, and it has been quite robust and reliable.

For this application I think 250 kbps (first version CAN) would be fine. It is necessary to check what the official maximum wire length is at 250 kbps, one source that I have says 87m and another says 250m.

I understand that the requirement is for isolation, there are isolated CAN transceivers available. It would be necessary to check the wire length separately for the isolated transceiver. I could look into these issues further if asked.

Anyway, the most compelling reason to use CAN instead of Ethernet is because CAN is real-time and Ethernet is not. Of course the non real-time medium can still be used, by arbitrarily picking a latency and providing that much delay and buffering to avoid artifacts from packets arriving earlier than the worst case scenario. But why do so? You're adding enormous complexity in order to get a substandard result.

With CAN you know that audio packets will take priority over other (control) traffic so you know exactly how long they will take to arrive. It would be prudent to provide one or two frames' worth of buffering just in case, however the frame size of CAN is deliberately set to just 8 bytes (with about 2 bytes overhead for address, check bit, stuff bits, etc). So at say 16 kHz x 12 bit samples the latency is about 16 samples or 1ms. There is no way that Ethernet could match that.

RS485 might, but I don't see a compelling reason to use RS485 over CAN bus given that CAN basically starts with capabilities similar to RS485 and adds additional robustness (such as higher tolerance to clock rate error, etc) and a higher layer protocol (address field, check bit, flags/stuffing etc) that you'd have to do yourself in software with RS485.

One good thing that can be said about RS485 is that it drives the bus high for 1 and low for 0, allowing faster speeds in general than CAN bus which uses a (slower) pull-up resistor for 1 and only drives low for 0. On the other hand, the CAN bus way greatly simplifies media access and collision management, which adds significant software complexity in RS485 and requires bus grant schemes etc that hurt real-time performance. Hence, I would go with CAN bus here.

One thing that can be quite tricky with digital audio distribution is sample rate error that builds up over time. Say you have an ADC and DAC at each end each running off a locally generated 16 kHz sample clock, then if the DAC at one end is slightly faster than the ADC at the other end, the data transfer will underrun and filler samples might have to be generated, if the DAC is slower then the data transfer will overrun and samples might have to be dropped.

There are many ways to deal with this, some of those ways require a timebase to be sent over the medium, and this is something that CAN bus does brilliantly. Our application has a number of radio transmitters on the CAN bus whose transmissions must be tightly timed l, and we are using a higher level protocol called UAVCAN on top of the basic CAN addressing and medium access protocol. UAVCAN has a time server built in that works really well, using the hardware to timestamp the sending and receiving of CAN frames.

If only audio is to be sent over a dedicated connection of at least 3 wires (or 4 including power), then a small and cheap microcontroller will do it. The STM32F4's have pretty good number crunching ability if you want to do compression, but the CAN controller has some frustrating errata that wasted a lot of my time. 8051 derivatives with CAN can be had for next to nothing but may require external ADC/DAC if quality is a concern. There may be a middle course... NXP? Or you mentioned specific chips, so if using those you could add an external CAN chip. I have a USBtin that uses an MCP2515 plus MCP2551 transceiver, these are cheap and common.

cheers, Nick

[TomS_]

I would go with UDP.  The extra overhead is basically nothing

But its still additional overhead to process and doesnt actually add anything except more complexity by having to then implement an IP stack.

Ethernet still allows you to address end points directly, you then just need (as suggested by someone else) a very basic control protocol that provides advertisement/discovery and other functionality as needed.

[mikeselectricstuff]

I would go with UDP.  The extra overhead is basically nothing

But its still additional overhead to process and doesnt actually add anything except more complexity by having to then implement an IP stack.

Ethernet still allows you to address end points directly, you then just need (as suggested by someone else) a very basic control protocol that provides advertisement/discovery and other functionality as needed.

And don't forget that you do not need to use globally unique MACs if it's point to point you could just use 1 and 2 (and not need a switch)
If devices have IDs of some sort then the MAC addresses can just be set to these IDs rather than having an additional layer of logical-to - physical address translation  (ARP).

[mariush]

Do you really need super low latencies for this particular application?

I mean, you're talking about stalls in restaurants, where most likely people push to talk or unmute, listed to a person, think for a bit, answer , maybe they ask to repeat if it's too noisy inside... i would think even 50-100ms of latency between person talking and being heard at the other end wouldn't be an issue.

Don't get it why you'd restrict yourself to CAN or RS485 when you could just use ethernet and leave yourself room for future stuff... maybe suggest upgrading the boxes in the future to have a small display that displays some ads/banners/products on sale or maybe some eInk screen to show the menu along with a couple of buttons or touch sensitive screen..

You could implement something like push update to everything by using udp, or just have a basic http server or tftp  ...with udp you could  just repeat broadcasting a package of data for 20-30 minutes and for sure even if a frame is lost, every stall machine eventually picks up the frames a second time or third time and builds up the update package eventually.

With ethernet you'd just put a 48 port switch on a half-rack and you're done. You can get 48 port 100mbps switches for around 100$ new ...
I'd think you'd have to custom make some box in which to terminate the cables and maybe have custom connectors when you could get patch cables or plain cat5e ethernet cable in 305 meter or higher spools. 

And... you could get a switch with power over ethernet on all ports to power the device at the stalls or just abuse everything and send 24v DC through unused wires in the cable ... or you could split ethernet cable on 2 x 4 pairs and handle 2 stalls at a time with one cable.

And you have cheap ARM micros with built in ethernet...

[T3sl4co1l]

To the OP:

You get what you pay for.  As free advice goes, this thread is one hell of a deal, I must say!

There do seem to be a lot of IT/network fetishists on here, but that's not really surprising.  It takes a lot of them to keep those networks running.

Tim

[nctnico]

Honestly, TCP would even be fine in this application -- the latency added will be negligible in a LAN environment.

No. TCP is unsuitable for streaming because it does resend and so on. Every streaming solution uses UDP. When a packet is lost, the content of the previous packet is replayed. By the time TCP does a resend the contents of the packet is meaningless.

Basically on a dedicated LAN, packet loss will be zero or next to it and in the rare case the retransmit latency is so low that it won't be an issue (this is a drivethrough order system, not a real time game).  A 50 millisecond audio buffer is irrelevant and is dozens of round-trip-times.  In this application UDP vs. TCP won't matter.  On a bigger network you are right, but then a simple raw UDP solution isn't great either, and you want to look at one of the well designed streaming protocols.

As you wrote the packet loss will never be zero and then you end up waiting for (exponentially increasing) TCP re-transmit timers which will make the audio pause / stutter every now and then. Using TCP for any realtime streaming application is asking for 'bugs' in installations which are impossible to reproduce and solve but it will have a negative impact on the overall quality of the system as seen by the customer. And trust me: the customer really doesn't care that in a small network there shouldn't be any packet loss. They just want the streaming to work flawless. All in all I really don't understand why people keep insisting TCP is useable for realtime streaming. It clearly isn't even though you can make it work in theory.

But then again: for the application of the OP using ethernet may be overkill although components (like a phy or a transformer) typically used for an ethernet network may be useful to keep the solution cheap. There are a lot of ways to make clever combinations but ultimately the best solution also depends on the skill & knowledge available at the company the OP is working at. The solution has to fit their processes and budget.

[ogden]

All in all I really don't understand why people keep insisting TCP is useable for realtime streaming. It clearly isn't even though you can make it work in theory.

Problem in their heads is packet loss which is seemingly solved by TCP retransmits. People who suggest to use TCP for realtime VOICE(!!) application are clueless and need to improve their knowledge about video/audio transport ALOT. RTP protocol which mostly runs over UDP is widely used in streaming and voip systems. Packetloss solution in RTP audio systems is plain simple - if packed did not arrive in time just play contents of previous one, obviously using crossfade to avoid click. Rarely anybody will notice.

[dmills]

RTP over UDP is used for BROADCAST PRODUCTION VIDEO at 10, 25, 40 and 100Gb/s in ST2110 and friends, it is a complete non issue for telephony grade audio.

We are not doing old school thinnet these days, modern ethernet is NOT CSMA-CD any more.

Regards, Dan.

[Marco]

I was surprised to have to read to reply #47 before T3sl4co1l suggested CAN bus. I have been working on a CAN bus system for a client throughout this year, and it has been quite robust and reliable.

Galvanic isolation for a CAN bus will cost you more than for RS-485 though (always nice to have an extra safety layer between a wiring mishap and customers). Also they have existing point to point wiring, so they don't really need a bus protocol.

Given the requirements that they just want to replicate the analogue system as much as possible and don't really care to add bells and whistles like recording and multiple listeners, I'd just keep it mostly ad-hoc. RS-485 has nice signalling levels, half duplex drivers are relatively cheap and it's protocol agnostic ... good fit.

[Jeroen3]

Problem in their heads is packet loss which is seemingly solved by TCP retransmits. People who suggest to use TCP for realtime VOICE(!!) application are clueless and need to improve their knowledge about video/audio transport ALOT. RTP protocol which mostly runs over UDP is widely used in streaming and voip systems. Packetloss solution in RTP audio systems is plain simple - if packed did not arrive in time just play contents of previous one, obviously using crossfade to avoid click. Rarely anybody will notice.

TCP is a stream, all bytes arrive in FIFO order. Any packet loss halts the entire stream. With millisecond interruptions.
That is horrible. You'd have to configure TCP beyond spec with tiny timeouts. Possibly inhibiting the stacks capability to communicate on the actual internet.
It's like using a lithium battery rpm controlled cordless drill as a hammer. Why wouldn't you just use a hammer???

[nick_d]

 

Galvanic isolation for a CAN bus will cost you more than for RS-485 though (always nice to have an extra safety layer between a wiring mishap and customers). Also they have existing point to point wiring, so they don't really need a bus protocol.

Yes, after I wrote the previous manifesto this occurred to me too. Actually, it depends on how many wires they have. If there are only 2 then RS485 may well be the go. If they have 3 then RS232 might be an option, not quite sure how the isolation would be done but similarly to RS485. If they have 4 wires then something like a current-loop in each direction would work. I recall that this used to be popular for things like keyboard connections to industrial PCs back in the day, although I wasn't up on the details. I envisage something like MIDI's physical layer, where basically the LED of a fast opto-isolator is driven remotely through a dedicated wire pair.

Given the requirements that they just want to replicate the analogue system as much as possible and don't really care to add bells and whistles like recording and multiple listeners, I'd just keep it mostly ad-hoc. RS-485 has nice signalling levels, half duplex drivers are relatively cheap and it's protocol agnostic ... good fit.

Quite. I have realized that the 5V swing of CAN bus is not good for long distances even though it is differential. Also, in my previous proposal I forgot to mention that I envisaged a use for the multidrop bus to carry multiple connections to a small cluster of booths where necessary to deal with issues like broken or failed wiring, but I realize now that this would be (a) way more complex, (b) too ad-hoc and (c) limited by data rate. If you wanted a bus, then I think the Ethernet proposals are better. Recently my apartment was refitted with video entryphones running over PoE and they're good, as another poster suggested (I think slightly over budget for the OP, possibly cheaper after development costs though).

cheers, Nick

[amlu]

you can get a working solution off the shelf, budget one would  be something like that:
https://www.bhphotovideo.com/c/product/969887-REG/behringer_x_32_rack_x32_16_midas_preamps_ipad_control.html
plus a digital audio snake to go with it...
its the lowest end but anyway used in pro audio/events and apparently does the job.

[dnwheeler]

Many of the solutions being proposed assume that there is some need to aggregate multiple signals on a single wire. As I understand the OP, there will be separate point-to-point connections for each stall. There won't be collisions and there's no need for addressing or high bandwidth.

As others have mentioned, running two separate AES3 lines (one for each direction) to each stall should be fairly easy and cheap. Then on the "station" end, a simple selector to pick which lines to connect to (with enough software to synchronize to the start of a frame - there might be an AES3 decoder chip that do this). AES3 also has a low-speed user data channel for additional data if desired.

[soldar]

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.

Hmmmm... It seems to me this should be quite simple and digital encoding is probably not needed. Plain Old Telephone wires run much longer bundled together. I would not discard analog because I think it would work and is simpler and cheaper.

OTOH, if the microphone can receive the speaker then you will have feedback problems. If the speaker is a headphone which cannot be picked up by the microphone then this is not a problem.

Having to deal with feedback and echo cancellation complicates matters considerably.