Saturday, August 27, 2016

Arduino Rover #2

My second rover is coming together.  The advantage of a ground rover is that it cannot fall out of the sky, so one tends to get rather more hours of amusement out of it than from a helicopter or fixed wing toy aircraft.

The first rover worked, but it was too complicated.  The problem with all toy projects is that I tend to forget what I was doing with it and I like to 'work' on multiple things at the same time.  My shop currently has a glider, a valve guitar amplifier, a VU meter, multiple radio transceivers and this rover all in various stages of incompletion.  Therefore any project needs to be modular and simple, so that I can see what is going on at a glance.  Otherwise, it ends up in a corner, gathering dust, rather sooner than later.

Rover #2 uses the Sparkfun Arduino Redboard for its brains and it is meant to be completely autonomous.  Addition of RC makes it too complicated and hard to maintain, so I ripped all that out (and it can now go back into the 2m electric glider!).

I re-used the Pololu 100:1 geared DC motors, enormous wheels and high power controllers, 7.8V
NiMH batteries, forward MaxSonar and Sharp IR range finder and a reverse Vishay IR Proximity sensor.   The sensors all have analogue outputs, so they are easy to hook up to an Aurduino A0, A1 and A2.  The motor controllers are serial and hooked together onto the same SW Serial Tx port used for the GPS Logger.  I only use the serial Rx for the GPS, so I use the Tx for the two motor controllers on a free pin D7.

The two wheels on the right are on one controller and the two on the left on another.  It simply turns with brute force - like a tank.

The chassis is my trademark olde skool wooden breadboard (It is rectangular, with rounded corners!) and the only parts that are screwed, wired and glued down with any sense of permanence are the 4 wheels, since having a wheel come off during a run, is disappointing.  The motors and wheels are of course totally oversized for this little toy, but it sure looks cool, eh...

The batteries, electronics and sensors are simply stuck on with 'chewing gum' (blue Tack-It).  Most wiring are plug in, using Berg 0.1" headers.  Only the batteries have polarized connectors so I can't plug them in the wrong way around (well, I still managed to do something like that regardless).

This way, it is easy to reconfigure this hoosammawhatsit and pull it apart to reprogram or solder something, without having to break out a pile of tools.


Three sensors should be enough for obstacle detection: IR Range finder, Sonar range finder and IR Proximity detector.

Here is some example code to read the simple sensors:

// Sharp IR Range Finder
// MaxSonar Range Finder
// Vishay proximity sensor
// Herman Oosthuysen, 2016

// IR values range between about 0x0165 with wheels touching a wall, to 0x0003 to the end of the room.
// Sonar values range between about 0x000b with wheels touching a wall, to 0x0190 to the end of the room.
// The proximity sensor shows about 0x03c0 when there is nothing and 0x003c when there is something.

void setup()

void loop()
  int   ir = 0;
  int   sonar = 0;
  int   prox = 0;
  char  res[5];

  ir = analogRead(A0);
  sonar = analogRead(A1);
  prox = analogRead(A2);
  sprintf(res, "%04x", ir);

  sprintf(res, "%04x", sonar);

  sprintf(res, "%04x", prox);


...and here is what the whole mess looks like once things are more or less connected:

Hmm, eye drops and non-alcoholic beer - both very important debug tools...

Pololu Motor Controller Setup

The motor controller needs to be configured (RC/Serial/Potentiometer control, ASCII/binary protocol and more).  This requires special software, which of course is not available for a Mac.  Curiously, they do have both Linux and Win32 versions of the control program.

So I fired up my trusty WinXP virtual machine on Virtualbox.  When plugging the USB cable in, it comes up as an unknown, so I created a USB port filter with only a Name: Pololu, Product: 0098 and Vendor: 1FFB, while ensuring everything else is completely blank.  Then replug the cable and wind up the Windows.  The Pololu program wants to run as administrator (unsurprisingly) and install a device driver twice, each time you plug the motor controller in.  I guess regular users of Windows would be used to this nonsense.

These motors are powerful enough that the buggy could do a wheelie.  I proved that with the first version.  So I would like to add an accelerometer and get it to flip onto its hind legs.

For the Arduino interface I set it to Serial/USB, Fixed 9600 baud, Binary, No CRC and made sure that the ID for the two controllers are different (mine are 13 and 14).  Save it and hope for the best.


