Compass Prototype 1

Building on yesterday’s Compass LED PCB prototype, I wanted to get the compass actually working so I could drive some LED’s.

Using Adafruit triple-axis accelerometer & magnetometer LSM303 and NeoPixel Ring – 24 x WS2812 RGB LED, I was able to get a functioning digital compass fairly quickly utilizing the Adafruit_LSM303 library.

I don’t know if I will use off-the-shelf LED’s for the compass as shown in the Compass PCB prototype 01 or use a Neopixel version via SparkFun, the WS2812 RGB LED Breakout. I save about 1.3 mA per LED versus my chosen through-hole LED if I use the WS2812 with a single channel of the RGB on, but to get white it costs me 60 mA! If I use this breakout board I won’t have to assemble or test out the components and boards or test out a self-designed board, which is a huge time saver and reduces the change of me messing up, but I don’t think I can afford the power for the compass.

If I use the Neopixel for the compass, I’m stuck using the Neopixel library for the compass and my home-brew shift registers to drive the lamp subsystem. Which might not be a problem since they both do different things. In the end it might come down to aesthetics: which system do I want more control over the color of light, the lamp or the compass? I think I would want more control over the lamp colors via the Neopixel than control the color of the compass.

Compass Prototype 01

Until I get a handle on my power consumption, I won’t be able to choose one system over the other.



Prototype 4 – Compass

Another day, another module. This time a compass, well, a magnetometer. In this case a triple-axis Accelerometer+Magnetometer (Compass) Board – LSM303 from Adafruit. This module will allow the lamp to know which direction (nominally) it is pointed.

Besides the lamp becoming brighter the closer it gets to a center of population, there is a compass ring which can point you in the correct direction. Prototype 3 with the shift registers is an early concept of the 16 LED’s, albeit in a straight line.

Conceptually it should work this way: the GPS module will calculate the distance between the Lamp and the closest Population Center, and get the numerical direction in degrees. The LSM303 will calculate the local orientation of the Lamp. Then we can compare the two, do some math, and light one of the 16 LED’s. Here is a great example (code) using Adafuit’s NeoPixel’s (warning, loud music):

Right now, the compass module is orienting what appears to be fairly close to precise measurements (using my trusty compass) and the trust sharpie + post-it combination. I just need to build the LED array, but that shouldn’t be too bad, but that is dependent on evolving the case design an additional step.

I am a bit concerned about magnetic interference from the other components, so I will have to find a place for it far away from the battery and the GPS module just in case.




Prototype 3 – Shift Registers

Now that both the GPS subsystem is at a good place and there is some material exploration going on, it is time to look at how to turn on a large amount of LED’s.

Photo by SparkFun

Shift Registers are fun little digital circuits where all they do is continually cascade bits, shifting in the data present at input and shifting out the last bit. The nice result is that you can drive multiple items – such as large array of LED’s – with only three pins: a clock pin, a latch pin which stores the data, and a data wire. I don’t know the upper limit, but at some point there becomes too many IC’s to sync at the right speed and you have too many LED’s to run off of the given power.

So now I can drive a n = (∞ − 1) amount of LED’s for the lamp itself, with power being the limiting factor, and have room for other items.  The upshot is that I can now easily drive the Compass subsystem –  an array of 16  LED’s which correspond to the 16 cardinal directions. Combining the GPS output from Prototype 1 with two shift registers was easy – with the help of Serial to Parallel Shifting-Out with a 74HC595 from Arduino. Mostly it is a lot of wiring and making sure that you have the clock, latch, and data wires connected properly. The hardest part was finding enough resisters to connect all the LED’s so they wouldn’t short out.

Here’s a photo of the prototype board, on the roof once again since the GPS module is having a hard time acquiring a signal from the satellites.

Prototype 3


Prototype 1 – GPS Module

This is the first time I have seriously worked with Arduino’s and physically building electronics, I wanted a way for me to remember what happened and document the many failures and few successes I will have.

Because the Lamp will have a series of different subsystems, I wanted to prototype and test out each one individually, because I don’t have a fully clear picture of what and how this project will evolve. I figure I have the following major subsystems:

  • GPS subsystem
  • Compass subsystem
  • LED lamp subsystem
  • LED directional subsystem
  • Power subsystem
  • Enclosure

I started with the GPS subsystem first, since I didn’t want to blow up anything messing with Lithium-ion batteries, and the GPS subsystem is the most important part.

I used an Arduino Pro Mini 328 – 3.3V/8MHz (buy: Amazon or Sparkfun) because I was worried about both size and power consumption. If this lamp was going to be the smallest and most portable lamp I could make, then I wanted to make sure that I wasn’t wasting space with the full Arduino shield.

GPS Prototype 1

