Electronics > Projects, Designs, and Technical Stuff
Digital audio protocol for 100M copper
<< < (7/14) > >>
Marco:

--- Quote from: mc73 on December 10, 2018, 06:14:15 pm ---There are long runs of conduit with multiple wires.

--- End quote ---

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.


--- Quote from: mc73 on December 10, 2018, 06:54:26 pm ---We'd prefer not to use the full ethernet stack.

--- End quote ---

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:

--- Quote from: mc73 on December 11, 2018, 05:37:07 pm ---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.
--- End quote ---
  Is that your target BOM cost, or CM price?  As a BOM it's not bad, as a CM price. . . :scared:


--- Quote ---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.
--- End quote ---
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.


--- Quote ---Seems like a lightweight ethernet protocol might be a good option. Anyone have any suggestions for an existing protocol or encoding for this scenario?
--- End quote ---
  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:

--- Quote from: mariush on December 11, 2018, 11:31:00 am ---[..]
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

--- End quote ---
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:

--- Quote from: mc73 on December 11, 2018, 05:37:07 pm ---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.

--- End quote ---
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.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod