Which modes/variants (port-wise) make sense?

[kripton]

I assume that several models or variants of a RP2040-based USB to DMX dongle might be useful.

Software-wise, it's only yet proven that DMX output is possible. DMX input and RDM are not yet implemented but I assume that each RDM-capable port or INPUT-only port will require one PIO state machine for itself.

Considering the existing resource limitations (PIO state machines, IO pins and USB protocol) I could think of (see comments)

[kripton]

A 16-universe, output-only model

• Proven to work from the RP2040 side using one PIO state machine for all 16 outputs
• Not possible with the current plan to use the Ja-Rule protocol since that uses one USB interface (with a pair of endpoints each) for each DMX-port, USB allows up to 16 endpoint pairs (16 IN, 16 OUT). One pair of endpoints is used by the CONTROL transfers and I would like to have a "serial" debugging port using CDC ACM which uses 3 endpoints. That would leave us with 13 useable pair of endpoints. However, I'm having problems for the USB device to enumerate if there are more than 9 USB interfaces for DMX. Investigation pending

[peternewman]

Is the USB bandwidth sufficient for this, or does it depend on the protocol?

[kripton]

There's a quick calculation I did before starting this all:

• One DMX universe is 250 kBit/s (minus a bit for BREAK and MAB but we will ignore that)
• Four universes are 1 MBit/s
• Sixteen universes are 4 MBit/s

