BETA testers for the µSC...

[Steve Gase]

New question: can I use 5v power delivered from a 4port passive hub BEFORE the uSC -- instead of power injection AFTER the uSC?

[arw01]

Someplace in the uSSC threads there was a post that Corey said that should work to a few tenths below 5v where the components will drop out.

[arw01]

I think most details are in the thread to set up the test.  I used default settings in the configuration tool, except no hybrid and no single rgb control.

Single RGB is basically grouping the whole string to make a dumb controller?  And your TM1804 was just 20 long?  I think am an a touch longer than that and have the new technicolor as well as pixabulbs.  Currently have the uSSC in between Zeus sections on the matrix and making some progress getting that going better.  Need to try a wired connections instead of wireless from the pc driving the matrix to see if response is related to wireless latency, but really should not as the ED and the wireless access point are in the same hub 10' from the computer!

[Steve Gase]

I think most details are in the thread to set up the test.  I used default settings in the configuration tool, except no hybrid and no single rgb control.

Single RGB is basically grouping the whole string to make a dumb controller?  And your TM1804 was just 20 long?  I think am an a touch longer than that and have the new technicolor as well as pixabulbs.  Currently have the uSSC in between Zeus sections on the matrix and making some progress getting that going better.  Need to try a wired connections instead of wireless from the pc driving the matrix to see if response is related to wireless latency, but really should not as the ED and the wireless access point are in the same hub 10' from the computer!

The single RGB did seem to be similar to string mode, but when I turned off the leading channels the other channels kicked into action after 20seconds.  So, it seemed more like a defective hybrid.  In any case, I disabled that box and no longer use hybrid or single RGB... so I'm ignoring that issue.   

The vanilla config without hybrid is where I see the freezing.

btw, I see also this freezing with strings of 50, and also strings of 128.

[corey872]

5V input should be fine.  The input power goes straight through the board to output at the nodes and everything on the board can live well below 5.0V.

Problem #1  One key would be what the PIC signal 'SIG' LED does during this time?  If it is steadily flashing as well, that should mean the PIC is processing and sending data in a regular, unimpeded manner.  The issue would then lie between the output of the PIC and the input to the node. (assuming the node string is known working)  This would most likely be a board issue going back to the hand assembled nature of the boards ... and the fact I sent them out 'as is' so the beta testers could have the experience of soldering the connections themselves.  Wish I would never have done that now!   Possibly a cold solder joint on one of the microscopic component pads somewhere.  During a lock-up, you might try poking, proding, and jiggling the components with your finger.  If there is an intermittent contact, that might jiggle it back into place ... or break it completely ...either way, it would confirm this suspicion.

If the SIG LED also stops during the pause, it could still be a board issue on the input side of the PIC, or a sign the PIC has stopped processing data for some reason.  I'd still be inclined to say a bad solder joint or something of that nature, as we've built up 1000's of hours of glitch-free processing on other boards.

Also curious - (maybe I missed this with all the posts) but if you set up for just a plain, non-hybrid, non-grouped string, 'typical' data transmission (ie run a sequence), etc - does the issue still persist?

Problem #2 - with the beta boards, you need to have 'test' engaged when you power up the board.  Whether you have a magnet, or jumper wire, it needs to be applied with the board off, then it should enter test mode when you apply power.  If you remove/reapply the test mode, the beta board will not start back into test mode until the power is cycled again. 

