pov – Engineer On The Loose

BlinkyPov – the light dawn (or at least brightens)

Oct 182012

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 40%

Acer Brightness 50%

Acer Brightness 70%

Acer Brightness 90%

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 !!

BlinkyPov – an issue in the programming web page

Tech No Responses »

Oct 152012

It looks like there is an issue in the BlinkyPov programming web page.

The blinky pov reads data on each low to high and high to low transition of the clock. The data is set, high or low (white or black), and the clock is transitioned, low to high or high to low. The clock then maintains it’s present state while the data is setup for the next bit value and then the clock is transitioned again.

If the clock is ever out of sync the data will not be read properly… It turns out it is fairly easy to get the clock out of sync.

Let’s say you are trying to program your blinky pov and you are becoming increasingly frustrated. You are changing messages, changing monitor settings, changing programming timing, starting and stopping and restarting and stopping again.

The blinky pov programming web page expects the initial value of the clock state variable (current_clock) be zero and the initial value of the clock to be black. The first data bit is setup and the clock is expected to transition from the initial value of black to white. The bliny pov programming page does not initialize the clock state variable properly at the beginning of each run and if the programming stopped when the clock value is high, the clock will be out of sync on the next programming cycle. Which will yield yet another failure to program.

This is fairly easy to show.

Let’s say you are trying to program a simple message, something short and sweet like this..

The bit pattern that needs to be programmed into the blinky pov is this…

You can see the hex and bit dump of the programming message by running my modified (and fixed) version of the blinky pov programming page at http://techspin.info/blinky_pov_web/blinky_programmer.htm.

If you look at the message the first 8 bits should be 0000 0101. That is, the clock should transition 5 times with the data black, the data should be set to white, the clock transition again, the data set to black, clock transition, data set to white, clock transition, data set to black, and so on.

To see the proper clocking reload the W&L blinky pov programming page (this initializes the clock properly) and setup the message above. Slow the delay to 1000 ms (one clock per second) so you can count the clock transitions while looking at the data. On a proper transmission you see the clock change state 5 times with the data black, the data change to white, the clock transition again and so on properly.

To see the failure reload the W&L page (do not use the TechSpin blinky pov programming page because it does not have the issue) and setup the message as before. Set the message delay to 1000. This time wait until the clock is white and hit the stop button. This is going to leave the clock state variable in the wrong state for initial programming. Now run the programming again with a delay of 1000 and count the number of clocks until the first data white. You will find the data appears to come one bit time too early. In actuality the clock dropped a transition. The data transitioned properly but one of the clock pulses was lost so the data seems to be bit slipped in the data stream.

Fundamentally the issue is twofold. First the web code assumes an initial state for the clock variable, which it does not enforce, and second, the code does not enforce synchronization of the clock state variable and the color displayed on the screen for the clock value during programming.

Look at the following snippet taken from the blinky programming web page source code…

function toggle_clock() { // this function toggles the color of the clock panel each time it is called if (current_clock == 0) { current_clock = 1; set_color_clock("white"); } else { current_clock = 0; set_color_clock("black"); }

setTimeout('set_data()', delay); }

The web page assumes the initial value of the current_clock is 0 and paints the initial color of the clock image as black. IF the initial value of current_clock is 0 AND the initial color of the clock image is black, then this snippet toggles the current_clock to 1 and paints the clock image to white. If on the other hand the current_clock is left at a value of 1, because you stopped the programming when the clock was white, the initial painted color of the clock image is black and then this function fails. It fails to toggle the color of the clock to white. If the current_clock enters this routine as a 1 the current_clock is reset to 0 and the clock image is painted black, which it already is so no image transition occurs so no data bit is read by the blinky pov device.

So how do you fix it? Basically two things should happen, the current_clock variable should be initialized on each programming attempt and the clock state variable and the painted clock image should be forced to be in sync.

Like most problems there are multiple ways to solve this problem. Here is how I tweaked the code…

First initialize the current_clock on each start of programming…

Second, maintain synchronization between the clock state variable and the painted image….

Doing this forces the clock state variable to the expected initial value and forces it to be in sync with the painted clock image at the beginning of the programming sequence.

As a work around if you stop the programming mid stream you should reload the programming web page to insure the state variables are set properly.

BlinkyPov – a possible solution to programming failures?

Tech No Responses »

Oct 132012

Looking at the traces from the last post I wonder if something as simple as a capacitor in parallel with R1 and R2 from SCLK and SDAT to ground wouldn’t be enough to filter the LCD update noise and allow the BlinkyPov to finally program.

Sensing Leds

