Replies: 6 comments 31 replies
-
|
A 16-universe, output-only model
|
Beta Was this translation helpful? Give feedback.
-
|
Is the USB bandwidth sufficient for this, or does it depend on the protocol? |
Beta Was this translation helpful? Give feedback.
-
|
There's a quick calculation I did before starting this all:
The RP2040 is a 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. |
Beta Was this translation helpful? Give feedback.
-
|
👍 (the reaction dialogue is hidden for some reason). |
Beta Was this translation helpful? Give feedback.
-
|
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)
|
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
Good thought. I think with RDM responder I meant mainly |
Beta Was this translation helpful? Give feedback.
-
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. |
Beta Was this translation helpful? Give feedback.
-
|
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:
|
Beta Was this translation helpful? Give feedback.
-
|
Yeah sorry, I meant the RDM supporting output ports could do DMX in too, using a PIO each.
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. |
Beta Was this translation helpful? Give feedback.
-
|
A model with fewer ports (2 RDM capable)?
|
Beta Was this translation helpful? Give feedback.
-
|
A PR might be easier to comment on. 😄
Looks like a great start.
Pico at 90 degrees with a separate cable would allow a shallower box, but might not be worth the hassle.
Neat touch, how do they get programmed?
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?
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?
From the standard:
And:
I.e. five pins should be the default, with maybe a disco option of three pin as a rarity.
As above, it should if you buy the expensive sockets. |
Beta Was this translation helpful? Give feedback.
-
Nice. If you generate images too, you can do magic things like this:
Exciting!
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. |
Beta Was this translation helpful? Give feedback.
-
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 :-/ ...
Thanks :)
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.
Unfortunately not at all :(
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 ....
Indeed, that looks great. I'll check if the 3D-views of KiCad can also be automated using Github actions.
Boards are already in Germany but might need about a week more for customs and shipping to me.
Indeed, 16 XLR ports are wide, no matter what :) 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. |
Beta Was this translation helpful? Give feedback.
-
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: 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)?")
Yeah that sounds like a nice simple solution for now for people building there own.
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)?
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?
Oh, wow, how confusing!
Yeah, I was mostly meaning they won't fit in your pre-cut panel, which is unified D (I think).
Heh, fair enough!
Yeah I've dismantled kit that had them before. I didn't realise they were 3 pin only.
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
See some of my links from earlier up too.
I guess they could also be stacked with some ribbon cable.
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).
Yeah sounds fairly doable, or (laser) cut plastic/wood, as someone made for the Number 1. |
Beta Was this translation helpful? Give feedback.
-
Indeed, this one looks very sophisticated. Nice find!
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.
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.
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.
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.
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 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 ;) |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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? |
Beta Was this translation helpful? Give feedback.
-
|
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. |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
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.
I'm just shamelessly recycling suggestions from what the existing code already supports! 😄 |
Beta Was this translation helpful? Give feedback.
-
|
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 |
Beta Was this translation helpful? Give feedback.
-
|
Seems like it ought to be possible if you can do DMX that way, although I guess bandwidth/frequency may be a challenge. |
Beta Was this translation helpful? Give feedback.
-
|
Actually from #1 (reply in thread)
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). |
Beta Was this translation helpful? Give feedback.
-
|
Indeed, using such a high-port-count device as a DMX splitter makes sense, especially if it is equipped with galvanic isolated bus drivers. |
Beta Was this translation helpful? Give feedback.
-
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)
Beta Was this translation helpful? Give feedback.
All reactions