The RP2040 is a Full-Speed USB device. That means it can do 12 MBit/s on the USB bus. Of course, USB itself has some overhead and depending on the protocol, there is additional overhead (very few for protocols such as uDMX or Nodle U1, a bit more overhead for the Ja-Rule-protocol, even more for protocols such as ArtNet or E1.31 over IP over an emulated network card or virtual FAT16 file system.

However, I think that 12 MBit/s should be more then enough if our maximum "output data rate" for 16 universes is 4 MBit/s. And using data compression (see #3), the actual data that goes from the host to the dongle should be even less.

[peternewman]

👍 (the reaction dialogue is hidden for some reason).

[kripton]

A model with 10 or 9 ports: 6 ports for RDM-capable outputs (RDM controller) or inputs (RDM responder) (using one PIO state machine each) + n ports OUTPUT (non-RDM) only (using one PIO state machine for all of them)

• Basic limitation is again the USB protocol. Pin-wise, if we subtract 12 GPIOs for the RDM-capable OUTs/INs, there would be at least 4 GPIOs for outputs only
• Using the Ja-Rule-protocol, this would impose a limit of 14 (useable endpoint pairs) - 6 (RDM-capable ports) = 8 possible OUTPUT-only ports
• Regarding the maximum 9 USB interfaces for DMX ports (=9) that would mean 9 -6 = 3 OUTPUT-only ports
• I would like to "reserve" one of the 8 PIO state machines to drive a string of WS2812 LEDs for status display

[peternewman]

The Ja-Rule RDM responders are dummy devices that sit entirely on the hardware (aside from logging). Enttec are the only people to have offered RDM input to a PC, and that just ACK TIMERed everything until the (slow) PC was ready to reply.

[kripton]

Good thought. I think with RDM responder I meant mainly replied by the hardware. Didn't think about forwarding RDM requests (from external) to the PC for answering and that the PC really is way too slow for such a thing.

[peternewman]

Good thought. I think with RDM responder I meant mainly replied by the hardware. Didn't think about forwarding RDM requests (from external) to the PC for answering and that the PC really is way too slow for such a thing.

Yeah they basically respond immediately telling you to wait, then pass the message up to the PC until it's replied and they pass that on. I'm not sure many people really use it.

Cool. I assume a theoretical DMX input device is only likely to use one PIO too, so those input ports could also cover that too.

I guess with multiple physical dummy responders you could make something more like a Labpack with potentially different timing and all the devices daisy-chained together.

[kripton]

I'm not sure if one PIO state machine can support multiple universes. In the TX-only case it's easy since all universes are timed synchronously. When receiving, the timing is given (or better: dictated) by the sender.

There are basically two ways:

• We could make the receiving code similar to how the rp2040 currently sends DMX: Just "clock in" / "sample" the data on the bus using the PIO and let the CPU (on the pico board, not the PC host) do the actual decoding. Then, one state machine can be used for several input pins. The decoding would be similar (or just copying the code) of https://github.com/OpenLightingProject/ola/blob/master/tools/logic/DMXSignalProcessor.cpp (which I just learned today that it exists) but I'm not sure if the microcontroller can handle it (CPU-load wise)
• Have some more intelligence in the PIO state machine (like detecting BREAK and MAB) and have the DMX content data for the CPU to fetch. This would mean there needs to be one PIO state machine (of 8 totally available) for each DMX input port.

[peternewman]

Yeah sorry, I meant the RDM supporting output ports could do DMX in too, using a PIO each.

• We could make the receiving code similar to how the rp2040 currently sends DMX: Just "clock in" / "sample" the data on the bus using the PIO and let the CPU (on the pico board, not the PC host) do the actual decoding. Then, one state machine can be used for several input pins. The decoding would be similar (or just copying the code) of https://github.com/OpenLightingProject/ola/blob/master/tools/logic/DMXSignalProcessor.cpp (which I just learned today that it exists) but I'm not sure if the microcontroller can handle it (CPU-load wise)
  Yeah the signal processor code isn't very complicated, but perhaps it might not be able to do lots of pins.

If you're dealing with break detection then you probably also need to do some packing somehow to represent the break in the data stream.

[kripton]

A model with fewer ports (2 RDM capable)?

• This would of course limit the number of required parts (RS-485 bus drivers, DC/DC-converters, XLR connectors) resulting in a lower total cost. It should even be possible to bus-power a device with up to 4 ports (500mA limit regarding what USB can provide to one USB 2.0 device, 100mA per port and 100mA for the Pico board)

[peternewman]

A PR might be easier to comment on. 😄

Okay, I've been busy on the hardware design. Don't expect this production-ready yet but it's a start.

Looks like a great start.

Baseboard:
RPi Pico obviously goes to the middle of the base board. µUSB is directly connected.

Pico at 90 degrees with a separate cable would allow a shallower box, but might not be worth the hassle.

Every baseboard has an I2C-EEPROM (256 byte) on board so that the base board can detect the presence and type of the
attached IO boards.

Neat touch, how do they get programmed?

Direction cannot be switched via software but one can re-solder 0-Ohm-Resistors to change the direction of the individual ports in hardware.

Any reason for not using handbags, or DIL/piano switches? Presumably cost and what needs soldering onboard? Perhaps add pads for the other options so someone could remove the factory resistors and make them dynamic?

This board is meant to be either mounted with 4x Neutrik NC3FD-H (expensive but they will fix the board to the front panel mechanically) or 4x Neutrik NC3FAAH (cheap).

Just a warning, NC3FAAH isn't unified D, so won't fit your pre-made panel idea as most (all?) of the panels are unified D so they take the whole range of connectors. Check the drawings to see the mounting hole differences.

I didn't look, but I'm guessing they have the same pad footprint?

A 5-Pin version is also desired but I'd like to find out if this PCB layout for two different socket works.

From the standard:

Equipment in this category shall use 5-pin XLR connectors

And:

A concession to use an alternate connector is available only when it is physically impossible to mount a 5-pin
XLR connector on the product. In such cases all the following additional requirements shall be met :

1. The alternate connector shall not be any type of XLR connector.

I.e. five pins should be the default, with maybe a disco option of three pin as a rarity.

This could theoretically fit 16 XLR port into 1U. I'm curious if this will work as designed ;)

As above, it should if you buy the expensive sockets.

[peternewman]

Update: ioboard_4ports_cheap and ioboard_2ports_rdm are both done and on github. I've also started to create a github action to automatically generate the schematic PDF and PCB production files on each commit.

Nice. If you generate images too, you can do magic things like this:
https://docs.github.com/en/github/managing-files-in-a-repository/rendering-and-diffing-images

I've also sent the baseboard_4slots and ioboard_4ports_cheap for production and assume to receive them in about 1 or 2 weeks :D The boards come with all SMD parts soldered and I do have the remaining THT-parts at home waiting for the boards to arrive.

Exciting!

@peternewman : Any opinion about that proposal? A bit what you expected it to be? Not at all?

It's quite wide! But I guess that's to be expected with so many ports!

Have you considered, depending on usage, some people might want all the connections on the front (e.g. laptop on top of a rack), although I guess most want it on the rear.

[kripton]

A PR might be easier to comment on. smile

True :) I'm still looking for a good way to work with kicad and git. Kicad changes lots of lines in the files for only trivial changes. And I still haven't found a way to use relative paths for symbol- and footprint-libraries shipped with the projects :-/ ...

Looks like a great start.
Neat touch, how do they get programmed?

Thanks :)
Good question. They are meant to be "read-only" and written once "on production". However, I think it would be okay for now to set their initial value via the web browser interface (still planning to have an emulated network interface + web server ;)).

