Replies: 2 comments 1 reply
-
As you pointed out, it would no longer be DMX. Do you have a link to a protocol specification document? I don't mind taking a look at a specification. |
Beta Was this translation helpful? Give feedback.
0 replies
-
@s4CD Do you have a link to a DMX512PF IC datasheet? |
Beta Was this translation helpful? Give feedback.
1 reply
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I know. DMX is a standard and has a standard baud rate and that standard is 250000. But hear me out.. are you familiar with DMX512PF IC? It is a pixel protocol that is structured essentially the same as DMX512 except at a baud rate of 650000, allowing for more channels per universe. It also accepts standard DMX512, but that limits you to 170 pixels (510 channels) per run.
I have tested that your library works perfectly with it after changing the declared baud rate in TeensyDMX.cpp line 12 to be 650000.
For testing I added a function (setSpeed) to the Receiver class and the Sender class that allowed switching between the speeds by calling dmxRx.end(), then dmxRx.setSpeed() (feeding a 0 or 1 depending what is desired) and then dmxRx.begin() (or dmxTx if sending) and it works fine to switch on the fly. To do this I had to make kSlotsBaud, kBitTime, and kCharTime NOT declared as constants and then in Receiver/Sender the function sets kSlotsBaud and recalculated the other two. This seems pretty janky but it does seem to work.
I have done pretty extensive tests sending data to a light string by hardcoding the declared baud rate to 650000. I have NOT done a ton of testing changing the speed on the fly, and I'm sure that how I did it is not the proper way to handle it.
I would love to hear what you think and see if you have any interest in adding this as a feature. I'm not sure where in the world you are, but a I could test as needed or potentially send a string or two of the 512pf lights.
Beta Was this translation helpful? Give feedback.
All reactions