This is a continuation of an already stupidly long adventure; you can read part 1 here but you'll probably need some time to really read it. If you are here just for the demo of the end product, you can click here!

Welcome back!

In the last article, I heavily focused on understanding/reverse-engineering Ultranet and getting a proof of concept working on FPGA. It was mostly about the protocol side: understanding the physical side, how data flows, timings, and wrestling with bits until both transmitter and receiver behaved correctly. As we'll see later, it turns out that I was wrong about the implementation!

In this article, I'm shifting gears to design a product that I'd actually use in live production.

The whole point of this project is to create an 8-channel stagebox for non-critical auxiliary audio lines that I will use in my live production. I recently received the dates and song list for the 2026 "tour" so timelines on multiple projects, including this one, got very real 🤩!

As discussed in part 1, there are many options on the market (ADAT, MADI, Dante, …), but those are (mostly) locked down and expensive. Reusing an existing protocol (like Behringer's Ultranet) is an easy way to design a futureproof(-ish) system while ensuring compatibility with many existing devices, all while learning about the intricacies of the system. This makes me more aware of the limits of a setup and lets me understand why things go wrong and how to bodge said things when it breaks 1h before go-time 😢.

Due to various reasons, I will stop referring to my project as Ultranet. As it is based on AES3, which is an open standard, I doubt I will annoy Behringer too much by publishing this project under a different name. 😅 Therefore, please welcome to the stage: HyperNet 🥁

Where I left off

At the end of part 1, everything was technically working, but not exactly production-ready:

• 🧮 Channel indexing is still an issue; for some reason, real Ultranet receivers are still not fully compatible with HyperNet, and the HyperNet receiver had indexing issues.
• 🔌 The audio frontends of the DACs and ADCs were mediocre at best.
• 🧩 The PCB layout design was made to be a prototype devboard rather than a real product
• 📦 The project was a bare PCB without any case

Quick Recap / Correction

AES3

As a reminder, AES3 is designed primarily to support stereo PCM 📊 audio encoded using biphase mark code (BMC).

Biphase mark code, also known as differential Manchester encoding, is a method to transmit data in which the data 💾 and clock 🕓 signals are combined to form a single two-level self-synchronizing data stream.

AES3 is composed of what are called audio blocks. These audio blocks are composed of 192 frames, each frame contains 2 subframes, which, in turn, contain 32 time slots.

A subframe is composed of:

The preamble can be one of three values:

Between the AES3 and S/PDIF standards, the contents of the 192-bit channel status word differ significantly, although they mutually agree that the first channel status bit distinguishes between the two 🤝. In the case of AES3, the standard describes, in detail, the function of each bit.

Broadly speaking, the channel status word indicates the type of data and has information about the clock and various metadata such as channel origin/destination.

Ultranet

The initial assumption that Ultranet squishes 🗜️ eight 48 kHz audio channels into a single 192 kHz AES3 stream turned out to be correct. In other words, the eight channels are interleaved into one high-rate AES3-like stream so that each 48 kHz channel fits into the 192 kHz timing without resampling.

However, initially, I assumed that Ultranet relied on the AES3 B-frame for channel synchronization, which seemed like a good idea since the protocol is based on AES3 🤔. That assumption was partly correct; it allowed me to receive audio, but it failed when it came to consistent channel indexing while receiving. At the same time, the transmitter either produced misaligned channels or didn't work whatsoever. This meant that the actual synchronization mechanism had to be different 🤨.

The P16-M tangent

This is when Christian Nöding contacted me again. He was working on the Ultranet output of the X32 for the OpenX32 project. I promptly sent him my code to try!

He tested it on a P16-M, and all he got was garbage 🗑️, random noise instead of usable audio. That immediately caught my attention. If his implementation didn't work on an actual Behringer device, something was clearly wrong in our understanding of the protocol.

By pure luck 🍀, I stumbled across a used P16-M listed for almost nothing on my local marketplace, so I grabbed it as soon as I could. Once it arrived, I hooked it up to my setup (the same one that worked flawlessly with the TFX122M-AN) and got the same garbage output. That was both good and bad news. On one hand it meant my implementation wasn't truly compatible, but on the other hand, now, I could reproduce the problem on real hardware and dig deeper into what was actually going on.

I then spent quite a while trying to debug things. At some point I got close and got channels 1-2 working, but after 2 days on the problem I had enough and decided that I wasn't going to test things blindly anymore 👀.

After a break, I promptly started to disassemble the mixer. At first glance/probe, I was surprised that none of the AK4114 appeared to have their B-frame pins connected to the XMOS chip 🤔. This is what set off alarm bells. I promptly soldered jumper wires on the SPI bus used to configure the chips and was again surprised by how little communication there was:

After a quick read of the datasheet, it turns out that their config is very standard. The config sent to the chips is setting one of them to use the crystal as a clock source and the other one as a slave. The config also re-routes their input directly to the output pin for the passthrough port.

I then snooped on the I2S output and B-frame output, which looked like what you would expect. I was so determined to find something weird that I went as far as managing to rebuild a WAV file from a 20-second capture done with the logic analyzer, which also worked just fine 🔊.

Reluctantly, I decided that I might learn something by desoldering the chips 🔥. This confirmed that the only thing connected to the XMOS chip was the I2S signal and the "valid" output. This effectively confirmed that synchronization was in no way tied to the B-frame, and as the channel and user bits weren't connected either, it left only one place where the XMOS chip could sync: the sample data

Back to research

Now, a sync signal in the sample data sounds wrong. How the hell did they fit 24-bit audio + sync into 24 time-slots 🤨 ????

After some google-fu, it turns out that they don't. Ultranet doesn't use 24-bit PCM, instead it uses 22-bit PCM.
In hindsight, I should have noticed it earlier; most quick start guides from Behringer mention that their A/D conversion is 24-bit, but they do not mention anything about the actual data.

However the guide of some devices (like the DL32) has an interesting line:

ULTRANET networking @ 48 or 44.1 kHz, 22-bit PCM

At the time I thought that was a typo 🤦, but I now realize that it is indeed correct. While the P16-M (and other devices that receive Ultranet) probably use 24 bits for their internal signal processing and the digital-to-analog conversion, the actual digital data transmitted over Ultranet is only 22-bit.

So, what is in those two bits? A bit more digging later, I found a few things on the web:

• https://reverseengineering.stackexchange.com/a/11337
• https://github.com/tuck1s/UltranetReceiver/blob/master/app_ultranet/src/i2s-32bit-simple.xc#L137
• https://github.com/doughadfield/Ultranet-to-I2S/blob/main/ultranet.c#L248

All of these projects implement some sort of sync based on the sample data 🤯.

Ultranet sync & channel index

Ok, enough teasing. As I said before, since the data itself was correct and I was just receiving channels with an offset, it meant that the block structure was already correct since:

Channel 1 (read subframe 1) being the first in each frame is an editorial choice for this article; the position of the subframe in the frame is not relevant for Ultranet

The subframe, however, is a bit different:

As you can see, it's stupidly simple, and after a quick analysis with the logic analyzer, here are the channel indices:

The choice of two bits is interesting; they could have used a third bit but instead chose to group them by two. That grouping explains why the channels offset always moved two at the same time 🙄.

I also find it very intriguing that the TFX122M-AN worked at all last time 🤔. It must use a different sync "procedure" than the P16-M 🤷‍♂️.

This is superb news 🥳 because while we lose some fidelity, the implementation just became WAY easier than using the B-frame signal:

• To receive, you just have to wait for two samples that have the same index and output them to the correct DAC.
• To transmit, it's even simpler; just put the correct index with the correct channel .

What's funny is that the channel status bits are still sometimes needed. I still have no idea what they mean, but for some reason it doesn't always work without them. Since they are not used anywhere, I guess that it's a simple pattern that is enough for the AK4114 to start decoding 🤷.

What's new?s

Now that I've set the record straight, let's actually start with part 2. After wrestling with the implementation, it's now time to clean up the move beyond the code spaghetti. This round of changes is all about making the design more robust, modular, and rack-friendly. In short: less "prototype held together with hopes and prayers", and more "something I can trust".

When I did my last PCB order, I snuck in a devboard for the DIX9211, a 216-kHz Digital Audio Interface Transceiver. This chip is similar to the AK4114 that's being used for almost every Ultranet product I've seen so far. It's partly used to replace the PLL1707 👋. It was responsible for generating the 24.576 MHz system clock that the FPGA used to decode and generate the AES3 data streams.
I'll talk about it later, but this chip also replaces the AES3 receiver inside the FPGA, which simplifies a bunch of things.

Also new, are modular DAC and ADC boards with proper analog frontends. This ensures flexibility, upgradability and reparability within the system. Imagine having to rebuild the whole board because someone blew up an input 🤦

In addition, I'm introducing an RP2040 as a supervisor MCU. It will be used to set up everything to its proper state and interface between the FPGA and other components. At its core, this project is an 8-in 8-out signal processor with interconnects, so it could be used for much more than a digital snake!

A much-needed improvement is a proper 1U case and CAD models to fit everything properly (okay, okay, you got me, a shelf with 3D-printed faceplates, I promise it looks good and feels solid 😉, you'll see!).

The last thing I need to mention is the move from fully open-source implementations to using built-in IPs inside my FPGA. Specifically, the transmitter is now using the Gowin SPDIF TX IP. While I do believe that a fully open implementation would be preferable. I also believe that using the best tools for the job is the smarter choice. I'm still very novice in the FPGA world, and while I could probably fix the previous implementation to make it do what I want, for me, it was just "easier" to use something that already works. Moreover, while this IP is proprietary, it is free, so… 🤷

Electronics redesign

DAC

For the outputs, I decided to stick with the same DAC chip as in the prototype. It performed pretty well for my application and integrated nicely with the FPGA 👍. The big change is moving from single-ended outputs to a fully balanced design. That means cleaner audio, lower noise, and better compatibility with professional gear, especially when running long cables on stage or in a studio.

With the move to balanced audio, it also meant new connectors 🔌. While I've seen balanced audio on TRS jacks before (in fact, my sound card, the UA25EX, does it this way), the proper connector to use is the XLR connector, which is way bigger than the small 3.5 mm jack I was using before.

The PCM5100A part of the schematic is super standard; it's basically a copy-paste 📋 of the datasheet. It's just configured for left-justified operation (via solder jumpers). Unfortunately, the PCM5100A is not a DAC with balanced outputs, so I need to adapt it somehow. The go-to, place & forget IC for this is the DRV134 or the DRV135. These chips are wonderful, but they also cost 5 EUR apiece in low quantities; that would mean 80 EUR of line drivers for the whole system 🤑. Much too expensive!

Instead, I chose to do a bit more work and use the NE5532. Here is how it looks:

So let's break it down. The NE5532 is composed of two independent operational amplifiers:

• The first one, U5B, is a simple non-inverting buffer ➡️. As I don't have a negative supply on this system, the audio signal is biased to be centered around 2.5V.
• The second one, U5A, is again a simple buffer 🔀, but this time in an inverting configuration.

It then goes to protection resistors and DC-blocking caps and finally ends up in the connector 🔌. The same frontend is repeated for the 2nd channel

The PCB itself is basic, although I took special care while routing the analog and digital parts to ensure that they didn't cross. The two ground planes are connected at one point under the PCM5100A as specified in the datasheet.

I also set a specific size limit to the PCB so that I could start 3D modeling 📐 as soon as possible:

ADC

The input side follows the same philosophy 🎓: keep the same ADC chip, but redesign the analog front-end for balanced operation. As said before, balanced inputs are essential to reject interference and ground noise. Since XLR inputs are used, the next "logical" step was adding phantom power. While the new board doesn't feature any configurable pre-amplifier (you could technically change the gain of the amp) to boost microphones and whatnot, I figured that adding phantom power couldn't hurt.

If I don't need it, I can simply disable it, but if I want to use microphones, I can simply use inline pre-amplifiers like the Klark Teknik Mic Booster CT1, which is a compact dynamic microphone booster with high-quality preamps. Super easy and pretty cheap!

It does add some complexity (especially since this modification came later, which meant the PCB had to stay the same size to avoid redesigning CAD models), extra power regulation, and proper protection circuits, but it opens up much more flexible use cases. Here is how one channel looks:

As you might have guessed, there's also a go-to IC for this application, the INA137. But same as before, this chip is far too expensive 💸 (less so but still). Instead I choose to use the OPA1677.

But first, we need to talk about what the hell phantom power is 👻. Phantom power is the standard way of powering devices through the same XLR cable that carries the audio signal. Instead of running a separate power line, 48V is applied equally to pins 2 and 3 of a balanced input relative to pin 1. Because the voltage is identical on both pins, it doesn't disturb the differential audio signal. Fortunately, there are plenty of places online to get the technical specifications (IEC 61938:2018 being the official document). Basically the max current is 10 mA, and you only need to connect two 6.81k resistors between each signal pin and the power source. On the schematic, this is the job of R22 and R24. If you would like to learn more about phantom, I can recommend this page: https://sound-au.com/articles/p-48.htm

Note that the specification says 6.81k, but I instead used 6.8k. This is because, apparently, at the time, getting 6.8k resistors with a low tolerance was complicated 🤷. By choosing 6.81k, the specifications ensured the proper tolerance. However, these days it isn't really a problem anymore.

Just after this is the protection circuit; first the signal goes through DC-blocking caps, followed by protection resistors and protection diodes. This circuit ensures that the signal will never have a voltage so far from the absolute maximum that it's going to break something. You'll notice that they are marked as DNP 🤔. It turns out they clamped the signal too much, so I just removed them, and I'll be careful about what I plug in. If you have suggestions, please let me know!

The signal is then biased to 2.5V and fed to an OPA1677 configured as a simple buffer, after which the signal goes through some passives and then goes to the PCM1808!

As before, the PCB itself is basic, and I also took care while routing the analog and digital parts. As with the DAC, the two ground planes are connected at one point under the PCM1808, as hinted in the datasheet.

I also reused the size limit of the PCB that I defined before.

Mainboard

The mainboard changed a lot; in fact, it changed twice while I started the writing process for this article:

As you might be able to see, the SFP and Ultranet ports on the board are basically unchanged. They don't really need to change as they worked perfectly on the prototype. Only the Ultranet TX and RX ports are swapped to facilitate routing and that's it!

This also applies to the FPGA, which is still the same Tang 9k that I used last time. It works very well and is easy to use, so why change it 🙂!

The whole right side of the board is dedicated to power management (3.3v digital, 5v analog, and 48v phantom) ⚡. Each input has its own switch to turn on phantom power instead of a global one.

The most significant change is the IDC ports to connect the ADCs and DACs boards. I chose IDC connectors mainly because they are very resilient, cheap, and widely used. That said, if I were to redesign everything, I would probably use FFC connectors to reduce the size 📏. These ports provide:

• An I2C port 💬 (Unused and unpopulated for my boards)
• An I2S port 🔉 (different pinout for DACs and ADCs to facilitate routing)
• Two GPIOs (Only used in the DAC connector to carry the mute signal 🔇)
• 3.3V Digital power ⚡
• 5V Analog power ⚡

Here is a high-level view of the schematic that shows how everything connects to each other:

The last thing that needs a special mention is the DIX9211. This chip is basically an AES3/SPDIF receiver that spits out I2S. This simplifies so much of the FPGA logic since receiving I2S is way easier than receiving AES3!

I'm configuring it with a Raspberry Pi Pico and a few DIP-switches. I also stole the pass-through idea from the P16-M and used the chip as a "biphase router" of sorts. I can configure what input port is used as the input for the DIR, and I can also choose which input port is used for the biphase output. This offers a lot of flexibility; for example, I could use my project to receive from the Ultranet port and at the same time send audio over the fiber link!

This chip was really a no-brainer compared to the PLL1707 that I used before, since for a few cents more, it adds easier decoding, biphase routing, clocks, etc. Massive boost in flexibility for the system!

HDL redesign

Receiver

Here is a diagram showing how the receiver works from a high-level view:

Since the DIX9211 outputs I2S it's pretty simple. The demuxer is the interesting part 🧐. You can find parts of the code below. In short, it loads bits from sdata on the bclk rising edge and saves the sample when lrclk transitions, saving the sample. When two successive samples have the same LSB, output them to their respective ports.

There's a bit of clock management to get the proper speeds for the four I2S outputs and a "small" block to make sure the I2S clocks are somewhat locked to the receiver (which makes sure the samples aren't loaded when written), but that's it.

After that, the signals go to an I2S transmitter block that has been modified to deal with four outputs at once.

 1-- Detect LR transition (channel boundary)
 2is_lr_changed  <= '1' when zlrclk /= lrclk else '0';
 3    
 4-- Extract active part of the audio signal and the current LSB of said signal.
 5-- The sample_data signal is 32bit but only the upper 24 bits matter
 6sample_audio_data <= sample_data(31 downto 10) & "00"; -- Remove the LSB as this is used for the channel index
 7sample_lsb_data <= sample_data(9 downto 8);
 8
 9-- Main deserialization process
10deserialize_i2s : process(bclk) begin
11	if rising_edge(bclk) then
12        if reset_n = '0' then
13            -- Reset all outputs and counters
14            sample_data            <= (others => '0');
15            prev_sample_audio_data <= (others => '0');
16            prev_sample_lsb_data   <= (others => '0');
17            ch1_out <= (others => '0');
18            ch2_out <= (others => '0');
19            ch3_out <= (others => '0');
20            ch4_out <= (others => '0');
21            ch5_out <= (others => '0');
22            ch6_out <= (others => '0');
23            ch7_out <= (others => '0');
24            ch8_out <= (others => '0');
25            data_ready <= '0';
26
27            -- Keep the edge detector running while in reset
28            zlrclk <= lrclk;
29        else
30            -- Shift serial input data into buffer (MSB first). 32 bits are shifted but only the upper 24 are valid data
31            sample_data <= sample_data(sample_data'high-1 downto sample_data'low) & sdata;
32
33            -- Save LRCLK for edge detection
34            zlrclk <= lrclk;
35                
36            -- On word clock transition:
37            if is_lr_changed then
38
39                -- Check if current LSB matches previous LSB
40                if sample_lsb_data = prev_sample_lsb_data then
41                    -- Two successive samples with same LSB whe are successfuly synced - output them
42                    case sample_lsb_data is
43                        when "00" =>
44                            ch1_out <= prev_sample_audio_data;
45                            ch2_out <= sample_audio_data;
46                        when "01" =>
47                            ch3_out <= prev_sample_audio_data;
48                            ch4_out <= sample_audio_data;
49                        when "10" =>
50                            ch5_out <= prev_sample_audio_data;
51                            ch6_out <= sample_audio_data;
52                        when "11" =>
53                            ch7_out <= prev_sample_audio_data;
54                            ch8_out <= sample_audio_data;
55
56                            -- When channel 8 is written, flag that the data is ready for 1 bclk cycle 
57                            -- The choice of lsb=11 is arbitrary, unless the input data is really fucked-up it shouldn't matter. There really should be a separate data ready signal for each pair
58                            data_ready <= '1';
59                    end case;
60                end if;
61
62                -- Store sample and LSB as previous for next comparison
63                prev_sample_audio_data <= sample_audio_data;
64                prev_sample_lsb_data   <= sample_lsb_data;
65
66            else
67                -- Still reading data
68                -- Clear the data ready flag
69                data_ready <= '0';
70            end if;
71        end if;
72	end if;
73end process;

Transmitter

Here is a diagram showing how the transmitter works from a high-level view:

As you can see, it's WAY more complicated than the receiver. This is mainly because I'm using a pre-made FIFO and S/PDIF transmitter block, there's not much code to show besides the diagram, but the most "interesting" part is the mux that pushes a burst of eight audio samples to the FIFO. Basically it waits for the signal that says that the FIFO is almost empty (e.g., finished with the last batch) and pushes the samples.

As before, there's a bit of logic to deal with the clock signals and their synchronization to the transmitter, but that part is pretty easy.

There's also a block to deal with the channel status. I don't really know why it's needed, but I simply use what the DL16 is sending.

 1push_data : process(clk) begin
 2	if falling_edge(clk) then
 3		if reset_n = '0' then
 4            -- Reset all outputs and counters
 5            burst_write_counter <= 0;
 6            sample_write <= '0';
 7            sample <= "000000000000000000000000";
 8        else
 9            -- Data from the I2S reader is ready, burst write the data to the FIFO
10            if data_ready = '1' then
11                burst_write_counter <= 8;
12            end if;
13            
14            -- Write samples on a bclk pos edge
15            if bclk_pos_edge = '1' then
16                if burst_write_counter = 8 then
17                    sample <= ch1_in(23 downto 2) & "00";
18                elsif burst_write_counter = 7 then
19                    sample <= ch2_in(23 downto 2) & "00";
20                elsif burst_write_counter = 6 then
21                    sample <= ch3_in(23 downto 2) & "01";
22                elsif burst_write_counter = 5 then
23                    sample <= ch4_in(23 downto 2) & "01";
24                elsif burst_write_counter = 4 then
25                    sample <= ch5_in(23 downto 2) & "10";
26                elsif burst_write_counter = 3 then
27                    sample <= ch6_in(23 downto 2) & "10";
28                elsif burst_write_counter = 2 then
29                    sample <= ch7_in(23 downto 2) & "11";
30                elsif burst_write_counter = 1 then
31                    sample <= ch8_in(23 downto 2) & "11";
32                end if;
33
34                if burst_write_counter > 0 then
35                    sample_write <= '1';
36                    burst_write_counter <= burst_write_counter - 1;
37                end if;
38            elsif bclk_neg_edge = '1' then
39                sample_write <= '0';
40            end if;
41		end if;
42	end if;
43end process;

Firmware

Since I chose to go with the DIX9211, I need a way to control it 🎛️. This could have been done in the FPGA, however, I didn't feel like implementing I2C by hand 🥱, so I decided to use a Raspberry Pi Pico. It takes up a bunch of space on the PCB, but it's way faster to work with.

Right now it's only configuring the chip, but as I said earlier, I did connect an SPI bus with two extra pins to the FPGA, this could be used for many applications ranging from basic config to audio input/output over USB.

I also alluded to earlier that, like the P16-M, I use the DIX9211 as a router 🔀. This is configured by the supervisor from some DIP switches:

There are a few additional registers to configure. The full config can be seen in the setup script below.
Again, I didn't feel like setting up a full C++ project with the pico-sdk (or even Arduino), so I just left CircuitPython and made it so that the script runs at boot. This has the downside of a small 500ms delay before it's configured after reset, but I can live with that 🤷!

It could be improved by periodically watching the inputs 👀 and reconfiguring accordingly. It would remove the need to push the reset button after changing the config, but then again, I was lazy for this part of the project.

 1import board
 2import busio
 3import digitalio
 4import time
 5from adafruit_bus_device.i2c_device import I2CDevice
 6
 7source_map = ["Fiber", "HyperNet 1-8", "HyperNet 9-16", "FPGA"]
 8
 9i2c = busio.I2C(sda=board.GP12, scl=board.GP13)
10
11device_dix = I2CDevice(i2c, 64)
12    
13def read(device, register, size=1):
14    buf = bytearray(size)
15    with device_dix:
16        device_dix.write_then_readinto(bytes([register]), buf)
17    return buf
18        
19def write(device, register, data):
20    buf = bytearray(1)
21    buf[0] = register
22    buf.extend(data)
23    with device_dix:
24        device_dix.write(buf)
25
26config_outsrc_1 = digitalio.DigitalInOut(board.GP0)
27config_outsrc_1.direction = digitalio.Direction.INPUT
28config_outsrc_2 = digitalio.DigitalInOut(board.GP1)
29config_outsrc_2.direction = digitalio.Direction.INPUT
30config_inpsrc_1 = digitalio.DigitalInOut(board.GP2)
31config_inpsrc_1.direction = digitalio.Direction.INPUT
32config_inpsrc_2 = digitalio.DigitalInOut(board.GP3)
33config_inpsrc_2.direction = digitalio.Direction.INPUT
34
35config_outsrc = (not config_outsrc_1.value) << 0 | (not config_outsrc_2.value) << 1
36config_inpsrc = (not config_inpsrc_1.value) << 0 | (not config_inpsrc_2.value) << 1
37
38print(f"DIR Input source: {source_map[config_inpsrc]}")
39print(f"DIR Output source: {source_map[config_outsrc]}")
40
41
42write(device_dix, 0x2F, [0b00000101])    # DIR Output Data Format
43                                         #   24-bit MSB first, left-justified
44                          
45write(device_dix, 0x31, [0b00000000])    # XTI Source, Clock (SCK/BCK/LRCK) Frequency Setting
46                                         #   SCK=24.576M BCK=12.288M LRCK=192k 
47                          
48write(device_dix, 0x34, [config_inpsrc]) # DIR Input Biphase Source Select, Coax Amplifier Control
49                                         #   rxin0amp normal / rxin1amp normal / rxin2 source
50                          
51write(device_dix, 0x6F, [0b00011100])    # MPIO_A, MPIO_B, MPIO_C Group Function Assign
52                                         #   MPIO_A = Biphase Input Extension (RXIN8 to RXIN11)
53                                         #   MPIO_B = DIR Flags Output or GPIO (Selected by MPB3SEL, MPB2SEL, MPB1SEL, MPB0SEL)
54                                         #   MPIO_C = DIR BCUV OUT, BFRAME/VOUT/UOUT/COUT
55                          
56write(device_dix, 0x71, [0b00000000])    # MPIO_B, MPIO_C Flags or GPIO Assign Setting
57                                         #   DIR Flags, set by MPB1FLG / MPC0FLG
58                          
59write(device_dix, 0x74, [0b01010101])    # MPIO_B1, MPIO_B0 Output Flag Select
60                                         #   LOCK LOCK
61write(device_dix, 0x75, [0b01010101])    # MPIO_B3, MPIO_B2 Output Flag Select
62                                         #   LOCK LOCK
63                          
64
65write(device_dix, 0x78, [0b11001110])    # MPO1, MPO0 Function Assign Setting
66                                         #   MPO1=XMCKO MPO0=RECOUT0 
67                          
68write(device_dix, 0x24, [0b00010100])    # Oscillation Circuit Control
69                                         #   OSCAUTO=0 (always operates) XMCKENX=1 (Output) XMCKDIV=01 (XTI/2 (12.288 MHz))
70
71
72write(device_dix, 0x35, [config_outsrc]) # RECOUT0 Output Biphase Source Select
73                                         #   RECOUT0=RXIN3 MPO0MUT=Output

3D Design

Designing the physical enclosure for this project turned out to be quite fun 😫. I didn't want to spend a bunch of money on a custom rack case, so instead I opted for the Scrooge McDuck 🦆 solution and used a standard 1U rack shelf. I've used this method in the past for my SDI over fiber project, so I knew it could work.

It's far from the best solution, but once everything is assembled, it's strong and, most importantly, very affordable. Using a shelf also means I don't have to worry about a custom front-panel or things like that. Instead I can just 3D-print the front and rear plates myself 👍.

Since the DAC and ADC modules have the same size, connector placement, and mounting holes, it was straightforward to design a holder for each. However, since this will be rack-mounted, I can't have screws on the bottom to attach the 3D prints. To solve this, I have 3 aluminum bars running for the whole length. These bars are then screwed in from the side:

I initially thought it wouldn't be enough and bought some strong double-sided tape. To my surprise, it turned out that it is surprisingly strong once all the holders are present 💪! My design made it so that 8 holders don't fill the full width, there's about a centimeter left that I use for status LEDs (like power, active, sync, …).

DAC & ADC Holder

For the DAC/ADC holder, I designed a compact holder in which I can slide the PCB in from the rear and lock it against the faceplate with four M3 screws into the XLR connectors. Additionally, there are three M3 screws on the PCB itself; this increases the overall rigidity of the holder and makes sure it won't break when plugging in cables.

The only difference between the ADC and DAC holder is that the ADC one has an extra hole near each XLR connector for an LED, which will indicate the presence of phantom power 💡. Soldering the LEDs was quite annoying due to the short leads, so if anyone knows where I can get LEDs with longer leads, I would appreciate knowing about it!

I also designed some dust covers that you will see later. They slide in the dovetail-like slot of the sled. While it's by no means waterproof (or even dustproof), it will stop things from touching the PCB directly, which is the most important part for me.

Main board

The mainboard is going to get stuck on the shelf with double-sided tape, so I just needed a simple plate on the bottom to isolate the PCB from the metal shelf. And to make everything look good, I also made a front plate to cover most of the components:

I left the FPGA in the open because it's the only part on headers because I might use it for other projects in the future!

Assembly

And it's finally time for assembly 🤩!

I started by putting the four DACs and four ADCs on their respective holders and sliding them into the shelf:

I then stuck the mainboard (and power supply) with some strong double-sided tape:

And finally I made "a few" custom cables to make sure everything looks neat:

Validation

Validation was quite fun because I discovered a few issues 😢:

These issues have been corrected in the schematics above

• Audio was leaking between the 2 channels of each DAC board.
  • This turned out to be caused by my 2.5V bias supply, I used a simple divider connected to both channels, I should have used either a 2.5V LDO or what I ended up doing, which was adding a 2nd voltage divider just for the 2nd channel.
• Gain issue with the DAC board:
  • Solved it by using a 0-ohm resistor for the feedback resistor of the opamp for positive output instead of the 10k I had before.
• Same gain issue with the ADC board:
  • Also solved it by using a 0-ohm resistor for the feedback resistor of the opamp instead of the 10k I had before.
• Fiber input not working on the mainboard:
  • Missing 100k pull down resistor on the negative signal of the differential pair coming from the SFP.

But after solving all of these, everything worked 🥳 !

Thanks to my dad, who's an actual sound engineer, and the Smaart software, I even managed to do some proper measurements 📏:

The signal is flat overall except in the lower frequencies. I suspect this is due to my choice of caps for the DAC 🤔, but it's more than good enough for me (in fact, it's better than what I measured at the output of the P16-M).

