TeensyDMX Receive Issue

[Aerokeith]

I've successfully used the teensyDMX library in the past to send DMX data, and now I have an application that requires reading DMX data (and then relaying it through a wireless link). I'm having a persistent and baffling issue where the data is read correctly some/most of the time, but often "glitches" to values that are seemingly-always smaller than the correct channel values.

I've talked to Shawn, the library's author. He's been very helpful but doesn't have time now to dive into helping me debug this. So I thought I'd check with all of you to see if anyone has had a similar issue (and hopefully knows the fix).

Setup: Teensy 4 on a custom PCB that includes a ISL8487EIBZ transceiver and H11L1 opto-isolator (which also provides level shifting). The data source for testing is a City Theatrical DMXcat. I've tried various code variations, including Shawn's BasicReceive example. The library version is 4.3.0-snapshot.

Here are some of the things I've tried:
- Scoped the Serial1 RX pin; signal looks clean
- Tried a different DMX data source; no change (and other DMX receivers can read the DMXcat data correctly)
- Tried a different board; no change
- Changed the DMX timing parameters on the DMXcat; no change

I guess I can't rule out some strange hardware issue, so I'll keeping poking at that. Shawn suspects that it might be caused by a change in the toolchain or framework code, so if I can figure out how I'll try to revert to older versions.

Thanks for any insight or suggestions you can provide!

Edit: I thought I'd try a different library, to try eliminating hardware as the source of the problem, but I haven't found another DMX library with receive capability that will compile/run on a Teensy...

 

[MarkT]

What load resistance does the H11L1 have? What voltage supply for it? I'd definitely suggest hardware issue in the first place.

 

[Aerokeith]

An isolated +5V for the DMX side and +3V for the MCU side. Here's the circuit.

 

[MarkT]

R11/R15 are too large for it to operate at full speed - see the data sheet and it indicates 270R load resistors in the speed specifications, and 5V supply. Even though its rated to 1MHz under those conditions, that doesn't mean the duty cycle will be 50%, i.e. the edge timings are likely to be out. So 250kbaud is probably pushing it a little hard even so.

If reducing those resistors to 270 doesn't fix the problem, perhaps find something fast like one of the ADUM315x digital isolators? You can do all three lines in one isolator chip too, and use less power for them.

 

[Aerokeith]

R11/R15 are too large for it to operate at full speed - see the data sheet and it indicates 270R load resistors in the speed specifications, and 5V supply. Even though its rated to 1MHz under those conditions, that doesn't mean the duty cycle will be 50%, i.e. the edge timings are likely to be out. So 250kbaud is probably pushing it a little hard even so.

If reducing those resistors to 270 doesn't fix the problem, perhaps find something fast like one of the ADUM315x digital isolators? You can do all three lines in one isolator chip too, and use less power for them.

Well, I got excited for a few minutes. I changed R11 to 220R and the rise time improved slightly, but no change in the symptoms. I'll look into the ADUM315 for future designs, but I've really got to figure this one out.

 

[BillFM]

You could try a loopback test by removing U4 from the circuit and tying output of U6 to the input of U3. Send data thru Serial1 and check if it's received without error.

Another loopback path is to test Serial1 TX-to-RX connection without U6 and U3 installed.

 

[Aerokeith]

OK, I've confirmed that this is a hardware issue. I tried a different board that has a differential receiver (a different chip type) and no optical isolation. The software worked fine in this configuration. I'll continue tweaking the resistor values of the original design to see if I can get it working. If not, I'll switch to an entirely different design.

Thanks to everyone for your help!