DMX Output Shifted +1 Channel in LOR 3.0.2

[dmoore]

VetteNut72 wrote:

So, let me make this clear. The problem is not in S3, but in the aftermarket hardware (dongles), This could also mean that protocol was not adheared to in many DMX implementations out there now. Why would LOR want to include support for a piece of hardware that does not conform to the standard? IMHO, I would get an Entec and use LOR software



Craig

Again, there are no protocols in these controllers - they are just devices that take data in and output data. Can you explain, technically in such as way as to be understood by a lay person, what you are saying about "shifting" of the address?

[jeffl]

I'll play the lay person.

I question if all the dongles are dumb, a USB485 probably. A Lynx Dongle I'm not sure is dumb. A Lynx splitter I would say is dumb as it has no PIC. I thought I read somewhere that the dongle might read the incoming data and regenerate the data before sending it on.

If the dongle regenerates the data improperly, I could understand how they could produce this kind of activity.

[dmoore]

jeffl wrote:

I'll play the lay person.

I question if all the dongles are dumb, a USB485 probably. A Lynx Dongle I'm not sure is dumb. A Lynx splitter I would say is dumb as it has no PIC. I thought I read somewhere that the dongle might read the incoming data and regenerate the data before sending it on.

If the dongle regenerates the data improperly, I could understand how they could produce this kind of activity.

I'm completely aware that the Lynx/Enttec Pro dongle "knows" about DMX, since it constantly repeats the DMX data stream. So, those dongles not only work at the RS485 layer but also one step up in the DMX protocol.

What I'm have a problem understanding, at a technical level, how these "raw" or "dumb" devices such as the LOR adapter, the dLight adapter, the RS485 adapter I sell, etc, etc know ANYTHING about DMX, LOR. MODBUS or any other protcol that runs over them. Their job is simply to take a stream of data from the host over the USB port and then output that data as a RS485 steam. All the timing and format is COMPLETELY in the host PC. So, it would appear that if anything is "offset", that would be a function of the host (LOR S2, LSP, xlights, vixen, etc).

Since this requires some effort - I'll give $50 to the first person that can layout the technical reason (and provide data that proves it) why these adapters work with other applications but not with LOR S3 and show where this "shifting" is occuring as a result of the hardware (or lack there of).

Thanks,
David

[jeffl]

What 485 adapter are you using to test? Last night I tested the LOR USB485B adapter sending DMX out of S3 and this adapter works properly.

[VetteNut72]

I'm going to keep this simple. I am going on what was said here and what the creator of this thread wanted to know.

The problem could originate at the dongle if it was set up improperly or in the controller software sending data to it.

Get an Enttec and S3, problem solved.

No, I'm not giving away how I do it because my handlers are tested and proven and know how to use the DMX/RDM protocol correctly. Tell your designers to get the data stream correct I have already given a hint to where I think the problem lies, I'm not going to make it any easier

I just read a few posts back that someone said the lynx dongle generates it's own data stream - - - - BINGO!! Read the DMX and RDM standards and fix the datastream So it does generate the DMX frame and therefore does deal with protocol. I wish some would get their facts together before they start an arguement with a hardware designer...


One good thing, pay yourself the $50 as you answered your own question


Craig

[dmoore]

I *am* the creator of this thread.

Craig, I want to thank you for your extensive assistance in helping bring this toward a resolution. I guess xLights, Vixen and LightShow Pro must just have it backwards. I just want to be able to provide my customers, which are also often LOR customers, more options with the least amount of hassle. I'm sorry if you don't agree.

Those with nothing to hide, hide nothing.

If there is anyone else that has the technical (not the trust me, I'm smarter than you'll ever be type) knowledge here, my offer still stands.

Thanks!
David



VetteNut72 wrote:

I'm going to keep this simple. I am going on what was said here and what the creator of this thread wanted to know.

The problem could originate at the dongle if it was set up improperly or in the controller software sending data to it.

Get an Enttec and S3, problem solved.

