I’m man enough to admit when I’m wrong, or at least only 50% right.
If you’ve been reading my blog posts you know we bought and built a blinky pov and have since struggled to get it to program reliably. When you’re a 14 year old with a 14 year old’s attention span it either works, or it doesn’t work, not a lot of patience for debugging.
We tried quite a few different ways to program the blinky, varying displays and display parameters, with limited success. The programming software was clearly running in the chip, or at least causing the programming status LEDs to light in the documented fashion. We did a pin for pin build verification. The blinky assembly instructions on W&L’s site for the BlinkyPov are first rate, so good even a child can build it and get it right the first time. A child did build it and did get it right the first time. The build verification showed the blinky pov was built to the documentation and a little off the cuff design analysis didn’t turn up anything sketchy. It looked like it should be working. We did go to the W&L blinky forums when we were initially having programming failures. The blinky forums have multiple posts by people having issues programming their blinky povs. We followed the advice to try changing displays, browsers, monitor settings, room lighting, etc, mostly without much luck. We could successfully program maybe 10% of the time.
After finally giving up our blinky sat on the shelf for a few months, shelved but not forgotten. As I’ve said before, I believe W&L’s BlinkPov is probably the coolest, most accessible pov toy to hit the market. I thought, and still think, it is a great device, I just can’t get it to program reliably.
After a few months on the shelf I pulled the blinky down and started digging around to see if I could figure out what was causing the programming failures. I rechecked the build verification, everything looked ok. I walked through the programming sequence, observing the LED’s, noting the states described in the BlinkyPov documentation. Still no go. At this point it was time to break out a scope and see what was going on.
I typically keep my main monitor at a reduced contrast and brightness. My main monitor is Samsung SyncMaster P2770 set at 50% brightness and 30% contrast.
Scoping the blinky SCLK and SDAT lines with the monitor at B50/C30 produces this trace.
The upper trace (yellow) is SCLK, and the lower (blue) is SDAT. Clearly this is sketchy. With the wild swings in the data and clock lines it is easy to see how the programming could, and would, go awry.
I scoped a couple other display devices, changing browsers and room lighting, posted the results here, and jumped onto the blinky forums and posted my findings. Wayne and Layne quickly responded with a couple good suggestions. In particular the idea that the display noise was coming from the LCD PWM. That made a lot of sense. I gathered up a couple displays, my main desktop monitor, and an Acer InspireOne netbook, and captured the following scope traces with varying brightness and contrast.
It is obvious from the traces below that the brightness and contrast have a huge affect on the signal captured by the blinky sensors.
I normally keep my main desktop monitor at 50% brightness (B50) and 30% contrast (C30). I first wanted to see what affect changing the contrast would have while keeping the brightness fixed. The following series of scope traces are at 50% brightness (B050) and 0%, 30%, 50%, and 100 % contrast (C000, C030,C050,C100).
Brightness 50% Contrast 0%
Brightness 50% Contrast 30%
Brightness 50% Contrast 50%
Brightness 50% Contrast 100%
The strength of the received signal is proportional to the contrast, more contrast, more signal. Since more signal sounds better than less signal, cranking the contrast up to 100% when trying to program seemed like a good idea. Changing the contrast doesn’t seem to help with the wild swings in the signal, but hey, at least they’re bigger, and bigger is always better.
With the contrast decided, 100%, it was time to try varying the brightness. Starting at a brightness of 50% (B50) and contrast 100% (C100) I stepped through, brightness levels of 50%, 60%, 80%, 90%, 95%, 98%, and 100%.
Brightness 50% Contrast 100%
Brightness 60% Contrast 100%
Brightness 80% Contrast 100%
Brightness 90% Contrast 100%
Brightness 95% Contrast 100%
Brightness 98% Contrast 100%
Brightness 100% Contrast 100%
It is clear that turning up the brightness, on my monitor really anything past 50%, will pull the LCD noise off of the black level far enough that it should allow the blinky to program. Cranking the brightness well above 50% cleans up the signals tremendously and gets them to the point where they start to look like digital signals.
With the huge benefit seen by turning the brightness up to 100% I wondered what the signals would look like with the brightness at 100% and the contrast something lower. On my monitor it is mildly annoying to change the brightness and contrast using the touch sensitive buttons provided by Samsung. If I only have to turn one setting all the way up, that is half the hassle.
The following traces are with the brightness at 100% and the contrast at 100%, 50%, 30%, and 0%.
Brightness 100% Contrast 100%
Brightness 100% Contrast 50%
Brightness 100% Contrast 30%
Brightness 100% Contrast 0%
With the brightness at 100% the signals stay pretty clean, even with the contrast turned down. BUT, I do see some funky steps in both the clock and the data with reduced contrast. My take away is, to get the cleanest signal turn up both the brightness and the contrast to 100%.
With the brightness and contrast at 100% I tried room lights on vs room light off.
Brightness 100% Contrast 100% Lights ON
Brightness 100% Contrast 100% Lights OFF
Having the room lights off seemed to clean up some noise near the black level. I haven’t looked at exactly how the blinky programming code determines the black level so the black level noise might or might not be an issue.
All of the above images are from my main desktop monitor. The Acer Netbook displayed large swings with reduced brightness so I decided to check it next. The Acer seems to only have brightness control on the keypad. It wasn’t immediately obvious how to change the contrast so I only took traces varying the brightness levels. The following images are at brightness 10%, 40%, 50%, 70%, 90%, and 100%. On the Acer the brightness needs to get up around 90% before the noise starts to pull off of the black level. And then at 100% the signal cleans up nicely.
Acer Brightness 10%
Acer Brightness 10%
Acer Brightness 40%
Acer Brightness 50%
Acer Brightness 70%
Acer Brightness 90%
Acer Brightness 100%
Acer Brightness 100%
So with all of this you’d think I’d have it nailed, the problem finally solved, turn the contrast and brightness both up to 100%, clean signals result, and programming should go off with out a hitch. Unfortunately not, nope, nada. I tried half a dozen times, nothing. Just a blinking error code. Man what a drag. Maybe it’s just me, maybe my blinky pov programming technique just sucks, but I’m turning up snakes eyes every time. I’m not giving up though. I know it can be done. I’m not going to let a bit of wires and blinking lights bring me to my knees. I will prevail…..
ps. I know it looks like I don’t have a life. Usually I do. In this case I really want to get this puppy working. Wayne and Layne have produced a nice little toy and I’m having a good time fencing with it. I shall emerge victorious !!