LOR CTB16D run by DMX problems

[jcdammeyer]

1. LOR CTB16D Formware Rev 4.3 addressed at 1 runs from PC and show software

2. iDMX1000 runs a DMX lamp.

3. DMX system runs the same DMX lamp.

4. DMX system doesn't connect to LOR. I believe I have the pins correct on the custom cable. I'll check with a meter and scope right down to the RS485 receiver to make sure the correct signals are connected to the correct pins.

5. DMX system timing has:

a) Bit time 4uS

SPACE for BREAK is 174uS

c) MARK after BREAK is 14.4uS

d) Time between slots 4uS

Looking at the timing from the iDMX1000 it's a lot slower with a SPACE for BREAK time of 242uS and MARK after BREAK of 42uS plus inter slot time is 13.8uS including the stop bit.

I still need to make up a cable which will translate the XLR3 iDMX1000 to the LOR RJ45 pins. Theoretically the iDMX1000 should control the CTB16?

So before I spend hours trying to track down what may not be important can you give me a clue as to how LOR decides it's a DMX frame and whether it should make the RED led stop blinking?

Even though the DMX spec says the minimum time for the SPACE for BREAK is 92uS does the CTB16D need a longer break? Or a longer MARK after BREAK.

I have to demonstrate for the client that the concept will work.then his 500 DMX light strings will require 32 LOR1600W. Can you deliver that many in less than a month?

Thanks

John Dammeyer

[jcdammeyer]

Don't know if it's considered rude to reply to my own post but here's an update.

I now have the CTB-16D running lights from DMX-512A messages. After playing with timing a bit I made up a cable to go from my iDMX1000 to the LOR. The CTB-16D immediately started functioning.

A bit of timing analysis with the scope and changing one thing at a time showed that in order for the CTB-16D to function it needs time between each character on the order of about 14uS.

It also seems to like a SPACE for BREAK time of 240uS even though my ESTA document says that as little as 92uS is allowed.

It also likes a longer MARK after BREAK. In the order of 56uS even though the minimum is specified to be 12uS.

But it's the time between characters that is the real deviation from the standard. Instead of having an interrupt routine stuff a new character into the UART transmit buffer it's best to wait until the transmit shift register is empty (1 stop bit time) and then delay an extra 10uS. Once the DMX data stream has that delay built in it looks like the data stream from the iDMX1000 and the CTB-16D immediately sets it's RED led to solid on and accepts the values in the slots.

By duplicating the timing of what the iDMX1000 sends out I can make my DMX Master control the LOR CTB-16D. Having to cripple the UART byte level transmission code is really disappointing.

So to sum up. The CTB-16D with Rev 4.3 software does NOT meet the ESTA 1.11-2008 USITT DMX-512A standard.

John Dammeyer

[JBullard]

The current firmware for the CTB-16D is 4.32. It has been out for some time. Don't remember what the changes were from 4.30 to 4.32. Might be worth a test to see if upgrading the firmware will make any difference.

Also the current firmware for the iDMX is ver 1.41 Might want to check the iDMX also.

[jcdammeyer]

Rev 4.32 eh? OK. I'll download and upgrade. Same with the iDMX. Usually always best to have the latest revision.

I understand why they might have that delay between characters. They probably use a common output routine regardless of whether the protocol is LOR or DMX. And since they have bidirectional communications with the hardware the transmit shift register (TSR) has to be empty before they turn the bus around for receive. (Standard RS485 practice). Although normally you send a burst and wait for the TSR only on the last character.

It's also possible that the CTB-16D, in order to do everything uses the received character as a trigger. Then does a bit in between each of the characters but needs that tiny little bit of extra time so the iDMX1000 is set up to give it that.

I wonder how many other DMX masters do this?

[gizmomkr]

Wow-
Im pretty nerdy, and I think I fell asleep trying to read the posts above.

I dont have a 16d, but I have run other controllers off DMX consoles, and didnt have any issues.

I understand your statment, it doesnt meet the spec, but would again say "it works"

IF it works with 99.9% of the consoles out there, I dont see much point to the post, unless your just looking for someone to say "your right"

[jcdammeyer]

gizmomkr wrote:

Wow-
Im pretty nerdy, and I think I fell asleep trying to read the posts above.

I dont have a 16d, but I have run other controllers off DMX consoles, and didnt have any issues.

I understand your statment, it doesnt meet the spec, but would again say "it works"

IF it works with 99.9% of the consoles out there, I dont see much point to the post, unless your just looking for someone to say "your right"

I'm not even sure how to respond to your comments but I'll try to bring it down to your level.

That you can use DMX for your projects is because people put together standards so equipment from multiple venders can operate together.

