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.
