DMX-Open and DMX-Pro broken timing ?

[Light-Mike]

Good morning,

I'm using a RASPI-Zero, as well as 3+ and 4 to generate local DMX, using TTY-AMA0 (and 1,2,3 on the RASPI-4).

DMX-Pro never really worked for me (Break  time too short), but now on Version 4.5 and 4.6 the timing on even DMX-Open seems to be broken:

ESTA DMX timing should be:
- 250KBaud
- Break >= 88us ; <<1s
- Mark After Break >= 8us, <<1s

I'm using an Artistic License Mircro-Scope IIa DMX Analyzer to measure timings.


What I get on Raspi-Zero on FPP 4.5 (bridge Mode):
Break timing                    DMX-Open: 51us       DMX-Pro: 81us
Mark After Break timing    DMX-Open:  2us        DMX-Pro:   6us
--> I can't control anything with this


Raspi 3+ on FPP 4.5.1.5 (player Mode)
Break timing                    DMX-Open: ~260us        DMX-Pro: 81us
Mark After Break timing    DMX-Open:      80us       DMX-Pro:   8us
Frame time                      DMX-Open:      25ms
--> Only DMX open works

Raspi 3+ on FPP 4.6 (player Mode)
Break timing                    DMX-Open:   50us          DMX-Pro: 81us
Mark After Break timing    DMX-Open:   39us          DMX-Pro:   8us
--> Nothing works


It appears that DMX Pro has a constantly ~8us too short break time and DMX open break time varies heavily...

Is there any chance to fix this?

[CaptainMurdoch]

FPP doesn't control the break timing on your DMX Pro dongle, because in this case, the DMX spec is implemented in hardware.  FPP just sends the data in the DMX Pro packet format and the dongle handles the timing on the wire.

FPP does control the timing on the DMX Open Channel Output since the DMX spec is implemented in software.  FPP currently is configured for a 200us break followed by a 20us pause although these aren't guaranteed to be exact since we aren't running a realtime kernel.  We have never had anyone else complain about these timings that I recall, but is is possible that most people's equipment still works if the timings happen to be out of spec due to timing in Linux.

I see that xLights' DMX Open output uses 1ms for both mark and break.  I don't know if we would go that high, but I could bump the values in FPP up in the master development branch of FPP if you would be willing to test with your hardware and analyzer.

[Light-Mike]

200us for Break would totally fine and if it jitters a little bit, that's cool too.
1ms would be excessively long, not required, but would still be within spec.

What I'm seeing here is times on DMX-Open on Raspi TTY-AMA0 of 50us + a little Jitter for Break timing on Version 4.5 and 4.6 (on a Raspi-Zero) which I did not see before (used to be ~260us = totally fine)

--> Something in the DMX open seemed to have changed?


Thanks for clarifying the USB-Pro output used with a USB-Dongle. DMX-Pro still produces an "output" when connected to Raspi TTY-AMA0, but with slightly too tight timings.

[dkulp]

Nothing in the DMX output code has changed since April.   Thus, I'm really not sure how you are seeing any differences.  I could possibly see a kernel upgrade or something, but that didn't even change between 4.5 and 4.6.

[Light-Mike]

Ok, found the problem.

Looks like the software is just fine.

Looks like I'm having some borderline iffy DMX opto isolators delaying the rising edge just long enough to be read as a break instead of a normal 0 byte... some of them work, some of them don't.

Please ignore this post. Not a software issue, but a hardware Problem on external kit.

[CaptainMurdoch]

Thanks for reporting back.