Well, for a moment there anyway.  I plugged a motor controller in wrong and fed 7.8V into the 5V supply, blew the Arduino out of the water and it went to join the crowd in the great computer heaven in the sky.   My Mac even rebooted - but is still working - fortunately.

This is why I like playing with thermionic valves - they can take a lot of abuse - little embedded processors not so much.  So it looks like I'll be making the courier company rich, unless I order multiples of these things as spares, a handful of zener diodes and whatnot for protection, but that feels like planned waste - sigh...

Monster Moto

Eventually, I replaced the two Pololu controllers with a Monster Moto board from Sparkfun.  This way, I just have three boards plugged together and one battery pack - simpler.

The Monster Moto control is described in another post.

Arduino Rover Pins Used

The GPS board has a lot of breadboard space and places where tracks can be cut and reconnected.  To get everything connected, I had to do a little surgery with a knife on the bottom of the GPS board, and remove two 810 Ohm SMD resistors from the top of the Monster Moto board, as explained below.

A0 - (EN1 Motor remove 810R); Sonar range
A1 - (EN2 Motor remove 810R); LED range
A2 - CS1 Motor
A3 - CS2 Motor
A4 - IR proximity
A5 -

D0 RX - USB Serial; (RX GPS switch to SW)
D1 TX - USB Serial; (TX GPS switch to SW)
D2 -
D3 -
D4 - INA2 Motor
D5 - PWM1 Motor
D6 - PWM2 Motor
D7 - INA1 Motor
D8 - INB1 Motor; (SW RX GPS cut track)
D9 - INB2 Motor; (SW TX GPS cut track)
D10 - (ICSP MISO GPS cut track); SW RX GPS
D11 - (ICSP SCK GPS cut track); SW TX GPS
D12 - (ICSP MOSI GPS cut track); SW RX 9DOF Sensor
D13 - SW TX 9DOF Sensor


Items in brackets were cut or moved.

A Friggen Laser Beam!

Just the day after I received my packet of spare Arduino Redboards, Sparkfun announced that the Garmin LIDAR is back - really bad timing, but I just have to have one.  What is a Rover without a Friggen Laser Beam?

Wow, this toy is sure getting expensive...

Have fun,


Thursday, August 25, 2016

Arduino LCD Button Shield

The Sparkfun LCD shield works very well.  It has five buttons wired to a single analogue input, which is a neat pin saver. 

However, the example code is much too complex to my liking.  Granted, it can handle multiple simultaneous button clicks, but who on earth will ever do that?  So I made something simpler:

#include <LiquidCrystal.h>

// LCD uses D4 to D9 and A0 for buttons

LiquidCrystal lcd( 8, 9, 4, 5, 6, 7 );

void setup()
  lcd.begin(16, 2);
  lcd.setCursor(0, 0);
  lcd.print("C'mon click it!");

void loop()
  unsigned char key;
  unsigned int sensorValue;
  sensorValue = analogRead(A0);
  if(sensorValue < 1000)
     sensorValue = analogRead(A0);
     lcd.setCursor(0, 1);
     lcd.print("                ");
     lcd.setCursor(0, 1);

     if ((sensorValue > 600) && (sensorValue < 620))
       lcd.print(" Select");

     if ((sensorValue > 840) && (sensorValue < 870))
       lcd.print(" Left");

     if ((sensorValue > 920) && (sensorValue < 940))
       lcd.print(" Up");

     if ((sensorValue > 890) && (sensorValue < 910))
       lcd.print(" Down");

     if ((sensorValue > 800) && (sensorValue < 830))
       lcd.print(" Right");


Have fun!


Minimalist Arduino GPS Parser

The Sparkfun Redboard and other toys can be a lot of fun indeed.  What I like about the Arduinos, is that the board support packages are very good and it is very easy to intersperse regular C with the simple Sketch code.

Here is a minimalist on the fly parser for NMEA GPS data positioning that I've been playing with.  It receives and analyzes one byte at a time, so there is no delay.  You have the data the very moment it is available:

// Minimal GPS Parser
// Herman Oosthuysen, 2016

#include <string.h>
#include <SoftwareSerial.h>

// GPS serial: 9600N81
// Example GPS data capture

//Time, Lat, North, Long, East, Fix:

//Heading true, heading magnetic, speed knots, speed kph

