ultranet-adventures-part-1/

[giscus[bot]]

ultranet-adventures-part-1/

Deep-diving into Ultranet and re-implementing both a receiver and transmitter on FPGA.

https://blog.thestaticturtle.fr/ultranet-adventures-part-1/

[jon68z]

Looking forward to your progress in Part 2. Can you tell me what Tool Chain you used and what the resource utilization of the FPGA was/is? Thanks and congratulations!

[TheStaticTurtle]

Thanks for the read!
Yeah, I'm also looking forward to it. I ordered the new pure-FPGA PCBs and a devboard for the DIX9211 to mess around with yesterday. 😝.

Can you tell me what Tool Chain you used and what the resource utilization of the FPGA was/is?

As you can probably guess, I'm no FPGA expert, so I'm not sure how I would improve it, but here it is:

Also, I saw you created a discussion yourself on GitHub. I use giscus to show them on the website, and it manages everything on its own, so I'm going to respond here:

Can you share the existing source code?

I'm planning to release everything properly (HDL & electrical) , but as you might have read, there are a few things I want to fix before doing so.
That being said there is a lot on the article already!

Again thanks for the read!

[jon68z]

Your descriptions and narrative were very well written, so it was a pleasure to read. I really enjoyed it. Thank you.

Interesting, just downloaded the Data Sheet for the Ti DIX9211. I'm not at all familiar with this device. What problem do you hope to alleviate with this chip? board space constraints? Looking forward to your further journey on this design.

[TheStaticTurtle]

Thanks, it took quite a while to write; I'm happy it's readable.

The DIX9211 is a bidirectional alternative to the AK4114 that Behringer uses.
Basically (if I read the datasheet correctly), using the DIX9211 would remove the AES3 transmitter and receiver block from the FPGA code.

I should be able to feed AES3 into the RXIN pin and get the pre-processed I2S SCKO, BCK, LRCK, DOUT and BSYNC signals. I should also be able to simultaneously use one of the MPIO ports as an I2S input and output a ready to use AES3 signal.

It's still very theoretical, but it would only leave a very basic clock divider, multiplexer, and demultiplexer running on the FPGA leaving the "high-speed" stuff in hardware.

It's totally possible to only use an FPGA (heck, if I wasn't hellbent on open-sourcing it, I could have probably used built-in SPDIF IP blocks in the Gowin designer). But the way I see it is that I would be spending 3 EUR more per board to avoid dealing with "high-speed" inside the FPGA, which also means I could get a smaller/cheaper one like the Tang Nano 1k.

The new version has separate PCBs for the DACs, ADCs & main board, so it will make it easier to tinker.

[jon68z]

Thanks for the clarification on using the Ti DIX9211. Very interesting usage to further reduce FPGA resources. Possible other features to use that opened up space are very intriguing... I definitely like your approach to separating out the design into multiple PCBs.

Thanks again for the info.

[l2002313456-del]

Hi Samuel,

I enjoyed reading about your Ultranet FPGA project — your work on decoding and implementing the protocol is impressive.

I'm Emily from PCBWay, a global PCB munufacturer in China. I'd love to explore a pontential collaboration by sponsoring free PCB prototyping that could help support your project as it progresses.

Would you be interested in collaborating? Feel free to contact me at any time.

Best Regards,
Emily
Email:marketing@pcbway.com

[rob-fi]

Hey Samuel!

I've looked at a few projects that have all done what you have with various different sizes and shapes of wheels, but yours is the most well-written of them all!

I thought perhaps I could bounce an idea of you and figure out the best way to do it: I basically want to just demultiplex 8 channels of the Ultranet into 4 stereo pairs of normal AES3 in the most straightforward way possible. No reclocking, no sample rate conversions, just the absolute minimum to re-package samples with the correct bits attached to make them valid AES3 again, and then feed out to XLRs (via the necessary transformers and passives of course). Unless I'm missing something, which I most likely am, I feel a whole bunch of stuff could be skipped (e.g. I2S conversion) that all of these projects that I've come across do. So far https://github.com/doughadfield/Ultranet-to-I2S looked like a good basis perhaps to explore the idea with (e.g. trying to skip the I2S part), but now I've come across your implementation also, I thought I'd ask your opinion! :)

Thanks!

[TheStaticTurtle]