With the choice of Arduino board my base voltage and speed was decided, I could then choose the GPS module. Sparkfun has a very nice GPS Buying Guide which helps put all their modules side-by-side. I chose the  GP-2106 SiRF IV with GP-2106 Evaluation Board to connect it to the Arduino based on current draw and size. One warning: this GPS module is very tiny with a tiny ribbon cable – through my testing both are a bit  fragile. The GP-2106 Evaluation Board is a nice way to connect the GPS module, but is also a bit finicky. That’s a technical term, but the problems I was having was to wake the GP-2106 up from sleep, which you theoretically can do by pulling the ONOFF pin on the GP-2016 Evaluation Board LOW then HIGH like thus:

void gpsSTARTUP () {
 digitalWrite(gpsPin, LOW);
 digitalWrite(gpsPin, HIGH);

void setup() {

It would sometimes work, but the GPS module needed unobstructed view to the skies to acquire a signal, which would often take between 60-120 seconds. Which is quite the bummer when you want to test your code, but on a nice summer NY day, and excuse to go to the roof is a good excuse.

Once I got a clear GPS signal, then it was bang-on easy to do something useful with it. This isn’t due to any competence on my part, but because of  the TinyGPS++ library by Mikal Hart which is just amazing. There are many examples included with the library, so it is pretty straight forward to take the example code and hack it to do something.

I was most interested in finding my exact location, then comparing it with a list of known coordinates, then lighting up a series of LED’s. In my case, the Mean and Median centers of population were the known coordinates. To do this, a quick FOR loop is sufficient to iterate though the 40 sets of coordinates and saving which one was closest so far. If I had a bigger dataset then this might not be the most efficient, but luckily the US has only been around for 22 censuses, and the data isn’t going to change with a quick velocity so I can kludge through it. It is super easy to get the distance and course to the destination using the TinyGPS++ library – there are simple hooks you can use to get all sorts of nice information from the GPS receiver.

Here’s the code:

 const int COORD_NUM = 40;
 double popArray[COORD_NUM][4] = {
 {0, 600, 600, 0},
 {1790, 39.27500, -76.18667, 0},
 {1800, 39.26833, -76.94167, 0},
 {1810, 39.19167, -77.62000, 0},
 {1820, 39.09500, -78.55000, 0},
 {1830, 38.96500, -79.28167, 0},
 {1840, 39.03333, -80.30000, 0},
 {1850, 38.98333, -81.31667, 0},
 {1860, 39.00667, -82.81333, 0},
 {1870, 39.20000, -83.59500, 0},
 {1880, 39.06889, -84.66111, 0},
 {1890, 39.19889, -85.54806, 0},
 {1900, 39.16000, -85.81500, 0},
 {1910, 39.17000, -86.53889, 0},
 {1920, 39.17250, -86.72083, 0},
 {1930, 39.06250, -87.13500, 0},
 {1940, 38.94833, -87.37639, 0},
 {1950, 38.83917, -88.15917, 0},
 {1950, 38.80417, -88.36889, 0},
 {1960, 38.59944, -89.20972, 0},
 {1970, 38.46306, -89.70611, 0},
 {1980, 38.13694, -90.57389, 0},
 {1990, 37.87222, -91.21528, 0},
 {2000, 37.69699, -91.80957, 0},
 {2010, 37.517534, -92.173096, 0},
 {2010, 38.472967, -87.410365, 1}, //begin median center
 {2000, 38.75644, -86.93074, 1},
 {1990, 38.96528, -86.53139, 1},
 {1980, 39.31667, -86.13750, 1},
 {1970, 39.79528, -85.52861, 1},
 {1960, 39.94028, -85.28333, 1},
 {1950, 40.00333, -85.03917, 1},
 {1950, 40.00333, -84.94750, 1},
 {1940, 40.07167, -84.66973, 1},
 {1930, 40.19778, -84.60973, 1},
 {1920, 40.19778, -84.73334, 1},
 {1910, 40.12583, -85.03333, 1},
 {1900, 40.05889, -84.81694, 1},
 {1890, 40.04751, -84.66694, 1},
 {1880, 39.95000, -84.12000, 1}
 // 0 for Mean center, 1 for Median center

void loop() {
 for(int i = 0; i < COORD_NUM; i++) {
 unsigned long distanceKmToLocation =
 (unsigned long)TinyGPSPlus::distanceBetween(
 gps.location.lng()) / 1000;

if(distanceKmToLocation < ClosestSoFar) {
 ClosestSoFar = distanceKmToLocation;
 ClosestIndex = i;
 ClosestYear = popArray[i][0];
courseToPoint =
cardinalDirection = TinyGPSPlus::cardinal(courseToPoint);

Once I had this, then getting the Arduino to do something with the data was fairly easy, in this case lighting up an array of LED’s depending how far away from the target coordinates we are:

GPS Prototype 1B


For those wondering at home, here is a breadboard view and a schematic view:


Prototyp1 bb Prototyp1 schematic


Some thoughts:

  • Gee is this GPS module a pain. I think I will have to try out a few different modules.
  • If I want a lot more LED’s I will run out of space on the Arduino soon. Looks like I need to find alternative means of driving a larger number of LED’s.
  • Prototyping on the roof can be fun, sometimes:

Rooftop Prototyping