Any reason for not using handbags, or DIL/piano switches? Presumably cost and what needs soldering onboard? Perhaps add pads for the other options so someone could remove the factory resistors and make them dynamic?

Yes: cost :) The PCB fab I currently use to produce the prototypes (JLCPCB) has some parts in their SMD-feeder all the time (they call them "Basic parts"). DIL switches or SMD-mounted pin headers are unfortunately not part of the basic parts and they charge extra if the need to load parts into their machines.
The pads for the other options (= DMX RX) are on the boards but not populated. So if one wants to change a TX-port to a RX-port, two resistors need to be unsoldered and re-soldered on a different position:

Just a warning, NC3FAAH isn't unified D, so won't fit your pre-made panel idea as most (all?) of the panels are unified D so they take the whole range of connectors. Check the drawings to see the mounting hole differences.

I didn't look, but I'm guessing they have the same pad footprint?

Unfortunately not at all :(
I know that NC3FAAH isn't D-norm but they are a lot cheaper (~8€ vs. ~0.8€ per connector). That's why the place on the PCB looks so strange.

From the standard:

Equipment in this category shall use 5-pin XLR connectors

And:

A concession to use an alternate connector is available only when it is physically impossible to mount a 5-pin
XLR connector on the product. In such cases all the following additional requirements shall be met :

1. The alternate connector shall not be any type of XLR connector.

I.e. five pins should be the default, with maybe a disco option of three pin as a rarity.

Thanks, I've known that the official standards don't allow XLR3. However, I didn't know that they state it so clearly ;) Until we know that it all works as expected, I'll stick with the XLR3 since the 5-pin Neutriks are really expensive. But I promise to also do 5-pin layouts.

The NC3FD-H have the big advantage that you can split them into 2 parts: https://www.neutrik.com/media/11281/download/bda-020---d-serie-xlr-chassis-connector.pdf. That means you solder the inner part of the connector to your PCB and mount the housing to the front panel. Then, you mate & lock them. Unfortunately, there is no 5-pin variant that does the same. And I wouldn't know how one would solder the connectors to the PCB if they need to be mounted to the front plate first :(

The NC5FAH look affordable (of course still more expensive than the XLR3s). Sadly the footprint doesn't exist in KiCad and I need to create it before checking if it can also be mounted on the PCB with the two existing footprints for the XLR3s ....

Update: ioboard_4ports_cheap and ioboard_2ports_rdm are both done and on github. I've also started to create a github action to automatically generate the schematic PDF and PCB production files on each commit.

Nice. If you generate images too, you can do magic things like this:
https://docs.github.com/en/github/managing-files-in-a-repository/rendering-and-diffing-images

Indeed, that looks great. I'll check if the 3D-views of KiCad can also be automated using Github actions.

I've also sent the baseboard_4slots and ioboard_4ports_cheap for production and assume to receive them in about 1 or 2 weeks :D The boards come with all SMD parts soldered and I do have the remaining THT-parts at home waiting for the boards to arrive.

Exciting!

Boards are already in Germany but might need about a week more for customs and shipping to me.

@peternewman : Any opinion about that proposal? A bit what you expected it to be? Not at all?

It's quite wide! But I guess that's to be expected with so many ports!

Have you considered, depending on usage, some people might want all the connections on the front (e.g. laptop on top of a rack), although I guess most want it on the rear.

Indeed, 16 XLR ports are wide, no matter what :)
Sure, we could also make a variant with 8 ports on the front and 8 on the back. That's the big advantage of using pin headers between the base board and the IO bords: Theoretically one could put a ribbon cable between them so their location is not fixed to each other.

And when there are bsaeboards with 2 or one slot(s) for IO boards, I'd say that a 3D-printed case might also be worth investigating.

[peternewman]

True :) I'm still looking for a good way to work with kicad and git. Kicad changes lots of lines in the files for only trivial changes.

