Readme update #34
Readme update #34
Conversation
|
Oh and as you see, I've decided on a new name since "rp2040-donlge" was a bit thin and didn't explain what the dongle does. rp2040-dmxsun might also not explain the purpose but it is at least distinguishable and memorable. The icon already supports this: https://github.com/OpenLightingProject/rp2040-dongle/blob/main/gfx/favicon.png. But of course, I'm open for proposals here as well. |
It's also easily backronymable, DMX Sixteen UNiverses 😆 ! |
README.md
Outdated
|
|
||
| Our next steps are to implement the same protocol as the [ja-rule](https://github.com/OpenLightingProject/ja-rule) device so a more advanced and extensible protocol is in use. | ||
| DMX-512-A works in groups called universes and each universe can contain up to 512 channels. dmxsun can transmit up to 16 universes, meaning you can control 8192 channels of DMX data at the same time. |
There was a problem hiding this comment.
Pedant, I think the official naming is slots rather than channels, but the latter is probably better known by most people.
There was a problem hiding this comment.
Please be pedantic :) If we do have a standard that uses some specific wording, we should stick to that here as well. In the source code, I might have used "frame" (for a complete DMX packet) and that's not actually in the standard as well.
|
|
||
| Currently, a universe can be `teared`. That means that the first half (or so) is already updated, while for the second half, old values are still be sent. This means if you have one fixture on channel 0 and another on channel 512 os the same universe and switch them ON or OFF at the same time, they might actually switch at different times. So another TODO is to add another layer of buffering. It's basically the same problem as with the V-Sync and screen tearing in videos or computer games. | ||
| Dmxsun is usually connected to its host via a single USB connection that also powers the device. | ||
| To the computer, the dmxsun device looks like a network card (it uses the CDC NCM interface) and the integrated DHCP-server assigns an IP-address to the host machine so they can talk to each other. |
There was a problem hiding this comment.
Is there actually a DHCP server? Isn't it just using zeroconf, which is more of a standard than a server?
There was a problem hiding this comment.
It indeed is a real DHCP server running on the device and proposing one IP address if asked for one (which is the standard behaviour of most OSes when they detect previously un-known network devices).
The lwIP stack that is used also supports "AutoIP" as a form of zeroconf. I had a quick look but found DHCP to be more "reliable". Some OSes might treat network connections as non-functional if their DHCP-requests stay unanswered.
However, I agree that some form of unsolicited service announcement (or mDNS) might help. And I should re-try the AutoIP to check if it works everywhere and makes things easier in the end.
|
|
||
| ## Connecting to real devices | ||
| To find out dmxsun's IP address, have a look at your kernel log on Linux (run `dmesg`) or hover over the `Disconnect USB device` icon in Window's task bar or check the network device properties on macOS. |
There was a problem hiding this comment.
You should add Avahi/Bonjour support to avoid needing to do this!
There was a problem hiding this comment.
True, mDNS seems to be the way of choice here.
However, the host name the device announces to the host should have some "random ID" in it so there is no problem when more than one device is connected.
There was a problem hiding this comment.
Well, the "MAC address" is also a pretty fake one: https://github.com/OpenLightingProject/rp2040-dongle/blob/f5f1d511b9f2d2f3d519904ce44945ea090ec4ae/src/tusb_lwip_glue.c#L42
But here again, I'd stick to the same approach as we currently do: Use one byte of the "unique board ID"
There was a problem hiding this comment.
Ah I didn't realise, yeah that should use part of the unique ID. I'd assumed something like that was already built into the library!
Reword channel -> slot to match the E1.11 standard
Thanks @peternewman for the review! Co-authored-by: Peter Newman <[email protected]>
Convert some URLs to proper links
Nice one, didn't even think of it! Want it in the Readme? ;) |
I've finally managed to bring the Readme to a state that the current state of the code and hardware design files deserves :)
Since English is not my native language, I'd be happy about a review. Codespell is happy but I prefer humans to give their opinions.