Avoiding dimmer levels 125, 126, and 127

[xmus]

http://www.christmasinshirley.com/wiki/index.php?title=Renard#Number_of_Circuits_.28Chann els.29

I'm finally taking some time to read through wiki, and I'm amazed at the data that has been collected. This project has come a long way since the last time I checked in back in early 2007, i can't believe how this community has come together to get such excellent documentation together. (I even stumbled across an assembly document in Wiki that I was completely unaware of, for the XMUS board! Nice job wjohn and tconley, i wish i knew that was there, i would have put my effort there, and not into a separate document! But that is my fault, not yours, i wasn't tracking real good through the summer)

So onto the dimming levels 125/126/127.....
What steps have been taken to avoid these dimming levels?
Is it up to the end user to not use them? That could get complicated in sequencing, especially for ramps/fades. Perhaps the Renard driver could do away with them? The number of channels per serial port can be DOUBLED if those codes are avoided........ that is pretty impressive, and worthy of some effort to avoid, even if it boils down to manual sequencing to avoid them I suppose, but it would sure be nice if they could be avoided all together.

I could write a Perl script to post process a vixen sequence and change all 125 and 126 events to 124, and all 127 events to 128. That would do it.... I wonder if the result would be visibly noticeable.

It would be nice if we could somehow automate a feature to correct this for all....

[BillAd]

Dave,

Good thoughts. What about a change to the Renard Plugin to alter these values directly?

Bill

[RavingLunatic]

I believe that Phil was asked that question a bunch of times (maybe 1 too many based on the reply I got) during the Renard development phase earlier this year. I believe (could be mistaken) that his mindset was to have the Renard give complete/smooth dimming at all intensity levels like the commercial counterparts.

Now that the Renard design is "out in the wild" and spreading, I think the users who are worried about channel count should experiment with those values and see if they feel that skipping those values causes a noticeable change during dimming.

If the community (or large enough segment of it) want to skip those values to get a larger channel count then maybe a second Renard plug-in (Renard-LrgCnt) could be created that automatically changed those values. {Probably too late in season to be done now}

Doing it in the plug-in would be preferred (I believe) to an external app so that changes could be made on the fly and quickly seen in the previewer.


Just another 2 cents....

[P. Short]

Actually, it's trivial to do, and would take only a few minutes.

However, I'm holding off because I don't want to step on KC's toes. There also needs to be discussion about the issues that could arise if multiple people are writing and/or distributing plugins.

--

Phil

[tconley]

Couldn't you just make it another flag in the fireware to supress those values.

[xmus]

I see.... It really does seem very reasonable to do this in the plugin.... Buy I can see both sides..... I wish there was some way I could just knock out the work, compile the plugin, and not burden others though.... Or someway to "repay" the effort, you know?

[JohnByrne]

For those of us with less experience what exactly does this mean?

[xmus]

For those of us with less experience what exactly does this mean?


start here
http://www.christmasinshirley.com/wiki/index.php?title=Renard#Number_of_Circuits_.28Chann els.29