Hi,

I've looked at a few projects that have all done what you have with various different sizes and shapes of wheels, but yours is the most well-written of them all!

Thanks it took quite a while to write 😅, I wanted to include a bunch of the basics so that it's easier for novices to understand!

No reclocking, no sample rate conversions, just the absolute minimum to re-package samples with the correct bits attached to make them valid AES3 again, and then feed out to XLRs (via the necessary transformers and passives of course).

Unless I'm missing something, which I most likely am, I feel a whole bunch of stuff could be skipped (e.g. I2S conversion) that all of these projects that I've come across do.

There's actually no re-clocking / sample rate conversion happening in my project. I'm pretty sure you could do the whole project in basic logic gates. From a bit stream point of view, sending one 192kHz signal or four 48kHz signals on the same line is the same:

• For a 48KHz AES3 stream we get two 24bit audio streams at 48KHz
• For a 192KHz AES3 stream we get two 24bit audio streams at 192KHz
• For a Ultranet stream (192KHz AES3) we get eight 24bit audio streams at 48KHz

So once we got these bits we need to do something with them, the simplest way to interface with outside peripherals is using a serializer with left-justified or I2S data which is very similar to SPI, you got a bit clock, data and a word clock (sometimes known as left/right) which switches at the sample rate. See for yourself:

Now if you want to output AES3 you've got a fair bit more work to do, you got the preamble as well as the four status bits to worry about. You also have to deal with the biphase encoding. AES3 is just more annoying to deal with than plain left-justified data. That being said, it's still fairly "easy" to implement if you want to give it a go you can look at open-source implementations of the thing.

To summarize:

• Once you got the bits you need to do something with them
• To convert Ultranet in 4 I2S signal you need to sync & deserialize the AES3 signal and re-serialize to 4 I2S signals
• To convert Ultranet in 4 AES3 signals you need to sync & deserialize the AES3 signal, rebuilt 4 individual AES3 streams with correct preambles & status bits and finally re-serialize to 4 AES3 signals

Let me know if I can explain further!

Thanks,
Samuel

[rob-fi]

That was actually really helpful. Thanks a lot. I have some food for thought now!

My end goal is to be able to get 8 (4 stereo) AES3 channels out of an X32 Rack to put into a Blackmagic Audio2SDI embedder. At my work I basically have every piece of expensive broadcast equipment you can think of to do this sort of stuff (we use Yamaha or Allen & Heath mixers which have AES outputs, or we use Dante AES adapters). But I'd like to have a low cost solution for my hobby/volunteer work also.

I have also considered, for at least one AES output, trying to modify my X32 to add the AES output that is present on the larger console models. The IC that handles it is there (it's the same one that does the Ultranet outputs) but the pin isn't connected. I just think it would be nicer to have something that plugs into the Ultranet port instead, as I don't use it for anything else.

Rob

[TheStaticTurtle]

My end goal is to be able to get 8 (4 stereo) AES3 channels out of an X32 Rack to put into a Blackmagic Audio2SDI embedder

Ohh, this is an interesting project! Fun fact I actually considered using SDI as a backbone to carry the audio, but the chips that can do it (GS2972 / GS2970A) are BGA and stupidly expensive for hobbyists. And finding an cheap-ish FPGA devboard capable of doing even SD-SDI is quite hard. But it's something I would like to try someday

At my work I basically have every piece of expensive broadcast equipment you can think of to do this sort of stuff (we use Yamaha or Allen & Heath mixers which have AES outputs, or we use Dante AES adapters). But I'd like to have a low cost solution for my hobby/volunteer work also.

Ha, I wish I had access to even pro-ish gear to at least test things out. It's incredible what you can achieve with time and perseverance as a hobbyist nowadays

For instance, there's a very cool project aimed to build an open-source software/firmware for the X32: https://github.com/OpenMixerProject/OpenX32

I have also considered, for at least one AES output, trying to modify my X32 to add the AES output that is present on the larger console models. The IC that handles it is there (it's the same one that does the Ultranet outputs) but the pin isn't connected.

That's a shame, but it's probably expected I would assume that it's also disabled in firmware

I just think it would be nicer to have something that plugs into the Ultranet port instead, as I don't use it for anything else.

Indeed, Ultranet to SDI is a pretty cool project!