const int rxpin=8;
//const int txpin=9;
const int txpin=255; // Rx only, frees up a pin
SoftwareSerial serial_gps(rxpin, txpin);

char ch = 0;
int cnt = 0;
int csv = 0;
int fix = 0;
int res = 1;
char dat[16];
char tim[16];
char lat[16];
char lng[16];

void setup()

void loop()

    // simple parser, start with $
    if(ch == '$')
      cnt = 0;
      csv = 0;
      fix = 0;
      dat[cnt++] = ch;
      if(ch == ',')
        dat[--cnt] = 0;
        cnt = 0;

        if(csv == 1)
          res = strcmp(dat,"GPGGA");
          if(res == 0)
            fix = 1;

        // Assume N, E
        if(fix == 1)
          if(csv == 2)
            strcpy(tim, dat);
          else if(csv == 3)
            strcpy(lat, dat);
          else if(csv == 5)
            strcpy(lng, dat);
          else if(csv == 6)
            Serial.print("Tim: ");
            Serial.print("Lat: ");
            Serial.print("Lon: ");
            fix = 0;

The result is:
Tim: 154417.000
Lat: 2413.4364
Lon: 05541.2907

Cool, now you all know exactly where I live.

In days gone by, there were phone directories, now, there is GPS.

There are Arduino GPS libraries available, but they are too complex for my liking.  For a toy, one can make some assumptions to simplify things, which saves processing cycles and memory.  I don't see the need to verify the checksum, or check whether the position is north and east - I'm not going to drive my toy car to the other side of the globe.

The Arduino software and Redboard works pretty good on my Mac, but if I unplug it from the USB port, then I have to reboot the Mac to get the USB serial port to work again when I plug it back in.  There should be a way to force the Mac to reload the driver, but I haven't gotten round to diving into the OSX weeds to figure it out yet.

Have fun!


Wednesday, August 10, 2016

Audio VU Meter

I have a bunch of Magic Eye tubes and was wondering what to do with them.  An audio VU meter with a microphone pickup could make a nice magical flickering display as I originally described here: An Angel Dancing On a Pin Head.

The example Rusky circuit works, but it needs much more gain to work with a microphone and it needs a power supply of sorts.  So, I dusted the old circuit off, hooked up a little triode as an amplifier to drive the display tube and my prototype works nicely.   Moving the resultant rat's nest from the breadboard into a proper display case is another matter though.

The 6E1P / EM80 is super simple, since the Target and Anode are connected together internally, so you don't have to.  It operates at a rather high 250V:
  • Pin 1: Gate
  • Pin 2: Cathode
  • Pins 4, 5: Heater
  • Pin 7: Anode
  • Pin 9: Screen 
Viewed from the bottom pin side, the pins are numbered clock wise, starting at the gap on the right.

The 6N21B miniature dual valve pin-out is as follows:
  • Pin 1: k1
  • Pin 2: s
  • Pin 3: g1
  • Pin 4: a1
  • Pin 5: h
  • Pin 6: k2
  • Pin 7: no pin
  • Pin 8: g2
  • Pin 9: a2
  • Pin 10: h
Because the double triode is physically small, the operating voltage is lower than normal at 'only' 100V.

For a little toy like this, a pair of huge transformers will increase the cost and their bulk will detract from the whole idea, so I made a simple direct mains powered supply - shocking, eh...

A magic eye tube is a tiny cathode ray tube as in old TV sets and requires a very high operating voltage.  So I used a voltage doubler on the 220 V mains.  That ensures that the electrons have sufficient kinetic energy to penetrate surface pollutants and stimulate the ancient zinc oxide fluorescent display properly.  High voltage capacitors are costly and one 630V electrolytic could cost as much as a transformer.  Put two identical(!) 315 V caps in series - much cheaper.

The miniature triode needs a much lower voltage, so I made a simple half wave rectifier for that.  So far - fairly standard.  The triode output is envelope detected to create a negative voltage to drive the display tube gate - any small signal diode will work - a 1N4148 is cheap.  You can put a trimmer on the display tube cathode to adjust the DC bias and together with the input volume control, get the shadow to flicker properly.

The heaters require about 300 mA (I have measured 280 to 370 mA) at 6.3 V.  So for that, I made a simple triac light dimmer circuit (test it with a light bulb and set it to minimum) with the two heaters in series (I used a quadrac - one less part).  To get the right current, install a 1 Ohm resistor in series with the tubes, measure the RMS voltage over it and tweak the trimmer - then maybe put a spot of glue/wax on it.