read the number of channels discussion (i assume written by phil, but I don't know that).

Then we'll bring you up to speed further if needed.

[holtm]

Maybe the current plugin could just have an option (I'm thinking check box next to the protocol list) to to avoid these special values. That would be one less plugin.

[xmus]

I'm dreaming of the following:

People download activeState perl for free (to a windows based computer).
they run a perl script that takes the name of the *.vix file as an argument (from the command line).
They get a report that says "Ch 4 time 3:20:025 = 126
They go back and manually fix the problem.
If you hover your pointer over any "square" in vixen, just below the "Row zoom" dialog box, you will see the intensity of that channel.
So with the laundry list of problems, you could use that intensity feature to pinpoint the problems, and manually assign new intensities.

However the intensity is reported as %, so you would be looking for something like 49% to 50% I would guess. And rounding errors make this interesting too.... With a resolution of 255 bits, loosing a couple of intensities is trivial, but with a resolution of 100 bits, loosing 2 bits is 2.5 times LESS trivial, add rounding errors....

That is totally doable with several hours of perl programming. However we would need to try it, and see if you could visibly detect this in a sequence that is forbidden from using intensities 49 and 50%.

[njamateur]

[quote="xmus"]http://www.christmasinshirley.com/wiki/index.php?title=Renard#Number_of_Circuits_.28Chann els.29

So onto the dimming levels 125/126/127.....
quote]

Sorry, but I have to ask:
What is the 125, 126, 127 issue?

I am sure this has been discussed but a search doesn't offer the reason.
I did find one thread:

"125, 126,127 issue, where two bytes are sent via the serial port to do a single channel rather than one, I had "too many" (in the worst case, not the nominal case) channels on a serial port, so when ramping, I had to manually remove instances of 125,126,127 and replace them with 124, and 128 (respectively?). If I had simply used 50mS I could have avoided that all together."

As I recall 1 byte gives you 256 00-FF levels
Why does 125-127 require two bytes?
If I use 50 ms for my interval does the 125, 126, 127 issue go away?
Why?

Thanks,
Mike

[xmus]

Sorry, but I have to ask:
What is the 125, 126, 127 issue?
Mike

http://www.christmasinshirley.com/forum/viewtopic.php?t=921&highlight=125

[xmus]

If I use 50 ms for my interval does the 125, 126, 127 issue go away?


I can't answer why the feature is there, I just know that it is....

It does not go away ever....

[P. Short]

OK.

Warning...moderately technical talk.

I needed a character to use as a start-of-frame marker, and somewhat whimsically chose 126 (0x7E) because it is the same as the frame delimiter sequence in HDLC.

Then, I needed a way to send a dimmer level in case the user actually wanted that brightness. So, I used the old technique of encoding the extra value(s) as two-character sequences, with one character (0x7F) chosen to indicate the start of each two-character sequence. If the user wanted a brightness level of 126, vixen would actually send two characters (127, followed by 48 = 0x30), and if the user wanted a brightness level of 127, vixen would send 127 followed by 49 = 0x31.

Now, one last problem. If the baud rate on the PC with vixen is slightly faster than the baud rate on the PICs, there would be a problem. The Renard PIC would be able to receive the data OK, but would have problems re-transmitting the data (the transmitter wouldn't be able to keep up with the receiver, and data would be lost). The solution to this was to select 125 as a PAD character. Vixen was supposed to transmit it every so often, but the Renard firmware was to ignore it. This would create a gap in the data that Renard was transmitting, so that the transmitter could catch up with the receive data if the PIC baudrate was just a tiny bit too slow. And, of course, an actual 125 dimmer level code now needs to be sent as a two-character sequence.

So that is why these three codes are special. They could have been any three codes, but I somewhat arbitrarily chose these three.

--

Phil

[xmus]

Wow, I'm really amazed ad how robust your code is.
I'm sure glad you released the beta plug in that kills the double length transmissions, so we can (in the worst case) double the number of channels in use! I can't see any difference (even on really really slow ramps/fades).

[RocketRick]

OK.

Warning...moderately technical talk.

I needed a character to use as a start-of-frame marker, and somewhat whimsically chose 126 (0x7E) because it is the same as the frame delimiter sequence in HDLC.

Then, I needed a way to send a dimmer level in case the user actually wanted that brightness. So, I used the old technique of encoding the extra value(s) as two-character sequences, with one character (0x7F) chosen to indicate the start of each two-character sequence. If the user wanted a brightness level of 126, vixen would actually send two characters (127, followed by 48 = 0x30), and if the user wanted a brightness level of 127, vixen would send 127 followed by 49 = 0x31.

Now, one last problem. If the baud rate on the PC with vixen is slightly faster than the baud rate on the PICs, there would be a problem. The Renard PIC would be able to receive the data OK, but would have problems re-transmitting the data (the transmitter wouldn't be able to keep up with the receiver, and data would be lost). The solution to this was to select 125 as a PAD character. Vixen was supposed to transmit it every so often, but the Renard firmware was to ignore it. This would create a gap in the data that Renard was transmitting, so that the transmitter could catch up with the receive data if the PIC baudrate was just a tiny bit too slow. And, of course, an actual 125 dimmer level code now needs to be sent as a two-character sequence.

So that is why these three codes are special. They could have been any three codes, but I somewhat arbitrarily chose these three.

--

Phil

One issue that comes to mind: by having all three special codes "next to" one another, you have a comparatively large "gap" to skip over if you wanted to avoid using them (to avoid the extra bytes and reduced number of channels). This might theoretically show up as a discontinuity in the dimming. Also, using "escape" codes leads to non-deterministic timing, depending on the exact data to be transmitted.

I see two (relatively) simple options for regaining determinism in timing while avoiding discontinuities in dimming levels:

1) Restrict the valid dimming levels slightly: Set (for instance) 0 - 253 as valid dim levels (with even timings from off to full on), and use 255 as start of frame and 254 as padding. That way, you get 254 levels of 100% smooth dimming, and your frame start and padding bytes don't cause any dimming levels to need "escaping".

2) Reduce throughput slightly by encoding multiple bytes in slightly more bytes, reserving the high order bit to signal "special" bytes. As an example: 7 bytes of "real" data is 56 bits. That same 56 bits can be encoded in the lower 7 bits of eight bytes, each of which has a "0" in the MSB. Bytes with a "1" in the MSB are used for special purposes, such as indicating start of frame, padding, and whatever else you feel like using them for in the future (CRC or checksums?). Encoding 7 bytes as 8 costs you just 12.5% in data rate, but guarantees that the rate always stays constant regardless of dimming levels.

At 57600 bps, you're looking at a raw data rate of 5760 bytes per second, or about 144 bytes per 25 mS period. With the "standard" plugin and firmware, you're looking at a maximum worst-case of about 72 channels, as each channel might take 2 bytes.

Using method 1, you get about 144 channels, each of which supports 254 dimming levels.

Using method 2, you get about 126 channels, each of which has a full 256 dimming levels.

(I say "about" because I'm neglecting the start of frame and padding bytes. Real-world numbers will need to subtract a channel or two to cover this overhead.)

Just a few ideas....

- Rick

[Virtus]

This might theoretically show up as a discontinuity in the dimming.
- Rick

If you can see it (even on the slowest ramp/fade) you have some pretty amazing senses. I tried and could not even detect anything changed...and yes, I did make sure that something actually had! :)