The software also gave me an estimate for latency, which is 0.56 ms (it's the equivalent of sitting ~20 cm from a speaker), which is again more than good enough for my application!

Demo

Ok enough text, let's see the demo 📹:

I didn't show every possible configuration but you can probably figure out how it would work. The last demo (with two boards) was filmed before the 2nd shelf arrived, hence why it doesn't look the same😅!

Conclusion / What's next

This project started with me wanting to carry timecode and a few other signals from stage to FOH and back. It then promptly spiraled out of control 🌪️ and fed my curiosity about the inner workings of Behringer's Ultranet and ended up as a robust, open hardware system I can actually trust on stage.

Just like my previous project, it taught me a lot. I learned about AES3 (and Ultranet) internals, clock domains ⌚, analog design, etc. This is huge because now when something goes wrong, I actually know what to look for, I can better estimate the limits of the systems I use, and I can figure out solutions to problems way faster. Working on a project like this not only gives you an insane amount of knowledge on the systems you are studying, but it also gives you a huge amount of respect for how much engineering goes into moving "just sixteen channels of audio".

Unlike the first part, I feel confident enough with my implementation to release this publicly on my GitHub. I do have to warn you that it's not a plug-and-play solution and requires a lot of work!

GitHub - TheStaticTurtle/HyperNet: HyperNet is an 8-in, 8-out open-source audio stagebox based on Ultranet

HyperNet is an 8-in, 8-out open-source audio stagebox based on Ultranet - TheStaticTurtle/HyperNet

While it would be cool to look at XMOS chips, AES50, or even StageConnect now that it's open-source thanks to Chris, I don't think I'll touch audio stuff for a while now. However, I'm nowhere near done with live production tools. I've been playing with intercoms ☎️ (think ClearCom, RTS, …) for a few years now, and I've already invested quite a lot of time (and money) into making open-source analog and digital prototypes!

This is a stupidly long article, it details the different phases thoroughly, you'll need probably some time to really read it.
Demo video is available at the end!

Why

In my last article about the open-source SDI to fiber converter, I briefly talked about my brand new MPO-12 cable with 12 OM3 fibers 🔦. I've also hinted that I might use the two spare fibers I had for audio 🔊.

These audio channels will be used mostly as side-channels, stuff like LTC time code, backup sound pickup, and (maybe) intercom

When I started this project, there were four "mainstream" ways I thought I could tackle this:

• S/PDIF (Sony/Philips Digital Interface) (or it's professional big brother AES/EBU)
  It's a digital audio interface transmitted over various connectors, such as (plastic) fiber-optic cables. This would be the most obvious option, S/PDIF can already be transmitted over fiber so it wouldn't be that difficult to adapt it to OM3 with an SFP module.
  • The main upside is that there are plenty of cheap modules that already exist to convert analog to digital and vice versa
  • The main downside is that it is only two channels per link 🤔
    
    
• ADAT Lightpipe
  Lightpipe uses the same connection hardware as S/PDIF: fiber optic cables (hence its name) to carry data, with TOSLINK connectors and optical transceivers at either end. The main difference stems from the fact that ADAT supports up to 8 audio channels at 48 kHz, 24 bits.
  • The main upside is that 8 channels is pretty good
  • The main downside is that from some quick research, there isn't a recent IC or implementation that exists and devices that implement the protocol cost too much for my use.
    
    
• Multichannel Audio Digital Interface (MADI) / AES10
  This interface supports serial digital transmission over coaxial cable or fiber-optic lines of 28, 56, 32, or 64 channels and sampling rates to 96 kHz and beyond with an audio bit depth of up to 24 bits per channel.
  • The main upside is the number of channels and the fact that it already runs over multimode fiber 🔦.
  • The main downside is that it's even worse than ADAT, there isn't a recent/easy implementation that exists and devices that implement the protocol have a prohibitive cost for hobbyist use.
    
    
• Dante / AES67
  This is a combination of software, hardware, and network protocols that delivers uncompressed, multichannel, low-latency digital audio over a standard Ethernet network 🌐 using Layer 3 IP packets.
  • The main upside is that there are plenty of channels (max 512) 📈, it's easy to use, and it's implemented on countless devices
  • The main downside is that implementing it to get low latency ⏱ will be a nightmare

I didn't really like any of these 😕, I did try to build a prototype ADAT board based on the AL1401/A1L402 ICs, but I didn't have any luck 🙁.

I did dip my toes in AES67 for another project, but access to the full specification as a hobbyist is a bit complicated and the overall setup required to get it working at all without dealing with latency requires a lot of work ⏳.

Then the universe dropped this gem 💎 from Christian Nöding:

This is what kickstarted the whole thing. From the video, it seemed that Ultranet (a protocol that I have heard of but never used), is somewhat based on two AES3 signals each containing 8 channels. This would mean either 8 channels bidirectional or 16 uni-directional channels on two fiber 🤩. Moreover, I do have (limited) access to hardware that can send and receive Ultranet so I can easily test my implementation. But the most important thing is that Christian proved it was possible to do it 🥳!

Note: for the story's sake, events, and discoveries aren't necessarily in chronological order.

Research

As always for big projects, I started by doing some research 📜, this part also contains discoveries and light-bulb moments I had during the project.

AES/EBU

I mentioned that Ultranet is based on AES3, also known as AES/EBU so let's start there, how the hell does this work, and where do we start?

The Audio Engineering Society (AES), is a professional society 🏢 devoted exclusively to audio technology. Alongside other groups like the European Broadcasting Union (EBU) 🎥 they standardize different technologies in the audio/broadcasting industry.

This article will talk exclusively about AES3. Newer standards are behind a paywall. Fortunately, AES3 is as older than me. It was first published in 1985 and was revised in 1992, 2003 and 2009. That means that we can find semi-recent leaked PDFs without much difficulty.

Moreover, there are a bunch of other documents linked to AES3 from which we can scoop up information:

• AES/EBU EG - Engineering Guidelines - (The AES/EBU audio interface)
• EBU Tech 3250-2004 - Specification of the digital audio interface (The AES/EBU interface)
• IEC60958 - Digital audio interface - Part 1: General
• AES-2id - Guidelines for the use of the AES3 interface

Electrical signals

AES3 can be transmitted over three main kinds of connections:

• IEC60958 Type I: This defines a balanced, three-conductor, 110-ohm twisted pair cable with XLR connectors. Type I connections are most often used in professional installations and are considered the standard connector for AES3
• IEC60958 Type II: It defines an unbalanced electrical or optical interface for consumer electronics applications. This implementation is the one used by S/PDIF. S/PDIF and AES3 are interchangeable at the protocol level, but differ at the physical level (voltage / impedances).
• BNC connectors: AES/EBU signals can also be run using an unbalanced 75-ohm coaxial cable. The unbalanced version has a very long transmission distance, instead of the 150 meters maximum for the balanced version. The AES-3id standard defines a 75-ohm BNC electrical variant of AES3.

From the EBU Tech 3250-2004 document, we can get a bunch of information about the electrical characteristics of AES3, which boils down in my opinion to the most important being that the system needs an impedance of 110 Ohm ± 20% with an amplitude that lies between 2 and 7 V peak-to-peak.

Data encoding

AES3 was designed primarily to support stereo PCM 📊 encoded audio in either DAT format at 48 kHz 🎤 or CD format at 44.1 kHz 💿. Instead of using an elaborate scheme to support both rates, AES3 allows instead to be run at any rate 💪, and encodes the clock and the data together using biphase mark code (BMC).

Biphase mark code, also known as differential Manchester encoding, is a method to transmit data in which the data 💾 and clock 🕓 signals are combined to form a single two-level self-synchronizing data stream. Each data bit is encoded by a presence or absence of signal level transition in the middle of the bit period (known as time slot for AES3), followed by the mandatory level transition at the beginning of the period. This also means that by design the encoding is insensitive to an inversion of polarity 🔀.

There are two variants of BMC:

• Transition on a 1 which is the one used for AES3
• Transition on a 0 which is irrelevant for this project

Here is an example diagram representing how the signal behave, there is a transition on each solid line plus a transition on the dotted line if the bit is a one:

Differential Manchester encoding has the following advantages:

• A transition is guaranteed at least once every bit, for robust clock recovery.
• If the high and low signal levels have the same magnitude with opposite polarity, the average voltage around each unconditional transition is zero. Zero DC bias reduces the necessary transmitting power and minimizes the electromagnetic noise produced by the transmission line.

All of these positive features come at the expense of clock speed 🏃‍♂️. BMC needs a clock twice as fast as the data rate to encode the bit stream

Blocks, frames, time slots

Now that we know how to read the bits, let's talk about what those bits actually mean!

AES3 is composed of what is called audio blocks, these audio blocks are composed of 192 frames, each frame contains 2 subframes, which in turns, contain 32 time slots.

A subframe is composed of:

The preamble can be one of three values:

Channel status word

Between the AES3 and S/PDIF standards, the contents of the 192-bit channel status word differ significantly, although they both standards agree that the first channel status bit distinguishes between the two 🤝. In the case of AES3, the standard describes, in detail, the function of each bit.

Broadly speaking, the channel status word indicates the type of data, has information about the clocks and various metadata such as channel origin/destination.

I won't go into more detail in this article mainly because it's mostly irrelevant for Ultranet 🧐. For AES3, you can find the full format in the EBU Tech 3250-2004 document. For consumer S/PDIF it's a bit more blurry but the English Wikipedia article has a nice table 📅.

Practical example

That's a lot to take in, so let's look at a practical example from my logic analyzer:

Let's see what we can figure out:

• This subframe starts with the B preamble, this tells us that it's the start of an audio block and that it's the left channel left.
• We are going to consider that the auxiliary bits are used for audio. This gives us 0xadffff, if we change the bit order from LSB-first (AES3) to MSB-first 🔀 (what is generally used for audio) the 24bit audio data is 0xffffb5.
• Even tho we have data the validity bit tells us that this frame is invalid 🛑 and that it shouldn't be played
• Then comes the user bit with an undefined structure.
• There is the channel status word, this tells us that the first bit of the word is a 0 indicating S/PDIF data
• Finally, the parity bit is 0 because the number of asserted bits in the 4-30 range already are an even number of 1s 🧮

And that's it really, the M preamble will then be used for the rest of the left channel subframes and the W will be used for the right channel. Then after 384 subframe, there will be another B preamble signaling a new block.

Ultranet

Now, how does Ultranet differ from AES3?

As there is no official documentation that is publicly available (or any leaks for that matter), everything that not straight out of a product sheet is informed speculation, reverse-engineering and trial & error and might not reflect exactly the actual protocol

What we know from product sheets:

I read through the datasheets/quick guides from several Ultranet compatible devices from Behringer and its subsidiaries. Here is what is always present and important to this project:

• Digital Processing
  • A/D conversion: 24-bit, 44.1 kHz / 48 kHz sample rate
  • Latency: <0.9 ms (from P16-I to P16-HQ)
• System
  • Signal: 16 channels, plus bus-power
  • Power:
    • P16-M consumes max. 5W
    • P16-D consumes max. 40W
• Cabling
  • Connectors: RJ45
  • Cables: Shielded CAT5
  • Cable length: max. 246 ft (ca. 75 meters) recommended

Apart from the channel count, given the audio format & latency plus the fact that the signal runs over CAT5, it sounds a lot like AES3 🤔. The product sheet also tells us that power is running on the same cable somehow.

Probing and reverse-engineering the electronics 🍑

As I said before, the work that Christian did is what kickstarted this project. At this point, he already published his video and figured out that as Ultranet uses generic CAT5 cables, which means they most likely also use standard wiring.

As it turns out (and we'll see why later in the protocol section), Ultranet does not send 16 channels down a single stream. Instead, it sends 8 channels over two separate (but synchronized) streams. That means 2 out 4 pairs are used for audio and leaves 2 pairs for power, which looks a lot like 100BASE-T with POE mode B 😅.

Earlier I briefly talked about the AES3 electrical specifications. Again the EBU Tech 3250-2004 document comes to the rescue, there is a whole section on differential pairs and how AES3 should be wired 🔌:

Here are a few other important characteristics that have to be respected:

The interconnecting cable shall be balanced and screened (shielded) with nominal characteristic impedance of 110 Ohms at frequencies from 0.1 to 128 times the maximum frame rate.

The line driver shall have a balanced output with an internal impedance of 110 Ohm ± 20%, at frequencies from 0.1 to 128 times the maximum frame rate when measured the output at terminals.

The signal amplitude shall lie between 2 and 7 V peak-to-peak, when measured across a 110 Ohm resistor connected to the output terminals, without any interconnecting cable present.

Any common mode component at the output of the equipment shall be more than 30 dB below the signal at frequencies from DC to 128 times the maximum frame rate.

That's a bunch of information, and there is even more in the document. But to be honest, for a prototype, I just YOLO-ed the design 🤡 based on a quick datasheet read through and the work of Christian.

So to summarize, the important things are:

• 110 Ohms ± 20%
• Between 2 and 7 volts peak-to-peak
• The AES3 bit stream is 6.144 Mbit/s for 48Khz 2ch and if we assume that Ultranet is 8ch/stream, that is 24.576 Mbit/s
• Behringer seem to skirt the "this breaks the spec" line of every specification they based Ultranet upon.

So we can safely assume 🧐 that they are using a standard line driver running at 5V over a generic Ethernet pulse transformer which has a typical impedance of 100 Ohms (which fits the tolerance)

During his project, Christian made a small PCB to receive Ultranet, he used the SI-52008-F an RJ-45 connector with integrated magnetics and POE capability. This connector is then wired to the AM26LV32, a Low-Voltage, High-Speed Quadruple Differential Line Receiver that can handle up to 32MHz data rates, can receive 5V signals and outputs 3.3V.

This seems pretty good, but writing this article I did notice that the common-mode range is 2 volts under the AES3 spec, but I doubt it's going to cause massive issues 🧨 for the prototype and I probably won't be swapping it for something else for part 2.

The AM26LV32 also has a brother, the AM26LV31 a Low-Voltage High-Speed Quadruple Differential Line Driver which has just about the same specs but goes into the other direction:

While writting this article I say things as tho they are obvious and the only option. Truth is until very late into the project I was extremly unsure about the electronics. At the time, I was struggling getting a signal in/out from real hardware and I was suspecting these circuit more and more.

All of this uncertainty lead me down the path of trying to reverse-engineering the electrical side of a proprietary protocol with nothing but Google Images 🖼. After much research, I stumbled onto the Klark Teknik DM80-Ultranet an Ultranet expansion card for the DM8000. What was fascinating was the very nice and high resolution 🔍 top view of the pcb.

After loading the image into Gimp, I began tracing out connections and with the help of The ultimate SMD marking codes database, I managed to get the information I was looking for:

The AES3 signals both go into a SN74LVC1G04 Single Inverter Gate and a SN74LVC1G125 Single Bus Buffer Gate which gives a 5V differential signal. It then goes into what I assume to be filters, a protection diode, and a common mode choke before going into either, the connector directly or through magnetics 🧲 (we can only guess here, but I think it goes straight to the connector).

The input circuitry goes from the connector (again, maybe through magnetics, but I doubt it) through what I assume to be a common mode choke into what I guess is a pulse transformer and I didn't bother going further as I already had this working, and it worked for Dr. Nöding.

After this evening, I was confident that the implementation that we'll see later was correct enough to work 😎!

Reverse-engineering the protocol

So how would you send 16 channels of digital audio down a CAT5 cable?

An important thing to remember is that while is its own unique thing, Ultranet is based on existing protocols and from what I've seen, they try not to break ⛓ them too much.

From different photos of main boards of products that implement Ultranet, we can see a recurring pattern, there always seem to be two of the same ICs, the AK4114. This IC is a High Feature 192kHz 24bit Digital Audio Interface Transceiver 🔊

The AK4114 is a digital audio transceiver supporting 192kHz, 24bits. The channel status decoder supports both consumer and professional modes. The AK4114 can automatically detect a Non-PCM bit stream. When combined with the multi channel codec (AK4527B or AK4529), the two chips provide a system solution for AC-3 applications. The dedicated pins or a serial µP I/F can control the mode setting.

Features include:

• AES3, IEC60958, S/PDIF, EIAJ CP1201 Compatible
• Unlock & Parity Error Detection
• Validity Flag Detection
• Up to 24bit Audio Data Format
• Master Clock Outputs

From all of this, it appears that it's a bog-standard AES3/SPDIF receiver. Which means that once again, Behringer didn't go too far into customizing the protocol 🔧.

So how do you fit 16 channels 🗜 into the 192kHz the chip supports? Well, you don't, as I mentioned before, there are two chips.
But wait, this still leaves 8 channels, so how do you do this? Well, 48Khz is for two channels, math tells us that 2 * 4 = 8 and that 48 * 4 = 192 that means it can fit, with some tinkering 🤔.

Okay, enough guessing: it would seem that Ultranet basically is AES3 running at 192Khz with the 8 channels multiplexed together.

You'll see later why I think that something fishy 🐟 is going on and that there is more to channel ordering than this, but it's the basic idea!

That leaves the content of those bits, are they different? Well, yes, somewhat!

• Because they use standard ICs the preambles need to be the same
• As well as the audio data.
• The validity bit seems to be inverted, which is a good call when you think about it.
• The user bits seem to be unused
• The channel bits are used but not idea for what, yet changing them seemed to have no audible effect.
• And again, since they use standard ICs, the parity bit simply cannot change (which I discovered the hard way)

And that's it, really. Behringer created a very elegant solution 😎 stretching existing specification/protocols to meet their needs and didn't completely reinvent the wheel!

Building a dev-board

I decided that my first step would be to design a prototype development board 🦾 where I could easily explore different avenues before going straight into a final design. This approach allows me to test various configurations and functionalities without committing too much time or resources upfront.

Where to start? A microcontroller 📟 seems like a good choice, but dealing with the specific signals required for this project is impractical on a traditional MCU (not to mention potential latency issues). While it might be possible to implement everything using a standard MCU, it would most likely require a specialized digital interface chip (DIX) such as the AK4114. Given these constraints and my interest in exploring new technologies, this was the perfect project to finally start working with FPGAs.

A mention must also be given to the XMOS series of ICs ‼️. This is what Behringer is using in their Ultranet products (specifically the XL216-512-TQ128 in the P16-M). XMOS chips are weird 🫠 (in a good way) they are multicore microcontrollers dedicated to audio processing which means they have many peripherals related to audio as well as reference implementations.

XMOS chips are something that I definitively want to try someday 🤔 but FPGAs have been on my radar for quite some time now, I never had a practical use case until now.

This project can be boiled down to shifting bits around, which is precisely what an FPGA does best! By using an FPGA, I can implement complex digital logic directly in hardware, which offers significant advantages over software-based solutions when it comes to speed.

However, as I never dealt with FPGAs before, this is project is a bit of a long shot 🏹, but for hobby projects I almost always work like that, so let's get started!

But which FPGA

FPGA characteristics are far and wide; they range from tiny FPGAs capable of running basic tasks to monstrous devices that can handle hundreds of gigabits of data per second 🌐.

Given my project requirements, I need something that is powerful enough to :

• Receive and transmit two AES3 streams at 192 kHz
• Handle at least 4 stereo I2S inputs
• Handle at least 4 stereo I2S outputs

I also want something powerful enought in case I want to do fancier stuff like mixing/equalizer/filters in the future 🎚️.

So it mainly came down to what I could get on a devboard for cheap and fast, there are two options I considered:

• Arduino MKR Vidor 4000
  • This board uses the Intel Cyclone 10CL016 FPGA.
  • It offers an integrated ARM Cortex-M0+ microcontroller and a full suite of onboard peripherals, making it versatile for various applications.
  • The Cyclone 10CL016 is capable of handling moderate complexity tasks and has sufficient resources to manage the AES3 streams efficiently. It can even do SDI with some help
  • It's what Dr. Nöding successfully used in his project.
• SiPEED Tang Nano 9K
  • This board uses the Gowin GW1NR-9 FPGA.
  • It provides a cost-effective solution with an integrated USB interface, making it easy to program and debug.
  • The GW1NR-9 FPGA is smaller but still offers enough logic resources for my project's requirements.
  • Thanks to its price it's a pretty popular option among hobbyists.

In the end, despite that the RTL I'm basing this project upon was successfully tested on the Vidor 4000, I decided to proceed with the Tang Nano 9K due to its cost-effectiveness💸, ease of use, and adequate performance for my project's needs. This choice allows me to focus 🎯 on developing the core FPGA functionality without the unnecessary complications of having to use the Arduino IDE alongside the Quartus Prime IDE.

I/O

As this is a devboard that I want to potentially re-use in other projects ♻️, I went all in and included a wide range of connectivity options that would make this board versatile enought.

Instead of implementing the 16 inputs and 16 outputs that Ultranet uses, which would render this already big pcb even bigger. I opted to implement only half ✂️, which is good enought for development purposes as I can still receive one of the AES3 streams in its entirety.

The second part of this project will probably have some way to get the full 16 channels, but I think that 8 is enough for now anyway 🤷‍♂️.

At the very beginning, I mentioned that the end goal of this project is to run it over fiber 🔦, so I decided to incorporate an SFP cage along with the appropriate line driver and receiver.

If you want to read more about SFP/SFP+ modules you can read the chapter I wrote on it for my 3G-SDI to fiber project

I also included footprints for DLT1150R and DLT1150T Toslink connectors 🔦. These optical audio connectors support up to 16 Mbps data transfer, so I can't pass Ultranet on them, but they provide an additional layer of flexibility 🤸‍♂️ for connecting various audio devices using the "normal" implementation of AES3. And who knows, maybe I'll implement ADAT someday.

Finally, the star ⭐ feature of this project is the inclusion of Ultranet transmit and receive ports with the isolation transformers and line driver/receiver discussed before.

As a last-minute touch, I added several status LEDs 💡 and three buttons on the 1.8v GPIO port of the tang 9k which I didn't want to use for anything else.

Analog domain

When it comes to handling audio signals of the project 🔊, there are multiple options available. You can use dedicated DACs (Digital-to-Analog Converters) and ADCs (Analog-to-Digital Converters), or you can opt for CODECs (ADC+DAC combined generally with some additional features), each one having its advantages and disadvantages ⚖️.

However, in this case, using a codec is a terrible choice 👎. CODECs typically share the same reference clocks between the ADC and DAC part. This doesn't work for my application because while I generate the master clock for the transmit side, the decoder recovers it from the AES3 stream. In theory, they are the same but in practice various factors will slightly influence the clock speed 🕝.

While I'm sure it's possible to implement some sort of sample rate synchronization, I opted for the much simpler option of using dedicated ADCs and DACs each with their clocks.

The analog to digital converter I choose is the PCM1808 👈. This device is a high-quality single-ended, analog-input 24-bit ADC capable of operating at up to 96 kHz sample rate in stereo mode.

The digital to analog converter I went for is the PCM5102A 👈. This device is a high-performance audio stereo DAC with an integrated PLL (meaning I don't have to generate the master clock), capable of handling up to 384 kHz sample rates and supporting 32-bit PCM interfaces.

The choice of ICs came down to familiarity ✨ with the specific chips and ease of configuration. Given that both the PCM1808 and PCM5102A are well-documented and widely used components by both enthusiasts and professionals, they provide a reliable foundation for my project requirements.

Compared to other ICs, these are configured only by pin strapping 🔌 this means it's easier to troubleshoot, and I don't need to implement another protocol like I2C or SPI in the FPGA just to configure them.

ADC: PCM1808

The schematic of the ADC is almost straight out of the typical application schematic provided in the datasheet. The datasheet does mention that in certain application an additional antialiasing filter could be required. But this is a prototype with the main goal of getting any sound at all 🔊, not necessarily a high-quality one.

The FMT pin is tied to 3.3V for all ICs which tells the ADC to send data in the left-justified format. The other option would be I2S, neither format is the perfect as it depends on the implementation and simply changes the way the data is sent. Simply put, I2S mode offsets the data by one BCLK cycle which is a bit more annoying to deal with.

The other two strapping pins (MD1 & MD0) control whether the IC operates in master or slave mode. The schematic on top is the one from the second ADC which handles channel 3 & 4. The first ADC is almost identical 🪞. It simply has additional test pads on these pins that allow me to easily change this behavior.

This leaves me the flexibility of not needing to implement the word clock & bit clock dividers in the FPGA.

In the end, I did use slave mode because of one very specific line of the datasheet that you could easily miss:

7.3.5.1.1 Master Mode
In master mode, BCK and LRCK work as output pins, timing which from the clock circuit of the PCM1808 device controls these pins. The frequency of BCK is constant at 64 BCK/frame.

7.3.5.1.2 Slave Mode
In slave mode, BCK and LRCK work as input pins. The PCM1808 device accepts 64-BCK/frame or 48-BCK/frame format (only for a 384-fS system clock), not 32-BCK/frame format.

Typically, you would expect a 24 bit ADC to use 48 cycles but the PCM1808 offers the possibility of using a 64 cycle bit clock 🎉. This significantly simplifies the clock generation and also allocates me a bit of time to process the data because I get an "extra" 8 clock cycle per channel to move data around.

DAC: PCM5102A

Once again, the schematic of the DAC is almost straight out of the typical application schematic provided in the datasheet 📋.

The FMT pin is (unfortunately 🤦‍♂️) set to use the I2S format.

Additionally, this DAC has extra pins like the FLT pin which controls the filter used (normal latency FIR or low latency IIR) or the DEMP pin which enables the de-emphasis when used at sampling rate of 44.1 kHz.

It also has the XSMT to allow external devices to mute the DAC with a simple binary signal 🔇. The datasheet provides a good example of how to use this pin to mute the signal in case of an "unplanned shutdown" or under-voltage condition which will avoid (or at least reduce) the dreaded "pop" sound 💥.

PCB

Just like for the schematic, the PCB layout is practically the same as the datasheets.

You will notice the fuckload of test points 🚀 (some being outside the screenshot and always accompanied by their ground point 🌱). This is used to easily connect my logic analyzer and facilitate debugging.

Clocks

Clock signals ⏱️ are the heartbeat of any digital circuit, providing a consistent timing reference that ensures all operations within the system occur in harmony. Without precise clock signals, systems would operate chaotically, leading to data corruption and unreliable performance.

The Tang 9k has a 27MHz crystal 🏃‍➡️ on board and two PLLs on-chip, which could theoretically be used to generate the "master-clock" needed for the audio ICs. However, after conducting preliminary tests before designing the PCB, I found it challenging 😵‍💫 to achieve precise clock generation from these on-chip resources. The internal PLLs did not provide the exact frequencies required for audio processing requirements, and configuring them was a bit complex.

Given that I'm lazy 🥱, at some point I simply didn't want to deal with this anymore, I decided to use a dedicated clock generation chip, specifically the PLL1707.

I can't stress how awesome this chip is 🤩. It's a perfect example of "don't re-invent the wheel". For a few bucks more, it's an excellent choice to offload the generation of a precise and stable clock signal, especially since it's specifically designed for audio applications. One of its key features is its ability to generate frequencies of 512 (up to 768 actually) times the sampling frequency, which means it can produce the 24.576 MHz clock signal (48kHz * 512) needed for my project.

For internal operations within the FPGA that require faster speeds, instead of deriving from the 27MHz clock, I utilized this 24.576 MHz signal and multiplied it by 10 with a PLL to achieve higher-frequency clock signals for internal processes 🧩.

Schematic

By now you should get the idea. I read the datasheet and copied and pasted the schematic 😅. I'm kidding of course, generally I read it through at least once before drawing it 🤡.

The chip is configured to use the "Double sampling rate" mode (SR pin) for a 96Khz sampling frequency (FS1 & FS2 pins) plus CSEL set to high. This configuration gives me the following clocks:

PCB

Unfortunately, the datasheet doesn't provide a typically pcb layout 😕, thankfully this IC is simple to route so it wasn't a big issue. Again, there are a bunch of test points to facilitate debugging.

Board bring-up & mistakes

The bring-up ⚡is the process involving initial testing the board to ensure everything functions correctly. This includes setting up power, verifying analog connections, and ensuring digital 📱interfaces work as intended.

When I first plugged my logic analyzer into the board, I noticed that there was absolutely no activity on the data lines of the analog side 😵. This is weird because the master clock (and the derived word & bit clock) were present, and the ADC should be autonomous 🤖.

Turns out, I connected the 3.3VA and 5VA supply lines to the ADCs and DACs, but I completely forgot to actually supply power to these connections 🔌 which is of course, essential for the chip to power up. Thankfully, as I had plastered the board with test points and 0-ohm resistors, the fix was relatively effortless 👌.

During the first reception test I noticed that while I was sending data and the right clocks to the DAC, I wasn't getting any audio 🔇. It turns out that the XSMT pin cannot be left floating, so I had to add a pull-up. As luck had it, the XMST line ran directly next to the 3.3V supply, so I could simply scrape the solder mask and solder a small resistor. You wouldn't even know it's a bodge. 😅

Further down in the development, I also needed to alter the configuration of the PCM5102A from the I2S format to the left-justified format, which was a bit easier to deal with 😮‍💨.

Another less important issue is that in my haste to get his devboard out the door, I swapped 🔀 the left and right channels of the DACs. Continuing with issues on the DAC side, I also messed up the output filters 🎛️ which reduced the audio quality quite a bit!

Apart from these relatively minor issues, everything surprisingly worked just fine.

FPGA implementation

Ok, let's start writing code (well, for FPGAs it's called RTL).

When I started writing the implementation, I did not have access to any hardware that supports Ultranet, so I started by writing a blind implementation, meaning I wrote both the transmitter and receiver parts at the same time, validating that they were working by connecting them together and looking at logic analyzer captures.

I also foolishly didn't start a git repository right away because at the beginning I was "just messing around". That means that the implementation shown here is mostly the final version for part 1.

Edge detectors

Before we start I need to explain one of the building blocks I used a lot: edge detectors. They give a synchronous notification of an asynchronous edge. Synchronization is conventionally done with a two-stage shift-register that is clocked by the target domain's clock. The shift-register is then extended, and the values are compared with the last two signals:

In layman's term, it lets me "watch" a signal which is not running at the same clock speed (or which isn't even a clock at all).

Transmitter

Here is a pretty good overview of how the transmitter works:

Clock

The Clocks block is responsible for deriving the required clock signals for different parts of the module based on the master clock. It takes the 24.576 MHz clock and generates the following clocks:

• AES3 bit clock running at 24.576 MHz (simply "buffered")
• AES3 word clock running at 192Khz
• I2S Bit clock running at 3.072 MHz
• I2S Word clock running at 48Khz

The process of dividing a clock is simple to do, you simply need a counter. Here is for example the process for the bit clock:

1i2s_bit_clock: process(mclk)  begin
2    if(rising_edge(mclk)) then
3        count_i2s_bclk <= count_i2s_bclk + 1;
4        if(count_i2s_bclk = 3) then
5            i2s_bclk <= not i2s_bclk;
6            count_i2s_bclk <=0;
7        end if;
8    end if;
9end process;

As I said, the aes3 bit clock can simply be "buffered" like so:

1aes_bclk <= mclk;

I2S Deserializer

The I2S Quad deserializer block is responsible for reading the bits of the serial audio data coming from the ADCs in sync with the different clock signals. The special thing about this block is that it takes four different inputs and already integrates the left/right demuxer to output the eight different 24bit vectors.

The module starts with a few edge detectors, the processes run on the much higher +100Mhz clock. Here I am using the bit clock as an example, but they are mostly all the same, you can see the 3 shift register stages and the comparator:

 1detect_bclk_edge: process(clk) begin
 2    if rising_edge(clk) then
 3        zbclk <= bclk;
 4        zzbclk <= zbclk;
 5        zzzbclk <= zzbclk;
 6        if zzbclk = '1' and zzzbclk = '0' then
 7            bclk_pos_edge <= '1';
 8        elsif zzbclk = '0' and zzzbclk = '1' then
 9            bclk_neg_edge <= '1';
10        else
11            bclk_pos_edge <= '0';
12            bclk_neg_edge <= '0';
13        end if;
14    end if;
15end process;

Then there are two processes, the first one is the one that makes the counters tick and more generally, where the flow of data is "managed". The second one is reading the serial data on the positive edge of a bit clock and shifting it into the appropriate buffer when told so by the first process.

 1detect_sample: process(clk) begin
 2    if rising_edge(clk) then
 3        if bsync_pos_edge = '1' then
 4            -- Sync detected, reset every signal
 5            bit_cnt <= 0;
 6            new_data <= '0';
 7        else
 8            if lrck_edge = '1' then
 9                -- Left/right clock edge detected this means new channel -> reset the bit counter
10                bit_cnt <= 0;
11            end if;
12
13            if bclk_pos_edge = '1' then
14                -- Bit clock positive clock edge detected -> increment the bit counter
15                bit_cnt <= bit_cnt + 1;
16            end if;
17
18            if bclk_neg_edge = '1' then  	
19                -- Bit clock negative clock edge detected ->
20                -- Only read the first 24 bits, check the counter and set the signal appropriatly
21                if bit_cnt = 0 then
22                    has_data <= '1';
23                elsif bit_cnt >= 24 then
24                    has_data <= '0';
25                end if;
26            end if;
27
28            -- Raise new_data at the end of the last bit, only for one clk cycle
29            if bit_cnt = 31 and bclk_neg_edge = '1' and lrclk = '0' then 
30                new_data <= '1';
31            else
32                new_data <= '0';
33            end if;
34
35              -- Output the data
36            if lrck_pos_edge = '1' then
37                sample_out_ch_1_r <= sample_ch_1_r_buf;
38                sample_out_ch_2_r <= sample_ch_2_r_buf;
39                sample_out_ch_3_r <= sample_ch_3_r_buf;
40                sample_out_ch_4_r <= sample_ch_4_r_buf;
41            end if;
42            if lrck_neg_edge = '1' then
43                sample_out_ch_1_l <= sample_ch_1_l_buf;
44                sample_out_ch_2_l <= sample_ch_2_l_buf;
45                sample_out_ch_3_l <= sample_ch_3_l_buf;
46                sample_out_ch_4_l <= sample_ch_4_l_buf;
47            end if;
48        end if;
49    end if;
50end process;
51
52get_data: process(clk) begin
53    if rising_edge(clk) then
54        if bclk_pos_edge = '1' and has_data = '1' then
55            if lrclk = '1' then
56                sample_ch_1_l_buf <= sample_ch_1_l_buf(sample_ch_1_l_buf'high-1 downto sample_ch_1_l_buf'low) & sdata1;
57                sample_ch_2_l_buf <= sample_ch_2_l_buf(sample_ch_2_l_buf'high-1 downto sample_ch_2_l_buf'low) & sdata2;
58                sample_ch_3_l_buf <= sample_ch_3_l_buf(sample_ch_3_l_buf'high-1 downto sample_ch_3_l_buf'low) & sdata3;
59                sample_ch_4_l_buf <= sample_ch_4_l_buf(sample_ch_4_l_buf'high-1 downto sample_ch_4_l_buf'low) & sdata4;
60            else
61                sample_ch_1_r_buf <= sample_ch_1_r_buf(sample_ch_1_r_buf'high-1 downto sample_ch_1_r_buf'low) & sdata1;
62                sample_ch_2_r_buf <= sample_ch_2_r_buf(sample_ch_2_r_buf'high-1 downto sample_ch_2_r_buf'low) & sdata2;
63                sample_ch_3_r_buf <= sample_ch_3_r_buf(sample_ch_3_r_buf'high-1 downto sample_ch_3_r_buf'low) & sdata3;
64                sample_ch_4_r_buf <= sample_ch_4_r_buf(sample_ch_4_r_buf'high-1 downto sample_ch_4_r_buf'low) & sdata4;
65            end if;
66        end if;
67    end if;
68end process;

Ultranet muxer

The Ultranet mux block has a simple job, each time the AES3 word clock rises or falls, it needs to increment the channel counter and output the data for said channel. Additionally, it takes a "copy" of the input vectors each time it sees that new_data is rising.

Once again, the module starts with some edge detectors, but the main logic can be seen below. As you can see, it's pretty simple!

 1process(clk) begin
 2    if (rising_edge(clk)) then
 3        if new_data_pos_edge = '1' then
 4            -- Buffer the sample for each input channel
 5            ch1_buffer <= ch1_in;
 6            ch2_buffer <= ch2_in;
 7            ch3_buffer <= ch3_in;
 8            ch4_buffer <= ch4_in;
 9            ch5_buffer <= ch5_in;
10            ch6_buffer <= ch6_in;
11            ch7_buffer <= ch7_in;
12            ch8_buffer <= ch8_in;
13
14            -- Reset the channel counter
15            channel_cnt <= 0; 
16        end if;
17
18        if aes_lrck_edge = '1' then		
19            -- Increment the channel counter on each pulse
20            channel_cnt <= channel_cnt + 1; 
21
22            -- Output the corrsponding sample
23            if channel_cnt = 0 then
24                ch_out <= ch1_buffer;
25            elsif channel_cnt = 1 then
26                ch_out <= ch2_buffer;
27            elsif channel_cnt = 2 then
28                ch_out <= ch3_buffer;
29            elsif channel_cnt = 3 then
30                ch_out <= ch4_buffer;
31            elsif channel_cnt = 4 then
32                ch_out <= ch5_buffer;
33            elsif channel_cnt = 5 then
34                ch_out <= ch6_buffer;
35            elsif channel_cnt = 6 then
36                ch_out <= ch7_buffer;
37            elsif channel_cnt = 7 then
38                ch_out <= ch8_buffer;
39            end if;
40
41        end if;
42    end if;
43end process;

AES3 Transmitter

Here I can't take much of the credit, I heavily based my work on the following S/PDIF transmitter project:

https://ackspace.nl/wiki/SP/DIF_transmitter_project

But I adapted it to support the long 384-bit vector for the two channel statuses as well as supporting the user bits and validity bit. Spoiler: this is going to bite me in the ass later!

Receiver

Here is the overview of how the receiver works:

AES3 Receiver

I can't take credit for this block either, it's almost a copy-paste of the fantastic aes3rx project:

https://opencores.org/projects/aes3rx

This block takes a very fast clock plus the aes3 input and spits out the recovered clock signals (bit clock & word clock), the sound data and the block start signal.

It also output an "active" signal that can be used to indicate that a signal is being received.

Clocks

Just like the transmitter, the Clocks block is responsible for deriving the I2S clock signals based on the AES3 clocks and bsync signal. It takes the 12.288 MHz bit clock and 192 kHz word clock and generates the following clocks:

• I2S Bit clock running at 3.072 MHz
• I2S Word clock running at 48Khz

The clock dividers are a bit different from the ones used for the transmitter. First, I have edge detectors for bsync, aes_bclk and aes_lrclk.

Then the I2S bit clock divider is a standard divider with the addition of bsync check so that it resets to the correct state.

 1i2s_bit_clock: process(aes_bclk)  begin
 2    if(rising_edge(aes_bclk)) then
 3        -- Make sure the clock is properly synchronized at the block start
 4        if(bsync_pos_edge = '1') then
 5            i2s_bclk <= '1';
 6            count_i2s_bclk <= 0;
 7        else
 8            -- Divide the AES3 bit clock to get the I2S bit clock 
 9            count_i2s_bclk <= count_i2s_bclk + 1;
10            if(count_i2s_bclk = 1) then
11                i2s_bclk <= not i2s_bclk;
12                count_i2s_bclk <= 0;
13             end if;
14        end if;
15    end if;
16 end process;

The word clock is even more complex, instead of synchronizing to only the AES3 word clock and the bsync signal, I also make sure it's properly synchronized to the bit clock:

 1i2s_lr_clock: process(clk) begin
 2    if(rising_edge(clk)) then
 3        -- Make sure the clock is properly synchronized at the block start
 4        if(bsync = '1') then
 5            i2s_lrclk <= '0';
 6            count_i2s_lrclk <= 0;
 7        else
 8            -- Make sure the word clock is properly synchronized to the bit clock
 9            if(aes_bclk_neg_edge = '1' and aes_lrclk_pos_edge = '1') then
10                -- Divide the AES3 word clock to get the I2S word clock 
11                count_i2s_lrclk <= count_i2s_lrclk + 1;
12                if(count_i2s_lrclk = 1) then
13                    i2s_lrclk <= not i2s_lrclk;
14                    count_i2s_lrclk <=0;
15                end if;
16            end if;
17        end if;
18    end if;
19end process;

Ultranet Deserializer

The Ultranet deserializer block is similar to the I2S deserializer of the transmitter. It is responsible for reading the bits of the serial audio data coming from AES3 receiver block in sync with the different clock signals. It then outputs a 24bit vector containing the audio data, a 3bit vector containing the channel index associated with the data and a "new data" signal that is asserted when the data is ready to be used.

Just like the I2S deserializer, there are two processes, the first one is the one that makes the counters tick and keeps things in sync. The second one is reading the serial data and shifting it into the buffer when told so by the first process.

 1detect_sample: process(clk) begin
 2    if rising_edge(clk) then
 3        -- Check if we are starting a new block
 4        if bsync_pos_edge = '1' then 
 5            -- Yes, reset counters and signals
 6            bit_counter <= 0;
 7            channel_counter <= 4;
 8            new_data <= '0';
 9        else
10            -- No, check if we are on the rising or falling edge of the word clock
11            if lrclk_edge = '1' then
12                -- Yes, reset the bit counter
13                bit_counter <= 0;
14                -- Increment the channel counter up to the defined number of channels then reset to 0
15                if channel_counter < (CHANNELS-1) then
16                    channel_counter <= channel_counter + 1;
17                else
18                    channel_counter <= 0;
19                end if;
20            end if;
21
22            -- Increment the bit counter (up to 32 bits) on a rising edge of the bit clock
23            if bclk_pos_edge = '1' then
24                if bit_counter < 31 then
25                    bit_counter <= bit_counter + 1; -- increment bit_counter until bit 31
26                end if;
27            end if;
28                
29            -- Sample the data on the falling edge of the bit clock
30            if bclk_neg_edge = '1' then  	
31                -- Set the audio data region signal if we are in the correct range [....AAAASSSSSSSSSSSSSSSSSSSSEUCP]
32                if bit_counter = 4 then
33                    in_sound_data_region <= '1';
34                elsif bit_counter >= 24+4 then
35                    in_sound_data_region <= '0';
36                end if;
37            end if;
38                
39            -- Assert the new data signal within the unused 4bits at the end of the frame
40            if bit_counter = 30 and bclk_neg_edge = '1' then 
41                new_data <= '1';
42            else
43                new_data <= '0';
44            end if;
45        end if;
46    end if;
47end process;
48    
49-- Send the data out
50sample_out <= sample_data;
51channel <= to_unsigned(channel_counter, channel'length);
52
53get_data: process(clk) begin
54    if rising_edge(clk) then
55        -- Receive individual bits for audio-data (24 bits) on the rising edge of the bit clock and only if in the correct region
56        if bclk_pos_edge = '1' and in_sound_data_region = '1' then
57            -- in AES3/EBU the first bit after preamble is LSB, so we have to shift from the left to the right
58            sample_data <= sdata & sample_data(sample_data'high downto 1);
59        end if;
60    end if;
61end process;

Ultranet demuxer

The Ultranet demuxer is probably the simplest block on this whole project. In retrospect, it should probably be integrated into the deserializer. The only thing it does is splitting the audio data into individual vectors according to the index received when the new data signal is asserted:

 1process(clk) begin
 2	if (rising_edge(clk)) then
 3	    -- Store individual channels to output-vectors on the rising edge of new data
 4		if new_data_pos_edge = '1' then
 5			if channel = 0 then
 6				ch1_out <= sample_in;
 7			elsif channel = 1 then
 8				ch2_out <= sample_in;
 9			elsif channel = 2 then
10				ch3_out <= sample_in;
11			elsif channel = 3 then
12				ch4_out <= sample_in;
13			elsif channel = 4 then
14				ch5_out <= sample_in;
15			elsif channel = 5 then
16				ch6_out <= sample_in;
17			elsif channel = 6 then
18				ch7_out <= sample_in;
19			elsif channel = 7 then
20				ch8_out <= sample_in;
21			end if;
22		end if;
23	end if;
24end process;

I2S Transmitter

Thanks to the move from I2S mode to left-justified mode on the DACs the implementation of the transmitter is basic. As always, there are some edge detectors, followed by the two main processes.

The first one is keeping the bit counter in sync in relation to the bit clock and reset signal. It also handles loading the sample buffer on the last bit. The second process simply output the audio data to the correct channel.

 1detect_sample: process(clk) begin
 2	if rising_edge(clk) then
 3		if reset_n = '0' then 
 4			bit_counter <= 0;
 5		else
 6            -- If the left/right channel changes, reset the output bit counter
 7			if lrclk_edge = '1' then
 8				bit_counter <= 0;
 9			end if;
10                
11            -- Increment the bit counter a positive edge of the bit clock
12			if bclk_pos_edge = '1' then
13				bit_counter <= bit_counter + 1;
14			end if;
15                
16            -- Update the sample buffers on the last positive bit clock edge 
17            -- TODO: Shouldn't this be on the negative edge of LRCLK?
18			if bclk_pos_edge = '1' then  	
19				if bit_counter = DATA_WIDTH-1 then
20                    sample_ch_1_l_buf <= sample_ch_1_l;
21                    sample_ch_1_r_buf <= sample_ch_1_r;
22                    sample_ch_2_l_buf <= sample_ch_2_l;
23                    sample_ch_2_r_buf <= sample_ch_2_r;
24                    sample_ch_3_l_buf <= sample_ch_3_l;
25                    sample_ch_3_r_buf <= sample_ch_3_r;
26                    sample_ch_4_l_buf <= sample_ch_4_l;
27                    sample_ch_4_r_buf <= sample_ch_4_r;
28				end if;
29			end if;
30		end if;
31	end if;
32end process;	
33	
34send_data: process(clk) begin
35	if rising_edge(clk) then
36		if reset_n = '0' then
37            -- Reset asserted, send zeros to the output
38			sdout_1 <= '0';
39			sdout_2 <= '0';
40			sdout_3 <= '0';
41			sdout_4 <= '0';
42		else
43            -- Normal state, output the proper bit (left or right) for each channel on the negative bit clock edge
44			if bclk_neg_edge = '1' then  	
45                if lrclk = '1' then
46                    sdout_1 <= sample_ch_1_l_buf(DATA_WIDTH - 1 - bit_counter);
47                    sdout_2 <= sample_ch_2_l_buf(DATA_WIDTH - 1 - bit_counter);
48                    sdout_3 <= sample_ch_3_l_buf(DATA_WIDTH - 1 - bit_counter);
49                    sdout_4 <= sample_ch_4_l_buf(DATA_WIDTH - 1 - bit_counter); 
50                else
51                    sdout_1 <= sample_ch_1_r_buf(DATA_WIDTH - 1 - bit_counter);
52                    sdout_2 <= sample_ch_2_r_buf(DATA_WIDTH - 1 - bit_counter);
53                    sdout_3 <= sample_ch_3_r_buf(DATA_WIDTH - 1 - bit_counter);
54                    sdout_4 <= sample_ch_4_r_buf(DATA_WIDTH - 1 - bit_counter);
55                end if;
56			end if;
57
58		end if;
59	end if;
60end process;    

It's working?

Well, after a lot of tuning, the answer is YES!🎉 And honestly, it's working pretty well considering that this is my first time working with FPGAs. Here's a logic analyzer capture I took right after I got everything up and running for the first time 🏆:

I'm much happier with the implementation of the receiver, it's much more stable/polished than the transmitter. The biggest thing by far is that the reset signal is actually used and everything re-sync correctly after it has been asserted.

I think that, the only reason the transmitter seems to work at all is that the clocks are never actually stopped during operation 😅.

Still, it’s more than good enough for a first prototype 👍.

Testing on real hardware

So let's have fun with some real hardware that supports Ultranet. I managed to borrow these devices:

• The Midas DL-16 which is a 16 Input, 8 Output Stage Box with 16 Midas Microphone Preamplifiers, ULTRANET and ADAT Interfaces.
  I can use it in standalone mode as an overkill A/D converter to convert the 16 analog inputs to Ultranet.
• The Turbosound TFX122M-AN which is a Coaxial 1100W 2-Way 12" Stage Monitor with Klark Teknik DSP Technology and ULTRANET.
  Unfortunately, it's the only piece of hardware with an Ultranet input I had access to. It has the downside of being a loudspeaker so bit-shift mistakes at 2am are quite annoying. But at the same time, the configuration app proved unexpectedly useful for debugging.

Transmitter

I started by verifying the transmitter. I was feeling pretty confident since everything had worked on my devboard so far. So, I plugged the RJ-45 cable into the speaker, expecting things to work. But then, disaster struck 🌪️. I couldn't even select the Ultranet input from the speaker's built-in controls.

F---, that means that either my implementation is not working at all or that I messed-up something 😕. I decided to troubleshoot by downloading the Turbosound Edit app and connecting to the speaker. Unexpectedly, I was able to force the input to be an Ultranet input but was then immediately prompted by this error message:

To my surprise 🤯, even though the error appeared, the speaker did seem to switch to the Ultranet input. I started hearing something that could only be described as audio thrown into a blender, chopped up, and distorted (Fun fact this first test was at 3am, I wasn't the favorite person in the morning!).

This told me that my implementation wasn’t completely broken. It was close, but just not quite there yet.

After much troubleshooting 🛠️, I figured out that the Ultranet inverts the validity bit. Once I applied this fix, I was able to get rid of the Check ULTRANET! error message. This discovery not only unlocked the built-in controls but also the VU-meter on the Turbosound Edit app:

This was interesting because I only sent an audio signal on channel 1, not the third one 🧐. During testing, I got multiple variants of this, for example, sending audio on channel 2 resulted in audio on channel 2, 4, 6 and 8.

No matter what adjustments I made, the audio was always barely recognizable, and it sounded like it was skipping samples.

I also went down's the rabbit hole of updating the speaker because I noticed that the changelog included something about Ultranet compatibility. Unfortunately, this didn't change anything to my situation.

At that point, I decided to take a step back from the transmitter and turn my attention to the receiver, maybe I'll have better luck 🍀.

Receiver

So, the receiver… well, how do I put this? It was even worse than I expected 😢. I couldn't get anything stable or consistent. All I could capture were small chunks of audio, with the aes3rx module showing an "active" status only intermittently. Definitely not the kind of reliable performance I was aiming for.

At this point, I decided to go back and re-watch the video that originally inspired this whole project 📺. While watching Christian troubleshoot similar issues, I noticed that he had solved his problems by increasing the clock speed going into the aes3rx module, pushing it up to 200 MHz 💨. This immediately stood out to me as a potential fix for my situation.

Note: At this point I was still deriving the "main clock" from the 27 MHz crystal provided by the Tang Nano 9k. I was also only providing a ~100MHz clock to the aes3rx module.

So, I went ahead and tested this. I decided to increase the PLL factors of the main clock to push it closer to that 200 MHz target. Unfortunately, this is where my lack of experience with FPGAs really showed. No matter what I tried, I couldn't make it work properly. The best I could manage was around 150 MHz, and anything beyond that would cause the module to brick 🧱.

But after much trial and error, I stumbled upon a "solution". Instead of using the 27 MHz crystal, I switched to the 24.576 MHz clock from the PLL1707. I fed that into the PLL, adjusting the factors until I could reach a 245.76 MHz "main clock". And just like that… I was able to decode the data.

While this was a breakthrough, I’m not entirely happy with the outcome 😕. For one, it means that 44.1 kHz Ultranet support is now off the table. Moreover, the whole project now relies heavily on a "patch" that I don’t fully understand, something I’ll definitely need to revisit for part 2 🤔.

But hey, at least there is audio coming out of the damn thing 🎉 which means I now needed to fix the transmitter.

Transmitter again

With this renewed boost in confidence 🚀, I was finally ready to tackle the transmitter once more. Knowing that the receiver was working properly, and that the transmitter had worked with my receiver before, meant that a significant portion of the transmitter's implementation was already functioning as expected. The hard part seemed to be behind me.

I quickly ruled out a few possibilities: the preambles were fine, the audio data was correct, and the validity bit was being set properly. That narrowed it down to a few suspects: the channel status bits, the user bits and the parity calculation.

Determined to get to the bottom of this, I painstakingly recorded the Ultranet stream coming from the DL-16 under various input combinations 💾. I spent a few hours capturing 500ms slices of data at 200 MHz, trying to build a database in which I could search for any anomalies that could give me a clue.

After writing a script to analyze all of this 📜, the conclusion was pretty simple:

The parity was untouched (duh, or it wouldn't work with off-the-shelf chips 🤦‍♂️), the user bits were unused (always 0) and the channel status bit repeated the following pattern:

000000000000000000000000000000000000000000000000000000000000000011000000111100110000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

Interpreted like the 2 AES3 subframes but with 8 subframes it would provide this information:

• Subframe 1: 00000000 11000000 00000000 00000000 00000000 00000000
• Subframe 2: 00000000 11000000 00000000 00000000 00000000 00000000
• Subframe 3: 00000000 01000000 00000000 00000000 00000000 00000000
• Subframe 4: 00000000 01000000 00000000 00000000 00000000 00000000
• Subframe 5: 00000000 00000000 00000000 00000000 00000000 00000000
• Subframe 6: 00000000 00000000 00000000 00000000 00000000 00000000
• Subframe 7: 00000000 01000000 00000000 00000000 00000000 00000000
• Subframe 8: 00000000 01000000 00000000 00000000 00000000 00000000

While writing this article, now that I look at it, byte 2 does look like a channel offset, but who knows if I'm reading that correctly 🤷‍♂️, that's for part 2 of this project.

Coming back to my issue, even after using this bit sequence in the aes3 transmitter (and verifying that the correct bits are indeed being sent), it didn't change much. I did get better sound somehow 🤬🤯.

Oh, f---, that was the issue!

At some point, I decided I’d had enough of listening to garbled audio or staring at endless walls 🗑️ and went all-in: I dedicated a full day to analyzing logic analyzer traces instead. And sure enough, that’s when I found it.

Looking closely at the preambles sent by the DL16, I noticed something peculiar. They always started with a 1. The typical pattern looked like this: 1110010. Not once did I see the alternate pattern that starts with a 0, like 0001101.

I then repeated the process for my implementation and bingo. That’s when I saw the problem: my transmitter was happily alternating between both versions of the preamble.

This immediately tickled my brain, why would the signal from Behringer only use one form of the preamble?

That’s when I remembered a modification I made earlier while adding support for user bits in my S/PDIF transmitter module 📝. I knew I'd need to include those in the parity calculation, so I updated the logic like this:

1parity <= data_in_buffer(23) xor data_in_buffer(22) xor data_in_buffer(21) xor data_in_buffer(20) xor data_in_buffer(19) xor data_in_buffer(18) xor data_in_buffer(17)  xor data_in_buffer(16) xor data_in_buffer(15) xor data_in_buffer(14) xor data_in_buffer(13) xor data_in_buffer(12) xor data_in_buffer(11) xor data_in_buffer(10) xor data_in_buffer(9) xor data_in_buffer(8) xor data_in_buffer(7) xor data_in_buffer(6) xor data_in_buffer(5) xor data_in_buffer(4) xor data_in_buffer(3) xor data_in_buffer(2) xor data_in_buffer(1) xor data_in_buffer(0) xor user_status_shift(23) xor channel_status_shift(23);

But remember how I mentioned earlier that I had extended the user and channel status vectors to 384 bits to match the full length 📏?
Yeah. Well, the parity calculation? Still hardcoded to pull from bit 23.

As soon as I fixed the logic to XOR the correct final bits of the expanded vectors, bam. Everything lined up. It just worked 🔥. I also went ahead an added the missing validity bit in the calculation. The reason I got better sound when I added the channel status bits is probably because the parity calculation was correct more often for some reason 😅.

It would seem that in every project there is an issue where I sink countless hours of debugging just to find out it's one of the stupidest mistakes ever. But hey, that's life … 🤡

It's working (encore)?

Yes! This time, it’s really working! 🎉

Well almost there is something really strange happening: the channel order is correct, meaning they are in sequence, but the channel offset is all kinds of messed up. For example, if I send audio into channels 1-2 of the DL-16, it always ends up on channels 5-6 on my devboard. Even weirder: when using the "Through" port of the TFX speaker, the channel offset becomes completely random 🎲. Every so often it’s 1-2, other times 3-4, etc.

The odd thing is, when I plug the DL-16 into the TFX and look at the VU meters in the Turbosound Edit app, it indicates that the audio first gets received on the wrong channels, but then automatically corrects itself to the right ones (Probably after the channel status has been received completely). This is the fishy behavior I mentioned in the research section of this article 🐟.

But hey, let’s not get bogged down in the details. I GOT ULTRANET WORKING!!!🥳 And, more importantly, this weird offset issue doesn’t seem to affect devboard-to-devboard communication, which is somewhat of a relief 😌.

After around two and a half months of intense work, countless hours of testing, and plenty of moments wondering if I was losing my mind, I finally have a fully functional transmitter and receiver implementation of Ultranet.

This was no small feat. Ultranet is a proprietary protocol, it is based on AES3, but with its quirks and implementation challenges. Without access to official documentation, a good portion of the process involved reverse-engineering, experimenting, and a lot of trial and error. But ultimately, it paid off.

Both the transmitter and receiver are now reliably exchanging data in sync, and the system is behaving almost as expected 🥳.

What's next

So… what’s next? 🤔 If you’ve been reading closely, you probably noticed me hinting at a part 2 more than a few times throughout this article. For once, I’m actually going to split both the development process and the write-up into two parts. This first "prototype" phase is already a beast on its own, and I want to give the next phase of the project the attention it deserves.

Part 2 will pick up where this leaves off. Here's a brief look at what that will include:

• 🧮 (Hopefully) Tackling the channel indexing issue: This is the one big unknown about Ultranet that is still left, and I want to figure out the damn thing.
• 🔌 Schematic: I want to revisit the audio side of the design, particularly on adding proper balanced inputs and outputs.
• 🧩 Final PCB layout(s): This first version was mostly a proof of concept. Part 2 will focus on finalizing the board design which will probably be multiple interconnected ones.
• 📦 1U/2U Racked case: Time to move from bare PCB on the bench to something that actually looks and feels like a finished product.

Now, just to set expectations: this second part is still a long way off. I usually don’t start writing about a project until it’s at least 90-95% complete, and as of right now… well, the design phase hasn’t even begun. It is coming because I have a (very loose) deadline, but might be a while before you see the next article about this project 📅.

Conclusion

Throughout this project, I questioned, more than once whether sticking with an FPGA implementation was the right call 🤔. There were definitely moments where the idea of switching to the AK4114 felt tempting. It would’ve simplified many things and saved me from a few late nights staring at timing diagrams wondering what broke this time. But the AK4114 is officially end-of-life, not to mention pretty expensive for what it does so that option was quickly shelved 🗄️.

There are other chips on the market from Texas Instruments and others, that could’ve filled the gap. But let’s be honest: where’s the fun in taking the easy route when you could be fighting with VHDL and constraints files instead? 😭.

I don't think I would go with the FPGA route if this was a work project, but as this is a side project that will be used in a non-critical part of my infrastructure, I achieved my primary goal with this massive project: learning 👨🏻‍🎓. Diving into the deep end with the FPGA kept the challenge alive, and it ended up being a fantastic learning experience

By sticking to the original goals, I set out at the beginning, I had to understand how things and why. And as frustrating as that was at times, it paid off. My understanding of FPGAs, and real-time audio protocols has improved quite a bit. Honestly, there’s no better way to learn than by getting your hands dirty, messing around with stuff, breaking it 🪓, and then figuring out how to fix it. It’s chaotic 💥, but it works.

Looking back, I'm incredibly happy with what I’ve built so far 🤩. This is only Part 1 of the journey, but even at this stage, it's a solid milestone 🚩.

If you’ve made it this far, thanks for reading! I hope Part 2 ends up being even better, and who knows, maybe next time I’ll even sleep. Maybe.

This is a stupidly long article, it details the different phases thoroughly, you'll need probably some time to really read it

Every once in a while, I have the pleasure of working with my local choir. Every few years, they perform on stage, featuring around 3 hours of music 🎶. In the past, my involvement was mostly behind the scenes👻, helping wherever I could. However, last year, I decided to take on a more ambitious role and conduct an experiment that would elevate the entire performance.

I took every piece of video equipment I could get my hands on and set out to record the shows and provide live Image Magnification (IMAG) of the band 🎥. This would be a significant step up from previous years, where recording had been outsourced with mixed results. The idea was to bring a new level of engagement for both the audience and the performers, while also creating a high-quality record of the event 🎞.

The rest of the tech staff later admitted that they were, at first, skeptical of this 🤨. But it turned out to be a resounding success. The live IMAG was enthusiastically received by both the singers and the audience, adding a dynamic visual element that enhanced the overall experience 🥳. It allowed those seated further back to see the work of the musicians 🥁. As for the recording, the quality far exceeded my expectations, surpassing in many ways what had been achieved in previous years 🤩.

Why

The last show was wonderful, but I always want to improve things. Something that's been bugging me in my video setup is that it was a mess. I mean, I had HDMI cables here, SDI there, some RTSP streams, and even NDI feeds. Talk about a tech salad 🥗!

Don't get me wrong, it worked… mostly, and that's what happens when your budget is almost none. But I had to run custom scripts before the show 📜 and more than once the IMAG showed the blank Elgato logo or a freeze-frame ⬛. So, I kept thinking, "There's got to be a better way to do this."

As I mentioned, the issue had always been the budget 💰, I was at the time an apprentice in a different field with no contacts or knowledge in the AV production world. Video isn't exactly the cheapest part of a live production. The technology evolves rapidly, which means the quality is always increasing.

So for the next show, I want to do one thing: simplify the heck out of my video system, specifically transport 🔌.

I started digging into different options and, there are a few contenders:

• NDI: This system is pretty slick, but there is a catch: you either need fancy cameras that speak NDI right out of the box, or you have to shell out for converters that will set me back at least 300 EUR a pop 🙁. Not to mention that if you want to get low latency, you need special mixers.
• RTSP: Now, this one's tempting: It's wonderful and very popular, but it's got a bit of a lag issue, and you still need converter boxes. Although they are a bit cheaper.
• HDMI: It's pretty reliable but length is a severe issue 🔭 unless you use active cables.
• SDI: Now we're talking! This is like the Goldilocks of video options for me. It's not dirt cheap, but compared to the others, it's a steal. You can find affordable converters to and from HDMI and it's used all over the place in pro setups.

But wait, it gets better! SDI got a neat trick up its sleeve - you can easily convert it to fiber ⚪. Like effortlessly convert it!

My idea is the following: an MPO-12 breakout (fancy connector with 12 fibers) and an armored MPO-12 cable. Throw them in a DIY stage box, and boom! We're in business: one cable, multiple cameras. This setup would be like the Swiss Army knife 🔪 of video transport. I'm thinking of something like 2 fibers for 10 Gb Ethernet 🌐, at least 8 for video feeds 📹, and 2 spares that I'll probably use for audio in the future.

However, the cost of fiber converters can be a hurdle, almost as much as IP converters (NDI/RTSP). For example, Blackmagic offers a 12G SDI to fiber converter priced at around 155 EUR 💸:

https://www.blackmagicdesign.com/fr/products/miniconverters/techspecs/W-CONM-29

While this is a reliable and professional option, the price tag is a bit hefty for a project that's meant to be low-cost and accessible. I don't really need 8k video, 1080p60 is more than fine for IMAG, so 3G-SDI will do.

Unfortunately, I couldn't find a cheaper alternative, even for lower data rates. I was on the lookout for more budget-friendly alternatives, and purely by chance, I stumbled upon this post on X by twi_kingyo.

金魚

適当なSFPモジュールで3G-SDI信号伝送できちゃって草　　数10kmを光ファイバ伝送できちゃうな

The post was a game-changer for me. From the picture, it certainly looks like SDI-HDMI converters plugged into a test board with a fiber cable in the middle. Very crude, DIY approach to 3G-SDI to fiber conversion, but that looked both affordable and in line with what I had been envisioning.

As I read a bit more, I immediately thought that this is precisely what I want to do

Research

I started this journey by researching a ton on the two major components of this project, namely SDI and SFPs.

SFP / SFP+

SFP (Small Form-factor Pluggable) and SFP+ (enhanced SFP) modules are compact, hot-swappable transceivers used in networking to transmit and receive data over optical or copper connections. They are widely used in switches, routers, and other networking equipment.

Their key features include

• Form Factor: Small size allows for high port density.
• Hot-swappable: Can be replaced without turning off the device.
• Versatility: Supports various protocols (1GbE / 10GbE / Video).

See this Wikipedia page about them for more information:

Small Form-factor Pluggable - Wikipedia

SFP modules take very few signals:

Most of them don't need to be dynamically adjusted, and some can be ignored outright. As long as the module gets power, has the correct rate and has its transmitter is enabled, it should work fine.

What's even better is that basic modules (short distance, multimode ones) are relatively "passive". Some include a reclocker that resyncs the data, but not always.

This means that, as long as it's a differential signal, you can feed just about anything to the module

From the techsupportmacgyver community on Reddit: UART over sfp fiber optic finally working

Explore this post and more from the techsupportmacgyver community

Experiment With SFP Modules With This Handy Breakout

While most home networking hardware comes with network ports baked in from the factory, industrial grade gear is typically more versatile. Using standards like Small Form-factor Pluggable, or SFP, …

And, as long as they support it, they can be relatively easily managed using the DDM (Digital Diagnostics Monitoring) protocol

Optical Power Meter (with SFP and DDM protocol)

To build DIY optical power meter with standard SFP module and Arduino - Can measure optical power in dbm and watt - Can Enable/Disable TX power output (laser source) - Can debug via UART And Arduino Library - a lib for SFP/DDM interfacing (not only optical sfp transceiver - to interface and interpret DDM (Digital Diagnostics Monitoring ) protocol (which used in most optical fiber communication) scheme and format - to debug, monitor, detect alarm and control SFP via DDM - to extend the capability of handling data TX/RX interface (Arduino data over optical fiber)

GitHub - feuerrot/sfp-i2c: Read the data of an SFP(+)-module and print it pretty

Read the data of an SFP(+)-module and print it pretty - feuerrot/sfp-i2c

What's even better is that they are cheap. The SFP+ transceivers that I have are the DELL FTLX8571D3BCL-FC. I got them for around 8 EUR, but you can get them cheaper: here is an eBay listing for ten modules for 70 EUR.

https://www.ebay.fr/itm/116299329366

There are special ones for video that can handle weirder and faster signals with better signal integrity (12G-SDI for example) but from my testing, 3G SDI works just fine on these modules.

SDI

SDI (Serial Digital Interface) is a family of digital video interfaces first standardized by SMPTE. It's a widely used family of standards for transmitting uncompressed digital video signals over coaxial or fiber optic cables. It's primarily utilized in professional broadcasting and video production. SDI enables high-quality video transmission with low latency, making it ideal for live broadcasts and studio environments.

It supports a ton of formats 📼📀💾 described in the following table:

SDI uses uncompressed digital video and audio formats. The data is typically encoded in a YCbCr color space, with 10-bit or higher color depth, ensuring a high dynamic range and color fidelity. Alongside video, an SDI signal may contain up to 16, 48 kHz, 24-bit audio channels.

Data is encoded in NRZI format, and a linear feedback shift register is used to scramble the data to reduce the likelihood that long strings of zeroes or ones will be present on the interface. Thanks to NRZI encoding, the interface is self-synchronizing and self-clocking ⏱. SDI uses a form of forward error correction to maintain signal integrity, which is especially important for long-distance transmissions 🔭

On the physical layer side, SDI transmits signals using coaxial cables with BNC connectors, designed for minimal signal loss and interference. And as mentioned, it can also use fiber optic cables for longer distances and increased bandwidth.

See the Wikipedia page for more details:

Serial digital interface - Wikipedia

SDI is way more complicated to handle and most often requires an FPGA with specialized components, see this DIY pattern generator for example:

Arduino Does SDI Video With FPGA Help

If you are running video around your home theater, you probably use HDMI. If you are running it in a professional studio, however, you are probably using SDI, Serial Digital Interface. [Chris Brown…

Thankfully, for this project, I don't actually need to decode/encode anything myself. Just to convert signals, which is generally cheap.

First prototype

After this extensive research, It would seem that all that I really need is a cable equalizer for RX and a cable driver for TX to convert the 75-ohm single-ended and 100-ohm differential pairs 🤷‍♂️.

When I saw @twi_kingyo post, I quickly found the LMH0397, which looked prefect at first glance. The description said 3G SDI bidirectional I/O with integrated reclocker.

I got very excited 🤪 and quickly (too quickly) designed a PCB and sent it to production 🏭.

I usually spend at least a week 📅 on a prototype. However, I treated this more as a breakout board than a proper prototype, which means I skimmed 🏄‍♀️ through plenty of things.

And it worked, well, partially worked.

Stupid mistake

In my haste, I didn't fully read the datasheet 🙄. While it is bidirectional in the sense that I can do both directions. It cannot, however, do it at the same time.

Something that I would have seen if I read the f-ing 🤬 datasheet:

The LMH0397 is a 3G-SDI 75-Ω bidirectional I/O with integrated reclocker. This device can be configured either in input mode as an adaptive cable equalizer or in output mode as a dual cable driver, allowing system designers the flexibility to use a single BNC either as an input or output port to simplify HD-SDI video hardware designs.

If I had read things more carefully, I would have done things differently, but it worked and that meant I had a proof of concept.

Second prototype

The second prototype was very cost minded 💰. My target was around 25eur per converter

The LMH0397 is a great chip, but it is 18.5 EUR per unit 💸 in low volumes and has redundant features not needed for a simple media converter.

I spent a while searching for an alternative. First thing I did is to take the reclocker out of the equation 🧮 which, while useful, isn't needed in most cases, especially at lower data rates. Now, I needed a simple cable equalizer and a cable driver. There are a few options, for instance Texas Instrument or Semtech have some interesting chips.

But the ones I choose are from Microchip, the EQCO30T5 and EQCO30R5.

While these chips are marketed as HD-SDI Transmitter/Receiver, they are capable of 3G-SDI Video. Interestingly 🤔, they also seem to be able to be used for a data back-channel and power over coax, but this won't be of any use for me.

Schematic

The schematic (at least the interesting parts) is based on the typical application circuit of both schematics. Compared to the LMH0397, the EQCO30T5 and EQCO30R5 are super simple to connect.

PCB

This is the first prototype with the appropriate dimensions, my plan was to fit everything into a 1U case (fiber splitter, converter modules, …). This means it has to be at most 45 mm tall, but I decided that my target would be 35 mm 📏. This would leave enough space for the chassis, mounting & cables.

First test

Once I received the PCBs, I immediately soldered four chips on two separate boards. Powered them up and amazingly there wasn't any magic smoke 🌋!

I then screwed in SMA to BNC adapters and connected my HDMI-SDI & SDI-HDMI 🖥️ converters. Same as before, to avoid destroying an SFP+ module, I took a 1m DAC cable and connected the two boards.

And it worked! I got a picture on my monitor!

But I was far from done 😓.

Issues for longer distances

Using a 1m DAC is fine and all, but the goal is at least a 50m distance. To start things out, I used a 15m cable and as the video showed, it still worked. Somewhat

I used Jellyfin to play videos on the output and mysteriously, while I had the window in the foreground everything was fine, no issues at all! But, as soon as I clicked elsewhere, the link crashed and would not come back up.

While the "Sync" LED indicated that it was trying to sync, using my 50m fiber cable didn't show any picture in any condition!

After some investigation, I realized that the only thing that changed in the source picture was the color of the title bar of the window:

After grabbing the pixel color (which was RGB 43, 43, 43), I did a quick test with paint to try to reproduce the issue. And as you can see, it appears that this color is indeed part of the problem:

My best guess is that this color somehow translates to the gray (RGB 68, 68, 68 YCbCr 68, 128, 128) part of the SDI pathological test pattern.

The SDI pathological test pattern is specifically designed to stress test the SDI equalizer and PLL performance. The test pattern consists of a static test image with the top half of the lines filled with a shade of magenta, and the bottom half of the lines filled with a shade of gray.

22.1.4. SDI Pathological

From what I understand, these colors basically produce long strings of zeros and ones 👨‍💻 in the data stream. This type of pattern is particularly challenging for SDI equalizers and PLLs to process and keep synced correctly.

At this point, I was sure that the issue was caused by a bad design on my part 🤦‍♂️ and feared that maybe the EQCO30T5/EQCO30R5 were pushed too far with 3G SDI. However, I couldn't shake off the feeling that there might be something else at play here 🤔.

So instead of re-thinking my test setup, I went ahead and started working on the third prototype.

Third prototype

Alright, so, let's dive into the third prototype 3️⃣.

The second prototype had many issues, the biggest one is, as demonstrated, the SDI pathological test patterns. This was the main thing I wanted to tackle with this iteration, and I was hopeful that it would be the last one.

Changes

SDI equalizer

First off, I swapped out the EQCO30R5 SDI equalizer for the LMH0344.

While both chips are designed for SD-SDI & HD-SDI with the capability to go up to 3G-SDI, the EQCO30xx chips seem not to be designed for this application but more to be used in the other direction.

On the other hand, the datasheet of the LMH0344 talks way more about 3G-SDI. Alongside that, it also has a Mute pin and Cable/Carrier detect signaling pin. It also mentions that the footprint is compatible with the LMH0044, LMH0384 and LMH0074; It also states that it replaces both the GS2974A and GS2974B chips from Semtech.

This gives me a lot of flexibility in case I want to change chips in the future 📅.

But, as it turns out, the footprints of the EQCO30R5 and LMH0344 are extremely similar (at least the important parts), a few pins are marked DNC on the EQCO30R5 and a capacitor is needed by the LMH0344 where there isn't one for the EQCO30R5.
Both of these issues can be solved by adding 0-ohm resistors that may or may not be placed during assembly.

In my head, this switch was good because the new component offered better performance and more flexibility 🤸‍♂️.

Power supply

During my tests, I noticed that the AMS1117 LDO regulator that I was using to provide 3.3v to the SFP+ module and other ICs was getting rather hot 🔥.

A quick search online + digging around in datasheets revealed the issue:

• The SFP+ module alone consumes around 500mA
• The EQCO30T5 typically consumes 45mA
• The EQCO30R5 typically consumes 55mA

Which gives a total of 600mA ⚡.

A quick calculation for the max power dissipation of the AMS1117 shows that current consumption is borderline over the limit, which explains why I had a furnace on my board 😂.

While I choose an LDO to reduce the risk of electrical noise producing more issues, this won't do. The end goal is to stack several of these boards together, which means that heat might cause issues.

Instead, I complicated things a bit more 🙄 and went with the TPS5430, a 3A step-down buck converter which integrates the MOSFET. The buck converter will provide a more efficient voltage regulation and can handle higher current demands without getting hot. The only reason I chose this model is that it's part of the "Basic" parts selection of JLCPCB which means I don't have to pay extra later.

But I recently used the AP62200 for another project and I quite like this chip, mainly due to its size and the fact that it can accept 5V (something the TPS5430 doesn't 😥).

Fixed layout

The previous prototypes all had different size, different mounting hole locations, etc…

I wanted to change that, so I decided on a fixed layout ⚓ for every "external" component:

• SFP cage & connector
• Status LEDs
• SDI In & Out connectors
• Mounting holes

This resulted in something like this:

I then decided that if I were to do another prototype, these components would not change location.

PCB

As you can see, I also added configuration pads for the SFP+ module and experimentally added a link between the LOS signal of the SFP to the output enable of the cable driver, I also added a link between the cable detect of the equalizer and the TXDIS of the SFP

Issues for longer distances still present

I wish I had a video to show you but as I'll explain later, I don't have any V3 boards that are fully populated anymore

Even with all the improvements / changes I made in the third prototype, the performance issues were still a nagging problem. Using a 15m fiber cable worked, but extending that to even longer distances like 50 meters didn't work whatsoever. When I hooked up my setup to test it over this distance, there wasn't any picture at all on the receiving end.

A potential solution

While doing some tests, I realized that the very first prototype used the LMH0397 which, while unidirectional, did include a reclocker ⏱.

After getting this board up and running again, I managed to get some partial success. The artifacts were completely gone with the 15m fiber 😃 and the 50m one now showed a picture but still had artifacts present in some cases 😕.

I was thinking that maybe if I had them on each side, it would work better, but that would raise the price so much. Instead, I decided that I would investigate a bit more before committing to this solution.

Oh, f---, that was the issue!

After spending countless hours tweaking my design and trying different configurations, I was about ready to pull my hair out. It seemed like, regardless of what changes I made, those pesky signal integrity issues persisted.

Then one day, while discussing this with some friends, we discussed the fact that it would be a good idea to have "proper" equipment to validate my design. Up to now, I used cheap-ish converters I bought off AliExpress, so I decided to buy the Micro Converter Bidirectional SDI/HDMI 3G from Blackmagic.

After waiting a few days for the parcel to arrive, I proceeded to test it. To my surprise, everything worked, flawlessly, even with the 50m cable 📏.

I then tried using the cheap HDMI to SDI converter with the Blackmagic one acting as the receiver, and I could see that the lock indicator flickered. The other way around worked but showed the same symptoms as before.

In the end, most of these issues were caused by these cheap converters. Once I switched them out for higher-quality ones, everything clicked into place. The long-distance performance improved drastically, and the intermittent issues vanished.

This is when I realized two things:

• The converters I had are not suitable for long distances!
• I had to buy new converters that are twice the price 💸.

For fun, I also tried to chain every piece of fiber and coax I had ⛓️. This came to a total of 95m of fiber and 30m of coax, if this test was completed successfully, it would mean that the signal would have traveled 220m 🤔, and to my surprise, IT WORKED 😮🥳

I also decided that I wasn't happy with the current version, mainly due to the LEDs and the fact that these prototypes were still using a 2-layer board, which is a hell of a sin with high-speed signaling.

Fourth prototype / Final versions

Nothing significant changed in these versions.

The only things that changed are:

• SMT LEDs for status & power indicators
• Changed the footprint of the jumpers to allow floating configuration
• Power input via the center mounting hole
• Debug port with all the signals and I2C connections

One thing that I also wanted to change was the connector. The ones I was using were 50-ohm SMA connectors, which are both the wrong impedance and connector for SDI.

As mentioned before, SDI uses 75-ohm cabling & connectors, the most common of which are BNCs. That said, other connectors exist such as HD-BNC or DIN 1.0/2.3

Initially, I wanted to use proper BNC connectors, but after browsing Digikey I quickly found that they are SHOCKINGLY expensive 😮. Proper edge connectors from the likes of Amphenol RF or others costs a minimum of 5 EUR per connector.

This is unacceptable for such a low-cost device.

Instead, I simply used the footprint of the 034-1030-12G from Amphenol which is a 12G 75-ohm right angle HD-BNC connector. This means that these boards are technically compatible with a connector, but there's no way in hell I'm going to use it.

Instead, I'm buying SDI male-male panel mount patch cables, cutting them in half ✂️ and soldering them directly to the PCB.

According to the responses, I got from my question on electronics.stackexchange.com:

Soldering RG179 coaxial cable directly to PCB

I'm building a very low-cost bidirectional SDI-3G to fiber converter. I am in the process of selecting a connector for the SDI part. The issue is that I can't really find one that won't explode the

It should be perfectly fine to solder them directly.

One thing I did differently is that I made two versions of this prototype, one being the "Normal" version using the EQCO30T5 and the "Reclocked" version using the LMH0397

This was done for three reasons:

• One of the SDI links is the main output going to the IMAG, and while I can tolerate a camera going down due to signal integrity, I cannot accept the main output acting a way it shouldn't.
• Debugging 🐛. Due to the way it's routed, I can technically use one of these boards as a poor's man eye diagram to help me show signal integrity issues. I could even use it as a repeater if I really wanted to.
• I already had the chips for my previous prototype 🤷‍♂️.

"Normal" version

Here is a photo of it soldered to a BNC pigtail:

"Reclocked" version

Here is a photo of it soldered, unfortunately the rest of the pigtails and SFP cages hadn't arrived yet:

Assembly

Fortunately, making 4 prototypes means that I actually had almost enought chips to fully assemble everything, so I went to work. After a few hours, I was done with what I had.

When I designed the PCBs, I originally wanted to use standoffs to carry current. But when assembly time came, I realized that that would be a nightmare to disassemble 😫. So, to solve this, I decided to create a custom 3D-printed mount that could house eight of these converters (with only 6 slots populated, two reclocked bidirectional and four unidirectional normal ones).

This setup ensured that all components were neatly organized and securely mounted. The 3D-printed base also includes integrated power distribution 🔌 with JST connectors, making it easy to plug in & out each converter for troubleshooting without any messy wiring.

Conclusion

Unfortunately, I haven't got a 1U rackmount case to show yet 😥 because I'm not fully committed to the SDI-only stage box design that these converters will live in, but I'll either make a new post or update this one once done ✍.

As for the price, without including the time it took to design and assemble them, I would say that I reached my price target by a small enough margin 🤑. But what I do realize is that if I had to pay someone to design this, it wouldn't be economical, at all 💸. And suddenly the 155 EUR price of the Blackmagic converter (which can do 12G-SDI) seems much more reasonable, I would even say cheap!

That being said, what a journey! From the partial success of the initial prototype to the very frustrating issues with long-distance signal integrity 🤬, I learned some valuable lessons along the way 🚀.

Looking back, the most important takeaways are:

• Testing equipment matters, when dealing with unknown & difficult stuff that requires external components, always prioritize the quality of the equipment you use to validate your design, even if pricier 💰. In that spirit, I'll probably upgrade a bunch of equipment in my lab.
• Paying attention to detail, be it reading datasheets more carefully 🔍 or properly tweaking a design. Every little detail counts for a production tool.
• Iterative design isn't something I generally do, mostly due to budget constraints 💵. Except that in this instance, each prototype taught me something new, leading to better performance in the next iteration 🔄. I'll definitively do it more

Here is the repo holding the schematic & PCB for each version:

GitHub - TheStaticTurtle/oshw-sdi3g-fiber: An affordable and open source bidirectional 3G-SDI to Fiber converter.

An affordable and open source bidirectional 3G-SDI to Fiber converter. - TheStaticTurtle/oshw-sdi3g-fiber

While this project has come a long way from that first proof of concept, there's always room for improvement 🚀. The pro-AV space is exciting and constantly evolving, so there are plenty of opportunities to innovate. I'm already thinking about other projects 🤐 (audio over fiber, anyone?).

If you read this out to the end, first congrats 🎓, second, don't hesitate to reach out. I'm always down for a chat. Happy hacking! 🔧✨

Why ????

The story about how I thought that tunneling audio over DNS and how I actually started working on it is idiotic.

A few weeks ago, I went on an 8h flight to the US for work 🛫. 3 Days before I reminded myself that I needed to find a solution for me to be able to listen to music on the plane. My phone is pretty old, it's an OnePlus 5T 64g version, and, unfortunately, this model does not support SD cards and currently has less than 1g of free space, a complete pain.

I listen to all my music on Spotify and with less than a gigabyte of free space I wasn't about to download my playlist locally 😥.

Just as was about to leave work that day, I remembered that many airplanes (especially international ones) offer an internet service. When you connect to their Wi-Fi it will ask you to either log in or purchase an internet plan and I thought, there's no way they are blocking DNS queries even if you don't pay 🤔.

That's when I thought, maybe, just maybe, if I were to encode audio and put it in DNS records I would be able to stream audio. I then messaged a few friends about this idea, and, as expected, they agreed that it was stupid and then left work and got in my car.

But then because my brain is weird, I couldn't stop thinking about how I could implement it, and at the end of the ride I had a pretty good idea how to implement AoDNS.

But then, my brain, still being peculiar, decided that it would be better to write code for 7h straight to write a proof of concept and go to bed at 4am while having work in the morning instead of going to sleep 💤.

How does it work

I'll spare you all the details because between my 7h rush and the actual version, quite a few things changed and improved.

Most of the code is written in such a way that it would be straightforward to implement new functionalities like, for example, encryption 💪.

Here is how I made everything work:

Audio & Compression

I needed a simple way to get audio in and out and, as I wrote this in python I chose the easy way and used pyaudio. However, all the audio collection happens in a class that inherits from a base class, meaning that it would be trivial to add another way of inputting or outputting audio assuming that it supports arbitrary raw pcm frame lengths.

As raw pcm takes quite a bit of space, if I wanted to even have hope of making this work, I needed to compress/decompress it 📚, my default choice (and the one I stuck with) is to use opus. Opus is an open audio codec design for transmitting audio over the internet. It can use very low bitrates and a wide variety of sample rates & frame sizes. As a bonus, it's super simple to use.

If the audio is voice only, Codec2 might also be an adequate option for even lower data usage. A quick calculation result in 163 bytes for 1sec of audio 😲.

Most codecs require a specific frame size, opus for example, is calculated like this: 60 * rate // 1000. This is why it cannot be changed. Instead, it's queried during initial setup and re-used by the audio streamers.

What will adjust the amount of data collected is the sample rate and channel count. Theses are configurable when starting the example.

My goal for this project was to get 8kHz 1ch working. As you can see in the following table, compressing data to Opus is pretty good, in general, the output is only 6% of the input. One thing to note is that, for Opus, the size of the compressed data isn't fixed and varies following the input signal 🔊.

Storing the data

As I said, the plan is to store the audio data in TXT queries. To keep everything compatible with the outside world, I choose to store the data as ASCII 👨‍💻. There's also some option to consider here:

To maximize the amount of data I could store in one record, I decided to use base91. It's not too obscure and still does a pretty good job.

One issue I stumbled on early is that TXT strings are limited to a max of 255 characters. Which, for me, roughly equates to 200 bytes of data after the base91 step.

The DNS server can easily bypass this limitation by simply answering multiple TXT strings 😏. My local responder (Windows server 2022) could handle around 3 KB of data in one record before it simply stopped responding.

One issue that arises when sending multiple strings is that the first answer you get from the responder might be ordered correctly, but, at least with Windows server, the second one won't be and instead will be in a randomized< order 😭.

To solve this, I added an incrementing prefix to each string. The prefix is separated from the actual data by using ''' which is one ASCII char that is not used in the base91 table.

After all of these steps, you can query a record and get a response like this one:

# dig +ttlunit TXT seq_49680.music.example.com

;; ANSWER SECTION:
seq_49680.music.example.com. 21s IN TXT  "003'''8U|7E/J`Cc82|8XLpLk^T__5uf~F8PN7~Mfa(E^>WsjNBHV(<2AF|H<us_*}Dyt68)v%:^`<w?&OxM}_ZUf6S&KTbCtFQp$sD!]*a\""
seq_49680.music.example.com. 21s IN TXT  "001'''8U{OOU8]UVh.PiU!N=6WJ3k@>+fl&&<`>SnpY4Tzo_%W(Z_rs)@jzY1x|abYVng=d^vUg5cY\"+K~@OsihU3cxIyz+&MMQu!m,>=dHbsaD"
seq_49680.music.example.com. 21s IN TXT  "004'''rXSKF[23x}`Z!lP@HP8lDSWPhw^ViX!^CZHUgV9m=p}~kb5yk89@f*4/%Kk_!c2[{|\"d,~?B:u|RltK]Ce]t0zf5S{h6H;W"
seq_49680.music.example.com. 21s IN TXT  "005'''8Uy]!Pn!e%1J&xz;V,~d@7J%Ca#ct]D7B^U?u4|],2IE]7ZuE$9;2n;V~{UmwB8P;)=cU/LSdxGvNn>{PoBFUHx:&4]jrS^aDu{ve7)\"EU"
seq_49680.music.example.com. 21s IN TXT  "006'''8Uy]jZ/.]MJLfG%lrc[5FJuJ8$Ixk9VfRjLsLg*Hc`P!x1sHSZpIv5%Rf%|DfXm]%Lr}B%$lRn1oYmOZ+C|sM9bZi6&H+$NipeyS<>|bVvT"
seq_49680.music.example.com. 21s IN TXT  "007'''8Uq&l<\"!uR/i})@E]<TsXZ%0&ulQ%YB|p97tmV)mA|8[+M3;~G`XSu*cKo^Yg`Mq:JAiR{W*x`9mHe>e&?LfsL1!boJ^&\"[PPER0.("
seq_49680.music.example.com. 21s IN TXT  "008'''rX%=qo9rl2P@`BC!>T,O>(+ZU?hp}]WQT^MGki99SL18Ho[!yUL4]6jgEM*5eqkhMLs}fIwx&5N*^&XJv#0zG:5@vtC8|>[cO(.U_^WeFNFB"
seq_49680.music.example.com. 21s IN TXT  "009'''rX%=Ai]%`3:7z5swE1HMB9BS+7Wv@7\"w+nYNl&\"M_Z*6=T<p>Zp?Kwo|M},B;$Uwf`c~UrkLbUDuk8H69%},V}X>Ja~QRD"
seq_49680.music.example.com. 21s IN TXT  "010'''rXKK!74bs7GWw.mBS/@NVj7gCgGy_@sv*9+]tTvB;6a|*N*6Lr.fDcyb&sH2(f=_#zV?^Tb@H)De]<j^.4?3])hA"
seq_49680.music.example.com. 21s IN TXT  "011'''rXSK]\"hAk4R.zCnc{\";RBm[~,Kgl`kB]sxx^b=9PW&n.sK~1MWbOd[E:IdL`6Y%*3@>?`M2Sh^cmAH~3]3;[uJl`>5ITZUK5\"m!C"
seq_49680.music.example.com. 21s IN TXT  "012'''rX%=M5c+YU5JS`di#g7xy=;n~TrBLt*5FFhWpQ\"S#li//^[1xA*Wgsd]l+K~F1znI;<y30[Y2!A\"OlDY:d[)8_DAC"
seq_49680.music.example.com. 21s IN TXT  "013'''rXn;Erky{T>_HKk<OV2UD?wyYfEWMgbsJ?/HV;nMW,]`<O9Z*Wp[}<Z0n0.J4(KmD:(by2/187?oOsuL3_3}bUE2`xNjX[E1h4v%r\""
seq_49680.music.example.com. 21s IN TXT  "014'''8U{O%;Nl>EKbAo.w2?@(HJzsf(Ip9|Ac`rg1>hS!7tS(Uw68%gO#8M(Vf7>EZ.yN;zElg[Ga7(?_lMw%0y#d:oAa&)|6T3A>lB"
seq_49680.music.example.com. 21s IN TXT  "015'''}AP;v[(v.gHQHsjlM/I{`60)WHD9^ia*<Lgq&5.iY9lM8$::#;zCp)06W<lE>xi9.T;]hd3$!aKaCmhG8G7wR#D[<nZZJ<WP$"
seq_49680.music.example.com. 21s IN TXT  "016'''rX%=Nm;nn6uRG<,JM:A5/sQJ~>qB/<o:iu^\"sX]Z`n)oHv9lzqP%VEM5OsBW8LEP1mK\"CLAcDrK.|8%s)~)V%h33Kr,8$ba|KvB"
seq_49680.music.example.com. 21s IN TXT  "017'''rX$gRf8^ooNsOpLYL5Zy@(5%,j^*qG3K|L}/]G&#^1#;o]mRRiH13zyw_^jZ#w2%s`6Qg.wQDR<h?MAQ6!`43ov]+Ez&75b<?k0BH34QE"
seq_49680.music.example.com. 21s IN TXT  "018'''8U+O@Nv/(&nR|5&kW$m6}laH`p<Zp|LCx{t_lc1;!U6:.k!>.7I8`<y?*a#?(SvK@gRwV&WYs@gdzNOHc4<cst4>cBHw[/oG*E9@FZ=CN"
seq_49680.music.example.com. 21s IN TXT  "000'''8U{O#xvTKUK{a)`$*k0t`OwPP$B+(Ogky5*um7:PR2$UN1Q.{J!NZGWJ1~n=].^osw7&qGSY=sw)]WptNCJ;fO4e}d4ybQIXTTt]on*E"
seq_49680.music.example.com. 21s IN TXT  "002'''8U4}l=%kj@6Ph3j9aZJO*qQ,2R*m2z[Kp.;h:%m6);/CR)8J4l}Im9IU5)H+KGLT4T`,(Jt}JwBmEqxMw7[pCUYPO,8>T^9jl.[:w6)EG"

The above example is 19 frames of 16kHz 1ch 16bit audio, which stores just a bit more than 1sec of audio 🎶. Perfect.

Generating the records

As you saw in the dig query above, the subdomain is seq_49680. Obviously, storing 49680 sequences is impractical and would consume a shit ton of space on each resolver.

This is why there is a special subdomain called sequence that will respond with a single TXT string that holds all the available sequence numbers separated by a comma.

However, due to the max length of 255 imposed by TXT strings, the string is compressed with zlib and then base91 encoded.

The issue is that even with this protection, there is a possibility that if the server is left running for long enought, the sequence number would grow so high that it will still overflow and take too much space. This will cause the server to crash 😕.

As the sequence numbers are linear on the server side, this could be improved by sending the first sequence number available and number of available records.

TTL

TTL is a big issue, especially if the server is behind resolvers which might not respect low TTLs 🕖.

The TTL of the sequence record is fixed to 10 seconds. This is done to ensure that it will be somewhat up-to-date before the client will ever run out of sequences. While I have not tested this extensively, 10sec should be high enought to work somewhat decently on the public internet 😅.

On the other hand, the TTL of sequence subdomains is dynamically calculated to be around 80% of the total length of audio data stored in all the records. The formula looks like this:

1seq_duration = (codec_frame_size * frame_count) / (sample_rate * channels * 2)
2ttl = int(seq_duration * sequencer.max_concurrent_numbers * 0.8)

Which at 16kHz, 1 channel and a queue of 75 sequence domains in the generator gives a TTL of around 23sec.

Demo

Here is a demo of AoDNS running a 16kHz 1 channel:

Conclusion

While this project was done purely as a tinkering experiment to test the feasibility of using DNS as a non-standard mechanism to move data around, I think it turned out pretty well 😃.

One thing that I didn't discus yet and what a friend mentioned to me, is the potential for free speech and public communication 👨‍👩‍👧‍👦. If the server chain is properly implemented and extended with encryption & DNSSEC & DoTLS or DoHTTPS, I think it would be pretty difficult to actually censor / modify the audio feed. If the validity of the responses is checked correctly, the worst possible outcome would be a DoS 🔇.

I think that it would be easier to find a DNS server that resolves to the full internet (which could be forwarded to AoDNS the server) rather than trying to establish TCP sessions on filtered networks 🌐. Especially since the traffic will look like normal DNS queries.

Since setting up DNS resolvers is mostly effortless, you could even set up many to act as load balancers / region separator.

This is of course pretty far-fetch and far from reality. But, overall pretty happy with this project 😄.

Note that when I finished the code I was less than 12h from my flight and still didn't have a solution 😅. (Ended up flashing the latest lineage on my old phone and installed Spotify 🤷‍♂️)

GitHub - TheStaticTurtle/AoDNS: AoDNS, or Audio over DNS is a method of streaming audio data with TXT queries.

AoDNS, or Audio over DNS is a method of streaming audio data with TXT queries. - GitHub - TheStaticTurtle/AoDNS: AoDNS, or Audio over DNS is a method of streaming audio data with TXT queries.

For a while now, I used ghost for my blog platform. And, honestly, ghost is a remarkable piece of software, by far the best one I was able to find when I originally set up my blog.

It has some issues though, the biggest one for me is that while it does not natively support markdown and instead uses a custom JSON format.

This is an issue as I write all my posts in markdown. I find it way more convenient and easy to use for the kind of blogging I do than using ghost text editor. It does somewhat convert when copying and pasting, but not everything gets translated (especially code blocks).

This is when I decided to migrate to another platform.

At first, as a stupid software engineer, I tried to build my own blog platform with Django. You can probably guess that it never saw the light of day. It's still sitting in my internal git server, half working.

A good while ago, I decided that enought was enought I was going to make this change happen. I laid out a list of requirements for my new website (blog and portfolio).:

• Static, don't want to deal with a database anymore
• No JS except for giscus for comments.
• Gets ALL information from Markdown files.

I tested countless static site generators (even tried to build my own). In the end, I chose Hugo.

The move

I spent a lot of time writing a Hugo theme for this new website, and to be honest, I still don't understand how certain things work.

You can find the source code here:

GitHub - TheStaticTurtle/website_theme: Theme for the thestaticturtle.fr website

Theme for the thestaticturtle.fr website. Contribute to TheStaticTurtle/website_theme development by creating an account on GitHub.

GitHub - TheStaticTurtle/website_blog

Contribute to TheStaticTurtle/website_blog development by creating an account on GitHub.

GitHub - TheStaticTurtle/website_portfolio

Contribute to TheStaticTurtle/website_portfolio development by creating an account on GitHub.

Two difficult things to do were image handling (mostly because I wanted to compress remote images as well as store them locally) and diagrams (because HUGO doesn't support on-build diagrams, only with JS).

But by far the most difficult one was to generate embed for links. Normally, it would pretty easy to parse out a web page and extract the opengraph tags. Try doing it in a go template 😭. Took a while, but with some patience and many regexes I got it to generate nice embeds at build time.

Conclusion

To conclude this tiny post, I'm pleased with this new solution and thanks to github actions it makes it even easier to write the blog posts easily.

The most important thing is that you'll probably never see any further adjustments if I migrate again, since I wrote the whole theme myself, and I'm pleased with it. It's mostly SCSS files and a few templates, so fairly easy to migrate to somewhere else.

I'm working in the backstage of concerts of our local choir. We have an intercom system, it's based on the Clear Com party line system, but that's a story for another time.

My issue is that I need to hear the audio from my computer and the audio from the intercom, and I guess that my phone would be a nice idea too. I didn't want something complicated like pan control / EQs.

So to recap, I need:

• 3 Stereo inputs with individual volume control
• 1 Output with amplified output for my headphones

It's been a while since I did some manual soldering on a proto board, and I wanted to avoid waiting 2 weeks for a PCB. So, I went to Farrell and Amazon and ordered a few things:

• 3x 10kOhm Log potentiometers
• DC Input jacks
• PAM8403 Amplifier boards
• 4x 6.35 mm TRS Jacks

Schematic

The schematic is heavily inspired by this project https://www.sonelec-musique.com/electronique_realisations_melangeur_audio_002.html, but with the PAM8403 replacing the op amp.

Soldering

Case

Assembly

Adding jack connectors

Adding power connector

Placing the PCB

Final photos

Final thoughts

Overall happy with this, not the greatest sound quality, especially because the PAM8403 isn't designed for headphones but it works.

As I spend most of my day in my office 🤓, I thought it would be a good idea to measure the CO2 levels of the room. CO2 isn't as dangerous as CO, but it can still pose some issues if the levels are too high. And after being in a room that hasn't any ventilation for +10h straight, the CO2 level is definitely high.

This study, found that the level of CO2 has a very negative effect on performance, particularly on thinking in general:

I also wanted to measure the PM2.5 concentration, as it could prove useful for automations down the road.

My office does have a window and, in summer, it's pretty easy, as I leave it open all the time. In winter, however, the room gets cold quickly. Which is why I wanted a sensor that can tell me if I need to open the window.

Options

So, what's available out there? Well, first of, I want something that won't send everything to some cloud that I don't control. That reduce the options quite a bit.

IMO, the Aranet4 from Aranet is the best sensor if I wanted something pre-made. Looks very well-made and is compatible with HomeAssistant. However, it's pretty pricey.

As I also wanted to measure the quantity of particulates floating in the air and I couldn't find a sensor that measured both that was at low enought price.

It meant DIY 🧐!

DIY

First, what do I actually need. I already have temperature and humidity from a Mi-Thermometer, I don't care much about the light level. What I do care about is:

• CO2
• PM2.5 / PM1.0 / PM10

After reading a few blog posts and watching a few videos, I choose to use the MH-Z19, it can measure the CO2 concentration in ppm from 0 to 5000ppm and the temperature and output it to either serial or PWM. Seems perfect for my needs.

For the particulate matter sensor, I choose a PMS5003 which gives me PM2.5, PM1.0 and PM10

Hardware

3D

I first hoped into SolidWorks and my something that reassembles a case.

The PMS5003 has an intake fan in it and by default the air is ejected on the same side:

So, here is what I came up with:

The air comes in from the side, ejected on the other side and then passes over the MHZ19.

On the front, I added a recess for a washer that I'll use a button using the esp32 touch library, a recess for the OLED and a hole for LEDs:

On one side I added an intake hole for the fan, an output, and a hole for the USB wire.

Assembly

Assembly was a little finicky. I started by inserting the OLED:

Then poured hot glue in the LED hole to act as a diffuser and then put the LED strip in:

Unfortunately, my 3D print wasn't perfect and the PM5003 didn't fit by less than a millimeter. So, I used some hot air to ease it in 😏:

Then with a lot of patience, I manage to solder everything to the ESP32 and hot glued it in place:

A bonus of the 3D print being slightly out of size, is that I can use the flat side of the PMS5003 to stick it to the wall with some double side tape.

Software

Usually, I would write my own firmware for the ESP32 that would publish the sensor data to my MQTT server and I would create the entities myself in HomeAssistant.

However, this time I chose to use ESPHome because it's way easier to use and integrates perfectly with HomeAssistant.

So let's get started. First thing to do is to set up esphome:

 1esphome:
 2  name: office-air-quality
 3
 4esp32:
 5  board: esp32dev
 6  framework:
 7    type: arduino
 8
 9logger:
10
11api:
12  encryption:
13    key: "FTt4GyAtVoM8tIqBhNSW3QF+SND9NaIA97l1FkfTdGg="
14    
15ota:
16  password: "8ebf931b96986fa4d46fb35987957b3d"
17  id: my_ota
18  
19wifi:
20  ssid: !secret wifi_ssid
21  password: !secret wifi_password
22  ap:
23    ssid: "Office-Air-Quality"
24    password: !secret ap_password
25
26captive_portal:

Next is the interface setup, I need the two UARTs for the pms5003 and mhz19, the I2C for the OLED, the touch interface for the button and the fonts for the OLED

 1i2c:
 2  - id: i2c_oled
 3    sda: 18
 4    scl: 19
 5
 6uart:
 7  - id: uart_pms5003
 8    rx_pin: GPIO16
 9    tx_pin: GPIO17
10    baud_rate: 9600
11  - id: uart_mhz19
12    rx_pin: GPIO26
13    tx_pin: GPIO25
14    baud_rate: 9600
15
16esp32_touch:
17  setup_mode: false
18
19font:
20  - file: "gfonts://Lato"
21    id: lcdfont_big
22    size: 15
23  - file: "gfonts://Roboto"
24    id: lcdfont_small
25    size: 12
26  - file: "gfonts://Roboto"
27    id: lcdfont_verysmall
28    size: 10

Then I need to add the sensors, fortunately ESPHome has platforms for the pms5003 and the mhz19. As I use an ESP32, I can also use the esp32_touch platform for the user button.

 1sensor:
 2  - platform: pmsx003
 3    uart_id: uart_pms5003
 4    type: PMSX003
 5    pm_1_0:
 6      id: pmsx003_pm1_0
 7      name: "Concentration particules <1.0µm"
 8    pm_2_5:
 9      id: pmsx003_pm2_5
10      name: "Concentration particules <2.5µm"
11    pm_10_0:
12      id: pmsx003_pm10_0
13      name: "Concentration particules <10.0µm"
14  - platform: mhz19
15    uart_id: uart_mhz19
16    co2:
17      id: mhz19_co2
18      name: "Capteur CO2"
19    temperature:
20      id: mhz19_temp
21      internal: true
22    update_interval: 30s
23    automatic_baseline_calibration: false
24    
25binary_sensor:
26  - platform: esp32_touch
27    internal: true
28    name: "Button"
29    pin: GPIO27
30    threshold: 1000
31    on_press:
32      - display.page.show_next: oled

Next are the outputs, I used a small OLED with 3 pages with the only thing changing being the PM2.5 / PM1.0 / PM10, CO2 is always displayed. And the light with the internal key to hide it from HomeAssistant.

 1display:
 2  - platform: ssd1306_i2c
 3    id: oled
 4    model: "SSD1306 128x32"
 5    address: 0x3C
 6    pages:
 7      - lambda: |-
 8          it.print(0, 0 , id(lcdfont_big), "CO2  ");
 9          it.print(0, 15, id(lcdfont_big), "PM2.5");
10          it.print(54, 1 , id(lcdfont_small), String((int)(id(mhz19_co2).state)).c_str());
11          it.print(54, 17, id(lcdfont_small), String((int)(id(pmsx003_pm2_5).state)).c_str());
12          it.print(92, 3 , id(lcdfont_verysmall), "ppm");
13          it.print(92, 18, id(lcdfont_verysmall), "ug/m3");          
14      - lambda: |-
15          it.print(0, 0 , id(lcdfont_big), "CO2  ");
16          it.print(0, 15, id(lcdfont_big), "PM1.0");
17          it.print(54, 1 , id(lcdfont_small), String((int)(id(mhz19_co2).state)).c_str());
18          it.print(54, 17, id(lcdfont_small), String((int)(id(pmsx003_pm1_0).state)).c_str());
19          it.print(92, 3 , id(lcdfont_verysmall), "ppm");
20          it.print(92, 18, id(lcdfont_verysmall), "ug/m3");          
21      - lambda: |-
22          it.print(0, 0 , id(lcdfont_big), "CO2  ");
23          it.print(0, 15, id(lcdfont_big), "PM10");
24          it.print(54, 1 , id(lcdfont_small), String((int)(id(mhz19_co2).state)).c_str());
25          it.print(54, 17, id(lcdfont_small), String((int)(id(pmsx003_pm10_0).state)).c_str());
26          it.print(92, 3 , id(lcdfont_verysmall), "ppm");
27          it.print(92, 18, id(lcdfont_verysmall), "ug/m3");          
28
29light:
30  - id: status_led
31    internal: true
32    platform: neopixelbus
33    variant: WS2811
34    pin: GPIO33
35    num_leds: 9
36    type: GRB

Thankfully, esphome automatically updates the OLED content. Which is not the case of the LEDs, so I used the SNTP platform to execute a script every 1 second.

The script does the following:

• Creates a call to turn on the LEDs
• With a transition of 100ms from the previous state
• And set the color based on the CO2 level:
  • >= 1500 → Purple
  • >= 1200 → Red
  • >= 900 → Orange
  • >= 650 → Green
  • < 650 → Blue
• Execute the call

 1time:
 2  - platform: sntp
 3    on_time:
 4      - seconds: /1
 5        then:
 6          - lambda: |-
 7              LightCall status_led_call = id(status_led).turn_on();
 8
 9              status_led_call.set_state(true);
10              status_led_call.set_transition_length(100);
11
12              if(id(mhz19_co2).state >= 1500) {
13                status_led_call.set_rgb(0.392, 0.015, 0.588); // Purple
14                status_led_call.set_brightness(1.00);
15              } else  if(id(mhz19_co2).state >= 1200) {
16                status_led_call.set_rgb(0.921, 0.000, 0.000); // Red
17                status_led_call.set_brightness(0.75);
18              } else  if(id(mhz19_co2).state >= 900) {
19                status_led_call.set_rgb(0.620, 0.392, 0.000); // Orange
20                status_led_call.set_brightness(0.27);
21              } else if(id(mhz19_co2).state >= 650) {
22                status_led_call.set_rgb(0.031, 0.690, 0.007); // Green
23                status_led_call.set_brightness(0.18);
24              } else {
25                status_led_call.set_rgb(0.007, 0.600, 0.749); // Blue
26                status_led_call.set_brightness(0.15);
27              }
28
29              status_led_call.perform();              

Results

Flashed the compiled esphome firmware and was greeted by some wonderful logs:

[20:43:27][D][pmsx003:236]: Got PM1.0 Concentration: 3 µg/m^3, PM2.5 Concentration 4 µg/m^3, PM10.0 Concentration: 4 µg/m^3 
[20:43:28][D][mhz19:057]: MHZ19 Received CO₂=693ppm Temperature=24°C Status=0x00

The LEDs and OLED lighted up with the correct info:

I added the entities in HomeAssistant, left it for a while and got these wonderful graphs:

Conclusion

Overall, I'm pleased with this project, I didn't take very long to make, it's not too big, it's not really distracting unless the level is too high. It's going to be a really useful tool for long programming or soldering sessions.

The Lenovo M73p is part of the ThinkCenter line of business-oriented desktop computers designed, developed by Lenovo. ThinkCentre computers typically include mid-range to high-end processors, options for discrete graphics cards, and multi-monitor support.

Generally, business-oriented desktop computers have different sizes for each model. I'm particularly interested in the tiny ones. They have been made popular by the Tiny/Mini/Micro project published on ServeTheHome.

To summarize, the idea is that there are plenty of technologies where one would want several physical nodes. In my case, the end goal is a HA setup for Proxmox VE.

Aside from the fact that having multiple nodes is obviously better for HA, theses small servers usually don't use a lot of energy, which today is a pretty good thing 💰. My four M73p consume somewhere between 60-85 WH depending on the load. Way better than one server powerful which might not be enought for everything that will consume +150 WH and won't have any HA 😕.

They also can be found for very cheap, I bought my nodes for somewhere between €60 and €90 each.

Of course, they have some downside:

• Small, means that you don't fit a lot in there:
  • 2.5” drive for older models, NVMe only for newer ones
  • Some models have a PCIe interface use for a dedicated GPU and. A user managed to fit a 10GbE network card, but models that do have this interface are often 2x / 3x the price of what I paid for my nodes
• Limited upgradability:
  • The M73 has only two Mini-DIMM slots for ram
  • Only one SATA port
  • Some models (including the M73) have CPU sockets, but they don't accept every CPU, and some are locked
• Only one 1 GbE Ethernet.

That being said, they are very capable machines, way more than I need for my homelab, especially if I have 4 of them.

In my homelab I'm planning to experiment with Ceph, or maybe GlusterFS which means data will be on the nodes themselves.

High Availability, however, requires at least two things that this computer lacks:

• Two disk (one for the OS, on for the data), there is a trick to run Ceph on a disk partition, but I would like something “stable”
• High-speed networking, for me, I don't think I require that much IOPS, So I think I'll go with 1Gbe for the proxmox cluster and 2.5Gbe for the Ceph cluster.

In this article, I'll fix the two disk issue.

Options for multiple disks

There are multiple options that I considered, I wanted to leave the internal SATA port for a SSD for the data of Ceph cluster. That didn't leave many options for the OS:

• USB 2.0 Key bodged to an internal header
• USB 2.0 SSD bodged to an internal header
• USB 3.0 Key plugged in the back
• USB 3.0 SSD Plugged in the back

I canned the USB Key solution pretty quickly, unlike OSes like Unraid where there is barely anything written to disk, Proxmox writes quite a lot which would destroy the key very fast.

I also wanted to avoid using the USB3 port because I planned to use these (or at least one of these) for the Ceph network and didn't want to have to share the bandwidth.

The last solution was the USB 2.0 SSD bodged to an internal header, which would work, and I would have probably done it if I didn't notice the mSATA port 🤔.

mSATA?

When you look at the M73 motherboard, you can see an obviously missing footprint marked MSATA1 right next to the Wi-Fi slot:

Which got me thinking. Could it be as simple as soldering a connector and plugging in an SSD? Tried soldering one and of course it didn't work 😑, that would be too easy.

Adding the mSATA Slot

After some research, I found that there are some M73 models that have a mSATA port, which makes this possible. So, I dug a little more.

I first found a video from someone who successfully modded the motherboard and IT WORKED, I got really excited and dug even more. I then found what, I believe, is the source of this mod: https://kknews.cc/digital/earlzm4.html. Turns out, all it needed was a few more passives and moving a resistor.

Parts list

Top side

On the top side, there are only three components. The inductor is pretty easy to solder, the cap, however, was a nightmare, I could not solder to that ground plane. The mSATA connector looks painful but with some solder paste, hot air, and a bit of rework with a fine point tip, flux, and solder wick, it's actually pretty easy

Bottom side

Bottom side is pretty easy, even for 0402, I replaced 0 Ohm resistor with wire bridges and swapped the resistor with some hot air. Not the prettiest job, but it should work.

Testing

After everything was soldered, I put a 128 GB SSD in the new slot, plugged a VGA cable and power and quickly hopped in the BIOS

I made sure the SSD was detected AND IT WAS 🥳 and quickly powered it off again because I didn't have the cooler installed.

I then put everything back together and also took the opportunity to clean the cooler and changed the thermal paste.

Finished by installing proxmox and that was it:

Booted just fine, both disks are detected. To finish things off, I did some benchmarks:

root@pve4:~# hdparm -Tt /dev/sdb
/dev/sdb:
 Timing cached reads:   17150 MB in  1.99 seconds = 8597.18 MB/sec
 Timing buffered disk reads: 428 MB in  3.01 seconds = 142.02 MB/sec

root@pve4:~# dd if=/dev/urandom of=/tmp/output bs=16k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
167772160 bytes (168 MB, 160 MiB) copied, 1.17751 s, 142 MB/s

Conclusion

I'm very pleased with this mod 😀, seems a bit dodgy but if the soldering's good, there is no reason it will pose any issue. Moreover, ⁣142.02 MB/s read and 142 MB/s write not bad at all, way better than what a USB 2 key will do 🤣.

Now I just have to do the same mod to the 3 other thinkcenter 😭.

This is a stupidly long article, it details the concept, design, and construction phases thoroughly, you'll need probably more than 45 min to really read it

Every once in a while, I work in my local choir. Every few years, they do a tour singing music for around 3h. This year there are more than 25 singers and 15 microphones. Add microphones for the drums, bass, guitar, saxophone, trumpet, ..... and you reach the maximum 32 channels of our MIDAS M32 console quite fast.

You may notice that 25 is greater than 15 🤔, that's because we have one or two techs who hand out the mics according to the all mighty “mic-sheet”.

Basically, this sheet is a grid of every song and every microphone with the performer's name if they need one. It gets fine-tuned over time during rehearsals so that when the first real concert comes, the mic transitions between performers are as smooth as possible. This is fine and worked for over a decade, but we are still human and sometimes mistakes happen. For example, someone might grab the wrong mic and go on stage, or maybe the microphone has become magically invisible 👻.

Combine that with my love for problem-solving 🤓, and I decided that I would do a system that can do multiple things:

• Keep the microphones neatly organized
• Connect to the MIDAS M32 and retrieve mute & fader values
• Display mute status to the backstage techs
• Determine if a microphone is in the holder or in someone's hand
• Display this in the mixing booth so that we can figure out what the hell is going on if something is wrong

One problem that could still happen is that someone could put the wrong microphone in the wrong holder, we would have no way of knowing which one is the right one. But my guess is that it's more likely that the mics run out of battery than someone misreading two numbers (one on the mic and one on the holder) 🤷‍♂️.

Microphone holders

I thought about using RFID tags on each mic to solve the "wrong holder" issue, and that would indeed make sure that the right microphone is in the proper holder. But, that brings me to the 2nd thing that this project needs to be: cheap! 💰 The thing is that I'm doing everything myself and don't want to spend 20 EUR per holder, especially knowing that one could break in the chaos of the backstage. No, I want it to be as cheap as possible.

But, I still need to have 15 of them connected to a controller capable of talking to the M32.

That took some though 🤔 as I originally wanted to do use a single bus or a daisy-chaining approach, where all holders would have an IN and an OUT port to simplify wiring.

Connecting 15 holders together

Single bus/daisy-chaining for the LEDs is easy, a few WS2812B in each holder will do just fine, and they already work with daisy-chaining ✅.

The input for the microphone detection was a bit trickier though, I first looked at one wire IO extenders like the DS2408 or the DS2413, but they are respectively 8 EUR and 3 EUR for a single chip in the quantities I need. Far too expensive 💸. At the same time I started this project, I had an ongoing PCB order, I thought that I could potentially put a full RP2040 block in each holder, but that would also be 2 - 5 EUR per holder in the quantities I require.

So short of doing some analog trickery to make the thing work on one wire 😐, I said f- that and committed to a star topology. That means I have to bring a cable from the controller to each holder that contains these signals:

• Ground
• LED In
• +5V
• LED Out
• Microphone detection OUT

The LED out of each holder is wired to the LED in of the next one, and the "Microphone detection" button goes to a GPIO of the controller.

Detecting the microphone

The first thing anyone would think of is a simple switch. While that could work, being on a budget also means that we don't have the same microphone, some are smaller than others, and I wanted to avoid doing two weeks of cad to try to make a holder compatible with everything (especially since I didn't even have access to the microphones at the start).

The second option I thought of 💡 is an IR proximity sensor. Those are also pretty cheap, 15eur for a pack of twenty is pretty good. So, I went ahead and ordered a pack, I could always find a use for it elsewhere if it didn't work out.

Once I got them I discovered a fatal flaw in my plan, the microphones are black and round ⚫ which doesn't really reflect the light from the sensor very well if at all. After some thinking and even trying to go back to the switch option, I realized the detection could be "normally closed" and use the microphone to block the path of the IR beam instead of reflecting it.

Perfect, I now have a cheap way of determining whether the microphone is in the holder or not 👍.

CAD

I still needed an actual solid piece of plastic to hold the microphone. The holder needs to satisfy these requirements:

• Holding a wide variety of microphones
• Able to be screwed to a piece of wood
• Able to hold a label for the microphone number
• A way to display and diffuse the LED light
• Enought space for IR LEDs in the holder arms
• Flexible enought to accommodate even bigger microphones if necessary

After some revisions (some of which happened while I was already printing) 🤫, I ended up with this design which is printed upright in two parts (holder and led diffuser):

The LEDs are inserted in the sidearms, in retrospect, it would probably have been better to order modules with 3 mm LEDs instead of 5 mm ones since they stick out a bit, but it doesn't need to be perfect, it just needs to work. It's going to get beat up anyway 🙄. The cable for the LEDs get routed in a small channel in the arm, which then comes out in the back, where I can put the rest of the components.

To make it easier to build the 16 modules, I chose to use a classic LED strip, I cut out 6 LEDs and jammed them in a little recess that I put in the design.

Finally, the PCB of the IR module gets attached with a piece of double-sided tape on the back and everything gets soldered together.

I then spent 4 days printing everything (I printed 4 modules at the same time, which kept the printer busy for around 18h 😴). The assembly was actually straightforward once I got the hang of it, but I'm glad it's done.

Now that everything is assembled, I printed some LED diffusers and stuck some labels with the microphone number printed on it:

Flaws and improvement

If I were to re-design this, I would probably do the following:

• Manufacture two PCBs:
  • One that follows the shape of the arms with side mounted IR LEDs and photodiode,
  • One that I could put on the back with some side mounted WS2812B-4020 instead of an LED strip. In addition, use some sort of interconnect with the side arms PCB,
• Maybe print the holder out of a semi-flexible material and not PLA (at least for the arms). Because while I did print them at 100% infill, I fully expect at least one to break at some point. A hard TPU seems like a better bet. Unfortunately, I don't think my printer will handle it well, especially in the winter.

This would make the holder slimmer and sturdier. It might even be possible to print this hypothetical version in metal.

Wiring

Originally, I wanted to have a cable going out the bottom of each holder with the JST connector and the same cable going to the controller. That would have resulted in a big mess of cables, especially at the start 😵.

Once everything was printed, we began shopping for a piece of wood that could holder everything. By pure luck, we found a U-Shaped channel of MDF that would be:

• Tall enough for the holders,
• Long enough for 16 of them,
• Deep enough to route the cable behind.

So, my dad and I started by drilling the two screw holes for each holder, plus a 20 mm hole for the cable to pass to the back. We choose to leave 2.5 cm of space between each holder to leave enough room to grab the mic easily, and something like 15 cm of space on each side for the controller.

Unfortunately, the +2 m piece of MDF wasn't very stiff, and the thing was flapping like crazy 🤔. I'll come back to that. To pile up on the bad news, the screws we chose were a bit too long by something like 5 mm.

Fortunately, we found some aluminum channels that are 20 mm deep and the perfect width. These aluminum extrusions are typically used on the side of flight cases. Mine looks a bit like this one: https://www.thomann.de/fr/adam_hall_6102_schliessprofil.htm

It was perfect 😄. The board looks super nice, the screws are not too long any more and as the bonus, the board is super stiff now:

You can see that the bottom screw is barely short enough, but it will actually be very helpful later to hold the cable harness 😏:

I then proceeded by cutting a ton of wires for power distribution and for the addressable LEDs data line 😫. Instead of soldering everything manually, I choose to use these wonderful heat shrink pieces that already have some solder in them: https://fr.aliexpress.com/item/1005003878417358.html.

The white cable you can see is the connection of the IR module. To connect this one, I cut a 16 conductor by +2 m long piece of ribbon cable, separated the cable where required and soldered the same heat shrink pieces everywhere.

This made for a very nice cable harness to put in the back (The photo is missing the ribbon cable) 👍.

To fix everything in place, I printed some big washer that I placed on the screw post of the holder with the cable underneath. After that was done, everything was nice and neat:

Controller

Now that I have 15 holders and a spare, I need something to control them. Originally, I wanted to use an ESP32 and fully integrate everything.

The controller needs to be able to do a few basic things:

• Connect to the M32 OSC protocol and get mutes/fader values,
• Drive the WS2812B,
• Read all the 15+1 inputs.

Alongside that, a few other things need to be considered when being in a "pro" context:

• Stability: The thing should start fast, can withstand a power cut, handle potential network disconnects, etc.
• Reliability: The thing has to stay connected and work for hours without interruption.

That meant Wi-Fi was out of the question because there are too many issues when numerous people are connected, and I don't have the time/budget to set up a proper Wi-Fi network 📡.

Fortunately, we already have a wired network planned, which means: let's go with Ethernet.

I actually figured out quickly how to get Ethernet working on the ESP32. While I did make some progress fairly fast, I figured that I couldn't reach the required stability and reliability level by the start of the first concert. It's just too much work to re-implement everything manually for a quick project.

So, I dug out a now very rare PI Zero 2, and decided that I was going to use it 🤷‍♂️.

Reading inputs

At first, I thought of a whole plan to use IO extender to read all the inputs. Then I looked closely at the PI and I realized that the thing has GPIO, I never used them to the point where I just forgot that they existed 😓.

A minimal issue is that my signal from the holders are +5V, and I need them to be ≤3.3V. This can be taken care of with a resistor divider, I chose 10K/10K because that's all I had in hand, which gave me 2.5V, not quite 3.3V but still above the threshold, perfect 👍.

LEDs

Well, there is not a lot to say here. The ws2812b is a single pin, so I just used one that was available and called it a day 😅

Ethernet

I have some cheap Ethernet dongles. I cut one up and soldered it up to the D+/D- test pads of the PI Zero, that gives me Ethernet connectivity

Wiring

To make things easier, I decided that I would use a PCB. The issue is that, again, that I needed this thing as soon as possible ⏱, so I can't do a pre-made PCB and wait a week for shipping. I decided that I would, instead, use a perfboard and do some manual soldering.

There really isn't a lot to say, I soldered in some headers, the resistors for the dividers and some terminal blocks for power and the LEDs data.

I also soldered some DuPont connectors to the D+ and D- of the Raspberry Pi for the Ethernet card instead of using a USB to OTG adapter.

CAD

I spent some time making the PCB and the Raspberry Pi fit inside a very basic box

Added some holes for power, and status LEDs:

I then added a place for the network card

Once that got printed, I put the PCB, network card (which I had to hot glue in to secure it), LEDs and the power connector in it. And, finally, wired the 16 inputs from the wire harness and screwed in the power cables and LED data cable.

After securing it on the MDF board, it looked perfect.

Software

As I needed it to work as soon as possible 🐇, I went with something I knew for sure and used python 🐍.

The first thing I did was test out the LEDs and inputs. I used the circuit python libraries because it just works. Didn't have to fiddle to make something work correctly. And, sure enough, everything worked right away, nice 👍.

Initially, I did everything in one big script, but that became an issue when I had multiple loops and a web server.

I then thought that it might be better / easier to write a few interconnected modules than to write a big one 🤔. There are a few options for connecting multiple parts together. ZMQ and MQTT are pretty popular, I then remembered that MQTT has a web socket version (which I could easily use for a Web UI later 🌐) and went with it.

MQTT Server

I chose to use the mosquito mqtt server, installing it was pretty straightforward:

1sudo apt update
2sudo apt install -y mosquitto mosquitto-clients
3sudo systemctl enable mosquitto.service

Then, I just need to enable anonymous access, traditional MQTT and Websocket support in the config:

1listener 1883
2listener 8080
3protocol websockets
4allow_anonymous true

Note: using authentication here wouldn't be very useful, since the credentials could have been easily recovered in the source code of the webui 🤷‍♂️

After a quick test with the MQTT explorer app on my computer to check that it was working. So, I went ahead and started working on the global config.

Configuration

The config.py file of x32_tally contains several variables that I can configure to alter the way the tool works. This includes:

• The address of the X32,
• The address of the MQTT server,
• Log levels for every module,
• Colors for the tally lights:
  • Muted / Active,
  • Muted blinking ON / Active blinking ON,
  • Muted blinking OFF / Active blinking OFF.
• Pin for the neopixels,
• List of input channels with:
  • The status (enabled or not),
  • The list of LEDs for the tally lights,
  • The pin for the "on-stand" detection.

IO Configuration

The io.py file contains definitions for the LedController and InputController classes. These act as a wrapper for the Adafruit libraries, this allows me/someone to easily change the input/output method without the need to rewrite every module 😏.

 1class LedController:
 2	def __init__(self):
 3		highest_pixel_id = 0
 4		for ch_n, ch in config.input_channels.items():
 5			if "tally_leds" in ch:
 6				highest_pixel_id = max(highest_pixel_id, *ch["tally_leds"])
 7		self.pixels = neopixel.NeoPixel(config.tally_neopixel_pin, highest_pixel_id + 1, auto_write=False)
 8
 9	def update(self):
10		self.pixels.show()
11
12	def set(self, leds, r, g, b):
13		for led in leds:
14			self.pixels[led] = (r, g, b)

1class InputController:
2	def __init__(self):
3		self.buttons = {}
4
5	def get(self, pin):
6		if pin.id not in self.buttons:
7			self.buttons[pin.id] = digitalio.DigitalInOut(pin)
8			self.buttons[pin.id].direction = digitalio.Direction.INPUT
9		return self.buttons[pin.id].value

This file also contains a function for creating MQTT clients. It takes a name and returns the client:

1def get_mqtt_client(client_id):
2	client = mqtt.Client(
3		client_id=client_id,
4		reconnect_on_failure=True
5	)
6
7	client.enable_logger(logging.getLogger("MQTT"))
8	client.connect(config.mqtt["host"], config.mqtt["port"], 60)
9	return client

Finally, this module also broadcasts the input channel config every time it's loaded. This is only for the Web UI, as it obviously doesn't have access to the config.py file.

1st module: MIDAS M32 to MQTT bridge

As the headline suggests, the most important thing is to forward messages from the M32 to the MQTT server so that other modules can access it.

As a request from the sound engineer, I purposefully did not implement the MQTT to M32 side to avoid something writing to the console and causing something bad 😕 (That being said, it would be trivial to implement).

The MIDAS M32 uses a custom implementation of the OSC protocol. OSC is wonderful, works super well, and it's widely used. It's no wonder they used it.

One tiny annoying thing about their implementation is that you need to send packets to the port 10023 of the console. But it does not respond to you on 10023, instead it responds to whatever ephemeral port the system decided to use to send the packet. This means that you need to keep the same socket.

It's a small inconvenience, but it also means that you don't have to select a different port for each app 👍.

Somebody did an incredible job of reverse engineering what each command does and published a ton of software for the X32. Including an emulator, which is helpful when you don't have the 3600 EUR console next to you. He also published a spec sheet of OSC commands which is very useful.

Turns out that to query a setting of the console you just have to send the same command that you would normally send for setting it but without the parameters.

Essentially, that would mean that I need to send /ch/XX/mix/on and /ch/XX/mix/fader every few hundreds of a second to poll the status. That would be quite resource intensive for both devices 😓.

Instead, the engineers over at Behringer/Midas added the /xremote command, this command will subscribe you to every update happening on the console (except VU meters for which there is a special command). The only thing is that you need to resubscribe every few seconds to keep receiving updates 👍.

To recap, I send:

• Every few seconds (read 5):
  • The /xremote command to subscribe to console updates.
• Every 60sec to force update of the values as a sanity check:
  • The /ch/XX/mix/on query to get the mute status of the channel XX,
  • The /ch/XX/mix/fader query to get the fader value of the channel XX,
  • The /ch/XX/config/icon query to get the icon of the channel XX,
  • The /ch/XX/config/name query to get the name of the channel XX,
  • The /ch/XX/config/color query to get the color of the channel XX.

Unfortunately, after some testing with the real thing (as I started the development with an emulator), it turns out that the /xremote command doesn't send every fader update when changing cues, and it meant I had to wait for the forced update to refresh the status 😕.

To solve this, I had to dive into how the /formatsubscribe command works. This command allows the reception of regular updates for a topic. In this case, I subscribed to mute and fader values.

Note that this command did not work on the emulator, hence why I didn't use it from the start 🤷‍♂️.

On a tangent, I also looked at the /showdump, /-prefs/show_control, /‐show/prepos/current and /-show/showfile/show/name commands that allow me to get the show, its cues and the current position of cues.

So, how does that work in code. I used the pythonosc module to parse and build the OSC messages. I then wrote a class that inherit from threading.Thread to keep receiving the messages in the background. This is probably not necessary, but I wanted to be able to re-use this lib somewhere else if needed. I started by creating a few helper functions.

Sending data

I first wrote a "send" function that wouldn't make the module crash if, for some reason, the network was not working.

 1    # Wrapper function use to send data to the console.
 2    # The function tries to send the message but does not raise an error if it fails (it just logs it).
 3    # This can happen if the network card is not up yet
 4    def _send(self, data: bytes):
 5        try:
 6            self._socket.sendto(data, self._address)
 7        except OSError as e:
 8            self._log.warning(f"Tried to send data but got: {e}")
 9        except Exception as e:
10            self._log.error(f"Tried to send data but got: {e}")

Next, I wrote wrappers around the OSC commands of the x32 that I'll often use.

 1    def _x32_format_subscribe(self, alias, addresses, start_i, end_i, interval=20):
 2        message = OscMessageBuilder("/formatsubscribe")
 3        message.add_arg(alias)
 4        for address in addresses:
 5            message.add_arg(address)
 6        message.add_arg(start_i)
 7        message.add_arg(end_i)
 8        message.add_arg(interval)
 9        self._send(message.build().dgram)
10
11    def _x32_renew(self, alias):
12        message = OscMessageBuilder("/renew")
13        message.add_arg(alias)
14        self._send(message.build().dgram)
15
16    def _x32_xremote(self):
17        message = OscMessageBuilder("/xremote")
18        self._send(message.build().dgram)
19
20    def _x32_info(self):
21        message = OscMessageBuilder("/info")
22        self._send(message.build().dgram)
23
24    def _x32_showdump(self):
25        message = OscMessageBuilder("/showdump")
26        self._send(message.build().dgram)

Followed that with a function to force query the status of the fader and to dump the whole show.

 1    def _query_channel(self, channel):
 2        self._send(OscMessageBuilder(f"/ch/{channel:02}/mix/on").build().dgram)
 3        self._send(OscMessageBuilder(f"/ch/{channel:02}/mix/fader").build().dgram)
 4        self._send(OscMessageBuilder(f"/ch/{channel:02}/config/icon").build().dgram)
 5        self._send(OscMessageBuilder(f"/ch/{channel:02}/config/name").build().dgram)
 6        self._send(OscMessageBuilder(f"/ch/{channel:02}/config/color").build().dgram)
 7
 8    def _query_show(self):
 9        self._x32_showdump()
10        self._send(OscMessageBuilder(f"/-prefs/show_control").build().dgram)
11        self._send(OscMessageBuilder(f"/‐show/prepos/current").build().dgram)
12        self._send(OscMessageBuilder(f"/-show/showfile/show/name").build().dgram)

Next, I did the re-sync and resubscribe functions. These functions are called respectively every 60 sec and every 5 sec.

The goal of the _re_sync is to be damn sure that our information is sync with the console. It also forces a /formatsubscribe command instead of a /renew.

The goal of the _re_subscribe command is to send the /renew, /xremote and /info commands to make sure we keep the update coming.

 1    # Resync function. This function is executed every 60sec to make sure the internal status is up-to-date with the console
 2    def _re_sync(self):
 3        self._log.info("[TX] Forced queried infos and subscribed")
 4        self.last_resync = time.time()
 5
 6        for i in range(1, 33):
 7            self._query_channel(i)
 8
 9        self._x32_format_subscribe(
10            alias="/subscribed/faders",
11            addresses=["/ch/**/mix/on", "/ch/**/mix/fader"],
12            start_i=1, end_i=32,
13            interval=20
14        )
15
16        self._query_show()
17
18    # Resubscribe function. This function is executed every 5sec to subscribe to updates from the console
19    def _re_subscribe(self):
20        self.last_resubscribe = time.time()
21        self._log.info("[TX] Renewed subscriptions")
22        self._x32_xremote()
23        self._x32_info()
24        self._x32_renew("/subscribed/faders")

Receiving data & handlers

Now that we can send messages, we need to receive them. I started by writing a handler for all messages. This function receives an OSC message and forward it to the appropriate internal or external handler.

 1    # Internal OSC message handler
 2    def handle_message(self, message):
 3        self.last_incoming = time.time() # Reset the last incoming timer
 4
 5        if message.address == "/subscribed/faders":
 6            self.handle_message__subscribed_faders(message)
 7            return  # Subscribed aliases are internal message no need to forward it
 8
 9        if message.address == "/node":
10            self.handle_message__node(message)
11            return  # Can't forward node responses
12
13        # If the address is "/info" retrieve the server version/name and the console model/version and trigger the connection handlers
14        if message.address == "/info":
15            self.handle_message__info(message)
16
17        # The message to every other handler
18        for handler in self.handlers:
19            handler(message)

The /info handler is basic. It simply extracts the information, stores it and calls every "connection" handler.

1    def handle_message__info(self, message):
2        self.x32_server_version = message.params[0]
3        self.x32_server_name = message.params[1]
4        self.x32_console_model = message.params[2]
5        self.x32_console_version = message.params[3]
6        for handler in self.connection_handlers:
7             handler(self.has_connection)

The handler for /node responses is a bit more complex. The node messages are basically an OSC message converted to a string and terminated by a newline. The only (string) argument looks a bit like this /-prefs/iQ/01 none "Linear" 0\n. To parse it, I used the shlex module to do lexical analysis of the received text (because the quoted text might contain space, I can't use a simple split). Using this method, the address is the first element, then I check if every parameter is a float or an int, if not, it defaults to a string. Then, I call the handle_message recursively to redistribute the message.

1    def handle_message__node(self, message):
2        data = shlex.split(message.params[0][:-1])
3        msg = OscMessageBuilder(data[0])
4        for param in data[1:]:
5            msg.add_arg((int(float(param)) if float(param).is_integer() else float(param)) if _is_number_tryexcept(param) else param)
6        self.handle_message(msg.build())

The /formatsubscribe command will send one binary blob message instead of multiple messages for everything subscribed. Since I subscribe to /ch/**/mix/on and /ch/**/mix/fader with a start of 1 and an end of 32 the console sends a binary blob consisting of 32 int32 for the mute status and 32 float32 for the fader values. Decoding this is straightforward thanks to the struct module and this format <i32i32f. Then I again call the handle_message recursively with "fake" messages

 1    def handle_message__subscribed_faders(self, message):
 2        if len(message.params[0]) != (4 + 4 * 32 + 4 * 32):
 3            self._log.warning("Messaged recevied by the /subscribed/faders handler that doesn't have the right size ({len(message.params[0])} != 260)")
 4            return
 5        data = struct.unpack(f"<i32i32f", message.params[0])[1:]  # Ignore first byte which is the length
 6        # Fake messages to maintain compatibility
 7        for i, value in enumerate(data[:32]):
 8            msg = OscMessageBuilder(f"/ch/{i+1:02}/mix/on")
 9            msg.add_arg(value)
10            self.handle_message(msg.build())
11        for i, value in enumerate(data[32:]):
12            msg = OscMessageBuilder(f"/ch/{i+1:02}/mix/fader")
13            msg.add_arg(value)
14            self.handle_message(msg.build())

Main loop

This loop is responsible for:

• Calling the _re_sync function every 60sec

1             if self.last_resync + 60 < time.time():
2                self._re_sync()

• Calling the _re_subscribe function every 5sec

1             if self.last_resubscribe + 5 < time.time():
2                self._re_subscribe()

• Checking that it's still connected to the X32

1            # Connection status check
2            if last_connection_status != self.has_connection:
3                last_connection_status = self.has_connection
4                # Notify handlers
5                for handler in self.connection_handlers:
6                    handler(self.has_connection)
7                # Force a resync if we just connected
8                if self.has_connection:
9                    self._re_sync()