openlightingproject/rp2040-dmxsun

RP2040-based USB DMX dongle with integrated web server

rp2040-dmxsun's Issues

Add optional Grove-compatible connectors to IO boards

Seeed studio provides an "Grove DMX module" (https://wiki.seeedstudio.com/Grove-DMX512/) which is basically an RS-485-driver + 3-pin XLR connector. It's not cheap, it's not 5-pin and it cannot do input or RDM.
However, we could support it by adding Grove-compatible connectors to the IO boards (before the RS-485 driver).

Implement wireless mesh

Currently, only "sniffer" and "broadcast" wireless modes are implemented. However, the RF24-library also supports a mesh mode (https://nrf24.github.io/RF24Mesh/index.html).This has the great benefit, that packets can hop from one node to another to extend the possible range. In the example topology (see https://nrf24.github.io/RF24Network/md_docs_tuning.html), let's assume the master node "00" is attached to a PC and receives DMX data from there. The nodes "015" and "025" are out of radio range of "00" and cannot directly receive the data. However, node "05" has "00", "015" and "025" in radio range and forwards data from "00" to "015" and "025".

However, the mesh is not "fully automatic" or self-healing. This means that some configuration needs to be done by the end user / operator.

Work in progress at main...kripton:mesh.

To clarify:

• How to implement "true broadcast" with RF24Mesh / RF24Network. "Multicast" between a group of nodes is implemented, but not a "broadcast to all nodes"
• How to keep stats / reachable nodes / mesh topology information available at every node?
• What about many nodes joining and leaving the network. Are the ids "burned" or can they be re-used?

pins for ws5500

Hello! I'm doing some tests with the ws5500 branch, does it work? What would be the pins used to connect my ws5500 board to the rp2040?

Thank you!!

Simplify Logging Code

You've currently got e.g.
https://github.com/OpenLightingProject/rp2040-dongle/blob/08e6e144c32b5bf002fd0e936cf510dbeb2a6162/src/jaruleproto.c#L15

In OLA we use __FILE__ too, but we also setup a macro to centralise and tidy most of the back-end commands (although I guess the latter might be a bit harder if it's all in a printf):
https://github.com/OpenLightingProject/ola/blob/ea3a18a925f123c8771ebc6c60327678e99ddcf2/include/ola/Logging.h#L59-L60

Device Descriptor Request Failed (RP2040 Zero)

That's what I get when I finished uploading the uf2 file into my RP2040 Zero. There's a notification that says the USB device is malfunctioning. Don't know whether this is a Windows 11 issue, or RP2040 Zero issue. I've tried changing USB ports but the error is still there.

The RP2040 Zero have WS2812 LED built into port 16 as its DIN, and after the uf2 finished uploading, the LED somehow turn full white. I think this maybe the problem, as the RP2040 Pico doesn't have WS2812 built into it. I'm not really sure though.

My system is on Win 11 Home (build 22631), AMD Ryzen 5 5600H

Any harware refrance.

Hi,
Im looking for any schematic to make one & try
If you have schematic i wll design pcb & share it.

Naming

It's also easily backronymable, DMX Sixteen UNiverses laughing !

Nice one, didn't even think of it! Want it in the Readme? ;)

Originally posted by @kripton in #34 (comment)

I'll leave that bit up to you either way.

But maybe if it's now called dmxsun the repo should be renamed to match so people can find it? Unless you're going down the route we did with Ja Rule where the software and hardware had different names?

Support for "real" Ethernet hardware

The current implementation emulates a network device via USB (CDC NCM) so that the host computer can transfer data via IP packets (web interface, ArtNet, E1.31/sACN). However, attaching a real Ethernet device could be beneficial. One could build a standalone 16-port ArtNet-to-DMX adapter.

However, the rp2040 only has a limited amount of GPIO pins and there are probably not enough to cater for a LAN8720 board (except if some of its pins were optional). There might be Ethernet-Boards that attach via I2C (no additional pins required) or SPI (one additional pin required for the CE line).

This will also require quite some refactoring on the software side. We could go all the way to allow packet forwarding from the emulated USB network interface to the "real" Ethernet hardware, so the dongle could be used as USB-to-Ethernet adapter as well. I assume that would not be worth the effort ;)

Unit tests

Well, this project currently has 0 tests implemented. Might be nice to have some :)

Replace kicad-exports with KiCad CI/CD template

See #35 : kicad-exports has been archived and https://github.com/nerdyscout/KiCAD-CICD-Template is the replacement, so our GitHub action needs to be reworked.

Use libartnet for Art-Net tx/rx instead of own implementation

OLP has a generic Art-Net implementation (https://github.com/OpenLightingProject/libartnet). This should probably be preferred to the current "custom" implementation

No new .uf2 build last 5 months

Currently there is no way to get compiled .uf2 file from this Github. Would it be possible to check bot for automatic builds as all artifacts are long expired? It is pain in the *** to compile it on Windows and not all guys has dedicated linux machine for such a purporse. Thanks in advance

Implement automatic binary generation using GitHub Actions

The binaries for the Pico board should easily be generated by some kind of CI pipeline

slot configuration not completely implemented

this is more a status report from trying the project, since the README does not mention it.
currently it is not possible to configure the IO boards on the slots.

cgi_config_ioBoards_config in webserver.cpp is actually implemented, and is reachable using an HTTP request (such as http://169.254.59.1/config/ioBoards/config.json?slot=0&boardType=3&port0dir=3&port0con=2&port1dir=3&port1con=2&port2dir=0&port2con=0&port3dir=0&port3con=0 , values are from boardconfig.h ), but the configuration is not reflected back (in the UI or functions).

currently 4 DMX outputs is hard coded and this can't be changed using the config.

Supported protocol / WS2812 LED strings

Hello,

I want to know whether the project supports WS2812 LEDs and XLights software.

Thank you in advance!

DHCP request not acked

after the DHCP offer from the RP2040 over USB, the computer (USB host) requests the offered IP.
but the RP2040 does not ACK this request.
thus the DCHP negotiation does not complete and the IP is not assigned to the interface (at least nor under Linuc Arch using dhcpcd).

see attached trace where DHCP client repeats the unanswered request.

Add some sort of source-code-level documentation

It would be great to have some nice documentation about all classes and methods there are in the source code. I'm thinking of doxygen and the like but I'm open to other proposals as well.

Hardware: Finish the IOboards with 5-pin XLR connectors

Currently, only the IOboards with 3-pin XLR connectors are done and have been ordered and tested. The 5-pin variants are not yet completed and/or tested. 5-pin XLR connectors a must to fulfil the actual DMX-512-A specification and for professional users.

pico rp2040 ethernet branch build failure (tcpecho_raw.h not found)

i am trying to Ethernet( ENC28J60 ) configuration with pico rp2040 as per main...kripton:ethernet) but get error..

Hardware: Design baseboard with fewer slots

Currently only a "full-blown", 4-slots baseboard has been designed to test the full capability of the hardware. However, most of the time, 16 universes are not needed and a smaller footprint would be desired.

Therefore, we should have:

• A baseboard with only ONE slot for an IO board
• A baseboard with TWO slots for IO boards
• Maybe a 4-slot-baseboard with one IO board to the west, two to the south and one to the east. Will be much more compact than the current layout that is focused on getting 16 XLR-ports fitted into 19", 1 U

Hardware: Add Grove I2C connectors to base board

The base board already routes the I2C bus to the IO boards. It would be nice if a Grove-compatible connector would allow additional extensions (OLED, LCD, input buttons, NFC?, ...).
Effort should be minimal.

Implement configurable patching via the web interface

Right now, the patching of incoming data to the internal DMX buffers and from there to output ports is hardcoded. What would be needed is the implementation to have the current patchings accessible and changeable via the HTTP API plus a visual representation on the Web UI.

Serial Numbers/UIDs

I see you've already mentioned this partly in #2 but given it's important we don't get UID clashes in our space so for now if you're using static ones it would be good to switch to some of the reserved ones here (any of the development blocks are fine):
https://wiki.openlighting.org/index.php/Open_Lighting_Allocations#UIDs

What serial(s)/MAC(s) does the RP2040 chip ship with and I can suggest some ways we could make use of them based on what we've done in the past.

pico only blinks

Hello, I'm trying to test your project but I load the latest version of your software and my pico only flashes the led quickly but no network device appears. load some sample uf2 projects and it works. im very new with pico am i forgetting something?

thank you!

WebUI: Use websockets instead of http polling/API

Currently the Web UI uses HTTP call to the device's API to get/update information like device status, buffer content (Console page), log entries, wireless status counters. Usually, a one second update polling interval is being used which makes the Console seem laggy when the values update often or fade. Websockets provide a nice way to make the Web UI more responsive and faster. Some "live audio mixers" that can be controlled via web browser from a tablet or similar uss websockets for control and signal level display (Soundcraft's Ui series).
The client/browser part should not be a problem (and a fallback to polling could be done if the user-agent doesn't support websockets). On the server side (lwIP stack and its http server) impementation will be quite some effort.

Hardware: Migrate files to KiCad 6.x format

KiCad v6.x changed the file format, especially for the schematics (see https://www.kicad.org/blog/2021/12/KiCad-6.0.0-Release/). The current files in the hardware folder should be migrated to this new data format.
Also, the GitHub-Actions might need to be updated/adapted.

Hardware: Footprint of NC3FD-H is incorrect

Some IO boards (4ports_unisolated for example) feature the NC3FD-H connector. Since that part was not available in any KiCad-library, I created it myself. However, the drills on the PCB are now smaller than what the actual connector requires and as such the connector cannot be soldered to the PCB :(

Web-UI compilation should be integrated properly

At the moment, the way the Web-UI is being built is a bit of a hack. It runs during the "CMake" step, not during "make" where it actually should be. Also, it doesn't fail the build if for some reason (NodeJS missing, dependencies not resolving properly, ...) the compilation of the Web-UI fails. This is all mainly due to my very basic knowledge of CMake.

Implement RDM

Lots of work to be done here :)
Depends on #21

I personally don't have much experience with RDM. I do understand the concept and benefits. However, I don't have any real fixtures to test it, only the "Arduino RDM responder".

Consider adding branch protection

https://github.com/OpenLightingProject/rp2040-dongle/settings/branches

This means that at least for PRs people know certain things have to pass before they'll be merged. You can optionally allow admins to ignore this.

uf2-file

Hi,
I am struggling to understand GitHub actions but I guess I don't have enough patience at the moment :)

If you just want to get started quickly find the most recent action run from the branch you're interested in, extract the attached artifact zip file (from https://github.com/OpenLightingProject/rp2040-dongle/actions/workflows/pico-build.yml ) and copy the rp2040-dongle.uf2 file to the Pico board when it's in bootloader mode.

I don't find any zip file or how to generate it?

rp2040-dmxsun - system compilation error

window system :-

I am getting complication error when run this command "make -j$(($(nproc)+1)) " and also window has issues finding libraries (lwip)

C:\Users\pico\Downloads\rp2040-dmxsun\pico-sdk\lib\tinyusb\lib\networking\dhserver.h:38:10:
fatal error: lwip/err.h: No such file or directory

i cant find .uf2 file in this repo. it will be helpful..

Implement a "switch to bootloader" command

When flashing the Pico over USB (instead of using the SWD-based debug port and OpenOCD), one needs to replug the board everytime it should be flashed. If fhe SDK allows it, add a command to the USB protocol to reboot to the bootloader.

Support Web interface, Art-Net, E1.31 and EDP via WiFi on the Pico W

Raspberry Pi released the Pico W including on-board WiFi 🥳 https://www.raspberrypi.com/news/raspberry-pi-pico-w-your-6-iot-platform/

While the radio-module doesn't support narrow-band RF in the 2.4GHz band and Bluetooth is not yet supported/enabled, the new Pico W is pin-compatible (except the on-board LED) with the current one.

It sounds like a good "step up" from the regular Pico and to enhance the dmxsun with the web interface, Art-Net, E1.31 and EDP via the WiFi-interface in addition to the emulated CDC NCM via USB.

Things needing work:

• The on-board-LED is now managed via the radio module. As such, GPIO 25 is no longer available and https://github.com/OpenLightingProject/rp2040-dmxsun/blob/main/src/pins.h#L45 leads to a compilation error. Easy fix
• pico-sdk 1.4.0 seems to ship lwIP in two places: lib/tinyusb/lib/lwip/ (where it already was before) and lib/lwip/ (where it was added to support IP via the cyw43 driver. This leads to the following compilation error (might be version conflict, needs investigation):

In file included from /opt/raspberrypi/pico-sdk/src/rp2_common/pico_cyw43_arch/cyw43_arch.c:12:
/opt/raspberrypi/pico-sdk/lib/cyw43-driver/src/cyw43.h:118:17: error: field 'dhcp_client' has incomplete type
  118 |     struct dhcp dhcp_client;
      |                 ^~~~~~~~~~~

• The cyw43 radio module seems to need two firmware blobs (https://github.com/georgerobotics/cyw43-driver/blob/195dfcc10bb6f379e3dea45147590db2203d3c7b/firmware/43439A0-7.95.49.00.combined, 220kByte and https://github.com/georgerobotics/cyw43-driver/blob/195dfcc10bb6f379e3dea45147590db2203d3c7b/firmware/4343WA1-7.45.98.50.combined, 416kByte). Compared to the 2MByte flash (which is the same since as with the regular Pico and has not been increased for the Pico W), those files are huge. The current main branch of rp2040-dmxsun generates a 1.5MByte uf2-file (debug build), mainly due to the React-based web interface. I'm afraid that with adding the two firmware blobs, the flash memory will not suffice :(. Not yet confirmed since I didn't yet fix the compilation error mentioned above

Hardware + Software: Create an "LED-String" board

This project is mainly focused on generating DMX data and driving RS-485-lines with it. However, due to the modular hardware design, the firmware can also be used to drive LED-pixel-strings with WS2812b or similar protocols.

The current boardconfig-data already has fields prepared for IO boards with that purpose. However, the hardware design and firmware implementation has not yet been done.

Implement DMX input

Currently, only DMX output is implemented. However, DMX input is highly desirable (so we can build an active DMX splitter, or receive DMX data from a console on an input port and forward that data to a PC or via wireless) and is also a requirement for RDM.

DMX input on the rp2040 has been implemented at https://github.com/jostlowe/Pico-DMX and I've verified it working (after some changes that have been merged in the meantime).

However, with the current "big locks" (which disable all interrupts as well) in the code, incoming DMX frames could be lost (if the end of an incoming DMX frame happens while the CPU is busy generating data for the next frames to be sent).

So besides changing the patching infrastructure and properly assigning the PIOs, SMs and GPIOs properly, the locking and interrupt disabling code needs to be re-worked.

Proposal: Split up the current "big lock"/spinlock to several smaller ones and think hard, when to disable interrupts and when not. Caution: Deadlocks can appear when code owning a mutex is interrupted by a service handler that also wants the same mutex that is locked by the interrupted code.

Also, the incoming data should NOT be immediately processed in the ISR. It should be appended to some kind of queue and be handled in the main loop.

Work in progress is here: main...kripton:dmxIn

Hardware: Finish, order and test the "isolated" IO board variants

For cost reasons and since I didn't know for sure if all features I had in mind actually work, I only ordered, soldered and tested the "unisolated" variants of the IO boards.
The "isolated" (= galvanically isolated and better protected against ESD) variants are more or less done but are yet untested. They are more expensive since they require DC/DC-converters with quite some output power and the isolated RS-485-driver ICs are more expensive than the non-isolated ones.

Demo version of the website

It might be nice to push a demo version of the website up to GitHub pages or the Open Lighting website, assuming it could be made to work standalone or with some dummy JSON files without too much work.

Re-investigate on zeroconf / mDNS

Currently, the device chooses one IP address based on the chip ID in the flash memory (if no IP has been stored in the config) and provides another IP in the same subnet to the host machine via DHCP.
This might be easier using AutoIP/APIPA provided by the lwIP stack: https://www.nongnu.org/lwip/2_0_x/group__autoip.html. We just need to make sure that all host OSes we want to support don't treat network connections as non-functional if their DHCP requests go unanswered.
Zeroconf is the name of the technology / processes ifself. Apple Bonjour and Avahi are two widely-known implementations.

Also, usbsun should at least advertise some kind of hostname and the services it provides via mDNS (also already supported by lwIP).

Design a "direct GPIO to XLR" board

See jostlowe/Pico-DMX#27 and https://github.com/kripton/rp2040-dongle/tree/DirectDifferentialOutput: It's possible to directly control fixtures via the GPIOs, not necessarily do we need an RS485 driver. While one cannot drive 16 universes that way (not even 8), it might allow for a very cheap IO board

WebUI: Update react from 17.x to 18.x

See https://reactjs.org/blog/2022/03/08/react-18-upgrade-guide.html