The question is, how much capacitance, and will enough capacitance to filter the noise be too much for the LED / photo sensor to drive.

Grabbing a random cap out of my parts box turned up a 1uF electrolytic. I hooked it across R2 with some hook grabbers and grabbed some scope traces.

Here is the first trace without any added capacitance.

When I first ran the web programming app I had the bit delay at 40 msec. At that rate with a 1uF cap the loading was such that the data line was not moving much at all. Slowing the data rate down to 200 msec and then 500 msec resulted in this trace.

I think I’m onto something here. Assume that everyone who has a blinky pov can solder, seems reasonable since the blinky pov is a kit that requires you to solder it up in the first place. It is not unreasonable to think most people with a blinky pov could solder a small cap dead bug style across R1 and R2. Then with appropriate slowing of the blinky pov web page you might be able to get to a reliable programming solution.

It is late where I am so I’m not going to figure out the proper value of the caps tonight but if someone else comes up with a good set of values please leave them in the comments below.

BlinkyPov – clock and data phasing issues

Tech No Responses »

Oct 132012

I was beginning to look at the blinky pov firmware and how it interprets the SCLK and SDAT signals but got sidetracked looking at the scope traces and phasing between the clock and data signals.

I scoped both the clock (yellow) and data (blue) and captured these traces.

scope hookup clock and data

It is pretty clear where the clock and data are supposed to be “1” and “0”.

According to the W&L Blinky POV design page

"The above diagram shows how we prepare the binary data values for transmission. First, we look at the binary value of each byte. For example, the hex value 0x6D is binary 01101101. We are using a “data and clock” transmission scheme, where the data value is sampled when the clock changes."

This says the data will be sampled each time the clock transitions, from low to high or from high to low.

If we zoom in on a particular transition, say from high to low, we see something interesting.

The clock is the yellow trace and data the blue trace. The first question I have is, where does the clock decide it is high or low? Looking at the nearly full scale swing in both clock and data it is hard to see where the “rising” and “falling” edges of the clock are and what the corresponding value of the data is when the clock rises or falls. Looking at the last scope trace in this series it is not clear what the value of the data will be read as when the clock is finally determined to be low. Clearly the data, the blue trace, is supposed to be high before and after the negative going transition of the clock.

BlinkyPov – measuring SCLK and SDAT

Tech No Responses »

Oct 132012

To repeat the intro to the last post, the blinky pov uses a neat little trick to read in new words and symbols to program into the blinky pov display.

Two light emitting diodes are mounted on the blinky pov and used in a fashion that causes them to act as light receptors rather than the traditional LED use as light emitters.

SCLK and SDAT, the incoming program data clock and data lines, are wired to pins RA2 (pin 11) and RA4 (pin 3).

Normally we think of digital signals as ON or OFF, digital data is a 1 or it is a 0. Unfortunately reality intrudes and 1 and 0 do not apply. Looking at the previous post we can see the clock and data signals presented to the blinky pov processor are decidedly not clean 0s and 1s.

Pins RA2 and RA4 can be, and are in the blinky pov, configured as analog input pins. Looking at the traces from the previous post there appears to be a good reason for wiring the clock and data to analog input pins.

(More to come here….. I’m looking at the code and I see some effort to calibrate for the black level….)

BlinkyPov – Sensing the data

Tech No Responses »

Oct 132012

The blinky pov uses a neat little trick to program new words and symbols into the blinky pov to display.

Two light emitting diodes are mounted on the blinky pov and used in a fashion that causes them to act as light receptors rather than the traditional LED use as light emitters.

Programming my blinky pov is not working, it’s as simple as that. There are a variety of reasons why programming might not work, from hardware issues to software issues. Either the data is not getting to the programmer or the programmer is not interpreting or programming properly.

The first place to look is the output of the sensor. Is the sensor generating Highs and Lows, 1s and 0s. Hooking an oscilloscope to the SCLK and SDAT lines generated the captures below.

First I hooked up SCLK and tried to program from my desktop monitor. It is a Samsung SyncMaster P2770. It supposedly has a 1ms response time and 70,000:1 contrast. The hookup and traces look like this…

Each burst of activity on the scope is a SINGLE clock pulse. One flash of white from the blinky pov web programming application.

Looking at the various scope traces it is clear the incoming data is neither a 1 nor a 0. This group of traces is from my main desktop monitor running Google Chrome at the Blinky POV programming website.

scope hookup desktop

The traces above are from Google Chrome. Somewhere in the random postings on the blinky pov forums was an assertion that different web browsers will display the white and black squares differently and thereby affect blinky pov programming performance.

