Well, Christmas is approaching, so I guess it’s the time of year when I start revisiting projects that abruptly paused around Dec 26th last year.
I guess the thing that has been nagging me the most has been that I never really got my light sequencing software working very well with the GE G-35 light strings, as described a couple posts ago. It continued to be kind of glitchy, especially when sending a lot of commands in rapid succession, like when doing ramps, fades, etc. Sometimes certain bulbs would be left on when they should have been off, some commands seemed to get ‘dropped’, etc. I’ve had a suspicion that the cause is one or both of: (a) the signal timing generated by the Arduino “protocol converter” sketch not being perfect, or (b) The Arduino processor speed not being able to keep up with the rate that commands are sent.
Recently, an Arduino-compatible board by Digilent, the Uno32, came to my attention. It claimed to be fully Arduino-compatible, but runs a PIC32 processor at closer to 80MHz. It aslo has more IO pins and memory, but the speed is what interested me. I’m all about spending a few paltry bucks to save time on this accursed hobby, so I ordered one, hoping that just have a faster processor would produce positive results…
…BINGO! The board did have one compatibility problem with my sketch – I guess it doesn’t support the same serial registers, including the one for tweaking the handshaking, but I included that line is desperation, not because I had any evidence it would help. I commented out the offending line, loaded the sketch (using Digilent’s custom IDE) fired up EverSequence and – sure enough – it works WAY better! Ramps and fades are pretty consistent and there is generally much less ‘glitchiness’.
That said, I still could an occasional bulb left in an inappropriate state. At this point, I still think (a) may be an issue. I’ve seen a thread or two about the Arduino serial library not being very accurate and people linking more accurate timing libraries (delay_x) to get better results, so I might investigate that. I kind of suspect I might have trouble getting the delay_x library to work on the Uno32 given the incompatibility I already ran into, so there’s some investigation there that may cause me to put it off indefinitely 🙂
UPDATE: (11/25/2013) I’ve continued to be plagued with a problem where the string refreshes get bogged down when sending lots of commands to multiple strings – like when trying to ‘fade’ a grid made out of five strings of bulbs. I recently realized I will likely never get high frame rates with several G35 strings running on this platform…read more here.