Tech – Page 3 – Engineer On The Loose

FTDI programmer for the Arduino Pro on the cheap(er)

Dec 312013

The Arduino Pro comes with a bootloader installed, meaning it is plug and play ready to work with the Arduino environment. All you need is a way to hook it up to upload new firmware.

The Pro is a stripped down version of the Arduino UNO. One of the stripped parts is the USB to serial programming interface. Programming the Pro requires either an ISP programmer or a USB to serial translator.

The Pro brings out the standard green to black FTDI cable programming header and Sparkfun recommends their FTDI programming cable (5V) for a plug and play experience. That is all well and good but a FTDI cable is pushing a cost of $20 USD (Sparkfun’s 5V and Adafruits 3.3V). You can buy FTDI breakout boards with the same pinout for a little less, around $15 USD (Sparkfun, Adafruit). That’s better than $20 but still more than twice the cost of other options.

If you are willing to wait for the shipping from China (or you order ahead) you can get a FTDI breakout for less than half the price of the Sparkfun or Adafruit breakouts. The iTeadStudio FOCA breakout has a couple of nice features over the Sparkfun and Adafruit breakouts, and one glaring hassle. First the good, the FOCA interfaces with either 5V or 3.3V systems with the flick of a switch. The FOCA also has an XBEE footprint allowing it to be used as a USB to XBEE interface (compare to Sparkfun’s USB to XBEE board at $25). All in all a pretty nice package for $6.50 USD (as of Dec 2013).

iTeadStudio FOCA

Now for the hassle part. The pinout of the FOCA is NOT a direct crossover to the “standard” green to black programming pinout on Sparfun’s and Adafruit’s FTDI cables, and of course the pinout on the Arduino Pro.

The pinout on the Pro is green to black being reset/dtr, TX, RX, power, cts, gnd.

Sparkfun Arduino Pro

The pinout on the FOCA is power, TX, RX, gnd, dtr/reset. Not a straight across plug and play.

FOCA Pinout

Fortunately for half the price it is pretty easy to make an adapter cable. I happened to have a 6 pin to 6 pin inline cable with crimped on connectors which made it easy to move the pins around.

The pins are held in place by little plastic fingers that can be easily lifted back with the tip of an Xacto knife or dental pick, allowing each pin to be slid out of the connector and moved to a different position.

A quick shuffling of both ends of the connector, to move green to one end and black to the other end on the Pro side, and to line up power, gnd, TX, RX, and reset on the FOCA side and wa-la, a FTDI programmer for under $7.50.

Sparkfun Arduino Pro 328 – 5V/16MHz Buzzer

Tech No Responses »

Dec 292013

I picked up an Arduino Pro from Sparkfun during their cyber monday sale. The Pro is a stripped down version of an Arduino UNO for about half to a third the price. It is missing quite a few features so if you are just starting out a standard Arduino is probably a safer bet. If Arduinos are old hat the price point is pretty attractive, I picked mine up for just under $9 USD.

The Sparkfun Pro has a round footprint in the middle of the board that turns out to be meant for installation of a buzzer, specifically the Sparkfun 12mm Buzzer. This little buzzer drops right onto the board, but other than a comment from Sparkfunion Robert there is no documentation on how to mount or use the buzzer.

It turns out the Buzzer recommended is really a tiny speaker. A mag coil driving a tiny disk. The two pins connected to the mounting holes connect to the Arduino digital pins 4 and 5. It doesn’t seem to matter which direction you mount the buzzer. I happened to mount the buzzer with the words arbitrarily “up”, which resulted in the “+” side of the buzzer “down”. Down being connected to D4 and Up connected to D5.

Sparkfun Arduino Pro

Driving the buzzer is relatively simple, you just set one of the pins, D4 or D5, to an output, pinMode(4,OUTPUT) or pinMode(5,OUTPUT), and drive the other pin, 4 or 5, with a changing signal. The recommended buzzer is basically a speaker and so the input needs to be modulated to generate a sound.

The simplest code to generate a 1 second, 1 KHz tone is:

void setup() { pinMode(5,OUTPUT); tone(4, 1000, 1000); } void loop() { }

The built in Arduino example toneMelody can be easily modified to play out the buzzer.

First open the toneMelody example:

Arduino toneMelody

Modify the bolded lines and upload the sketch to the Pro:

==========================================================================

#include "pitches.h"


// notes in the melody:

int melody[] = {

  NOTE_C4, NOTE_G3,NOTE_G3, NOTE_A3, NOTE_G3,0, NOTE_B3, NOTE_C4};
// note durations: 4 = quarter note, 8 = eighth note, etc.:

int noteDurations[] = {

  4, 8, 8, 4,4,4,4,4 };
void setup() {
  pinMode(5,OUTPUT); // set the "other" buzzer pin to an output
  // iterate over the notes of the melody:

  for (int thisNote = 0; thisNote < 8; thisNote++) {

    // to calculate the note duration, take one second 
    // divided by the note type.
    //e.g. quarter note = 1000 / 4, eighth note = 1000/8, etc.
    int noteDuration = 1000/noteDurations[thisNote];

    tone(4, melody[thisNote],noteDuration); // output the tone on the "+" pin
    // to distinguish the notes, set a minimum time between them.

    // the note's duration + 30% seems to work well:

    int pauseBetweenNotes = noteDuration * 1.30;

    delay(pauseBetweenNotes);

    // stop the tone playing:
    noTone(4); // turn off the tone

  }

}

void loop() { // no need to repeat the melody. }

==========================================================================

The Arduino Pro buzzer playing the toneMelody example sounds like this:

BlinkyPov – the light dawn (or at least brightens)

Tech No Responses »

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

Older Entries Newer Entries