Please investigate whether it is possible to send/receive arbitrary Ethernet frames over the AUX interface

[butrus]

In the AES50 the auxiliary channel is being described as Ethernet interface.

However Behringer/Midas apparently use this to send MIDI messages (the protocol for controling the stageboxes is well documented in the appropriate user manual of Behringer SD8 / S(D)16 stageboxes etc. I suspect that the protocol to connect two X32 or WING consoles together also goes through MIDI with some sort of SysEx messages...)

Please, investigate, whether it is possible to send arbitrary Ethernet packets such as the TCP/IP in parallel to Behringer's MIDI control messages.

That would open up some very fancy possibilities such as connecting to an OpenX32 enabled X32 mixing console through the AES50 link (e.g. form a second X32) using the ssh protocol.

Or tunneling DMX512 over AES50 using the standard ArtNET protocol.

[YetAnotherElectronicsChannel]

Hi butrus,

you can send any arbitrary data over the Aux Interface as of today. I just implemented a UART front-end as I believe that this is the way how it's also done on X32/Wing etc...

There is currently a configurable timeout implemented (see top-level UART-timeout parameter).
You basically prefill the internal FIFO and as soon as the timeout has passed, the data is going to be send as a full frame.
It would be possible to tunnel ethernet-frames this way with e.g. a ethernet-capable microcontroller or similar translating it to UART or you implement your own front-end.
Anyhow from what I saw, it seems there is a proprietary protocol not using ethernet-frames. Also, it seems there was a timeout-style framing implemented. (e.g. when actively turning the gain-knob on a Wing you see that it sends the control data exactly in 100ms windows).

Anyhow - the original SuperMac implementation (before it was acquired by Klark/Midas etc.) had obviously a direct RMII capable AUX-Interface to really use it as "Ethernet-Tunnel"... See here a photo of an old presentation from Sony-Oxford.

Please be aware that the aux-uart-functionality is very experimental and is still doing bit-errors (you also see distorted text-strings on the UART printout in the ReadMe). Christian Nöding from the Open-X32 project is investigating this at the moment more in detail.

[butrus]

Please be aware that the aux-uart-functionality is very experimental and is still doing bit-errors (you also see distorted text-strings on the UART printout in the ReadMe). Christian Nöding from the Open-X32 project is investigating this at the moment more in detail.

OK, that's an important information.

I have looked at the screenshot you provided an if there is indeed some sort of bit-rotting there a possibility still remains that these are in fact MIDI messages, padded with ZERO.

For example the very first message looks like it is 0xC0 0x17[=ETB] 0x00 which would be a valid MIDI.

The problem is that the first byte of a message seems to change and possibly there is some error in the decoding.

That part you were mostly interested in, with string identification looks like it could possibly (with be a little bit of bit rotting) be a SysEx MIDI message starting with 0xF0 (here 0x10, i.e. 3 upper bits zeroed)

For example, Behringer's SysEX for OSC for the XR18 looks like: F0 00 20 32 32 TEXT F7.

But I may be wrong.

Unless the bit errors are fixed we will never know.

But my question: Would be possible for you to post somewhere a bin dump of that uart stream, not just a screenshot? The longer the better. Maybe we can find a pattern...

[xn--nding-jua]

Hi,

currently I'm reverse-engineering the protocol. Since today I have a test-setup with a working AES50-connection and a direct UART-connection to the computer. This is my first glance of some of the messages:

Device- and Channel-Name Message with 1x WING

0x10 0x66	Message-ID
0xA5 0x64	Device-ID
0x00 0x00 0x00 0x5E
17 ASCII-Chars	Device-Name
384 ASCII-Chars	48x 8 ASCII-Chars Channel-Name

Device- and Channel-Name Message with 1x SD16

0x10 0x66	Message-ID
0x55 0xFF	Device-ID
20 ASCII-Chars	Device-Name "   PSD16\0\0\0\0\0\0\0\0\0\0\0\0"
0x02
384 ASCII-Chars	48x 8 ASCII-Chars Channel-Name

Device- and Channel-Name Message with 1x S16

0x10 0x66	Message-ID
0x58 0xCD	Device-ID
20 ASCII-Chars	Device-Name "   AS16\0\0\0\0\0\0\0\0\0\0\0\0\0"
0x02
384 ASCII-Chars	48x 8 ASCII-Chars Channel-Name

Short Message with 1x WING

0x05 0x04	Message-ID
0x2F 0xD2	?
0x00 0x00 0x00
8 ASCII-Chars (= 000000\0\0 when no second device in AES-chain)

Short Message with 1x SD16

0x05 0x04	Message-ID
0x31 0xC2	?
12 ASCII-Chars: "   P22    \0\0"

Short Message with 1x S16

0x05 0x04	Message-ID
0x31 0xD1	?
12 ASCII-Chars: "   A22    \0\0"

Tonight I will try to connect multiple devices in series and try to get on some headamp-messages. I will collect everything in a nice protocol-description-file in the end.

[xn--nding-jua]

@butrus Yesterday I had some success on decoding the protocol:

Unofficial AES50 AUX-Protocol for MusicGroup Devices.pdf

In the end I was able to control the +48 Phantom-Power of my S16, but I took a command that I received via AES50 from my X32Rack. To send own messages we have to understand how the two checksum-bytes are calculated:

Properties of this checksum word:

• Increases/decreases value when values in payload are increased/decreased
• Checksum Byte 1 seems to be responsible for odd payload-bytes
• Checksum Byte 2 seems to be responsible for even payload-bytes
• When multiple even- or multiple odd-payload-bytes have the same value, the checksum does not change
• Probably the length of the message is taken into account

I added some messages within the PDF. Maybe you have an idea?

[butrus]

OK, that's a nice challenge. Hopefully today evening I'll have the time for it.

BTW, 2.1. of your document: You can enable headamp-control on slave X32 and probably Wing too. You can try it to see whether the string changes.

"2" maybe a type of control. We have basically 4 possibilities:

• no control
• gain control
• phantom control
• gain+phantom control

Would be interesting to test devices with and without phantom... ?

[butrus]

Meanwhile, could you please try to figure out how does the checksum change if you increase a single byte by 2 / 4 / 8?

Are you sure this is not a simple XOR or so?

[butrus]

As to 2.1. again:

Would be really interesting to see how a Behringer SD8" idetifies itself.

"P200000" would be expected.

[butrus]

Meanwhile, could you please try to figure out how does the checksum change if you increase a single byte by 2 / 4 / 8?

Are you sure this is not a simple XOR or so?

I mean, of course, a 16-bit XOR..

Sorry for spamming... :-)

[xn--nding-jua]

Turns out that the calculation of the checksum uses the following equation:

At the weekend I will test this with my setup

[xn--nding-jua]

Umm, I was a bit fast. The mentioned equation works for the received messages, but the S16 is not responding. It seems that there is still more to Do...

I'm close. The checksum itself had a bitflip. Now I have to figure out why an additional 0x1F has to be take into account

[xn--nding-jua]

Its working - a bit. I'm able to control the gains and the phantom-voltage, but the checksum-calculation is still a bit buggy:

But we are on the right track 👍

[YetAnotherElectronicsChannel]

Its working - a bit. I'm able to control the gains and the phantom-voltage, but the checksum-calculation is still a bit buggy:

But we are on the right track 👍

Happy to see my board in action :D