No, I'm not giving away how I do it because my handlers are tested and proven and know how to use the DMX/RDM protocol correctly. Tell your designers to get the data stream correct I have already given a hint to where I think the problem lies, I'm not going to make it any easier

I just read a few posts back that someone said the lynx dongle generates it's own data stream - - - - BINGO!! Read the DMX and RDM standards and fix the datastream So it does generate the DMX frame and therefore does deal with protocol. I wish some would get their facts together before they start an arguement with a hardware designer...


One good thing, pay yourself the $50 as you answered your own question


Craig

[VetteNut72]

Really, you created this thread ??? "WOW". I didn't know that.......

David, I have nothing to hide, just have no information on any of the products that you mention. I didn't know that some aftermarket dongles create the data stream. This has absolutely nothing to do with the software packages you mention so another moot point. I told you where the problem lies several posts ago as did others.

BTW: Does your commitment to your customers include selling them hardware that does not conform to communication standards? Do you think LOR customers appreciate this and might want to take this into consideration when they consider spending their hard earned money? And then trying to make it look like an LOR problem, I think you have been hiding many things David

Trust me, I'm not smarter than you will ever be on most things, just this one - Product Development.... And you know I am covered by an NDA so using that aginst me does not show the best character on your part. And, BTW I agree with commitments and this hobby more than you could possibly even understand....

Have a nice day....
Craig

dmoore wrote:

I *am* the creator of this thread.

Craig, I want to thank you for your extensive assistance in helping bring this toward a resolution. I guess xLights, Vixen and LightShow Pro must just have it backwards. I just want to be able to provide my customers, which are also often LOR customers, more options with the least amount of hassle. I'm sorry if you don't agree.

Those with nothing to hide, hide nothing.

If there is anyone else that has the technical (not the trust me, I'm smarter than you'll ever be type) knowledge here, my offer still stands.

Thanks!
David

VetteNut72 wrote:

I'm going to keep this simple. I am going on what was said here and what the creator of this thread wanted to know.

The problem could originate at the dongle if it was set up improperly or in the controller software sending data to it.

Get an Enttec and S3, problem solved.

No, I'm not giving away how I do it because my handlers are tested and proven and know how to use the DMX/RDM protocol correctly. Tell your designers to get the data stream correct I have already given a hint to where I think the problem lies, I'm not going to make it any easier

I just read a few posts back that someone said the lynx dongle generates it's own data stream - - - - BINGO!! Read the DMX and RDM standards and fix the datastream So it does generate the DMX frame and therefore does deal with protocol. I wish some would get their facts together before they start an arguement with a hardware designer...


One good thing, pay yourself the $50 as you answered your own question


Craig

[jeffl]

Although it seams like overkill, curiosity killed this cat. I took the advice and an Enttec Pro is on it's way. I hope to be spewing DMX without worry this year.

Of course I'm going to test cheaper options to see if they work the same for fun.

[mschell]

I certainly don't want to re-open this can of worms, but I'd like to understand why some of the "dumb" dongles don't work either.

For the Enttec DMX Pro, and Lynx dongle, and the DIYC RPM dongles, there's a PIC that does the timing and generates a "valid" DMX packet.

For the Enttec DMX Open, the LOR RS485, and dmoore's programmer dongle, it's the driver in the PC that generates the datastream - the HW just does a level conversion from the USB serial input to RS485 output.

So my guess is that whatever driver is being used has to interpret the serial stream, including break characters or pad characters or whatever to correctly build a DMX packet. It may be that the driver chosen or automatically installed for the FTDI USB interface could be different between the LOR dongle and others. Given that the USB VID/PID can be different, a different driver could get loaded for each, and if the driver doesn't send out the right bits at the right time, then the DMX output will be wrong.

It could be an interesting experiment to "patch" the driver that comes with the LOR dongle to get loaded for another USB dongle and see if the behavior is different.