This was changed on the production boards (it's a physical board level change, not a firmware issue) so ANY time the magnet is applied, or pins 2 and 6 of the ICSP are jumpered, input data processing is suspended and the board enters test mode.

[Steve Gase]

Problem #1:

I took some video: https://dl.dropboxusercontent.com/u/79246681/uSC-1.0-Prob1.mp4

The video shows 2 identical stars close up so that you can see the LED activity on the uSC.  The left star is driven by the beta uSC with firmware 1.0.  The 50 pixels start at channel 1.  The right star is driven by a SSCv3 with the latest DLA firmware, and its 50 pixels also start at channel 1.  Both controllers are connected to the same DLA Active Hub, and receive identical pixelnet channel data from a EtD that gets its data from xLights 3.2.14.

What you'll see in the 30 seconds of this video is that the DLA SSCv3 has no freezing -- which rules out the EtD and xLights.

At time 27 seconds the left start freezes...  immediate the green DOUT led is off, but the others continue to flash.  At 29 seconds the yellow SIG led goes off.  At 30 seconds the SIG led goes on solid.  At 31 seconds star unfreezes and the DOUT and SIG return to normal.

I see this happening every 2min 10sec on the dot.  I left the lights running for 16 hours with the same behavior throughout.


To your questions:
Jiggling has no impact.  I did reflow the solder when I first saw the problems, and I saw no improvement.  The regular 2min 10sec has me think it is not a faulty board, nor faulty assembly -- everything else works as expected.

The SIG LED does stop, and you indicate a problem on the input side of the PIC... but again 2min 10sec.

[Steve Gase]

Problem #2:

Problem #2 - with the beta boards, you need to have 'test' engaged when you power up the board.  Whether you have a magnet, or jumper wire, it needs to be applied with the board off, then it should enter test mode when you apply power.  If you remove/reapply the test mode, the beta board will not start back into test mode until the power is cycled again. 

This was changed on the production boards (it's a physical board level change, not a firmware issue) so ANY time the magnet is applied, or pins 2 and 6 of the ICSP are jumpered, input data processing is suspended and the board enters test mode.

With the earlier firmware, it worked as you describe above... it can be enabled by powering up the board while the magnet or jumper is in place.

With the new firmware 1.0, I cannot get the test mode to be launched... doing this at power-up does not activate test mode.

[corey872]

I just loaded the 1.0 firmware on a board and test mode seems to work as expected.  Jumpering either pin 2 to 6 on the ICSP header, or jumpering the mag switch, or triggering mag switch with a magnet puts the uSC into test mode immediately with no power cycle.  So looking more like you might have a slight issue on the beta board.

I'd also note, I believe the beta boards went out with PIC24F04KA200 chips (maybe someone with a magnifying glass, good eyes, or a good macro camera can confirm the PIC chip has a 4 and an A in the ID), but the production models run a slightly newer PIC 24F08KL200 chip, mainly because the F04KA's were in limited supply when the boards went into production. 

The board I programmed had a F08KL chip, which represents the production version and what the 1.0 firmware was written for.  If you put 1.0 on a board with the F04KA chip, there might be some small, but notable differences.

I will do some more testing as time allows, but it's beginning to look like you might have an issue on the board or a F04KA / F08KL compatibility issue.

[David Pitts]

Good catch Corey on the chip version thing. Both firmware Steve is trying is for the 24f08kl200

[corey872]

OK - so back from my trip, I've tried to replicate this issue as closely as possible... with one small change - using some actual production boards: (hint... hint)

Kit: Beta uSC board   uSC V1 Production board
Firmware: Falcon Firmware V1
Configuration Utility: 1.0.11
Dongle:  DLA USB Pixelnet Dongle
Hub:  DLA 16-port Smart Hub
Strings:  20x TM1804 IP68 bullet pixels (ok, it was actually a 128 node string, with uSC programmed for 20)
Tester:  xLights 3.2.14

I have not experienced any issues over several days of running.  So at this point, given 1000+ hours of prior testing with no issues, my current test with no issues, as well as others reporting back no issues, I think we have to look at this as either a compatibility issue between the beta PIC chip / production firmware (which I think most likely at this point) or a board level issue with that specific beta board.

Based on the video, it seems like what happens is the PIC stops transmitting to the MOSFET driver (green LED goes out), the PIC does a minor 'reset' (PIC LED goes out), then the PIC starts transmitting data again.  It doesn't seem like a major 'power off' re-set because the PIC LED doesn't flash it's start-up 'code'.  The board doesn't lose power as the PWR LED remains lit and input data is coming in uniformly, looking at the DIN LED.  Also interesting you report it happening every 2m, 10s like clockwork... which also would seem to rule out something random / intermittent on the board. 

Anyway, thanks for letting me know about this.  If you want to send the beta board back, I can take a closer look and troubleshoot further.  But it seems at this point, additional testing has ruled out a systemic issue with production and shown this is most likely either a firmware incompatibility, or an board level issue with that specific beta board / set of components.

[Steve Gase]

For now, let's treat this as a beta problem and focus on production. 

when I get the production i'll swap between the two to ensure that I have identical conditions and the issue has been fixed.

thanks for looking!