I think the image thing would go a long way towards that. There also seem to be a few cool kicad related actions too.

Actually this could be the winner:
https://jnavila.github.io/plotkicadsch/
https://jnavila.github.io/plotkicadsch/plotgitsch_usersguide.html

Maybe I'm being optimistic though, it just seems like we're getting into lots of fiddly threaded discussion about one thing. Perhaps just another separate discussion for the hardware design as this isn't really entirely about (goes and checks, "A model with fewer ports (2 RDM capable)?")

And I still haven't found a way to use relative paths for symbol- and footprint-libraries shipped with the projects :-/ ...
It looks like relative isn't too hard, e.g. https://forum.kicad.info/t/how-to-make-kicad-schematic-libraries-load-with-a-relative-path/2639/9

Thanks :)
Good question. They are meant to be "read-only" and written once "on production". However, I think it would be okay for now to set their initial value via the web browser interface (still planning to have an emulated network interface + web server ;)).

Yeah that sounds like a nice simple solution for now for people building there own.

Any reason for not using handbags, or DIL/piano switches? Presumably cost and what needs soldering onboard? Perhaps add pads for the other options so someone could remove the factory resistors and make them dynamic?

Yes: cost :) The PCB fab I currently use to produce the prototypes (JLCPCB) has some parts in their SMD-feeder all the time (they call them "Basic parts"). DIL switches or SMD-mounted pin headers are unfortunately not part of the basic parts and they charge extra if the need to load parts into their machines.

What about letting the user add through-hole ones? Or at least putting in the pads so someone could do so, even if it just comes with the SMD stuff installed for now. It looks like there should be some space, or would clearance mean you'd need to make the board bigger (would that change the price much)?

The pads for the other options (= DMX RX) are on the boards but not populated. So if one wants to change a TX-port to a RX-port, two resistors need to be unsoldered and re-soldered on a different position:

I assume they are zero ohm again? In which case having a three pin header (or a pair of them) would let you bridge to TX or RX from a common. What's the second "switch" per port doing?

Just a warning, NC3FAAH isn't unified D, so won't fit your pre-made panel idea as most (all?) of the panels are unified D so they take the whole range of connectors. Check the drawings to see the mounting hole differences.
I didn't look, but I'm guessing they have the same pad footprint?

Unfortunately not at all :(

Oh, wow, how confusing!

I know that NC3FAAH isn't D-norm but they are a lot cheaper (~8€ vs. ~0.8€ per connector). That's why the place on the PCB looks so strange.

Yeah, I was mostly meaning they won't fit in your pre-cut panel, which is unified D (I think).

Thanks, I've known that the official standards don't allow XLR3. However, I didn't know that they state it so clearly ;) Until we know that it all works as expected, I'll stick with the XLR3 since the 5-pin Neutriks are really expensive. But I promise to also do 5-pin layouts.

Heh, fair enough!

That means you solder the inner part of the connector to your PCB and mount the housing to the front panel. Then, you mate & lock them. Unfortunately, there is no 5-pin variant that does the same.

Yeah I've dismantled kit that had them before. I didn't realise they were 3 pin only.

And I wouldn't know how one would solder the connectors to the PCB if they need to be mounted to the front plate first :(

I think looking at NC5FDM3-H you just feed them in from behind (indeed the webpage confirms, although not the panel depth) https://www.neutrik.co.uk/product/nc5fdm3-h

Indeed, that looks great. I'll check if the 3D-views of KiCad can also be automated using Github actions.

See some of my links from earlier up too.

It's quite wide! But I guess that's to be expected with so many ports!
Have you considered, depending on usage, some people might want all the connections on the front (e.g. laptop on top of a rack), although I guess most want it on the rear.

Indeed, 16 XLR ports are wide, no matter what :)

I guess they could also be stacked with some ribbon cable.

Sure, we could also make a variant with 8 ports on the front and 8 on the back.

Sorry, I didn't really comment very clearly, I was more thinking if people may want the USB input AND the XLRs on the same side, so you could bolt it into a rack and put your laptop on the top and cable everything into the front (at the loss of an XLR, or some magic way to make more space).

And when there are bsaeboards with 2 or one slot(s) for IO boards, I'd say that a 3D-printed case might also be worth investigating.

Yeah sounds fairly doable, or (laser) cut plastic/wood, as someone made for the Number 1.

[kripton]