The fuse and chokes provide some protection and spike/triac noise filtering.   You can wind your own chokes - a few turns on a ferrite toroid or ferrite cable clamp (easier to wind, since you can wind it while it is open!) is all that's needed.

Another (more expensive) solution, which avoids the triac noise, is to use a series capacitor to power the heaters.   You would need to use a capacitor that can handle the continuous current and high voltage.  You need to hook the tubes to a power supply at 6.3 V and measure the current once they warmed up and then select a suitable series element.  One possibility is a 4 uF Motor Run Film Capacitor Mouser Part No: 80-C276CC34400AA0J.  Here is the formula: C uF = 159155 x 0.3A / 50 Hz x sqrt(230V^2 - 12.6V^2) = 4.16 uF

As with any thermionic valve circuit, this one is dangerously 'hot' and noisy.  So when this toy is running, keep yer cotton picken fingers in yer pokkets - else you will be sorry.  I have a rubber mat on my shop floor, got zapped a few times and I'm still here...

La voila!


Saturday, August 6, 2016

FM Crystal Varicap Tuner

I like to keep things simple, but I also like to make things that are a little unusual.

To go with my Valve Amplifier, I wanted to make a simple radio tuner.  Where I live, there is a powerful FM transmitter almost in my back yard.  It is very strong and overpowers all other transmissions, so the only FM station that I can receive is Abu Dhabi Classic.  That gets rather trying after a while, but why not turn it into an advantage?

Since the radio transmission is very strong, it can be detected with a simple tuned circuit and a non-linear element - there is no need for a complex discriminator or PLL.

For an intuitive explanation of how it is possible to demodulate FM with an AM detector: If you tune an AM receiver adjacent to an FM signal, then when the FM signal is closer, the AM signal will be stronger and when it dithers further away, the AM signal will be weaker - that way, a simple envelope detector can detect a FM signal.  Some call this a slope detector.

Crystal sets are normally associated with shortwave radio, which require enormous coils, air capacitors and high impedance headphones.  In the 100 MHz FM band (88 to 108MHz), everything is much smaller, but a high impedance headphone may still be a problem to find.  Piezo electric speakers are commonly used in laptop computers and can be obtained from Digikey or Mouser, so you can use one of those, but do put a resistor in parallel, since it won't pass DC.  Mike's actually has everything you may need.

Variable capacitors are somewhat hard to get and air capacitors are still manufactured by at least one US company, but are expensive.  Using varicap diodes to tune a circuit is also expensive, but LEDs and zeners are cheap and make fairly decent DIY varicaps.

This circuit looks like a FM crystal radio with a 9V battery.

The battery is needed to charge the tuning capacitor, which is made from two red LEDs, used as varicap diodes.  Red LEDS provide about 10 to 30 pF capacitance with  9V bias (You have to take a handful of LEDS and try them - some patience required).  Other options are large rectifier or zener diodes, but a couple of 5mm LEDS look nicer.  Of course a real varactor will be better and more linear, but who has a varactor in his junk box?

If you want something a bit more predictable than a LED, then you could use 1N4001 rectifier diodes. The 1N4001..7 all exhibit the same curve, as shown in the data sheet here on page 2.  However, you would have to double them up to get sufficient capacitance.   To make a 100MHz RF circuit work, it is important to keep all wires short (just a few millimeters) and the parts very close together, otherwise stray capacitance and inductance will detune it and it won't work as intended.

The result is a FM crystal radio that can be tuned with a potentiometer.

In my eventual circuit, I used two LEDs and tune the tank with a 22k potentiometer.  Some more playing with a coil design tool settled on 5 turns, 10 mm diameter and 12 mm length for 150 nH and a Q of 600.  That improved the selectivity much.  I wind coils around a drill bit to get a precise diameter and the biggest bit I got is 10 mm, so...

BTW, a 1/4 wave antenna needs to be 75 cm in length and a 1/20 wave antenna needs to be 15 cm. On a receiver, a bad antenna affects both the signal and the noise, so the S/N ratio stays the same, but a longer antenna will certainly catch more signal.  If you solder the antenna on the top end of the coil, then it will load the coil and you won't be able to tune to the high end of the band, so solder it to the first turn from the bottom.

So, how weird is that?