E1.20 RDM (Remote Device Management) Protocol Forums

E1.20 RDM (Remote Device Management) Protocol Forums (http://www.rdmprotocol.org/forums/index.php)
-   RDM Timing Discussion (http://www.rdmprotocol.org/forums/forumdisplay.php?f=7)
-   -   Exceeding MAB time (http://www.rdmprotocol.org/forums/showthread.php?t=89)

Dan Scheurell March 29th, 2007 04:04 PM

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.


prwatE120 March 29th, 2007 04:49 PM


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

Dan Scheurell March 30th, 2007 08:23 AM

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.


All times are GMT -6. The time now is 10:51 AM.

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