sticking/stuck channels

Message Topic Search Topic Options Post Reply Create New Topic Printable Version

For you - what's keeping you on .69?  Why not go back to .41?

For the issue - I assume the lost ID are confirmed by using the Discover Units in the DL Utility, or by commanding a chase to a specify ID in the DL Utility and not seeing anything?  Do they reset to a value or just have no ID?  What would you estimate the total cat5 length?  I assume the sequences have changed since last year, so that clouds the issue a bit when comparing year to year.

An interesting test would be to assign all controllers the same ID, then compare behavior differences down the line.  Stuck channels....?  That's a bit of work for one test, but could let you know if there are network length/quality issues.

Software stuck channels (as far as I understand) are channels that receive an on command and don't receive/obey the off command - for whatever reason.  (I say software because I have had bad triacs that lead to stuck channels.)  The question is whether or not the command is getting out at all, or is just not picked up by the controller.  Another task that would be a LOT of work is to get a serial sniffer out and watch the commands - huge pile of data to dig thru...

Edited by deweycooter - 03 Dec 2009 at 8:18pm

Author	Message Topic Search Topic Options Post Reply Create New Topic Printable Version
deweycooter Members Profile Send Private Message Find Members Posts Visit Members Homepage Add to Buddy List Development Joined: 14 Oct 2007 Location: League City, TX Online Status: Offline Posts: 674	Quote Reply Posted: 03 Dec 2009 at 8:15pm
	For you - what's keeping you on .69? Why not go back to .41? For the issue - I assume the lost ID are confirmed by using the Discover Units in the DL Utility, or by commanding a chase to a specify ID in the DL Utility and not seeing anything? Do they reset to a value or just have no ID? What would you estimate the total cat5 length? I assume the sequences have changed since last year, so that clouds the issue a bit when comparing year to year. An interesting test would be to assign all controllers the same ID, then compare behavior differences down the line. Stuck channels....? That's a bit of work for one test, but could let you know if there are network length/quality issues. Software stuck channels (as far as I understand) are channels that receive an on command and don't receive/obey the off command - for whatever reason. (I say software because I have had bad triacs that lead to stuck channels.) The question is whether or not the command is getting out at all, or is just not picked up by the controller. Another task that would be a LOT of work is to get a serial sniffer out and watch the commands - huge pile of data to dig thru... Edited by deweycooter - 03 Dec 2009 at 8:18pm
	Aurora Lights Wiki

Pony_God Members Profile Send Private Message Find Members Posts Add to Buddy List Senior Member Joined: 01 Sep 2008 Location: Naples, FL Online Status: Offline Posts: 551	Quote Reply Posted: 03 Dec 2009 at 7:22pm
	I'll start with the point, then give the background. The point: I'm thinking that Borialis is sending out erroneous commands causing channels to get stuck. So here's my thoughts. 1. Durring the 2008 season, we did have sticking channels that cleared themselves up the next time that the channel was used. These stuck channels were fairly minimal, far between, quite random. Aurora .41, F/W 1.15beta, single network, 6 ACx16s, 1 Firefly. 2. This season we have quite a few stuck channels that still clear themselves out on next use. These channels are much more predictable, I know what songs, and what chases that they will get stuck in almost every time. Aurora .69, F/W 1.15beta, F/W 1.16, dual network, 12 ACx16s, Firefly not up yet. 3. We have had the last two controllers on network 1 loose thier IDs (even though we didn't loose any IDs last year) and yet they are getting command at times. The times that they are getting the commands are the exact same times that other channels get stuck on other controllers on other networks. 4. The channel that's getting activated on the two controllers are the same channel ID (or possibly one off) 5. Now, if those controllers do not have the correct ID, how are they getting a command? And why are they getting a command at the same time that other controlles are getting stuck channels? 5. Is there a command going out to _all_? 6. Since half of the firmware is last year's I would expect those controllers to have the same frequncy of stuck channels, but it's not. One of the controllers that has a lost ID has 1.15beta (from last year) and the other has 1.16 (new for this year) It just seems that thier are only two changes, a network addition and software update. What's everyone else's thoughts?
	Fine. You're so smart you rig up the lights. D-Light users Unite!