Smart string programming ghosts - figured out - well aparently not - now I did!

[sielbear]

And what is your method of playback?

[zwiller]

I hope I am not jinxing myself but I too was having a real bad time and ready to scrap this year due to all the various issues with my ss gear.  I spent months (and a lot of dough) making elements, ssc's, etherdongle too...   I had trouble sleeping one particular night that I spent alot of time during the day with the issue and I stumbled across a thread which mentions that although the etherdongle firmware was revised earlier in the year the wrong version was posted to the web.  I kid you not at like 3am I reflash the etherdongle and test the particular strand that was giving me issues and worked perfectly.     I am not kidding when I say it was like a religious experience for me.  Ever since then the cards began to fall in my favor... 

Not saying this fixes everything but it made a HUUUGE difference for me and I am watching the ss threads like a hawk hoping to help anyone who is in a jam like I was. 

[lonewolf41]

"What is the end channel (and node) of that controller?"

The string/controller starts on channel 1973 and ends on 2299 (6069 & 6396 in Vixen).   It has 108 nodes.  I have it in hybrid mode.  When I program it, it is forward and I just leave the string @ 128 nodes since it should not matter in forward mode that thee are not that many nodes.

"And what is your method of playback?"

I am using Vixen.  I actually created a 25 second sequence that uses the two problem areas from the 2 sequences that act up and copied and pasted those sections into a separate sequence that I loop for testing in Vixen.

"I kid you not at like 3am I reflash the etherdongle and test the particular strand that was giving me issues and worked perfectly.     I am not kidding when I say it was like a religious experience for me.  Ever since then the cards began to fall in my favor...  " 

Well, I reflashed the ED @ lunch and everything is the same.  The file I used was called Etherdongle2.hex if I remember.  It had an August 2012 date which is about when I downloaded it from the wiki.  Does that seem like the correct one?  Is there another one out there to try?  Can I borrow, pay for, or rent one of these experiences?   

"I had one string do that last year."

Last year I ran in string mode and only had about 200 channels so no large channel counts last year. 

Any of this trigger anything? 

Thanks again,
-Keith

[rrowan]

Still trying to wrap my head around the details but this is what I am thinking,

I think there is an issue with the sequence and nothing to do with the hardware

SSC setup with hybrid mode. Nodes should be a color but are white.

If your channels below the 3 hybrid channels are set for a certain value but at the same time a hybrid is on with a very small value that you don't see it would give you the white value. White as you know is all the 3 rgb channels on.

So try this.  Go to the section where the nodes are suppose to be Yellow and make sure the Empty columns are zero value. Select the "empty" cells and either click the off button or space bar until they are off. Run the sequence and see if that helps some.

Of course its just my opinion and I could be totally off the mark

Rick R.

[lonewolf41]

I have definitely thought about the sequence and something on in the first 3 channels.  I have looked it over and don't see anything.  Plus, the fact that the first 24 nodes of the string behave correctly seem to contradict this being the cause.

I will modify my test sequence and use the "clear channel" function in Vixen on house 4 Red, Green & Blue hybrid channels.  This should help to make sure that I didn't miss something.  Something else I just thought of is I may even try another test and just delete the hybrid channels completely and reprogram the controller for pixel mode and skip hybrid to see if it makes a difference. 

Thanks for the feedback.  It does spur more things to try.

-Keith

[zwiller]

You might try programming for just 108 nodes instead of 128 too.  I swear I read you shouldn't do that.  Could the additional 20 channel info bounce back and cause an overlay on others?  OR maybe something to do with the combination of hybrid mode and 20 additional unused channels. 

Hope you have an experience like mine soon. 

[lonewolf41]

I think they were at some point programmed for 108, but just decided to leave them @ 128 since was not supposed to hurt.  Will try 108 again though.  Easy enough to do.

Thanks again,
-Keith

[lonewolf41]

OK, did a little more testing this evening and just discovered something.  I was using the test function in vixen and going through the different channels (string RGB, node1 RGB, node2 RGB, etc.) one at a time to see how they behaved and found something interesting.  Everything is going great, but when it gets to node 25 red (channel 6144) the node goes yellow...meaning that it is turning on both red (channel 6144) & green (channel 6145).  The rest of the string is off by one for the rest of the string.  So when node 25 blue is supposed to light (channel 6146) instead node 26 red comes on.  It is like it is dropping or loosing a channel.

Now the ironic part of this is that channel 6144 is exactly 2048 away from 4096.  That is exactly 4 DMX universes or 1/2 of a pixelnet universe.  That seems a little too coincidental for me.

I don't know how to fix this.  If it was adding a channel, I could just put a blank channel in and live with it, but by dropping it, even if I added 2 blank channels to shift the colors back to where they were supposed to be, I would have a node out.  In reality, that would be much better than it looks now so I may try that..although I haven't put much thought into this yet, that is just my initial thoughts...it may work out differently in reality.

So this seems to be the most important and relevant discovery at this point.

Thoughts???

Thanks,
-Ketih

[zwiller]

Glad to read that you're getting somewhere.  So that means that channels 6144 and 6145 are coded together, right?  Could be part of the old boundary pixel issue.  Ultimately, a revision to the etherdongle firmware would fix this...  I would like to think it would be an easy tweak.  Maybe RJ will comment.

I hereby declare channel 6144 the lonewolf channel.   

 

[lonewolf41]

Ok, i added two blank channels starting at 6144 and sure enough, node 25 only works on blue but the rest of the string is now the correct color during the chase sequences.  I think what I will do is since it is not too: far/many, I will just add about 80 blank channels before house4 and shift the entire string over the 6144/2048 barrier.  So it does look like either the ED or SSC is combining channels 6144 & 6145.

Thanks again for your support and help,

-Keith

[jnealand]

Very interesting point.  I just looked at my string layout where I have a similar problem and I am crossing the 2048 boundary in that string.  Goes from 1948 to 2324. Will have to check it out by going channel to channel like you did.

[zwiller]

I am happy you got this figured out, but now I'm confused.  I just checked my sequences and they all contain the problem channel/s but I have no problem...  Further, I went and checked all my elements per channel before I put them up.  Also my sequences are such that even one pixel off/out would stick out. 

At this point, if we're blinking good I wouldn't change anything but I am not so sure what actually is going on.  I don't think it's the ED firmware, maybe SSC/hub or vixen?

Also, I wonder if the other sequences that were ok will now be off? 

Either way, happy blinky!   

[fyb2000]

Mine are fine, but I might have gotten lucky. 6144 is actually the beginning of one of my controller, and it (and all the surrounding channels) behaves correctly. Using LSP (and just checked them using the tester in there).

[lonewolf41]

Not sure why it is doing this either, but at least i can deal with it now.  These are V3 modded controllers & firmware BTW.  I may try and reprogram another V1 controller on an arch and set it to start just before 6144 and see what happens with it.

Thanks,
-Keith

[chrisatpsu]

i would reflash the etherdongle with the firmware in the wiki regardless of what the file looks like.

The etherdongle seems to have had a boundary pixel issue in the past that i believe was corrected with the new/correct firmware in the wiki

the issues you are having is screaming boundary pixel issue, especially where you see it acting up at a dmx boundary.