How many commands can I send 'at once'?

[beatnavy77]

[side Q: is anyone else having trouble 'pasting' content in the compose window?  I drafted this in Notepad but had to retype it all inside this window because 'paste' isn't working.]

 

Can someone provide info on the communications protocol 'on the wire'?  I'm interested in predicting the theoretical limit on how many commands can be transmitted in a set amount of time.

 

In particular:

- How many bits are required to send an on or off command?

- How many 'channels' are used to transmit on the wire?  i.e., when 8 bits is sent down the wire, are there 4 wires used to transmit 4 bits at a time, or is there just a single transmit wire so the 8 bits must be sent sequentially?

- Are there any situations where multiple commands can be grouped (i.e., on controller 1, turn on channels 1, 4, 7, 10, 13, 16, 19, and 22)?

- Is this a one-way protocol or does the receiver need to acknowledge receipt of the command?

 

If you don't like math, you may want to skip the next paragraph ...

 

Let's suppose the answers to the above ar "32 bits, one transmit wire only, no command grouping, and one-way protocol."  In that case, given a 500K network, ignoring minor transmission latency, a single command should take 32/500,000 = 0.0001 seconds.  So if trying to transmit commands to each of 8 CCB/CCP/CCR strings, which would amount to 8 x 150 = 1200 channels, to issue an on or off command to all 1200 channels (assuming no gaps between commands) it would take 1200 x (32/500,000) = 0.0768 seconds.  That is about 1/13th of a second, which I believe makes a significant and unacceptable visible delay between the first change and last change, so these would not appear to occur simultaneously.

 

Ultimately, I'm trying to determine how many events I can expect to occur at virtually the same time and keep the delay small enough to not be noticed.

 

Yes, I realize I can set channel 151 to '1' and control all 50 bulbs with a single RGB channel, but there are times when I'd like to display two colors on every other bulb (e.g. bulb 1=red, bulb 2=green; or alternating blue and green; or perhaps alternating magenta and white) and the only way I know of to accomplish that is to control each channel individually (feature request for a future firmware update?).  Things get even more busy when I want to rotate the colors on each bulb that would require commands on all 150 channels per string (i.e. bulb 1: turn red off and green + blue on; bulb 2; turn green off and turn red + blue on).

 

500K is far better than 57.6K, but will still have limitations.

 

Thanks.

 

[bbayjohn]

Let me tackle the first paragraph. To paste into the text command window you first need to activate the little button in the top left. Its right next to your avatar. It's above the B (Bold) and to the left of remove format.

 

I will let someone more technical savvy answer the second part to your question.

[bisquit476]

The LOR protocol is proprietary to LOR, and unlike DMX (which send's the full packet multiple times a second), LOR only sends the signal when changes occur. As far as the rest of your protocol questions, I have no idea.

[LOR Staff]

Our protocol is adaptive in that it sends different packets depending on the current state of the channels on a particular station.  We have several different packets that can be sent depending on which is the most efficient at that particular time.  We send different packets based on the type or age of your controllers.  We have different packets for legacy and extended addressing.  We 'compress' commands where possible, eliminating duplicate or commands that simply can't be seen by the human eye.  We also don't guarantee any particular order commands will be sent in, so 2 identical runs can produce 2 different outputs depending on how things compress/etc.

 

In other words, it is impossible for you to know exactly how many bits we are sending for any one particular time slice.

 

At 500Kbps, you can send 500,000 bits per second.  Every byte consists of 10 bits, so you can send 50,000 bytes/second.  But without being able to compute the amount of data we are actually sending, that won't do you much good.  Bandwidth is always limited.  If you need more than 500K, you can always add another network (up to a total of 16).  Once you get to that much data, you are probably going to switch over to something like E1.31.

[beatnavy77]

Thanks for the tip, bbayjohn -- that worked.

And thanks, DevMike, for the explanation. It would still be nice to know worst case, the max number of bytes it would take to send a single on or off command, but I understand why LOR may not want those details known.

There is another way I could get what I need with fewer commands, but it would take a firmware update. This may not be feasible for any of a number of reasons, but I figure it can't hurt to suggest the following new feature:

As mentioned earlier, there are a number of times when I want to display alternating colors on a CCB/CCP/CCR string. For example, perhaps I want alternate green and red. Or maybe I want red/white/blue every 3 bulbs. I have a feeling I'm not the only person that does this. It would be great if LOR could come up with a new set of modes (I'd suggest using the Logical Resolution settings on channel 151) allowing for nine values (say 52 through 60 if on channel 151) that would result in the following:

If set to 52, the first 2 RGB groups would be repeated throughout the entire string:

- Channels 1 to 3 commands would be applied on 7-9, 13-15, 19-21, etc.

- Channels 4 to 6 would also apply on 10-12, 16-18, 22-24, etc.

if set to 53, the first 3 RGB groups:

- Channels 1 to 3 would also apply to 10-12, 19-21, 28-30, etc.

- Channels 4 to 6 would also apply to 13-15, 22-24, etc.

- Channels 7 to 9 would also apply to 16-18, 25-27, etc.

and so on up until 60, where the first 10 RGB groups would be repeated. Or you might take it all the way to 75 (for 25).

If I didn't explain this clearly enough, please ask for clarification.

Either way, thanks for listening.