I believe the start of the DMX packet is a "break" signal of a specific time, and then the data starts a certain time later. If the timing is off, then the target DMX device may not "be listening" soon enough for the first channel data, and so starts responding to the channel 2 data as if it were channel 1. This also means that the device at DMX channel 512 may not respond to that channel's data value.

Again, whether it's the driver at fault, or something in the dongle that alters the timing, you can't fault S3 too much.

[dmoore]

mschell wrote:

Again, whether it's the driver at fault, or something in the dongle that alters the timing, you can't fault S3 too much.

That's why instead of the guessing that has been going on, someone with the actual skills (and I know they are here) neccessary can capture the data at the different points and determine where the shifting is occuring. I'm not trying to blame anyone or anything here - I just would like to technically understand the root cause so that end users have as many choices as possible.

Thanks,
David

[VetteNut72]

Yes, they are here David Do the people that engineer and develop GM vehicles have no skill because they won't disclose the particulars of the way, lets say ONSTAR works ?(this is just an example). Your 'assumption' that the answer is not known is just that, an assumption. You can bring in all the 'experts' you want and that will never change till YOU fiqure out the answer.

Your assumption that some have no skill just because they won't tell you what you want to know, and for good reasons, is IMHO, ridiculouse. If I was a DIY user like you and others in this thread, I might discuss it however, I am an actual product designer with many, many products that I fully designed that are on the market and running for years. Since this is an LOR board and all is fine in the LOR world, I suggest you take these discussions to a DIY board or get the answer from your 'designers'.

dmoore wrote:

mschell wrote:

Again, whether it's the driver at fault, or something in the dongle that alters the timing, you can't fault S3 too much.

That's why instead of the guessing that has been going on, someone with the actual skills (and I know they are here) neccessary can capture the data at the different points and determine where the shifting is occuring. I'm not trying to blame anyone or anything here - I just would like to technically understand the root cause so that end users have as many choices as possible.

Thanks,
David

[jeffl]

David,

Can you post a link to the dongle(s) or piece of hardware that your having trouble with?

[dmoore]

3.1.2 still does not fix "other" RAW adapters but it does add support to shift the address on Lynx controllers.

http://forums.lightorama.com/forum55/29388.html

[JonB256]

I just ran a test (at another user's request) of how the USB/RS485 Dongle did. This is not an LOR dongle, though. It is the D-Light version. Still uses the FTDI drivers, though there are some internal firmware differences.

The D-Light Version 3 dongle did not suffer from the channel count shift (using RAW).

I even tried a Version 2 dongle and it worked without the channel count shift.

My output controller was a Lynx Express (because it has channel LEDs, making it very convenient).

Is it possible that some controllers are affected when others are not?

[VetteNut72]

It seems like this is getting drawn way out to a point where it is getting old.

Let's look at the facts and apply some logic here.

The commercial enttex raw adapter works, the LOR USB485B works, LORs3 works and multiple products, tried tested and true products and devices also work. LOR included a patch to allow the Lynx adapter to work most likely by having S3 clean up the adapter's output and 'help' it conform to the standard. It was nice that LOR did that but they didn't have to. And let's see, doesn't the problem always show up when a non-LOR dongle or DMX source is thrown in the mix.

Looks like the problem is in other hardware and software and these developers need to address this issue now before it gets worse (and it will, trust me) in the future.

I have developed some DMX handler routines myself and many, many are out there operating for years. My routine adhears to the standard and works just fine and Dan has stated that LOR controllers also conform 100% to the DMX standard. Stick with LOR and you can be assured that everything will work fine when you hook it up.

Hope this helps keep things straight.

Craig

[dmoore]

Bob has received the other RAW RS485 adapter and is looking to make an update to LOR S3 in the future to work with these adapters so this should resolve the issue for any adapter that is "shifted".

[jeffl]

There is no question that many of these adapters appear to be non-compliant and should be. The point that most are trying to make is that other software packages seam to work with them all so LOR should as well. It's not right, just the way it is.

Unfortunately LOR will be put in a position to try and conform. Given their level of service, I'm sure they will do their best to please as many people as possible.