RDM support into Native UART DMX plugin

201 views
Skip to first unread message

Ankur Patel

unread,
Apr 9, 2019, 5:38:59 AM4/9/19
to open-lighting
Hello OLA Friends,

I am using ola version 0.10.6 on AM437x based TI evm using uart dmx plugin. System runs Linux with kernel 4.14. 

DMX is working fine on it. I would like to know is it feasible to implement RDM side into it? Can someone share any pointers on best reference plugin to look?

Thank you for reading the post.

Regards,
Ankur

Arjan van Vught

unread,
Apr 9, 2019, 7:10:26 AM4/9/19
to open-l...@googlegroups.com, bka...@gmail.com
Hi Ankur,

RDM is not possible with the native UART; RDM is not possible in Linux.

For RDM you would need to go for an Enttec Pro device. Or an Art-Net device. Both can be implemented with open source and not expensive hardware.

- Arjan
--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en

Ankur Patel

unread,
Apr 9, 2019, 8:46:39 AM4/9/19
to Arjan van Vught, open-l...@googlegroups.com
Thank you for your reply Arjan.

Might be a silly question but can you please share why it's not possible to have RDM in linux using native uart. Is it that linux cannot handle the timing requirements of RDM?

Regards, 
Ankur

Arjan van Vught

unread,
Apr 9, 2019, 8:59:00 AM4/9/19
to Ankur Patel, open-l...@googlegroups.com
Hi Ankur,


Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bka...@gmail.com> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

Peter Newman

unread,
Apr 9, 2019, 12:00:15 PM4/9/19
to open-lighting
Sorry Arjun, that's simply not true!

Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.

On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Arjan van Vught

unread,
Apr 9, 2019, 12:10:43 PM4/9/19
to open-l...@googlegroups.com, Ankur Patel
Hi Peter,

Op 9 apr. 2019, om 18:00 heeft Peter Newman <peterj...@gmail.com> het volgende geschreven:

Sorry Arjun, that's simply not true!
For native UART it is true. There are no working Linux drivers. The issue is timing. I have not seen otherwise.


Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:
There is a note : "The support is not 100% according to the standard .. “. That is telling me that it is not working in Linux. Unless we accept that we do not apply to the standards.


It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.
I can help you with a good  (inexpensive) RDM Responder -> open source and it successfully do the OLA RDM test.

- Arjan

On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

Peter Newman

unread,
Apr 9, 2019, 1:20:56 PM4/9/19
to open-lighting


On Tuesday, 9 April 2019 17:10:43 UTC+1, Arjan van Vught wrote:
Hi Peter,


Op 9 apr. 2019, om 18:00 heeft Peter Newman <peterjnewman> het volgende geschreven:

