DMX... Timing issue?

[SteveCS]

Hi all

I am using TeensyDMX.h on a 4.1, with a CTC-DRA-01-R2 DMX shield.

Daisy chain of 8x DMX lights on the system, and they all work fine... except two lights of a particular type.
These two don't play ball and flicker a lot. Either with or without a termination resistor in place.

Channel 0 is dimming/brightness level(0-255)
1, 2 and 3 are the RGB colours.

I am using the simple dmxTx.set(1, 0); command to control the required channel.

Any ideas what I can try to fix this issue? There seem to be a lot of extra commands in the keywords list, but I have no idea what any of them do.
I was thinking it might be a timing issue?

#######################################
# Syntax Coloring Map for TeensyDMX
#######################################

#######################################
# Datatypes (KEYWORD1)
#######################################

Receiver KEYWORD1
Sender KEYWORD1
Responder KEYWORD1
PacketStats KEYWORD1
ErrorStats KEYWORD1

#######################################
# Methods and Functions (KEYWORD2)
#######################################

begin KEYWORD2
end KEYWORD2
packetCount KEYWORD2
setTXEnabled KEYWORD2
setKeepShortPackets KEYWORD2
isKeepShortPackets KEYWORD2
readPacket KEYWORD2
get KEYWORD2
get16Bit KEYWORD2
packetStats KEYWORD2
lastPacketTimestamp KEYWORD2
setResponder KEYWORD2
setSetTXNotRXFunc KEYWORD2
setRXWatchPin KEYWORD2
rxWatchPin KEYWORD2
connected KEYWORD2
onConnectChange KEYWORD2
errorStats KEYWORD2
setBreakTime KEYWORD2
breakTime KEYWORD2
setMABTime KEYWORD2
mabTime KEYWORD2
setBreakSerialParams KEYWORD2
breakSerialBaud KEYWORD2
breakSerialFormat KEYWORD2
setBreakUseTimerNotSerial KEYWORD2
isBreakUseTimerNotSerial KEYWORD2
setPacketSize KEYWORD2
packetSize KEYWORD2
set KEYWORD2
set16Bit KEYWORD2
clear KEYWORD2
fill KEYWORD2
setRefreshRate KEYWORD2
refreshRate KEYWORD2
pause KEYWORD2
isPaused KEYWORD2
resume KEYWORD2
resumeFor KEYWORD2
resumedRemaining KEYWORD2
isTransmitting KEYWORD2
onDoneTransmitting KEYWORD2
outputBufferSize KEYWORD2
isSendBreakForLastPacket KEYWORD2
preBreakDelay KEYWORD2
preNoBreakDelay KEYWORD2
preDataDelay KEYWORD2
eatPacket KEYWORD2
processByte KEYWORD2
receivePacket KEYWORD2

#######################################
# Instances (KEYWORD2)
#######################################

#######################################
# Constants (LITERAL1)
#######################################

kMaxDMXPacketSize LITERAL1
kMinDMXPacketSize LITERAL1
kMinTXBreakTime LITERAL1
kMinTXMABTime LITERAL1


Thanks

[SteveCS]

Hmm I am starting to think this is something to do with the entire TeensyDMX library.

We used DMXsimple on another project and it worked fine. But DMXsimple doesn't compile on a 4.1, it throws up an error

[SteveCS]

Putting this in fixes the issue..

dmxTx.setPacketSize(100);
dmxTx.setRefreshRate(40);

What the heck in means, who knows.

I just don't understand why they bother to give you a text list of Keywords, and no explanation of what the hell they do. Not everyone knows this stuff.

[kd5rxt-mark]

Putting this in fixes the issue..

dmxTx.setPacketSize(100);
dmxTx.setRefreshRate(40);

What the heck in means, who knows.

I just don't understand why they bother to give you a text list of Keywords, and no explanation of what the hell they do. Not everyone knows this stuff.

@SteveCS:

Seems that you may not have read the README for the library ??

The following excerpts are taken directly from the README.md file:

### Packet size