True :) I'm still looking for a good way to work with kicad and git. Kicad changes lots of lines in the files for only trivial changes.

I think the image thing would go a long way towards that. There also seem to be a few cool kicad related actions too.

Actually this could be the winner:
https://jnavila.github.io/plotkicadsch/
https://jnavila.github.io/plotkicadsch/plotgitsch_usersguide.html

Indeed, this one looks very sophisticated. Nice find!

Maybe I'm being optimistic though, it just seems like we're getting into lots of fiddly threaded discussion about one thing. Perhaps just another separate discussion for the hardware design as this isn't really entirely about (goes and checks, "A model with fewer ports (2 RDM capable)?")

I agree, the discussions things looked very good and easy at the beginning but I also need to recap and search where new posts are and where our threads are going. I'm happy to have hardware-related stuff in new discussion threads or some other way. Feel free to open new ones.

What about letting the user add through-hole ones? Or at least putting in the pads so someone could do so, even if it just comes with the SMD stuff installed for now. It looks like there should be some space, or would clearance mean you'd need to make the board bigger (would that change the price much)?

No, you're right, I should add pads (and holes ;) for THT-Resistors. Space should be fine, we can also make them "vertically mounted" instead of "horizontal". That makes the pads closer. But I'll need to investigate.

I assume they are zero ohm again? In which case having a three pin header (or a pair of them) would let you bridge to TX or RX from a common. What's the second "switch" per port doing?

Yes, all "bridges" are 0Ohm. The reason why that board has two per port is: The +5V rail is fed by the USB port, so it has around 500mA (or more if using a wall charger and the second USB port on the baseboard). The +3V3 rail is fed by the Pico's linear voltage regulator and has limited output current. On the "isolated" variant of the IO boards, the ADM2483 chip has two supply inputs: one for the logic (+3V3 but low current) and one for the bus side (+5V but higher current). On the "non-isolated" variant, the RS-485 driver only has one supply input. When we want to SEND, we use the +5V as supply. This way, we don't need an additional voltage regulator (the RDM-capable non-isolated board has one). When we RECEIVE, we cannot use the +5V as supply since that would make the RS-485 driver output +5V on the DI-pin to the Pico board, which is not 5V-tolerant. But since only RECEIVING doesn't take much current, using +3V3 is fine in that case.
So the first resistor is to select the direction (Driver enabled and receiver disabled or the other way round) and the second resistor selects the supply rail used.
And there is the one point when using +5V supply and +3V3 on the inputs: It might happen that a logic 1 is not detected properly since the threshold is higher due to the higher Vcc. But I actually never had problems with that.

Yeah, I was mostly meaning they won't fit in your pre-cut panel, which is unified D (I think).

I need to try. I got the soldered boards here and the D pre-cut panel. Of course one cannot mount two screws per port (as it should be) but only one. But since it's 4 XLR connectors next to each other that should be enough.

I think looking at NC5FDM3-H you just feed them in from behind (indeed the webpage confirms, although not the panel depth) https://www.neutrik.co.uk/product/nc5fdm3-h

Sorry, I didn't really comment very clearly, I was more thinking if people may want the USB input AND the XLRs on the same side, so you could bolt it into a rack and put your laptop on the top and cable everything into the front (at the loss of an XLR, or some magic way to make more space).

Regarding all the 5-pins and port location questions: I'm thinking about also designing IO-boards that have RJ45 instead of XLR. Because there are those very nice breakout boards: https://images.static-thomann.de/pics//atg/atgdata/document/misc/stairville_rjj45_split_overview.pdf and they even exist in 3-pin and 5-pin versions. So one can use the same IO-Board and depending on preference wire up a 3-pin-XLR breakout box (or cable snake or rack unit) or a 5-pin one. It's more expensive in total than the 3-pin "AA" sockets but still cheaper than using 5-pin-XLR directly on the IO boards

[kripton]

Finally, the question arises if the ports' modes should be fixed (given by the hardware attached to the board) or software-switchable using the existing SET MODE command?

[peternewman]

If you can do RDM, then the direction has to be switched, in which case if DMX receive code is written, being able to switch a port between input and output seems a no brainer.

[kripton]

Yes, in order to to RDM, the dongle needs to be able to configure the direction on-the-fly.

