How do I work out the Ultranet protocol?

Question

Ultranet is a audio protocol that allows low latency audio with many channels to be transmitted over standard Ethernet cables. For instance you might have a Midas sound desk transmitting audio packets to a chain of personal mixers on a stage.

There is no documentation for it that I can find on the internet and I suspect that it's a Layer 1 protocol. In that it uses the hardware for Ethernet (cables and sockets etc) but not the wire format. The reason I believe this is that when I plugged my Macbook into the Ultranet output of a sound desk there was no IP and Wireshark saw exactly nothing on the wire. I tried setting a manual IP with a very wide mask but still got nothing.

I have in the past successfully decoded the Mymix protocol which is Layer 3. That just showed up as a packet stream in Wireshark... easy. Each packet had a header and a payload of 6 24bit samples.

I'm guessing the procedure starts with maybe an oscilloscope on the wires themselves? Or is there other things that I should investigate? (I have no idea how to use an oscilloscope btw... I know mostly software stuff).

Is there standard procedures for reverse engineering wire protocols?

Answer 1

Yes, it's 2xAES3-like. Data is basically PCM, 8 channels per pair. See http://www.diyaudio.com/forums/digital-line-level/261683-suggestions-please-16-channel-24-bit-digital-audio-recorder-3.html

Physical RJ45 pinout: 1: Ch 1-8 (TD+) 2: Ch 1-8 (TD-) 3: Ch 9-16 (TD+) 4: Vcc 5: Vcc 6: Ch 9-16 (TD-) 7: GND 8: GND

'Power over RJ45': Vcc is 15 volts DC (pins chosen are similar to Power over Ethernet standard). This comes from an internal switch-mode PSU and is intended to power the P16-m external monitoring boxes. It's not stated how much current each connector is specified to source (there are six output connectors on the P16-i). The P16-m's can also be powered by an external PSU, and the back panel reads "12v 300mA". So it's probably safe to say that each P16-i output socket could provide around 4 watts.

One other thing to note, is that the P16m requires some power draw on the Vcc pins, to switch on the data outputs. Some experimentation found that 5k6 resistor from Vcc to GND does NOT switch it on; whereas a 2k2 resistor DOES switch it on. So the P16m is looking for approx 7mA current draw to switch on the outputs.

Differential signal: Each P16-I output (1, 2, 3, 6) is fed via half of a 74LVC245 octal buffer transceiver device, used in output-only mode. These are producing nearly 5v peak signal, driven differentially on each pair.

The data rate on each pair is approx 12.2MHz, comprising 32 bits data x 8 channels x 48kHz sampling rate - in other words 1.5 MBytes per second. Two pairs means you have 3.0 MBytes per second of raw data.

The 32 bit 'samples' comprise 24 bits of audio + 8 bits of framing. The framing byte is usually 0x01, but occasionally is 0x09, indicating a 'multiframe'. That's essential for locking on to the correct beginning channel. Effectively the true data rate seen by the WM8804 is like "stereo 192kHz".

The 24 bits of audio are in fact 20-bit, the LS 4 bits on my unit are always zero. Other devices such as X32 might have different ADCs and therefore behave differently.

The differential signals can be received via a "MagJack" and a circuit such as this: http://tuck1s.blogspot.co.uk/2015/11/differential-line-receiver-for.html

For my purposes I wanted to stream in the audio in real-time, and write it to some permanent storage. I settled on an XMOS StartKit as being the ideal thing to play with. You can see more about them here: http://www.xmos.com/products/boards#startkit These are very low cost, available from Farnell, RS etc.

I've written some code for decoding and storing the signals onto SD card. For the sake of simplicity I'm writing just the MS 16 bits of the signals. Currently I'm streaming in WAV format and it works. I can load the recorded signals into Sonar X1 or Audacity and the audio shows up nicely.

My code's freely available on GitHub here: https://github.com/tuck1s/UltranetReceiver It's not perfect yet - there are many TODOs marked in the code.

Note a few things: - We don't have 'permission' from Behringer, they will probably tell us it is a proprietary interface. However it's pretty simple to decode with a DSO, and everything done can be done external to the box. - The SDCard code I have used drives the SD card in 4-bit mode. For commercial use you need to sign up to the SD Card Association which costs at least $1000 - The FATFS code I've used is based on published open source, originally on http://elm-chan.org/fsw_e.html and in the derived work here: https://github.com/xcore/sc_sdcard

Answer 2

Others have provided clues about this particular protocol, so I'll just address the general mechanism of decoding a protocol. You have specified "wire" but this generic method can and has been applied to protocols over fiber and RF as well.

Formulate a plan for investigation

The best start is often not mentioned, but is quite important in practice. That step is to formulate a plan. What do you want to know about the protocol? What do you intend to do with the knowledge? What you know could include, as with your case, the name of the protocol and its purpose. It might also be any clues you can glean or infer. For example, you know that it's low latency audio with multiple channels. Do you have equipment that you can control and observe, or are you just passively listening? Are there regulatory agencies or standards bodies which might have documentation on the protocol? Have you looked for patents or patent applications? Are there protocols with similar purpose that you can read about?

Investigate the signal visually

The human eye and brain are remarkably good at pattern recognition, so a useful first step is to convert the signal of interest to a visual representation. For a wired 2-wire connection, I would usually start by using a simple multimeter across the line. That gives some rough indication of what voltages might be present. That's important for both personal safety and the safety of any other equipment you might attach. In this case, since it's over Ethernet cabling, and given the purpose, it's likely to be compatible with Ethernet voltages, and possibly using Ethernet voltages +/- 2.5V. So the next step I'd use would be to attach an oscilloscope. The simplest and most typical 'scope setup is simply a graph of voltage over time. This can give a lot of insight. For instance, are there discrete voltage levels used? If so, how many (2, 4, more?)? Does the signal appear to be packetized or is it more or less continuous? What is the shortest duration between changes in the signal? More advanced 'scopes have other useful functions, such as spectrum analysis and/or FFT and time and voltage measurement.

Attempt to modify the signal in known ways

If you have equipment that you can control, try changing just one thing to see how it affects the output signal. For example, try sending a 1kHz sine wave audio signal over a single channel. Now send the same signal over 2 channels. Try changing the audio frequency. Try changing the audio amplitude. All of these can lead you to some insight about the protocol.

See if you can capture the signal in digital form

If you can faithfully digitize the signal and store it as a file in your computer, then you have many many more resources available to you for investigation. You can do the spectrum analysis on your computer. You can try out theories about modulation type, channelization, and so forth all on the computer by using off-the-shelf or your own custom software. This is the fun part for most of us!

Test your theory

If you think you have figured out the protocol and if you have either equipment you can control or at least more samples you can observe, then test your theory with that data. See if your computer implementation of the protocol matches what you observe. Ideally, you'd also be able to build your own interface and pretend to be one end or the other of the protocol. In the case of audio gear, you're not likely to hurt anything if you're not quite correct. Other realms (such as vehicle engine controls) may very well require much more caution. See if you can test corner cases and error conditions.

Share your results

If you can, and if it's responsible to do so, consider sharing your results. Chances are that somebody out there somewhere also has the same interest. By sharing notes, you'll both make more progress than if either works in isolation. Many's the time that I've had great luck finding even a half-baked partial implementation on github or sourceforge or the like, saving me a ton of time. I try to share what I've found, too, in the same spirit.

Good luck, and have fun!