Connecting a (cheap ;) nRF radio dongle via SPI to form a wireless DMX network

[kripton]

Just an idea that I would like to write down at least once. Open for lots of discussion :)
So the RP2040 has (one or more) SPI ports. So far, nothing special. Nordic Semiconductors provide chips that do radio communication pretty well (thinking about the longer-range, fewer bandwidth things in one of the ISM bands) and that can be spoken to via SPI. "Breakout boards" or "radio modules" containing such chips are actually pretty cheap. Those modules could be hooked up to the RP2040 to form a network of wireless DMX nodes.

I know that there are standards already such as LumenRadio CRMX or the RC4-based products or "WDMX". However, they all seem to be proprietary and closed. I would be happy to be proven wrong, though.

Some more details:

The nRF905 is the common chip for "sub-GHz" ISM band operation (frequency depending on region where it shall be operated). The chip is always the same, the module is usually tuned for a specific frequency (433/868/915MHz) and usually cost less than $/€10.

• Specification: https://infocenter.nordicsemi.com/pdf/nRF905_PS_v1.5.pdf
• Documentation example: https://www.electrodragon.com/w/NRF905
• Documentation example: https://www.espruino.com/NRF905
• Pricing examples: https://www.ebay.com/sch/i.html?_nkw=nrf905&mkcid=1&mkrid=711-53200-19255-0&siteid=0&campid=5337979701&customid=&toolid=10001&mkevt=1
  The disadvantage of those ISM bands is that you usually have some duty cycle limit so you cannot send all the time. Usually it's sending at most 1% of the time (= 36 seconds transmission in one hour), receiving only for the rest of the time. So it's not really suitable for a "one DMX sender sends updates all the time" scenario. Some devices enforce those limits, some don't. The advantage is that those bands are less crowded due to the duty cycle limitation and as such are pretty reliable. The range that can be achieved in those bands is also pretty impressive.

The other possible solution would be to use the famous 2.4GHz ISM band. Yep, the one that WiFi, Bluetooth and lots of cheap wireless microphones are using. However, there is no limitation of time transmitting and if using some frequency-hopping technology, the reliability and range can also be quite good. Price range is from very cheap to cheap, depending on transmit power and antenna design. Usually much cheaper than the nRF905.

• Specification: https://infocenter.nordicsemi.com/pdf/nRF24L01P_PS_v1.0.pdf
• Documentation example: https://howtomechatronics.com/tutorials/arduino/arduino-wireless-communication-nrf24l01-tutorial/
• Pricing examples: https://www.ebay.com/sch/i.html?_from=R40&_trksid=p2380057.m570.l1313&_nkw=nrf24&_sacat=0
• Pricing examples: https://www.amazon.de/Nrf24-Elektronik-Foto/s?k=Nrf24&rh=n%3A562066&language=en_GB

System-design wise, I would like to have (big wishlist here):