The following traces are from the same monitor, at the same height, in the same lighting conditions, at the same distance from the monitor. These captures are from running Mozilla Firefox.

The trace above is with Firefox and the room lights on. It was also recommended to turn the room lights off. The trace below is the exact same setup as above with the room lights turned off.

So far what I’m taking away from the various recommendations to try different browsers and lighting is that it is a smokescreen. I’m not seeing a difference in traces when trying to program from the same monitor.

Switching back to Google Chrome and pointing at my second desktop monitor, a Samsung SyncMaster P2350 produced the following traces.

Using Firefox and hooking the scope to the data line (SDAT) produced these traces.

Next I tried my netbook. It is an Acer Inspire One. The scope hookup was the same, the browser was Google Chrome pointed to the W&L Blinky POV programming website. This time I do see a difference. The light to dark transition from the netbook is much stronger and also has a much higher frequency carrier.

Switching to Firefox on the netbook produced similar results as on the desktop, that is, no real change.

Switching to a smart phone produced an interesting difference and probably explains why we had any success at all when using a smart phone to program the blinky pov.

BlinkyPOV Programming – time to crash and burn

Tech No Responses »

Jun 072012

Like apparently so many others we can’t get our blinky_pov to program. Perusing the BlinkyPov forums shows we are far from the only ones having problems programming the blinky pov.

I’m not thrilled with the technical feedback from Wayne and Layne either. Try turning off the lights, try turning on the lights, try using a different web browser, try using a different device, try turning the contrast up, try turning it down, and then the final pat answer, contact tecnical support through a private email. Hmm, I wonder how many of the frustrated blinky pov owners ever get the programming to work. We tried all of the advice, it turned out using the browser on a smart phone did actually work once or twice. None of the laptops, netbooks, multiple LCD monitors at home or work ever worked to program the blinky pov. Something aint right. Of course the icing on the cake is the final final pat answer from W&L, We have thousands of successful and happy blinky pov owners who are not having any problems. I wonder if that is true or if the majority of blinky pov owners just give up in frustration.

Now, with all that said, I am not giving up. The blinky pov is a cool little device and if it can be made to work it’ll be a neat little trick. Fortunately W&L have released the blinky pov as an open source project…. time to start digging.

Blinky Pov Design

Blinky Pov Source Files

BlinkyPOV Assembly – so far – so good

Tech No Responses »

Jun 072012

Wayne and Layne have put up a nice series of photos and instructions on building the BlinkyPOV, ala LadyAda over at Adafruit. Following these instructions and using a reasonable soldering iron (not a hot pointy death stick like I learned on), my 14 year old assembled the BlinkyPOV in about a half hour, maybe a little longer with some Q & A. We took the assembled BlinkyPOV, added batteries, and bada-bing, symbols and words flashing through the air. It was pretty cool. We high fived and buttoned up for the night with a win.

BlinkyPov Through Hole Build Instructions

BlinkyPOV – how cool is that

Tech No Responses »

May 172012

I was online the other day poking around, buying some parts for my latest project and stumbled across a persistence of vision (POV) toy / project that had a neat twist, the ability to upload and program new messages into the device non contact by pointing it at a web page. This implied new messages could be loaded from anywhere you could hit a web page, from school, the library, or via a smartphone from pretty much anywhere. And the neat part, for my intended audience, was no wires or special software required. How cool is that!!

This differs significantly from other POV projects / toys that go as far as require you to download a complete compiler and upload tool suite, modify the code running on the POV toy to generate new image patterns, and then upload the code into the toy by reflashing the entire program and data space. WOW, that’s a pretty high bar for a newbie or a youngling.

Since my audience was a 14 yo just getting into electronics and programming finding a project that was easy to build and even easier to use was great news. Out came the wallet and a BlinkyPOV was soon heading my way.

Not to spoil the end of the story but unfortunately we will discover that the promise and reality don’t always align.

In the meantime follow the links below for a laundry list of POV definitions, explanations, and projects.

The toy itself – Wayne & Layne BlinkyPov Blue

The non contact programming page – Wayne & Layne BlinkyPov Programmer

How it works (or doesn’t work) – Wayne & Layne BlinkyPov Design

The source code (gotta love open source projects) – Wayne & Layne BlinkyPov Code

ch00ftech links – good stuff here

http://ch00ftech.com/2011/10/24/led-persistence-of-vision-toy/

http://ch00ftech.com/2011/11/16/ldds/

A bunch of Hack A Day POV links – the always delightful array of weird and interesting tech happenings

http://hackaday.com/2012/03/02/wind-powered-pov-weather-station/

http://hackaday.com/2012/02/11/plotting-pictures-with-light/