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