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?

Disconver can not find the two controllers.

With the hardware utility, and ALL checked, ON/chase/twinkle/etc all get to the controller.

If they have an ID, I could not see it. I went from ID 1 though 20 and tested each with ON, and did not get them to respond. (One of the IDs is 12, I don't remember the other off-hand.)

cat5 100'? more? I can measure tomarow. It's less than last year because of the seperate networks. Net 1 is not terminated, net 2 is.

Sequences did change, I copied last years, and then imported this year's channels. I can send the one that I know has the error.

Durring any hardware tests, everything seems fine, but that's totally different software, speed, etc.

And that's how I understand a stuck software channel, partially. I see three options.

1. Software - sending bad data down the wire

2. Firmware - not obeying the commands

3. Hardware - triacs, etc.

As I see it.

3. The hardware seems fine, it can act normall and to firmware tests, and HWU tests.

2. Possibly, but some have the same firmware as last year and did not have as many stuck channels. If it was firmware, I would expect simmilar results.

That leavs option 1 again.

The net 1 cat5 is 150 foot. net 2 is at least 225 foot.

Test was done with HWU with ALL and fastest chase.

I let it go and just watched the arch and the tree (last two controllers on the line, and the two that lost the IDs.)

Ever 8 seconds or so a channel would stick. The same channel on both of the last two controllers.

I moved the cable even further away from power, I'll try to cut a new cable and see if everything clears up.

I did happen to try another usb-RS485 adapter and it acted the same.

That doesn't explain the first two controllers of net 2 sticking though. (Yes, I did run the HWU on net 2 and nothing stick with that.)

HWU ran on a sungle network.

Have not ran the show on a single network.

It's not damaged, and looks good its entire length, but I'll try and cut a new calble tomarow to test that.

 

I know that other people have sticking channels, but not sure about the adapter version.

I'll have more time over the weekend, so I'll try to determine better what firmware is sticking, make the new cable, re-set the IDs, try downgrading to .41, and upgrading the 1.15beta arch that's sticking.

See if any of those changes make a difference.