E1.20 RDM (Remote Device Management) Protocol Forums  

Go Back   E1.20 RDM (Remote Device Management) Protocol Forums > RDM Developer Forums > RDM Timing Discussion

RDM Timing Discussion Discussion and questions relating to the timing requirements of RDM.

Thread Tools Search this Thread Display Modes
Old March 29th, 2007   #1
Dan Scheurell
Junior Member
Join Date: Mar 2007
Location: Middleton, Wisconsin, USA
Posts: 4
Default Exceeding MAB time

RDM imposes a restriction on the MAB time (88 us) that is new since DMX. Some combinations of external UART and CPU may have difficulty guaranteeing that time (if, for instance, interrupt priorities are relatively fixed and a higher priority interrupt preempts and takes its sweet time.)

It seems like the restriction is based on performance considerations, to prevent the line from laying around idle for too long. In that case, exceeding the spec a bit (say for about 40 us) may not be a tragedy? I can imagine that some RDM devices could assume that the controller has gone, but I'm wondering if, in general, the extra time would go unnoticed.

Dan Scheurell is offline   Reply With Quote
Old March 29th, 2007   #2
Task Group Member
Join Date: Jun 2006
Posts: 181


This is a maximum allowed time for the MAB. If you are greater than this, you are not compliant. The restrictions on times were designed to keep RDM traffic "tight" and reduce the impact on the throughput of null start code packets. If, as you suggest, your system cannot meet this time you cannot claim compliance, as the spec currently stands.

What your are suggesting is that your system can have (presumably intermittently) up to 88us of intercharcter delay ... which seems unusually high. A necessary approach may be to mask interrupts accordingly to keep the MAB short, or rejig priority levels. Once you have sent the start code (and thus completed the MAB), there is more slack on interbyte time.

Please dont forget RDM also places a restriction on the total packet time.

Can you elaborate on your particular hardware/system that exhibits this problem ?

Exceeding the spec for the extra 40us you propose WOULD be a potential tragedy, as someone else might legimately reject your packet based on receipt of what is (to them as per the spec) an illegally timed packet. Unlikely perhaps, but possible and legitimate.

This was not (to my knowledge) ever flagged as an issue during public review.

Peter Willis
prwatE120 is offline   Reply With Quote
Old March 30th, 2007   #3
Dan Scheurell
Junior Member
Join Date: Mar 2007
Location: Middleton, Wisconsin, USA
Posts: 4

Thank you, Peter, this is just the kind of answer I was looking for.

We have a separate timer, with separate interrupt, that is used to handle break and MAB timing. (Separate from the UART, that is.) So the interslot time is not an issue, that's handled by the UART itself. Total packet time is also compliant. The interrupt priorities are mostly fixed (MPC852 running Vxworks,) unless I modify the OS code. The timer interrupt is being preempted by other DMX ports and the system clock. This is, indeed, an intermittent problem that occurs too often when busy and interrupts align just so.

I'll bring the MAB time into spec range somehow, probably modifying the OS code to give higher priority to these particular timer interrupts, as you suggest.

Dan Scheurell is offline   Reply With Quote


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

Similar Threads
Thread Thread Starter Forum Replies Last Post
Time between controller packets Dan Scheurell RDM Timing Discussion 1 April 1st, 2007 11:38 PM

All times are GMT -6. The time now is 02:11 PM.

Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2024, vBulletin Solutions, Inc.