Without those standards it's a gamble as to what works and what doesn't. You have been able to take advantage of the work of many others for very little expenditure I suspect. Standards are why the 5 pin XLRs work between venders. That's why DMX RJ45 connections work together but don't work with LOR RJ45. They have different standards and you need an adaptor.

Great that you've been lucky so far.

Making a blanket statment like "99.9% of the consoles out there" suggests you are being argumentative. I doubt you have the required education or knowledge as you've already written that you didn't understand the earlier postings.

So if you can't contribute something constructive in place of being insulting please just leave the Post Reply button alone. All you are doing is demonstrating your own ignorance and now you've let everyone knows this.

[Donny M. Carter]

A man wrapped up in himself makes a very small bundle.

~Benjamin Franklin

[jcdammeyer]

My applogies if you feel I've insulted you. I was reacting, obviously badly, to someone who told me I put him to sleep with my request for help and then my subsequent discovery and response. And then he inferred that the only reason I was posting was to have someone say "you're right". His words.

I posted to the DMX part of the forum since that was where I was having problems. Not the "how to put lights on the house and make them flash" section.

I started off the thread with a request for help. I continued my research and then 12 hours later posted what I found. Since LOR represents their product as being compatible with DMX 512 and I found it wasn't, I reported that as any responsible person should. I also reported the solution.

As for being an internet bully. The tone of your response surprises me. I feel quite intimidated so if that was your intention then you have succeeded. If this was the wrong thread please tell me which one is the right one rather than just telling me to go away.

Again, my appologies for offending you.

John

[jeffl]

John,

I would contact LOR directly as you have the ability to supply them the data they would need. Another resource that seams to be a DMX expert is Crag, "VetteNut72". I'm not sure who Craig is affiliated with so he may or may not be able to help.

[gizmomkr]

My response of "falling asleep" was purely and simply meant as humor. I think its a fine way to joke that your interests and analysis go beyond that of thegeneral hobbiest, but I certinaly did not intend it as an insult.

My contribution was to say " I have not had problems using a variety of DMX consoles talking to LOR controllers. Maybe someone else would read that, and say they had an issue... and if they did, im sure they would love to hear about timing and mark and breaks.

I suppose I'm defending the controller by stating "it works for me" because you seem quite upsett "Having to cripple the UART byte level transmission code is really disappointing."

You never really go into detail of your "DMX System", but since you were able to make the timing adjustments (although you clearly feel them un necessary) I would further assume whatever is sending your DMX signals is of your own design. Maybe someone else using a PIC or Microcontroller would want to comment on that.

I enjoy sharing my experiences and helping others. I appreciate that many problems can be solved different ways. I dont need to question anyones education to converse with them. Something I love about LOR is it takes something that would traditionally require a strong background in Software, Electronic controlls, Computers, Etc - and It opens this up so that "the average Joe" can make something magical.

What more can I say : I like the blinky lights.

[jcdammeyer]

Giz,

So let's clean the slate and start over.

I have several different DMX drivers here of my own design. I bought the spec from ESAT for both DMX and ACN/E1.31 (Ethernet) and have the gear to be able to analyze the messages quite accurately.

I was frustrated that I could connect a lamp (again of my own design) to the iDMX1000 and have it work like a charm and also have my PIC32 based ACN E1.31 to DMX module run the lamp without issues certainly placed the problem with the 16D.

That's why I was eager to receive the DMX transmitter from j1Sys. It also uses a PIC32 for the Ethernet side and has 4 smaller 8 bit PICs to generate the DMX messages. Alas, emails to j1Sys go unanswered so I don't know if their unit has ever run an LOR 16D.

But the mail is slow and I hadn't seen an answer yet from any LOR people that I had hoped were monitoring the forum. So I analyzed the DMX signal from the iDMX1000 and duplicated them one step at a time.

I searched for a document and postings on this subject in all the forums and the user manuals. Unfortunately LOR isn't very verbose on the subject. And again perhaps rightfully so. If they publish the timing they give away what costs $40 from ESAT and probably violates a copyright.

I have no idea on the qualifications of the people monitoring the DMX threads. I was assuming that there was the complete range of folks with absolutely no electronics background just having fun blinking lights but I also assumed that there might well be some really technical folks who have some DMX stuff from various companies and some that they have built from scratch. Some who had run into the same problem I have.

After all, Elektor Magazine published in Europe and (now owner of Circuit Cellar Magazine) has published numerous articles on DIY DMX lamps over the last few years. The amount of LED stuff has dramatically increased in the two years since I bought my LOR stuff and put blinky lights on my house. I have this box of plastic Santa Claus figures that I want to retro fit with RGB LEDs so they can be different colours.

Alas, last year we did a kitchen reno and acquired a new puppy so the house was dark over Christmas. Now This year I'm using even more LEDs and fixtures for which I've written DMX code. Same processor as in the 16D and it didn't need the DMX byte stream to be slowed down.