What I meant by this question was rather if it makes sense to have one model with 8 OUTs and 0 INs, another one with 6 OUTs and 2 INs, another one with 4 OUTs and 4 INS OR to have ONE mode with 8 ports, whose role can be toggled via software. But as I read your answer again, I'm seeing that you would go for the second option. Didn't understood that when reading it the first time ;)

[peternewman]

Yeah, essentially as soon as you have RDM controller support (or even just can afford a second pin per port), you have the ability to do dynamic changes of direction, either completely in software, or worst case by uploading alternative firmware. At which point I don't really see the benefit in locking it down.

From a practical point of view, your demand might change last minute/on the fly, so why restrict things? You could even just use it as a splitter.

[kripton]

Yep, I already thought about the splitter thing. One point to note, though: In most cases when you assign mutliple GPIO pins to the rp2040's PIO state machines, they need to be contiguous. That means if you switch the first 5 ports to OUT only, then have two RDM-capable ports (each probably needing on PIO state machine of its own) and then again 9 ports OUT again, you cannot use the same state machine as for the first 5 ports.

[peternewman]

That seems a strong case for your modules though. So you'd just arrange those ports so you've got your two RDM-capable ports first, then your 5+9 basic outputs. Or can you not mask output pins either and hence they'd need to go first too?

[peternewman]

If you can drive WS2812 pixels, why not offer, as the Number 1 did, DMX to SPI entirely in hardware? Or at least consider it as a future enhancement/plan for the option.

[kripton]

So having WS2812-LEDs on the board (not via SPI though) was more meant as a static (in the sense of LED count) status display. So if there are 8 LEDs (which is common, see for example: https://www.adafruit.com/product/1426 or https://www.amazon.de/NeoPixel-Stick-WS2812-5050-Integrated/dp/B00KLBTT1E, one could use the GREEN component as the status for universes 1-8, the BLUE components as status for universe 9-16 and the red components for other stuff (HOST PC connected and sending data, RDM status LEDs, ...)

It's not actually meant to be user-controllable but for sure it could be just that in the future.

I'd love to see if multiple WS2812-strings could be drive by just ONE of the PIO State-Machines. The current example (https://github.com/raspberrypi/pico-examples/blob/master/pio/ws2812/ws2812.pio#L21) uses conditional jumps which would hint that there needs to be one state-machine per string.

However, there seems to be a second example in the same file that I just got aware of now: https://github.com/raspberrypi/pico-examples/blob/master/pio/ws2812/ws2812.pio#L57
This basically does what the current DMX-generating code does: Have the memory prepared by the CPU (https://github.com/raspberrypi/pico-examples/blob/master/pio/ws2812/ws2812_parallel.c#L25), then use the DMA to push the data to a PIO SM that just clocks out the memory content to the GPIO PINs.
Using this, yes, the dongle could be extended to support DMX-to-WS2812 LEDs. Cool idea!

[peternewman]

Ah yeah, I guess not needing a clock there's no real benefit of using the SPI port over a PIO.

Yeah that makes sense having some on-board indicators for debugging and troubleshooting.

Using this, yes, the dongle could be extended to support DMX-to-WS2812 LEDs. Cool idea!

I'm just shamelessly recycling suggestions from what the existing code already supports! 😄

[kripton]

Even though the RP2040 can do SPI in hardware, I'd rather reserve that for further extensions (such as the wireless DMX idea) and drive the WS2812-LEDs using the PIO. And I haven't yet investigated if multiple WS2812-strings can be driven off a single PIO state machine. Still interested to try this, though

[peternewman]

Seems like it ought to be possible if you can do DMX that way, although I guess bandwidth/frequency may be a challenge.

[peternewman]

Actually from #1 (reply in thread)

You could even just use it as a splitter.

Another off the bat idea, you could use the device as a standalone DMX and/or RDM splitter with some potentially fairly basic code in the middle.

There's also a whole range of other utility boxes you could make when you have DMX in and out code working, similar to the filters we've talked about for OLA in the past (e.g. output the top and bottom half of a universe to separate outputs, top/bottom set values, add padding channels or virtual dimmers etc). Just using the USB for power and/or config (although that could also be done via RDM).

[kripton]

Indeed, using such a high-port-count device as a DMX splitter makes sense, especially if it is equipped with galvanic isolated bus drivers.
The Nodle U1 interface and clones can be configured to do active repeating from one port to the other and such.