• MUST HAVE: Some kind of stand-alone software that talks to the RP2040 over some USB-based protocol to configure and monitor the system
• MUST HAVE: Every participant can be configured as sender (= transmitting DMX frames) (either controlled by a Host PC or reading the data on one or more DMX INPUT ports) or as receiver (= receiving DMX frames over the air and converting them to RS-485-based DMX-512 or to WS2812-based LEDs or to control el-cheapo LED-devices that are usually controlled via an infrared remote control. That basically means that there should be only "one device" not devices with a fixed role.
• SHOULD HAVE: There should be some discovery protocol so that one can connect a laptop to any participant (usually the sender) and perform a receiver discovery
• SHOULD HAVE: data encryption with a key set via the configuration software or a pairing button
• SHOULD HAVE: data compression (see Using data compression for the USB protocol #3) and intelligent delta-only transmission
• SHOULD HAVE: Broadcast the data to not send the same data to multiple devices in multiple transmissions. However, each receiver should be configurable to output specific DMX universes so one can either choose:
  • to send only a few number of universes that are output by ALL receivers
  • to send one universe for each receiver in the network, each outputting only one
  • a mix of the above ;)
• SHOULD HAVE: Some kind of feedback channel so the receivers can report current radio signal levels and maybe report non-received frames. And battery level if the receiver is battery-powered
• NICE TO HAVE: Some kind of Display at each participant with buttons and a menu. Makes the product more expensive
• NICE TO HAVE: Visual radio signal strength and current role indication via LEDs or an OLED display
• NICE TO HAVE: The radio module could connect to "non-radio" USB-DMX-dongles via some kind of extension connector so that existing dongles can be upgraded

I might have had more ideas about that but right now, I cannot remember anything more :D

Of course, the sender device should still be able to output DMX data via the "local ports" and not "send via air, only". And in larger systems, this increases the number of "ports" that the DMX-data-generating software need to address and patch. And their number might well be very dynamic, depending on the number of receivers in the system. OR one fixes the number of possible universes to lets say 32 universes and the "patching" of the universes to the individual receivers is done by the standalone control software.

[kripton]

I already did some experiments and "radio protocol" design using ESP32-based boards that have their own 2.4GHz-low-bandwidth system (called ESP-NOW). Current code is here: https://github.com/kripton/DMXoverNOW. However, the code is not yet well structured nor documented, nor working flawlessly. Probably the most relevant parts (radio protocol wise) are:

• https://github.com/kripton/DMXoverNOW/blob/master/ESP32_Master/src/ESP32_Master.ino#L407
• https://github.com/kripton/DMXoverNOW/blob/master/ESP32_Slave/src/ESP32_Slave.ino#L271

Reading the "old" code again, much less mature than I had in mind. But it worked as a very basic wireless DMX system ;)

Talking about the ESP32, the RP2040-based board announced by Arduino (called Arduino Nano RP2040 Connect but not yet available) will most probably feature a WiFi/Bluetooth module from uBlox that is said to contain an ESP32. So it might be that this board is VERY interesting if the ESP32 can be freely programmed. However, I expect the board to cost more than $/€ 30. We will see, no official prices or availabilities announced yet.

[kripton]

Another requirement:

• NICE TO HAVE: Some kind of repeater or meshing functionality to extend range, reliability or both

[peternewman]

I know that there are standards already such as LumenRadio CRMX or the RC4-based products or "WDMX". However, they all seem to be proprietary and closed. I would be happy to be proven wrong, though.

I don't think you are unfortunately. They offer modules of various types and complexities to add their stuff to you product.

• MUST HAVE: Some kind of stand-alone software that talks to the RP2040 over some USB-based protocol to configure and monitor the system

This could potentially be dummied up as RDM so it just integrates into the rest of the GUI.

[kripton]

Yep, making the dongle's radio configuration (and scanning for peers/slaves) valid RDM frames is a brilliant idea 👍

[kripton]

Regarding the W-DMX "standard", this is quite interesting: https://web.archive.org/web/20210407214854/https://fccid.io/2APCT-DMXG5SB/User-Manual/User-Manual-3851043.pdf

[kripton]

This is even more interesting: The Wireless Solution Sweden Sales AB, Nano G5 uses the nRF51822 chip: https://fccid.io/2APCT-DMXG5SB/Internal-Photos/Internal-Photos-3851039. So, hardware-wise we are already compatible with the W-DMX. It would just be lots of work to reverse-engineer the RF protocol they use.

Update: Well, it might be (and I assume) that the nRF51822 is compatible with existing nRF24 chips but can do things (RF-wise) that the nRF24 is not capable of. So having one nRF24 might not suffice to participate or be a master in the W-DMX network.

[kripton]

Update: I attached an nRF24L01+-dongle to the board and porting the https://github.com/nRF24/RF24 library to the RP2040 is in progress (nRF24/RF24#727). Right now, I have QLC+ generating data, passing it to OLA, passing it via USB to the pico board. This sends it via the nRF24-dongle to an Arduino that has 8 WS2812-LEDs attached. Update rate is currently relaxed to 100ms (= 10 updates per second) but it's working like a charm after adding some additional capacitors. Looks like they should be added to the baseboard in the next revision ;)

This nRF24-library already has a mesh implementation ready: https://github.com/nRF24/RF24Mesh. I will try that next. Looks promising, really curious to see how well it will work!