Problem with short DMX512 MAB

[Steeeeker]

I’ve got a bit of a hardware issue with the nRF52811 UART, receiving DMX data from a Chinese DMX controller.

Standard DMX data-rate is 250Kb/S, so the minimum bit time is 4.0uS.   To start out a DMX frame, there is a long BREAK (low signal) > 96uS followed by what’s called a MAB (high signal) that’s supposed to be > 12uS.

In the image below, you’ll see that these cheap Chinese controllers send out a MAB far less than what’s required.   Should be >12uS, but we’re getting between 1.45uS and 5.5uS.   One MAB of 1.472uS shown below.

While I'd like to just stay away from these junk controllers, our customers pick them up from Amazon and complain to us that we don't work right.   So, we have to be compatible with them no matter how bad they are...

That said, here’s the guts of the issue.   The nRF52811 chip can properly detect the BREAK shown by the “BLIP” signal in the image above.   However, at that point, the UART is running and looking for valid start-bits and characters.   Because we only get an abbreviated high signal 1.42uS for the MAB, the UART doesn’t detect the first byte 0x00 at all.   If the MAB is longer, over 3.5uS, then the UART can detect the first 0x00 byte.

The result is that we get frame misalignment from half the frames, as the MAB duration varies in each frame from 1.4uS to 5.5uS.   I've tried using rising-edge events on the Rx signal in parallel, but the edge event latency prevents it from being useful as a solution.

Other processors have UART oversampling built into the hardware, and sometimes it’s configurable where you can select 8x or 16x oversampling of individual bits.   Does the nRF52 chip have configurable UART oversampling capabilities, maybe in a hidden register that we can work with to cure this?   

Has anyone else run into this "Short MAB" issue, and do you have tips on how they solved it???

Thx!

- Steve Krattiger

[tesc]

Hi,

we get frame misalignment from half the frames, as the MAB duration varies in each frame from 1.4uS to 5.5uS

Certainly a bad situation to be in. Also, since DMX512 allows a varying number of channels sent in each frame, it isn't as simple as checking the length and adjust accordingly.

Please note that MAB as low as 4 μs was at one point allowed by the DMX512 specification, although later raised to 8 μs and with nominal value of 12 μs. But 1.4 μs I agree is definitely out-of-spec behavior.

Nevertheless, even when a customer uses equipment which is demonstrably way out-of-spec, not coexisting with that equipment may still not meet the customer's expectations. Especially if there are other equipment which does handle the way-to-short MAB. Sadly being right isn't always considered to be good enough.

Does the nRF52 chip have configurable UART oversampling capabilities, maybe in a hidden register that we can work with to cure this?

Unfortunately not, no.

Has anyone else run into this "Short MAB" issue, and do you have tips on how they solved it???

I encourage the community to weigh in on this one.

We have not delved into "DMX512 with shorter than 4μs MAB" here at Nordic Semiconductor, no. Lower than 4 μs MAB has never been in-spec, and the current minimum value is double that, at 8 μs. Both of which your solution using the nRF52811 handles gracefully.

The only "solution" I could think of, is to analyze the data and try to detect whether or not the channels are shifted. I.e. by using metrics like number of channels, change from last frame, if the first byte (slot 0) contains a reasonable start code (0x00 for channel data, 0x17 for text packet, etc.) However that would make for a particularly hacky workaround with its own potential failures, and I do not like it. Be aware for instance, that a first byte of 0 is necessary for correct alignment (assuming the standard start code of 0), but not sufficient, as a leading 0 could also be in the shifted state with a value of 0 for the first channel. If you do anything like that, it should be a last resort option which the user can actively turn on, explicitly for compatibility with out-of-spec controllers.

Final words: Do you by any chance see the shortest MABs only when using very long or bad cables? Or does the signal really have such a short MAB out of the controller? I'm a bit surprised, frankly, that such equipment would work in the field. I am thinking that your equipment surely cannot be the only equipment struggling when connected to those bad controllers? Is there any enforcement of DMX512 compliance, qualification, etc, which can be used to force such bad actors to compliance (or out of business)?

Regards,
Terje

[Steeeeker]

Hi Terje,

Right now, this is being tested on single units with cable lengths <5m.   The dimmer(s) are all putting out very short (illegal) MAB signals with or without proper bus-termination.   I have 3x bad controllers here from different companies, and 2 good ones.   The bad ones all operate the same with short varying MAB, it's likely they all have the same chip inside.

As far as I know, there's no DMX Compliance companies out there, I sure wish there were!   And this is further complicated by the fact that we're also using RDM communications, so the first Control byte can be either 0x00 (DMX), or 0xCC (RDM).

But to update everyone, I have solved the issue by using both the UART and rising-edge GPIOTE at the same time on the Rx signal.   By getting an nrf_systick() timestamp on the first two rising edges after BREAK, one for the start of MAB, and one for the end of first byte, we can see the difference when the first byte was missed.   Granted, there is a 12uS - 24uS delay getting the events, we were able to eliminate 98% of the framing issues by frame recovery by using rising-edge timing.

To catch those last few frames that sneak through this, we also added a comparison between last_frame bytes, and current_frame bytes as you mentioned, and just dump any frames with radical changes.

I'm sending this build into our QA testing today, we'll see if it passes.

Thanks!

SteveK

[tesc]

Hi,

Thank you for the update.

Steeeeker said:

without proper bus-termination

Yikes. I feel with you.

Steeeeker said:

But to update everyone, I have solved the issue

Steeeeker said:

we were able to eliminate 98% of the framing issues

Steeeeker said:

I'm sending this build into our QA testing today, we'll see if it passes.

It sounds to me you have found a good solution given the circumstances, and I sincerely hope it passes QA. 98 % success rate sounds very good to me, for communicating with such out-of-spec devices.

Regards,
Terje