DMX simple - modifying the break

I'm using the DMX simple library to control RGB LEDs. The LEDs dont like the DMX from the Arduino.

The manufacturer stated the following:

The problem is the "SPACE" for BREAK of the TRISTAR-RGB-DMX, which is 500. The standard DMX "SPACE" for BREAK is 88~144, but some DMX controllers handle a wide range of from 88~1,000.

So at this point, unless we can get our engineers to change the "SPACE" for BREAK, you need a DMX controller than can handle 500.

I've had a look at the DMX simple code, but I'm out of my depth, looks to me that this is the important section:

/** Transmit a complete DMX byte * We have no serial port for DMX, so everything is timed using an exact * number of instruction cycles. * * Really suggest you don't touch this function. */ void dmxSendByte(volatile uint8_t value) { uint8_t bitCount, delCount; asm volatile ( "cli\n" "ld tmp_reg,%a[dmxPort]\n" "and tmp_reg,%[outMask]\n" "st %a[dmxPort],tmp_reg\n" "ldi %[bitCount],11\n" // 11 bit intervals per transmitted byte "rjmp bitLoop%=\n" // Delay 2 clock cycles. "bitLoop%=:\n"\ "ldi %[delCount],%[delCountVal]\n" "delLoop%=:\n" "nop\n" "dec %[delCount]\n" "brne delLoop%=\n" "ld tmp_reg,%a[dmxPort]\n" "and tmp_reg,%[outMask]\n" "sec\n" "ror %[value]\n" "brcc sendzero%=\n" "or tmp_reg,%[outBit]\n" "sendzero%=:\n" "st %a[dmxPort],tmp_reg\n" "dec %[bitCount]\n" "brne bitLoop%=\n" "sei\n" : [bitCount] "=&d" (bitCount), [delCount] "=&d" (delCount) : [dmxPort] "e" (dmxPort), [outMask] "r" (~dmxBit), [outBit] "r" (dmxBit), [delCountVal] "M" (F_CPU/1000000-3), [value] "r" (value) ); }

Which part of this deals with the 88us break?

Thanks

Hi Soapdodger. I'm the DmxSimple author.

The section you quoted transmits a single byte - it does not transmit the break part. You're looking in the wrong place.

The break is sent in the dmxState==0 state of the TIMER2_OVF_vect interrupt routine. The code there isn't exactly the most hackable - its pretty bodgy there. I'll see what I can do to give you an adjustable break length.

By the way, excellent work discovering the break length problem. Makes fixing it a whole lot easier.

I believe this is the code in question. Basically increasing the number 35 to something longer in both places should increase the start break time. If 35 bits = 88us, and you need 500us, then roughly x8, i.e. (35*6=210).

if (dmxState == 0) {
      // Next thing to send is reset pulse and start code
      // which takes 35 bit periods
      uint8_t i;
      if (bitsLeft < 35) break;
      bitsLeft-=35;
      *dmxPort &= ~dmxBit;
      for (i=0; i<11; i++) _delay_us(8);
      *dmxPort |= dmxBit;
      _delay_us(8);
      dmxSendByte(0);
    } else {

here's what i found,

I tried 210 as suggested and found the LEDs wouldn't respond at all to that timing.

in fact from 420 - 130 I get no response at all

at 120 - 0! the LEDs exhibit the same behaviour as before, not working until plugged into another source of DMX.

the fact that things will work with a value of one points to something not being right!

I tried messing with the delay 4 - 16us worked as above, 2us corrupted the dmx.

I also tried 210 and 48us no joy there either.

Am I doing the right thing by just tweaking the bitsleft parameter?