Responder Packet Timing issue

[ericthegeek]

Originally Posted by berntd

This is a responder based on a Linux non real time environment.
The OS is busy doing heaps of other stuff so we are not able to use interrupts as it takes too much cpu time and we can't get them fast enough when the OS is busy.

My personal opinion is that to do RDM, you really need a software architecture that can respond to events on the wire within a few tens of microseconds. You might be able to stretch that to 100us. But if the software takes a millisecond or more you're going to have problems.

You might explore using a small/cheap microcontroller as an RDM Co-Processor to handle the low level timing. I haven't followed recent Real-Time Linux developments, but there may be a solution there too.

Originally Posted by berntd

If we have to compromise one of the time 2 values, which one is preferable?

The timings in the standard are strict for a reason, must stricter that traditional DMX. This was done to minimize the impact on the NSC data throughput. Controllers have a bit more flexibility, but responders are tightly constrained. If you compromise any of the timings, it may cause problems with some systems.

Someone who's more clever than I might be able to find a solution, but I'm foreseeing issues if you have to use a single DMX timeout for everything.