Sorry Arjun, that's simply not true!
For native UART it is true. There are no working Linux drivers. The issue is timing. I have not seen otherwise.
Can you be more specific? I think detecting the break is likely to be the only potentially challenging part (I don't know if the Linux driver handles this), the rest is just reading and writing bytes and passing them up the OLA stack. Why do you think the onboard UART shouldn't be able to do it when a USB connected FTDI can?

Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:
There is a note : "The support is not 100% according to the standard .. “. That is telling me that it is not working in Linux. Unless we accept that we do not apply to the standards.

It just means he's not implemented it yet. At least he's honest enough to admit it, compared to some commercial controllers which seemingly don't even check the CRC:

Or the hundreds of DMX fixtures which don't check the start code and therefore break with RDM.

Indeed looking at the code, I think that comment is out of date for the current codebase:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.
I can help you with a good  (inexpensive) RDM Responder -> open source and it successfully do the OLA RDM test.
Doing the OLA RDM tests doesn't imply compliance with the standard ( https://www.openlighting.org/rdm-tools/rdm-responder-tests/faq/#Is_this_a_E120_Compliance_Test ). The linked PR above allows a successful test run against a fixture (or to be more accurate correctly detected some failures in a buggy fixture).

From a quick look at your code I can't immediately see back-offs for slow responders.

- Arjan

On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

Arjan van Vught

unread,
Apr 9, 2019, 1:37:43 PM4/9/19
to open-l...@googlegroups.com
Hi Peter,

Op 9 apr. 2019, om 19:20 heeft Peter Newman <peterj...@gmail.com> het volgende geschreven:



On Tuesday, 9 April 2019 17:10:43 UTC+1, Arjan van Vught wrote:
Hi Peter,

Op 9 apr. 2019, om 18:00 heeft Peter Newman <peterjnewman> het volgende geschreven:

Sorry Arjun, that's simply not true!
For native UART it is true. There are no working Linux drivers. The issue is timing. I have not seen otherwise.
Can you be more specific? I think detecting the break is likely to be the only potentially challenging part (I don't know if the Linux driver handles this), the rest is just reading and writing bytes and passing them up the OLA stack. Why do you think the onboard UART shouldn't be able to do it when a USB connected FTDI can?
I’ve been told by Linux developers that it is almost, or mostly impossible to have RDM support in the Linux. Basically due to timing issues.


Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:
There is a note : "The support is not 100% according to the standard .. “. That is telling me that it is not working in Linux. Unless we accept that we do not apply to the standards.

It just means he's not implemented it yet. At least he's honest enough to admit it, compared to some commercial controllers which seemingly don't even check the CRC:

Or the hundreds of DMX fixtures which don't check the start code and therefore break with RDM.

Indeed looking at the code, I think that comment is out of date for the current codebase:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.
I can help you with a good  (inexpensive) RDM Responder -> open source and it successfully do the OLA RDM test.
Doing the OLA RDM tests doesn't imply compliance with the standard ( https://www.openlighting.org/rdm-tools/rdm-responder-tests/faq/#Is_this_a_E120_Compliance_Test ). The linked PR above allows a successful test run against a fixture (or to be more accurate correctly detected some failures in a buggy fixture).
I also reference to https://lightning-dmxcontrol.com/faq#4 This is DMX, but I am convinced that it will also apply for RDM as well.


From a quick look at your code I can't immediately see back-offs for slow responders.
Not sure if I understand this remark. Your advice is a having good RDM Responder when developing and debugging the possible native UART RDM plug-in. My responders are implemented according to the E1.20 timing standard.  Hence I am suggesting to use such inexpensive RDM Responder (which will also pass the RDM Responder test).

- Arjan 


- Arjan

On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en


--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com

Ankur Patel

unread,
Apr 9, 2019, 9:09:43 PM4/9/19
to open-l...@googlegroups.com
On Wed, Apr 10, 2019 at 2:00 AM Peter Newman <peterj...@gmail.com> wrote:
Sorry Arjun, that's simply not true!

Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

Thank you Peter. I appreciate your advise. 
What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.

True, I managed to have logic analyser, enttec sniffer and RDM Responder.  Looks of it I have all tools and pointer to start with. Will keep you posted.

Again Thank you Peter and Ola team.

Regards,
Ankur
On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

--

Peter Newman

unread,
Apr 11, 2019, 5:51:26 PM4/11/19
to open-lighting


On Tuesday, 9 April 2019 18:37:43 UTC+1, Arjan van Vught wrote:
Hi Peter,


Op 9 apr. 2019, om 19:20 heeft Peter Newman <peterjnewman> het volgende geschreven:



On Tuesday, 9 April 2019 17:10:43 UTC+1, Arjan van Vught wrote:
Hi Peter,

Op 9 apr. 2019, om 18:00 heeft Peter Newman <peterjnewman> het volgende geschreven:

Sorry Arjun, that's simply not true!
For native UART it is true. There are no working Linux drivers. The issue is timing. I have not seen otherwise.
Can you be more specific? I think detecting the break is likely to be the only potentially challenging part (I don't know if the Linux driver handles this), the rest is just reading and writing bytes and passing them up the OLA stack. Why do you think the onboard UART shouldn't be able to do it when a USB connected FTDI can?
I’ve been told by Linux developers that it is almost, or mostly impossible to have RDM support in the Linux. Basically due to timing issues.
Well Keeper of the Keys appears to be doing a very good job of proving that wrong.

Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:
There is a note : "The support is not 100% according to the standard .. “. That is telling me that it is not working in Linux. Unless we accept that we do not apply to the standards.

It just means he's not implemented it yet. At least he's honest enough to admit it, compared to some commercial controllers which seemingly don't even check the CRC:

Or the hundreds of DMX fixtures which don't check the start code and therefore break with RDM.

Indeed looking at the code, I think that comment is out of date for the current codebase:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.
I can help you with a good  (inexpensive) RDM Responder -> open source and it successfully do the OLA RDM test.
Doing the OLA RDM tests doesn't imply compliance with the standard ( https://www.openlighting.org/rdm-tools/rdm-responder-tests/faq/#Is_this_a_E120_Compliance_Test ). The linked PR above allows a successful test run against a fixture (or to be more accurate correctly detected some failures in a buggy fixture).
I also reference to https://lightning-dmxcontrol.com/faq#4 This is DMX, but I am convinced that it will also apply for RDM as well.
Indeed, OLA has a similar comment in it's FAQ:

The linked comment says:
"The open usb dmx just puts through the data it receives via usb. As your computer is doing multiple things at once, it can slightly delay the bytes that are sent through the usb port. If this is halfway an array of dmx channels, it can cause the dmx-packet to be corrupted, which results in a wrongly interpreted dmx-array by the receiving devices. This appears as flickering."

I'm not sure this is technically true, I think a well written responder/DMX fixture ought to see the partial frame, and then timeout on the gap caused by the PCs delay and discard the rest of the packet. I don't think it should interpret it as a break and therefore offset frame data, although I imagine most people using an Open USB DMX are probably controlling fixtures at the cheaper end of the market.

From a quick look at your code I can't immediately see back-offs for slow responders.
Not sure if I understand this remark. Your advice is a having good RDM Responder when developing and debugging the possible native UART RDM plug-in. My responders are implemented according to the E1.20 timing standard.  Hence I am suggesting to use such inexpensive RDM Responder (which will also pass the RDM Responder test).
 Apologies, I assumed you were talking about your controller code and had been looking at that, rather than your responder code as a responder to test against.

My point still stands though, there are also Arduino ( https://github.com/mathertel/DmxSerial2 ) and Teensy ( https://github.com/chrisstaite/TeensyDmx/ ) based responder code too which I've worked on and tested against the OLA RDM responder tests. I still wouldn't recommend using them to develop and test code unless you've also got access to a different RDM controller to test your implementation first. It's all to easy to get a pin misconnected or similar and unless you've tested it you may be none the wiser.

Peter Newman

unread,
Apr 11, 2019, 6:00:42 PM4/11/19
to open-lighting


On Wednesday, 10 April 2019 02:09:43 UTC+1, Ankur Patel wrote:


On Wed, Apr 10, 2019 at 2:00 AM Peter Newman <peterjnewman> wrote:
Sorry Arjun, that's simply not true!

Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

Thank you Peter. I appreciate your advise. 
What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.

True, I managed to have logic analyser, enttec sniffer and RDM Responder.  Looks of it I have all tools and pointer to start with. Will keep you posted.
Excellent, that sounds very promising. Let us know if we can do anything to help? Is that one of the old red Enttec Sniffers or a new one? The old one can be used with our sniffer software:

The new ones will need some work to support it, but perhaps that's another challenge if you're feeling keen?

Again Thank you Peter and Ola team.

Regards,
Ankur
On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

Arjan van Vught

unread,
Apr 12, 2019, 5:16:14 AM4/12/19
to open-l...@googlegroups.com


Op 11 apr. 2019 om 23:51 heeft Peter Newman <peterj...@gmail.com> het volgende geschreven:



On Tuesday, 9 April 2019 18:37:43 UTC+1, Arjan van Vught wrote:
Hi Peter,

Op 9 apr. 2019, om 19:20 heeft Peter Newman <peterjnewman> het volgende geschreven:



On Tuesday, 9 April 2019 17:10:43 UTC+1, Arjan van Vught wrote:
Hi Peter,

Op 9 apr. 2019, om 18:00 heeft Peter Newman <peterjnewman> het volgende geschreven:

Sorry Arjun, that's simply not true!
For native UART it is true. There are no working Linux drivers. The issue is timing. I have not seen otherwise.
Can you be more specific? I think detecting the break is likely to be the only potentially challenging part (I don't know if the Linux driver handles this), the rest is just reading and writing bytes and passing them up the OLA stack. Why do you think the onboard UART shouldn't be able to do it when a USB connected FTDI can?
I’ve been told by Linux developers that it is almost, or mostly impossible to have RDM support in the Linux. Basically due to timing issues.
Well Keeper of the Keys appears to be doing a very good job of proving that wrong.

Keeper of the Keys are using FTDI and not the native UART.


Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:
There is a note : "The support is not 100% according to the standard .. “. That is telling me that it is not working in Linux. Unless we accept that we do not apply to the standards.

It just means he's not implemented it yet. At least he's honest enough to admit it, compared to some commercial controllers which seemingly don't even check the CRC:

Or the hundreds of DMX fixtures which don't check the start code and therefore break with RDM.

Indeed looking at the code, I think that comment is out of date for the current codebase:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.
I can help you with a good  (inexpensive) RDM Responder -> open source and it successfully do the OLA RDM test.
Doing the OLA RDM tests doesn't imply compliance with the standard ( https://www.openlighting.org/rdm-tools/rdm-responder-tests/faq/#Is_this_a_E120_Compliance_Test ). The linked PR above allows a successful test run against a fixture (or to be more accurate correctly detected some failures in a buggy fixture).
I also reference to https://lightning-dmxcontrol.com/faq#4 This is DMX, but I am convinced that it will also apply for RDM as well.
Indeed, OLA has a similar comment in it's FAQ:

The linked comment says:
"The open usb dmx just puts through the data it receives via usb. As your computer is doing multiple things at once, it can slightly delay the bytes that are sent through the usb port. If this is halfway an array of dmx channels, it can cause the dmx-packet to be corrupted, which results in a wrongly interpreted dmx-array by the receiving devices. This appears as flickering."

I'm not sure this is technically true, I think a well written responder/DMX fixture ought to see the partial frame, and then timeout on the gap caused by the PCs delay and discard the rest of the packet. I don't think it should interpret it as a break and therefore offset frame data, although I imagine most people using an Open USB DMX are probably controlling fixtures at the cheaper end of the market.

And the Open USB DMX are not opto-isolated as well. It really depends on the requirements you have set when using such a solution.

Instead of using USB, why not using Art-Net 4 moving forward ?

Maybe I should start a new thread for; What is the acceptance for Art-Net 4? It can do RDM and then the more network friendly sACN E1.31 DMX.

- Arjan


From a quick look at your code I can't immediately see back-offs for slow responders.
Not sure if I understand this remark. Your advice is a having good RDM Responder when developing and debugging the possible native UART RDM plug-in. My responders are implemented according to the E1.20 timing standard.  Hence I am suggesting to use such inexpensive RDM Responder (which will also pass the RDM Responder test).
 Apologies, I assumed you were talking about your controller code and had been looking at that, rather than your responder code as a responder to test against.

My point still stands though, there are also Arduino ( https://github.com/mathertel/DmxSerial2 ) and Teensy ( https://github.com/chrisstaite/TeensyDmx/ ) based responder code too which I've worked on and tested against the OLA RDM responder tests. I still wouldn't recommend using them to develop and test code unless you've also got access to a different RDM controller to test your implementation first. It's all to easy to get a pin misconnected or similar and unless you've tested it you may be none the wiser.

- Arjan 


- Arjan

On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en


--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com

Arjan van Vught

unread,
Apr 12, 2019, 5:46:42 AM4/12/19
to open-l...@googlegroups.com

Op 11 apr. 2019, om 23:51 heeft Peter Newman <peterj...@gmail.com> het volgende geschreven:



From a quick look at your code I can't immediately see back-offs for slow responders.
Not sure if I understand this remark. Your advice is a having good RDM Responder when developing and debugging the possible native UART RDM plug-in. My responders are implemented according to the E1.20 timing standard.  Hence I am suggesting to use such inexpensive RDM Responder (which will also pass the RDM Responder test).
 Apologies, I assumed you were talking about your controller code and had been looking at that, rather than your responder code as a responder to test against.

My point still stands though, there are also Arduino ( https://github.com/mathertel/DmxSerial2 ) and Teensy ( https://github.com/chrisstaite/TeensyDmx/ ) based responder code too which I've worked on and tested against the OLA RDM responder tests. I still wouldn't recommend using them to develop and test code unless you've also got access to a different RDM controller to test your implementation first. It's all to easy to get a pin misconnected or similar and unless you've tested it you may be none the wiser.

I am not sure if I do understand the pin misconnected remark; What has pin’s to do with software? Basically you can do a very initial simple test with a ’null-modem’ cable between the RDM Controller and the RDM Responder. Of course with the assumption that they both running at the same voltage (3V3 vs 5V). In such a controlled development environment, there is also no need to have opto-isolation. 

In all fairness, the DmxSererial2 code is not comparable with https://github.com/vanvught/rpidmx512 . Just compare the supported PIDs -> http://www.orangepi-dmx.org/orange-pi-dmx512-rdm/rdm/rdm-supported-pids , and the built-in supported sensors -> http://www.orangepi-dmx.org/orange-pi-dmx512-rdm/rdm/built-in-supported-sensors

You can use, for example a 10$ Raspberry Pi Zero for initial start of development. My point; no need to invest in an expensive RDM Responder for an initial code development. 

- Arjan



- Arjan 


- Arjan

On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

-- 
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en


-- 
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en


-- 
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com

Peter Newman

unread,
Apr 12, 2019, 11:58:01 AM4/12/19
to open-lighting


On Friday, 12 April 2019 10:16:14 UTC+1, Arjan van Vught wrote:


Op 11 apr. 2019 om 23:51 heeft Peter Newman <peterjnewman> het volgende geschreven:



On Tuesday, 9 April 2019 18:37:43 UTC+1, Arjan van Vught wrote:
Hi Peter,

Op 9 apr. 2019, om 19:20 heeft Peter Newman <peterjnewman> het volgende geschreven:



On Tuesday, 9 April 2019 17:10:43 UTC+1, Arjan van Vught wrote:
Hi Peter,

Op 9 apr. 2019, om 18:00 heeft Peter Newman <peterjnewman> het volgende geschreven:

Sorry Arjun, that's simply not true!
For native UART it is true. There are no working Linux drivers. The issue is timing. I have not seen otherwise.
Can you be more specific? I think detecting the break is likely to be the only potentially challenging part (I don't know if the Linux driver handles this), the rest is just reading and writing bytes and passing them up the OLA stack. Why do you think the onboard UART shouldn't be able to do it when a USB connected FTDI can?
I’ve been told by Linux developers that it is almost, or mostly impossible to have RDM support in the Linux. Basically due to timing issues.
Well Keeper of the Keys appears to be doing a very good job of proving that wrong.

Keeper of the Keys are using FTDI and not the native UART.
Yes, I know that, unless the issue is the kernel itself, I'm not sure it's representative, I'd have said the increased overheads of the USB interface on the FTDI ought to make things harder than a native UART.


Keeper of the Keys has working code which does RDM over an FTDI on Linux, I see no reason that shouldn't work on the native UART either. Ankur, this would also be the best code/plugin to base it off of. He's still doing a little bit of fine tuning based on my reviews, but it works:
There is a note : "The support is not 100% according to the standard .. “. That is telling me that it is not working in Linux. Unless we accept that we do not apply to the standards.

It just means he's not implemented it yet. At least he's honest enough to admit it, compared to some commercial controllers which seemingly don't even check the CRC:

Or the hundreds of DMX fixtures which don't check the start code and therefore break with RDM.

Indeed looking at the code, I think that comment is out of date for the current codebase:

It may not even be too hard (famous last words), given the interface code is pretty similar apart from how the raw data is actually written.

Likewise others had done it previously on Windows with an FTDI:

What I would say if you're planning to implement this on the UART is you need a known good RDM responder and ideally a scope or logic analyser, so you don't have too many variables when you're first testing.
I can help you with a good  (inexpensive) RDM Responder -> open source and it successfully do the OLA RDM test.
Doing the OLA RDM tests doesn't imply compliance with the standard ( https://www.openlighting.org/rdm-tools/rdm-responder-tests/faq/#Is_this_a_E120_Compliance_Test ). The linked PR above allows a successful test run against a fixture (or to be more accurate correctly detected some failures in a buggy fixture).
I also reference to https://lightning-dmxcontrol.com/faq#4 This is DMX, but I am convinced that it will also apply for RDM as well.
Indeed, OLA has a similar comment in it's FAQ:

The linked comment says:
"The open usb dmx just puts through the data it receives via usb. As your computer is doing multiple things at once, it can slightly delay the bytes that are sent through the usb port. If this is halfway an array of dmx channels, it can cause the dmx-packet to be corrupted, which results in a wrongly interpreted dmx-array by the receiving devices. This appears as flickering."

I'm not sure this is technically true, I think a well written responder/DMX fixture ought to see the partial frame, and then timeout on the gap caused by the PCs delay and discard the rest of the packet. I don't think it should interpret it as a break and therefore offset frame data, although I imagine most people using an Open USB DMX are probably controlling fixtures at the cheaper end of the market.

And the Open USB DMX are not opto-isolated as well. It really depends on the requirements you have set when using such a solution.
Yep, and I suspect people at that end of the market just want a cheap solution (touch wood) but I've not blown up a computer yet, although mostly using a Pro or similar.

Instead of using USB, why not using Art-Net 4 moving forward ?
Because a directly connected USB device needs less config generally than an IP to DMX gateway. It normally doesn't need another PSU and it's just plug and play, I don't have to know it's IP or configure it at all, I don't need a switch if I want to use my Ethernet connection for other things and I don't have to potentially faff with routing tables if I want to use WiFi at the same time.

Maybe I should start a new thread for; What is the acceptance for Art-Net 4? It can do RDM and then the more network friendly sACN E1.31 DMX.
Why not use RDMnet? It should be out very soon now, and fixes some issues with Art-Net 3/4, including it's RDM support.

Peter Newman

unread,
Apr 12, 2019, 12:11:28 PM4/12/19
to open-lighting


On Friday, 12 April 2019 10:46:42 UTC+1, Arjan van Vught wrote:


Op 11 apr. 2019, om 23:51 heeft Peter Newman <peterjnewman> het volgende geschreven:



From a quick look at your code I can't immediately see back-offs for slow responders.
Not sure if I understand this remark. Your advice is a having good RDM Responder when developing and debugging the possible native UART RDM plug-in. My responders are implemented according to the E1.20 timing standard.  Hence I am suggesting to use such inexpensive RDM Responder (which will also pass the RDM Responder test).
 Apologies, I assumed you were talking about your controller code and had been looking at that, rather than your responder code as a responder to test against.

My point still stands though, there are also Arduino ( https://github.com/mathertel/DmxSerial2 ) and Teensy ( https://github.com/chrisstaite/TeensyDmx/ ) based responder code too which I've worked on and tested against the OLA RDM responder tests. I still wouldn't recommend using them to develop and test code unless you've also got access to a different RDM controller to test your implementation first. It's all to easy to get a pin misconnected or similar and unless you've tested it you may be none the wiser.

I am not sure if I do understand the pin misconnected remark; What has pin’s to do with software? Basically you can do a very initial simple test with a ’null-modem’ cable between the RDM Controller and the RDM Responder. Of course with the assumption that they both running at the same voltage (3V3 vs 5V). In such a controlled development environment, there is also no need to have opto-isolation. 
At some point I need to tell my code which pin is connected to the Driver Enable and Receiver Enable on my RS485 transceiver, if I cross those over it won't work, or if I've made some other wiring error (e.g. crossing the two differential lines). Unless I've got a working unit already, that's a lot harder to test.

In all fairness, the DmxSererial2 code is not comparable with https://github.com/vanvught/rpidmx512 . Just compare the supported PIDs -> http://www.orangepi-dmx.org/orange-pi-dmx512-rdm/rdm/rdm-supported-pids , and the built-in supported sensors -> http://www.orangepi-dmx.org/orange-pi-dmx512-rdm/rdm/built-in-supported-sensors
The number and range of PIDs doesn't matter in the slightest, as long as the device correctly supports the discovery ones that in itself would actually be enough to develop RDM support, although a GET and a SET and ideally broadcast and vendorcast SET support would help to cover a few edge cases around timeouts. Certainly the minimum requirements from E1.20 would be plenty sufficient. All the heavy lifting happens higher up the OLA stack, the plugin only really needs to shift bytes on and off the bus correctly.

You can use, for example a 10$ Raspberry Pi Zero for initial start of development. My point; no need to invest in an expensive RDM Responder for an initial code development.
An Arduino will likely still be cheaper than a Pi Zero if cost is your main driver. I'd agree you don't need to buy an expensive RDM responder (although it depends what you mean by expensive, there are plenty of sub £75 LED drivers with RDM support available now, you probably want a scope or logic analyser too, in which case that cost may well be cheap). I'd still strongly recommend (and this is based on experience assisting numerous other people asking for help over the years) to people if they're going down this route to ensure they've got one part that's tested and known working, so if they're going to DIY the controller AND the responder, then borrow someone else's controller first to prove your responder works. If they really can't do that, then at least build known working controller and responder circuits first (e.g. Arduino), or prove the DMX out bit works or something, before attempting to write a whole new controller stack on e.g. the native UART or SPI or whatever.

- Arjan



- Arjan 


- Arjan

On Tuesday, 9 April 2019 13:59:00 UTC+1, Arjan van Vught wrote:
Hi Ankur,

Op 9 apr. 2019 om 14:46 heeft Ankur Patel <bkankur> het volgende geschreven:

Is it that linux cannot handle the timing requirements of RDM?
Yes, that is the case.

- Arjan

-- 
The Open Lighting Project: open-lighting@googlegroups.com, #openlighting (irc.freenode.org)

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en


-- 
The Open Lighting Project: open-lighting@googlegroups.com, #openlighting (irc.freenode.org)

To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com
For more options, visit https://groups.google.com/groups/opt_out?hl=en


-- 
The Open Lighting Project: open-lighting@googlegroups.com, #openlighting (irc.freenode.org)

Arjan van Vught

unread,
Apr 12, 2019, 1:09:11 PM4/12/19
to open-l...@googlegroups.com

Op 12 apr. 2019, om 18:11 heeft Peter Newman <peterj...@gmail.com> het volgende geschreven:


You can use, for example a 10$ Raspberry Pi Zero for initial start of development. My point; no need to invest in an expensive RDM Responder for an initial code development.
An Arduino will likely still be cheaper than a Pi Zero if cost is your main driver.
Wiith a Raspberry Pi Zero for $10, you have also the SDCard for easy upgrading of the firmware. And easy setting the RDM Responder configuration by means of .txt files.
Also there it HDMI, which gives you a fast debug output if needed. It is just a more easier platform to work it.  

Note that I am slowly moving away from the Raspberry Pi boards. The next supported board is the Orange Pi Zero. Major advantage is its availability and the onboard SPI flash; the board boots from SPI flash and all configuration items can be stored in SPI flash.

I'd agree you don't need to buy an expensive RDM responder (although it depends what you mean by expensive, there are plenty of sub £75 LED drivers with RDM support available now, you probably want a scope or logic analyser too, in which case that cost may well be cheap).

I have such a cheap RDM dimmer. And in cheap, it won’t passes the OLA RDM test. Such a device, is in my opinion, not good to work with when developing a RDM Controller.

I'd still strongly recommend (and this is based on experience assisting numerous other people asking for help over the years) to people if they're going down this route to ensure they've got one part that's tested and known working, so if they're going to DIY the controller AND the responder, then borrow someone else's controller first to prove your responder works. If they really can't do that, then at least build known working controller and responder circuits first (e.g. Arduino), or prove the DMX out bit works or something, before attempting to write a whole new controller stack on e.g. the native UART or SPI or whatever.
There is no DIY RDM Responder in this case. The variable here is the RDM Controller. So it is a reliable development environment.  

- Arjan

Peter Newman

unread,
Apr 14, 2019, 5:46:21 PM4/14/19
to open-lighting


On Friday, 12 April 2019 18:09:11 UTC+1, Arjan van Vught wrote:


Op 12 apr. 2019, om 18:11 heeft Peter Newman <peterjnewman> het volgende geschreven:


You can use, for example a 10$ Raspberry Pi Zero for initial start of development. My point; no need to invest in an expensive RDM Responder for an initial code development.
An Arduino will likely still be cheaper than a Pi Zero if cost is your main driver.
Wiith a Raspberry Pi Zero for $10, you have also the SDCard for easy upgrading of the firmware. And easy setting the RDM Responder configuration by means of .txt files.
Also there it HDMI, which gives you a fast debug output if needed. It is just a more easier platform to work it.
That sounds like the SD card is another expense, but it depends what you've got available. If the HDMI output can display packet captures, that could actually be very useful when doing initial development.

Note that I am slowly moving away from the Raspberry Pi boards. The next supported board is the Orange Pi Zero. Major advantage is its availability and the onboard SPI flash; the board boots from SPI flash and all configuration items can be stored in SPI flash.

I'd agree you don't need to buy an expensive RDM responder (although it depends what you mean by expensive, there are plenty of sub £75 LED drivers with RDM support available now, you probably want a scope or logic analyser too, in which case that cost may well be cheap).

I have such a cheap RDM dimmer. And in cheap, it won’t passes the OLA RDM test. Such a device, is in my opinion, not good to work with when developing a RDM Controller.
Does it respond correctly to discovery, GET DEVICE_INFO and GET/SET DMX_START_ADDRESS (for example), if so then it's completely sufficient for developing an OLA based RDM controller.

I'd still strongly recommend (and this is based on experience assisting numerous other people asking for help over the years) to people if they're going down this route to ensure they've got one part that's tested and known working, so if they're going to DIY the controller AND the responder, then borrow someone else's controller first to prove your responder works. If they really can't do that, then at least build known working controller and responder circuits first (e.g. Arduino), or prove the DMX out bit works or something, before attempting to write a whole new controller stack on e.g. the native UART or SPI or whatever.
There is no DIY RDM Responder in this case. The variable here is the RDM Controller. So it is a reliable development environment.
Unless you're sending out assembled (and tested) units, then there is a DIY responder! When was the last time you heard of a commercial unit arriving broken? At a minimum with an Arduino or Pi based solution, you're going to have the microcontroller (or SBC) and a shield/hat which need plugging together and some code loading. I'll admit with a Pi and a Hat, and having checked the HDMI output to prove it's booted, there's probably not much can go wrong with it at that stage (assuming the Hat has a fitted XLR), but equally at the expense of all that you've probably paid for a cheap commercial unit. If you start DIYing parts of the system (e.g. on breadboard), or moving to processors with less feedback (although Arduino's serial console could probably still show enough to give me a good level of faith), then with each change you reduce the reliability of your development environment and hence increase the risk it's the responder at fault rather than your work in progress code. A commercial RDM responder (or controller), rules all of that out instantly, as you can confirm 100% the other end of the chain works in at least some scenario (and then test kit allows you to play spot the difference if it doesn't work as intended with your new RDM controller).

- Arjan

Ankur Patel

unread,
Jul 2, 2019, 1:46:14 AM7/2/19
to open-l...@googlegroups.com

Hello Peter,

Many thanks for your pointers, got basic RDM working using native Uart. I can able to discover around 40 fixtures and are responding to DMX as well. Also I can set RDM Get/Set on all of them with no issues.

At present, I am tuning it up to have smooth RDM when DMX is running on background. For now when I initiate RDM, looks like it stops DMX til it receives response from fixture. I will also upload it somewhere so that you or anyone can do code review on it.

Again thanks all.

Regards,
Ankur.

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com

Peter Newman

unread,
Jul 3, 2019, 11:03:41 AM7/3/19
to open-lighting
Excellent Ankur, that sounds very promising indeed.

Yeah you should push an initial version up to GitHub and open a pull request and then people can start looking at it or having a play already.

I think it should still wait for the RDM response (or timeout) when it sends one and stop sending DMX, but the timeout should be fairly quick, and some things may choose to rate limit the RDM data. Is it currently doing it to the extent that it's unusable due to the lack of DMX updates?

On Tuesday, 2 July 2019 06:46:14 UTC+1, Ankur Patel wrote:

Hello Peter,

Many thanks for your pointers, got basic RDM working using native Uart. I can able to discover around 40 fixtures and are responding to DMX as well. Also I can set RDM Get/Set on all of them with no issues.

At present, I am tuning it up to have smooth RDM when DMX is running on background. For now when I initiate RDM, looks like it stops DMX til it receives response from fixture. I will also upload it somewhere so that you or anyone can do code review on it.

Again thanks all.

Regards,
Ankur.
On Mon, Apr 15, 2019 at 7:46 AM Peter Newman <peterjnewman> wrote:


On Friday, 12 April 2019 18:09:11 UTC+1, Arjan van Vught wrote:


Op 12 apr. 2019, om 18:11 heeft Peter Newman <peterjnewman> het volgende geschreven:


You can use, for example a 10$ Raspberry Pi Zero for initial start of development. My point; no need to invest in an expensive RDM Responder for an initial code development.
An Arduino will likely still be cheaper than a Pi Zero if cost is your main driver.
Wiith a Raspberry Pi Zero for $10, you have also the SDCard for easy upgrading of the firmware. And easy setting the RDM Responder configuration by means of .txt files.
Also there it HDMI, which gives you a fast debug output if needed. It is just a more easier platform to work it.
That sounds like the SD card is another expense, but it depends what you've got available. If the HDMI output can display packet captures, that could actually be very useful when doing initial development.

Note that I am slowly moving away from the Raspberry Pi boards. The next supported board is the Orange Pi Zero. Major advantage is its availability and the onboard SPI flash; the board boots from SPI flash and all configuration items can be stored in SPI flash.

I'd agree you don't need to buy an expensive RDM responder (although it depends what you mean by expensive, there are plenty of sub £75 LED drivers with RDM support available now, you probably want a scope or logic analyser too, in which case that cost may well be cheap).

I have such a cheap RDM dimmer. And in cheap, it won’t passes the OLA RDM test. Such a device, is in my opinion, not good to work with when developing a RDM Controller.
Does it respond correctly to discovery, GET DEVICE_INFO and GET/SET DMX_START_ADDRESS (for example), if so then it's completely sufficient for developing an OLA based RDM controller.

I'd still strongly recommend (and this is based on experience assisting numerous other people asking for help over the years) to people if they're going down this route to ensure they've got one part that's tested and known working, so if they're going to DIY the controller AND the responder, then borrow someone else's controller first to prove your responder works. If they really can't do that, then at least build known working controller and responder circuits first (e.g. Arduino), or prove the DMX out bit works or something, before attempting to write a whole new controller stack on e.g. the native UART or SPI or whatever.
There is no DIY RDM Responder in this case. The variable here is the RDM Controller. So it is a reliable development environment.
Unless you're sending out assembled (and tested) units, then there is a DIY responder! When was the last time you heard of a commercial unit arriving broken? At a minimum with an Arduino or Pi based solution, you're going to have the microcontroller (or SBC) and a shield/hat which need plugging together and some code loading. I'll admit with a Pi and a Hat, and having checked the HDMI output to prove it's booted, there's probably not much can go wrong with it at that stage (assuming the Hat has a fitted XLR), but equally at the expense of all that you've probably paid for a cheap commercial unit. If you start DIYing parts of the system (e.g. on breadboard), or moving to processors with less feedback (although Arduino's serial console could probably still show enough to give me a good level of faith), then with each change you reduce the reliability of your development environment and hence increase the risk it's the responder at fault rather than your work in progress code. A commercial RDM responder (or controller), rules all of that out instantly, as you can confirm 100% the other end of the chain works in at least some scenario (and then test kit allows you to play spot the difference if it doesn't work as intended with your new RDM controller).

- Arjan

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lighting+unsubscribe@googlegroups.com

Keeper of the Keys

unread,
Aug 26, 2019, 4:43:10 PM8/26/19
to open-lighting
Hi everyone,
Hope you don't mind me digging this up, but since I saw me mentioned a bunch of times I figured I should clarify a few things:

"The not 100% according to standard" remark was originally be made because I had the plugin wait the minimum defined wait time for a response and then moved on regardless of how much of the reply was received, the standard as far as I understand actually demands you wait until the maximum timeout if less then a full reply was received (or until the full reply is in), in the mean time I have added code that hopefully handles this situation, however I also have only a single cheap Chinese LED driver that does RDM and does not take more then the minimum wait to reply so this has never been tested in "real life".
The other location where timing is an issue is with Break/MAB and possibly with inter-frame times, however all these times are allowed to be dragged out in the DMX and RDM standard, whether or not their timings on the line stay within the limit I don't know since I don't own a logic analyzer.

The potential main problem with using a UART on any non-realtime OS is turn around time, FTDI chips will receive and buffer data thus RDM DUB replies can be succesfully detected, I suspect that with FTDI it would also be possible if we were using them as the ttyUSB UART devices, with other UARTs it is harder to say.

*However* since UARTs are used for all kinds of communication at much higher speeds then the 250kbaud that we need I suspect that it should be possible with most modern UART hardware unless it depends on a OS level systemcall to change direction in which case the DUB reply is close to impossible to catch.

HTH,
Keeper of the Keys (Eli)

Op woensdag 3 juli 2019 18:03:41 UTC+3 schreef Peter Newman:
To unsubscribe from this group, send email to open-l...@googlegroups.com

Hippy

unread,
Mar 16, 2021, 8:21:53 AM3/16/21
to open-lighting
Hi All,  long time, no see! 

Hey I am bumping this old thread, primarily because I am trying to get feel for where OLA is with RDM Controller via Native UART, specifically with Pi4 in mind. 

I've been reading much, but I find levels of success... are people running rPi UART with RDM or DMX with OLA reliably?

Given in issue https://github.com/OpenLightingProject/ola/issues/1700#issuecomment-749697266 that MagnusHerrlin was reporting and showing 4 ports working, is there any confidence that RDM Controller and DMX output could work on multiple ports?

Cheers,
  Hippy

Hippy

unread,
Mar 16, 2021, 8:47:16 AM3/16/21
to open-lighting
Okay, now reading the code, I don't think RDM it is implemented at all in OLA for UART... presume the timing is too tight?

Cheers,
Hippy

michael

unread,
Mar 16, 2021, 1:18:55 PM3/16/21
to open-l...@googlegroups.com
I habe Build this and Hooked up to a rpi4, via a small adapter: https://www.stickel.org/LightingConsoleHardware/DmxIo4/DmxIo4.html

I am in the process of writing a driver. I started with a dmx4linux2 loopback driver and hooked a userspace driver between that and a you device. I wrote a dedicated overlay that makes the user being used by that you driver. The userspace driver in between supports RDM. It is very alpha code but works with pl011 and 16c550 parts. As another testbed I have a microzed board with a bitstream containing 32 16c550 parts.
I do not have a public repository of It, as this is alpha state.

Michael 



Von meinem Samsung Galaxy Smartphone gesendet.

-------- Ursprüngliche Nachricht --------
Von: Hippy <dmx...@gmail.com>
Datum: 16.03.21 13:47 (GMT+01:00)
An: open-lighting <open-l...@googlegroups.com>
Betreff: Re: [open-lighting] RDM support into Native UART DMX plugin

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com
---
You received this message because you are subscribed to the Google Groups "open-lighting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/617f1364-2610-4b0d-b7d4-441b3529b2b4n%40googlegroups.com.

Peter Newman

unread,
Mar 23, 2021, 10:40:49 PM3/23/21
to open-lighting
Hi Hippy,

I don't believe Ankur ever posted a link to his work in progress RDM UART code unfortunately. Maybe he'll see this or reply to an email?

Keeper of the Keys FTDI RDM code ( https://github.com/OpenLightingProject/ola/pull/1541 ) is still pending some review effort from me, but I did test it at the Plugfest last year and found 64 or 128 of the Labpack responders with no issues, so it's certainly functional.

In terms of other stuff at the cheaper/simpler end of things, Jannis is working on this:

For anyone else wanting to develop RDM/DMX this code (here until it gets merged), supports any sigrok logic analyser to show RDM/DMX on the wire:

Michael, if you want to hook that into OLA, you potentially don't really need to support much on the RDM side at all, apart from the ability to send/receive packets and OLA can do all the hard work.

Rowan Maclachlan

unread,
Mar 25, 2021, 8:03:39 AM3/25/21
to open-l...@googlegroups.com
Thanks very much Peter and others, your answer is most appreciated and helpful.  I'll report back one day on my success, keep up the good work!

Cheers,
 Hippy

--
The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
To unsubscribe from this group, send email to open-lightin...@googlegroups.com

For more options, visit https://groups.google.com/groups/opt_out?hl=en
---
You received this message because you are subscribed to the Google Groups "open-lighting" group.
To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/cbdab76a-bcc7-464f-adc1-e0af6d658499n%40googlegroups.com.

bka...@gmail.com

unread,
Jun 22, 2022, 11:22:31 PM6/22/22
to open-lighting
Apology Guys|Peter, for getting away from this project for so long.

Looks like I am back on, which I wanted to since long. Before I push an initial version on github, please find the attached patch of the changes I did. This is for someone in need of quick reference. The patch works for ola: 0.10.6-r0. (I know its couple of versions back now). Again would like to thank every one here on the OLA team. 

Any questions or concern, please reach out. I should be able to repond in time. 

Regards,
Ankur

To unsubscribe from this group, send email to open-lightin...@googlegroups.com
0001-Added-the-support-for-UART-RDM-DMX.patch

Peter Newman

unread,
Jun 30, 2022, 11:07:41 AM6/30/22
to open-lighting
Thanks Ankur.

Unfortunately I've still not done enough to get the other stuff merged either.

Your code looks good from a quick glance. Do you want to push a copy of it up to GitHub or similar against a fork of the OLA repo, even if it's against the older release, as that will make it far easier for people to compare it and hopefully merge it in eventually.

Peter Stuge

unread,
Jun 30, 2022, 3:03:38 PM6/30/22
to open-l...@googlegroups.com
Hi,

For background: I've implemented DMX controllers and DMX fixtures on
different kinds of bare metal hardware with register level programming,
with careful timing analysis of wire signals as well as protocol. Both
implementations run 24/7 in various configurations, coupled together
and individually with foreign opposites. I know Linux kernel USB and
serial some.

Arjan van Vught wrote:
> > Is it that linux cannot handle the timing requirements of RDM?
>
> Yes, that is the case.

Peter Newman wrote:
> > > Sorry Arjun, that's simply not true!
> >
> > For native UART it is true. There are no working Linux drivers.
> > The issue is timing. I have not seen otherwise.
>
> Can you be more specific? I think detecting the break is likely to
> be the only potentially challenging part

As Keeper of the Keys confirmed, that's right.

The challenge is not in creating something that works in "easy"
situations with a controller that outputs conservative timing onto
a wire without any error conditions.

The challenge is to always behave correctly, throughout the complete
range of timing permitted by the specification, including rejecting
non-compliant signalling and never entering an undefined state.

(Once, a DMX cable got shorted by things moving on stage during a show,
setting off the smoke machine and blinking various lights at random.)


> (I don't know if the Linux driver handles this),

Linux provides no timing information for BREAK duration or other
wire state to userspace. tcsetattr() can set BRKINT in c_iflag,
causing SIGINT delivery on "a BREAK" but AFAIK that state lacks
further definition.

So it's impossible to know BREAK and MAB duration in userspace.

If a userspace program were to timestamp both such SIGINT and the
first received byte thereafter (START) then a rough guess could be
made about the sum of BREAK+MAB duration, but it remains unknown (and
possibly hardware dependent!) exactly *when* "a BREAK" triggered SIGINT
and we actually need to know BREAK and MAB duration individually.

Add to this that every syscall (context switch) and even more so signal
delivery introduces huge timing uncertanity; each syscall can have
jitter on the order of many ms, making userspace timestamps useless
for measuring single-digit us.

So, not possible to correctly determine wire states required by spec.


> Why do you think the onboard UART shouldn't be able to do it when
> a USB connected FTDI can?

Arjan van Vught wrote:
> I’ve been told by Linux developers that it is almost, or mostly
> impossible to have RDM support in the Linux. Basically due to timing issues.

Nothing on USB can turn around within us. USB has high bandwidth but
also relatively high latency.

A USB-UART could theoretically report wire timing for BREAK and for
received bytes (allowing calculation of MAB duration) and so allow
userspace to correctly determine compliant DMX frames, but I know of
no such device.

<rant>FTDI is by far the worst USB-UART product on the market! Their
USB protocol constantly wastes CPU cycles (ie. power) as well as USB
bandwidth and their chips are absurdly overpriced. The inefficient USB
protocol results in suboptimal data transfer, making communication work
even with opposites incapable of wire speed, creating the illusion that
FTDI work better than alternatives when in fact poor FTDI quality masks
problems elsewhere.</rant>

I haven't looked into RDM-specific timing requirements; I don't know if
a hypothetical USB-UART which reports BREAK+byte timing would suffice
for a robust and compliant RDM implementation, or if a USB RDM device
would neccessarily have to implement RDM outside of the USB host.


A project that functions with FTDI hardware can do so only by making
assumptions about wire state, e.g. simply ignoring BREAK+MAB timing,
which IMO is unacceptable if you want to achieve a robust
implementation - something suitable for production.


Keeper of the Keys wrote:
> The other location where timing is an issue is with Break/MAB and possibly
> with inter-frame times, however all these times are allowed to be dragged
> out in the DMX and RDM standard,

As far as I know neither BREAK nor MAB nor inter-frame times may be
dragged out arbitrarily?

The minimum permitted durations are in the low us and the timing
parameters need to be measured and validated to determine compliant
frames, so that specific action (e.g. wait for next BREAK) can be
taken on non-compliant signalling, in order to avoid that the
receiver ends up in an incorrect state or misses an *actually*
compliant frame after some wire problem or interference.


> *However* since UARTs are used for all kinds of communication at much
> higher speeds then the 250kbaud that we need I suspect that it should be
> possible with most modern UART hardware unless it depends on a OS level
> systemcall to change direction in which case the DUB reply is close to
> impossible to catch.

Hardware can do it and the kernel has precise timers internally.

So it might be doable to create a DMX/RDM line discipline that
attaches to a serial port, takes care of low level frame IO and
exchanges full, compliant frames with userspace through some
possibly-to-be-created interface. A project idea for someone! :)
Note that the kernel serial layer could need some adjustments to
support the idea.

In any case, userspace has no chance to do the same successfully
using standard serial APIs. And USB hardware latency is way too
long even for a kernel driver to meet microsecond turnaround (in
case that's neccessary for RDM).


That said, of course a simple FTDI dongle that works in at least some
situations with at least some controllers is good fun.

Please don't compare that with Arjan's bare-metal work though -
that is a very unfair comparison!

Linux userspace simply cannot support robust, strict DMX.

Some things will work fine in some or even many cases, but because
error cases remain undetectable it is impossible to preclude malfunction.

So good fun, but not reliable. Be sure to actually want that.


Kind regards

//Peter

mic...@cubic.org

unread,
Jun 30, 2022, 5:11:39 PM6/30/22
to open-l...@googlegroups.com
Hi,

It is possible to implement an RDM capable DMX linux kernel driver for a UART like the 8250 successors (e.g.16450) if the right serial clock is provided. The gma2 is a proof. In order to be successfull you need to ignore the linux serial driver, as it is not designed for industrial protocols with strict timings and the need to have more control over the uart. Remember that it is intended to connect Terminals.  In my, sometimes rare spare time I am working on a successor to dmx4linux,with a completely different, frame based, abi. I have implemented a kernel driver implementing the abi as well as a loopback card module.  In parallel i created a cuse based implementation of the abi to be able to easily play around with the abi and implement tests without the need to have a kernel driver. I used that aproach together with uio to implement an RDM capable dmx driver and a set of tools. One is an RDM responder. I tested this on a MicroZed board with a custom carrier that connects to some DMX level shifter boards. As a sandbox I put together a bitstream containing some 16450 uarts. It gives me the opportunity to play arround with different hardware configurations without really rewiring hardware,  due to the fpga inside the ZYNQ.
One of the next steps is to optimize and improve the userspace implementation of the uart card driver and then move it over to the kernel space. The abi uses a pseudo RDM frame for communicating the result of a discovery request (timeout,collision,single-reply), like on the gma2.

https://www.stickel.org/LightingConsoleHardware/MicroZedDmxCarrier/MicroZedDmxCarrier.html

Best regards
Michael

30.06.2022 21:03:44 Peter Stuge <pe...@stuge.se>:
> --
> The Open Lighting Project: open-l...@googlegroups.com, #openlighting (irc.freenode.org)
> To unsubscribe from this group, send email to open-lightin...@googlegroups.com
> For more options, visit https://groups.google.com/groups/opt_out?hl=en
> ---
> You received this message because you are subscribed to the Google Groups "open-lighting" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to open-lightin...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/20220630190335.14496.qmail%40stuge.se.

Rowan Maclachlan

unread,
Jun 30, 2022, 11:17:41 PM6/30/22
to open-lighting
Hi Michael, 

> The gma2 is a proof

The GMA1 did this too... but uses a Oxford OX16PCI954 PCI UART Chip that can generate interrupts when a break is recieved and has a fractional prescaler to lock on to 250000 baud.

This probably helps a lot.

Cheers,



To view this discussion on the web visit https://groups.google.com/d/msgid/open-lighting/b128b787-4fa0-4cb9-b927-ad22bfe8ed9a%40cubic.org.

mic...@cubic.org

unread,
Jul 1, 2022, 2:04:25 AM7/1/22
to open-l...@googlegroups.com
The gma2 used exactly the same. Later they switched to pcie with dma support and even larger fifo. The 16450 also has a status event when receiving a break. Some of these 8250 clones do have a transmitter empty event, specially those with rs485 support. The one in the gma2 npu did not and I had to use a tasklet, once the thr was empty and I had no more to send, to emulate the transmitter shift register empty Interrupt.

Michael

01.07.2022 05:17:44 Rowan Maclachlan <dmx...@gmail.com>:

mic...@cubic.org

unread,
Jul 2, 2022, 6:01:35 AM7/2/22
to open-l...@googlegroups.com
Hi,

I also created a userspace implementation of the uart driver that uses verilator or iverilog together with a verilog implementation of a 16450 uart. It makes it possible to verify and test the driver without the need for real hardware.

I try to put some of it on github this Weekend.

Michael

01.07.2022 05:17:44 Rowan Maclachlan <dmx...@gmail.com>:

Hi Michael, 
Reply all
Reply to author
Forward
0 new messages