The packet size can be adjusted and retrieved via `setPacketSize` and
`packetSize()`. Smaller packets will naturally result in a higher
refresh rate.

This can be changed at any time.

And

### Transmission rate

The transmission rate can be changed from a maximum of about 44Hz down to as low
as you wish. See the `setRefreshRate` and `refreshRate()` in `Sender`.

Note that the rate won't be higher than the limits dictated by the protocol,
about 44Hz, no matter how high it's set. The default is, in fact, `INFINITY`.

This can be changed at any time.

As referenced in the README.md file, the following code excerpt is taken directly from Sender.cpp:

bool Sender::setRefreshRate(float rate) {
  if ((rate != rate) || rate < 0.0f) {  // NaN or negative
    return false;
  }
  if (rate == 0.0f) {
    breakToBreakTime_ = UINT32_MAX;
  } else {
    if (refreshRate_ == 0.0f) {
      end();
      begin();
    }
    breakToBreakTime_ = 1000000 / rate;
  }
  refreshRate_ = rate;
  return true;
}

The author of that particular library is very active in this forum. A polite inquiry would probably elicit an informative reply.

Hope that helps.

Mark J Culross
KD5RXT

P.S. I have absolutely no experience with DMX, nor with the TeensyDMX library, but I am very comfortable digging thru code to try & analyze/understand underlying functionality, so I thought I'd take a look to see if I could possibly provide any assistance. I do hope that helps. MJC

[kd5rxt-mark]

Hmm I am starting to think this is something to do with the entire TeensyDMX library.

We used DMXsimple on another project and it worked fine. But DMXsimple doesn't compile on a 4.1, it throws up an error

@SteveCS:

I do not have any experience with DMX in any form, but in an attempt to possibly provide some help, I loaded up the TeenxyDMX library.

I tried compiling both of the examples for DMXsimple, & they both successfully compile with the following setup:

  Arduino IDE Configuration (last built with Arduino 1.8.19 + Teensyduino 1.58b2):
     Tools/Board:           "Teensy 4.1"
     Tools/USB Type:        "Serial"
     Tools/CPU Speed:       "600MHz"
     Tools/Optimize:        "Faster"
     Tools/Keyboard Layout: "US English"
     Tools/Port:            "COMx Serial (Teensy 4.1)"

Post the full text of the error (this is a variation on the "Forum Rule: at the top of the page") that you are encountering for potential help in resolving that.

Mark J Culross
KD5RXT

[shawn]

The keywords.txt file is for the Arduino IDE’s syntax colouring. It’s not meant as documentation. I’ve tried to make the README as complete as possible, but perhaps it deserves a section on possible electrical or “bad hardware” problems. (I can’t promise a timeline for adding it, however.)

The issues you describe might be electrical, or they might be due to the fixture not completely following the DMX spec. If you got it to work by changing the refresh rate, then maybe there’s something wrong with the lights, or even cabling. How are you connecting everything? What sort of cables are you using? For example, how long are they and what is the impedance? A common mistake is to use microphone cabling instead of DMX cabling; those have different characteristic impedances.

Flickering can also happen when a fixture receives non-null-start-code data and it doesn’t ignore those packets. Or maybe those lights just can’t handle a 44Hz refresh rate. Does changing the refresh rate without changing the packet size work too?

Or maybe the daisy chained devices are somehow interfering with the signal? What happens if you just connect the lights that flicker, without daisy chaining them?

Could you post your code? (Please wrap in CODE tags if you paste code.)

I’ve spent a lot of time verifying the library produces DMX signals that are accurate and correct, and while that doesn’t guarantee anything, I’ve been using this library in real-world projects with success. Problems that I’ve seen are most frequently with the fixtures themselves not being implemented properly or with how everything is hooked up, and with what components and wiring.

@SteveCS, What does the output look like on a scope or logic analyzer? TeensyDMX is interrupt-based and asynchronous, and so it’s possible that other libraries interfere with the timing, however, I wouldn’t expect, because of the flexibility in the DMX protocol, that the signal would be changed bad enough to go out of spec.

(Thanks, @kd5rxt-mark, for jumping in.)