Rx Capturing five channels of NULL data.

[bdyetton]

Hi Mike,
Thanks again for the DMX code here, its been working really well for me, but i've been implementing a bit of a workaround that i'd love to fix properly.
It seems that with my usb to DMX unit (ENTEC OPEN DMX USB) i'm capturing 5 channels worth of null (0) bytes at the start of each transfer.
e.g. my first 8 channels look like this:
bytearray(b'\x00\x00\x00\x00\x00\xfe\x19\x00')
when they should instead look like
bytearray(b'\xfe\x19\x00\x00\x00\x00\x00\x00')
I'm sure i'm sending the correct channel data from my computer (e.g. in the above example chn1 is 254, chn2=25).
I've just been ignorning the first 5 channels as a workaround. This generally works, but sometimes, the correct data without the 5 NULL channels comes through and messes things up.
I also tried with a ENTEC DMX USB PRO and that was worse: there was a variable amount of NULL channels coming through.

Could the wait after the start bit being too short?
(in dmx.py)
"3. The PIO waits for a zero (start bit) and starts to sample the data ~6us later - the start bit should be 4us long"

Could it be the race condition you mentioned?
Any dirrection I should consider investigating more?
As a safer workaround i'm considering outputting a constant 255 on the first channel, and then when i process it, i'll just search for the first 255 and take the remaining channels. I'd loose the very last channel of the dmx universe, but i'm not using those anyway.
Thanks!

[MikeEllis-personal]

Sorry to hear you're having this problem - I can't say I understand it though. I've been using the code with an EntTec DMX USB Pro for several months and it's behaved pretty well. The only slight oddity I've seen is that if the DMX cable is unplugged and reconnected, it can lock up, and I'm not sure what's going on as (naturally) it never goes wrong when there's any test equipment connected!

I don't think the wait after start bit is the problem - the timing from start bit to stop bit is strictly defined for DMX (4us per bit) and we want to sample the data bit in the middle of the 4us window, so 6us is exactly right.

The race condition referred to is between detecting the end of frame (which isn't precisely defined) and setting the IRQ which causes the DMA to be reset ready for the next frame. I have found that the Pico can take so long to service that interrupt that it misses the start of the next frame. However, this results in the first few channel values (or worst case the entire next frame) being missed, not in non-existant 0 values being received.

I'll have a look at the code and see if I can understand what's going on, but I can't give a timescale I'm afraid as I'm rather busy with other projects at the moment. If you manage to work it out for yourself, please let me know!

Good luck.