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?

  • 3
    Might be 2x AES3 data streams over Cat5 cable?
    – fret
    Sep 14, 2015 at 6:27
  • It doesn't have to be IP to be able to be captured with wireshark; when Novell Netware still existed, wireshark's predecessor ethereal captured IPX packets just fine. So yes, this might be something that's different from Ethernet even on Layer 1. Did you try plugging the Midas sound desk into a standard network hub (not switch), and plug a mixer into a different port on the hub? This should be transparent on Layer 2, but not on Layer 1, so if it works, Layer 1 is standard, but if it doesn't, then yes, it's a non-Ethernet-Layer 1 protocol, and you'll need a logic analyzer to investigate. Sep 14, 2015 at 6:37
  • No I haven't tried putting a hub between the mixer and the personal monitor. Something to try next time I'm at the auditorium. The link I found seems to indicate that the protocol is definitely Layer 1, and I'll be reading up on the WM8804 S/PDIF TOSLINK board that seems to work with the personal monitor. There is a pin out on that forum I linked...
    – fret
    Sep 14, 2015 at 7:03
  • It's an analog signal. If someone wants to put in the time to create a digital bridge, great. But it hardly seems like it is worth the time considering that the vendor could change it whenever. Maybe demand should drive the vendor to provide an Ethernet/WiFi bridge? I'd buy it. Sep 19, 2021 at 6:53

2 Answers 2


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


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!

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.