So again my appologies. Unfortunately I took your comments the wrong way and reacted badly proabably due to my frustrations with the problems I'd had and the time I'd wasted.

Cheers,

John Dammeyer

P.S. my desire to use Ethernet and E1.31 comes from a USB bottleneck for getting lamp information down to the hardware in a timely manner while trying to update 3710 channels at 25Hz.

[gizmomkr]

Thanks,

Olive branch accpeted, and extended back.





The background helps a lot - I understand what your trying to do, and 3,710 is a hefty channel count.

I make no claims to be a protocol guy - I'm not, so I dont have much to offer in that area. But I have used a lot of commercial DMX hardware over the years. I worked for a sizeable AV Production house. We had fixtures from Thomas Engineering, Robe, Elation, Chauvet... The list goes on. Our primary show control was HOG PC, but we also had a handfull of consoles

I have used the Arduino DMXShield, but never with LOR. I have met Ed Bryson, and I love his products. He is a verry talented engineer, and I'm really looking forward to E1.31 coming to LOR. Ed talked alot about design of the boards and the PIC to offload the DMX processing. It sounds like great stuff, I just cant use it yet.

One final note on the protocol. I know there are many EE's that doo have a higher level of interest and understanding than I. There is a great deal of respect over the LOR protocol here. Clearly there are those that can decipher the code, but thats not discussed on these boards - not to say that talk of straight DMX protocol isnt welcomed (it is) but with respect to LOR devices, that could be a fine line.

I'm sorry I dont have more to offer on the technical side of your issue, but I'm glad to see you got it worked out.

3710 channels must make for one hell of a display.

[jcdammeyer]

Hi Giz,

The 3740 channels comes from 748 lamps each with RGB & W LEDs with an additional group Intensity value. The group intensity allowed setting a specific RGB colour and then dimming it without a colour shift. Say you have R=255, G=128 and B= 32. After 32 steps of dimming it now becomes R=233, G=96, B=0 which is a totally different colour. We designed White LEDs into the clusters of RGB LEDs to avoid the rainbow effect because the LED light isn't coming from exactly the same place.

That issue is even more visibile with 3 strings of RGB Christmas LEDs wrapped together to try and also make white light. From many angles it will appear weighted to one of the other colours. Plus, one single White LED also resulted in much lower power consumption. Even the combination RGB LEDs like in the CCR or other light tapes have a tiny bit of that. It's too bad that the LED manufacturers don't put a white LED die into the RGB LED packages but there I'm being picky.

The refresh rate was 24Hz to match the cine fim camera frame rate which can be translated without flicker to either 50Hz or 60Hz television (International viewing market). There's a still photo in my profile and a link to a video here: This one was run with two USB ports that just mirrored the show information to 1496 lamps with a total of 7480 channels. (53,856 LEDs hand assembled into boards over a 2 month period)

Alas the client wasn't interested in synchronizing to music so the FM transmitter we purchased was never used. Nor were they interested in us showing any candy cane or other Christmas oriented colours or shows during December.

Now the lamps are being repurposed into Christmas lights etc.

John

[LightORamaDan]

jcdammeyer wrote:

1. LOR CTB16D Formware Rev 4.3 addressed at 1 runs from PC and show software

2. iDMX1000 runs a DMX lamp.

3. DMX system runs the same DMX lamp.

4. DMX system doesn't connect to LOR.  I believe I have the pins correct on the custom cable.  I'll check with a meter and scope right down to the RS485 receiver to make sure the correct signals are connected to the correct pins.

5. DMX system timing has:

 a) Bit time 4uS

  SPACE for BREAK is 174uS

c) MARK after BREAK is 14.4uS

d) Time between slots 4uS

Looking at the timing from the iDMX1000 it's a lot slower with a SPACE for BREAK time of 242uS and MARK after BREAK of 42uS plus inter slot time is 13.8uS including the stop bit. 

I still need to make up a cable which will translate the XLR3 iDMX1000 to the LOR RJ45 pins.  Theoretically the iDMX1000 should control the CTB16?

So before I spend hours trying to track down what may not be important can you give me a clue as to how LOR decides it's a DMX frame and whether it should make the RED led stop blinking?

Even though the DMX spec says the minimum time for the SPACE for BREAK is 92uS does the CTB16D need a longer break?  Or a longer MARK after BREAK.

I have to demonstrate for the client that the concept will work.then his 500 DMX light strings will require 32 LOR1600W.  Can you deliver that many in less than a month?

Thanks

John Dammeyer

Our controllers follow the DMX standard so if the signal sent to the controller follows the standards then it will work.

I do not have any information about specific minimum or maximum values.

Dan