Showing posts with label raspberry pi. Show all posts
Showing posts with label raspberry pi. Show all posts

Thursday, December 7, 2017

AutoBSP Gets Your Geppetto Board Booted

What is AutoBSP

AutoBSP is a new service offered to Geppetto designers that accelerates board bring-up by customizing a boot configuration file -- a device tree -- for every design.

Quick, What Is a Device Tree?

Device trees are logical maps of the hardware connected to a processor. Linux bootloaders can make use of them to help multiplex GPIO pins, assign addresses to external devices, deliver device settings to kernel modules, and control the SoC’s power-up sequence.

Device tree source (DTS) code is compiled into binaries -- or device tree blobs (DTBs) -- and added to the boot partition of a device’s disk image. The bootloader then reads this DTB and configures the SoC and the operating system with help from its contents.

The SoC, its application-specific processors, programmable power systems, and connected devices are broken down into a tree of nodes. Each node contains vital information about its configuration, voltage levels, GPIO assignments and interrupt vectors. These are used by the kernel and drivers to bring up, operate and expose them to the userspace.

Why Should You Care?

One SoC, many devices: Just a few NXP i.MX 6 boards

In an ecosystem where, for any given SoC, there may be tens of SBCs, compute modules, or expansion boards, board bring-up can be an incredibly difficult challenge. The inclusion of device tree support in the Linux kernel facilitates the process by adding a flexible abstraction layer between the firmware and the hardware, removing the hardware description from the kernel.

Device drivers can be written to glean variables, parameters, and logical addresses for the various hardware components and chip features it needs to operate from the device tree; Regulators can be programmed and sequenced; Chip features can be activated and disabled.

Your Geppetto Board is Unique to You

Let’s say you’ve just designed and ordered a custom board using the Geppetto interface. You have included a Linux-ready COM and a particular collection of sensors, ports and devices that suit your application. That board will be in your hands in a few weeks, tested and ready to go. Gumstix will offer our own flavour of Yocto Linux through our storefront, as well as developer documentation, spec sheets, and other helpful resources.

With almost 200 modules available in the Geppetto library and more added regularly, there are endless possible arrangements that your design might take and it’s possible that you’ll want it running some flavour of Linux. It’s our goal to offer you as much support and information as possible to help get your platform up and running as fast as we can get it in your hands.

AutoBSP is Unique to Your Geppetto Board

Normally, someone would have to manually create a device tree to bring up the components on your board, meticulously adding, tweaking and debugging each node until all of the devices work as expected. AutoBSP delivers a working, compiled device tree specific to your design on demand.

This means that, as soon as the product is in your hands it will be ready to run, saving hours of development and testing. AutoBSP is one more way that Gumstix is accelerating your time to market by getting your prototype designs ready for development as fast as we can deliver the hardware.

SoC and Compute Module Support

Most Linux-ready COM connector and Processor modules are supported by AutoBSP, and the rest are on their way. Here’s some detail:

What AutoBSP Can Do:

AutoBSP will currently build DTBs for boards designed for the majority of platforms available in Geppetto. The following COMs and SoCs are currently supported:

  • Gumstix Overo and Overo STORM COMs
  • Gumstix DuoVero COMs
  • Toradex Colibri iMX6 COMs
  • Toradex Colibri iMX7 COMs
  • TechNexion PICO iMX6 COMs
  • Raspberry Pi 2/3 and Raspberry Pi CM/CM3
  • AM335x (Pepper) SBCs
  • AM437x (Poblano) SBCs
  • SCM-iMX6 (Cobalt) SBCs

What AutoBSP Will Do:

Just like Geppetto, AutoBSP is constantly expanding to accommodate the needs of its users. Expect support to grow as new SoC modules are added to Geppetto. Some additions are already underway.

  • BeagleBone Black
  • Arduino-supported MCUs
  • 96Boards CE (Dragonboard 410C)

Wait, Did You Say Raspberry Pi?

That’s right. When you design a Raspberry Pi HAT, or an RPCM expansion board, AutoBSP will deliver a DTB overlay specific to your board. That’s one file to configure I2C devices, assign GPIOs, and activate SoC features. If you’ve gone and purchased a Gumstix Pi HAT and you’re looking to get started quickly on your next maker project, the AutoBSP-generated dt-overlay will help you skip much of the trial-and-error setup procedure you deal with for other HATs and get you coding as fast as possible.

Copy AutoBSP’s DTBO file to your Raspberry Pi boot partition’s ‘overlays’ directory and change the ‘dtoverlay=’ string in ‘config.txt’ to match and the Linux kernel will ‘see’ your board and its devices when it starts up.


At Gumstix, we are constantly looking for ways to make our lives easier. The benefit is that we pass these helper services, or their benefits, along to our clients. It started with the COM. Gumstix pioneered the idea in 2003 with the Verdex and Verdex Pro - a Linux-ready compute device the size of a stick of gum. This enabled hardware developers to test, prototype and deploy their designs more easily, encapsulating the compute power in a single, replaceable module.

We carried the idea forward ten years later when Geppetto was born. We further modularized the concept of the computer by introducing hardware as feature modules on a virtual board. Start with a COM connector, drop in USB, Ethernet, and any of the ~150 modules in the Geppetto library to build your own development board, prototype or production device. Click 'Complete Design' and Geppetto generates the CAD files for you and sends them to our engineers for review.

Geppetto now takes advantage of all of the back-end data that Geppetto uses to render your board as well, providing extra resources for engineers and developers. Through the 3D preview feature, users can export the 3D rendering of their device to an STL file.

AutoDoc delivers valuable signal and connection data on the fly before your design is even ordered. It includes links to reference manuals, feature outlines, signal descriptions and their associations, and much more.

Now, AutoBSP goes a step further and gives you the files you need to get Linux up and running. With a featured Yocto image from Gumstix and an AutoBSP DTB, you will have your board running in minutes instead of days.

You can expect to see more of these types of services to crop up from time to time as we discover new ways of making your life easier.

Just One More Reason

AutoBSP is just one more reason why Geppetto is THE design-to-order tool for IoT, embedded, and robotics hardware. Test-drive Geppetto today at and create your next innovation.

Tuesday, September 5, 2017

Updates: Intel Joule, LoRa, Arduino and Protocase

Blog Break

It has been a while since I posted a blog entry.  I have been knee-deep in a challenging internal project and haven't had much time to come up for air.  Today, I've got a chance to reflect on some of the things that have been happening here at Gumstix and share my perspective with you.

First, there's the EOL announcement from Intel that blindsided the x86-focused IoT community:
 the Joule, Edison, and Curie modules are soon to be no more than a footnote in the history of embedded computing.

Also, Just recently, hardware support for LoRaWAN was added to the Geppetto module library and 3 LoRa boards were released.  I got to play with that quite a bit.  It also brought with it an ATmega32U4 Geppetto module, supplanting the Curie module as our primary Arduino-compatible MCU.

Finally, I've been talking a lot with Protocase.  These guys are cool.  They provide design and production services for custom small-run enclosures, rackmounts, brackets, and consolets. I'm very excited to see what they're making for me.

Intel EOL Announcements and Me

I'll admit it, I took the Intel Joule news harder than maybe I should have.  I spent a lot of time working with it and it's carrier boards.  I was looking forward to putting the GadgetDrone in the air with the AeroCore 2 for Joule, the Caspa HD and one of the RealSense point cloud cameras we have at the office.  I liked the idea of setting up my Workstation board in a 3D-printed enclosure as a Yocto build slave.  Oh and I still hope to test the Caspa 4K's "tone-mapping (Er, I mean HDR) Video" mode.

I was also sad to see the Curie go.  Working with our Radium 96Boards IE board is a lot of fun.  It had been a while since I'd worked at the MCU level.  Bare-wire programming on an 8051 and using a dual-Arduino Uno plus ZigBee robot controller were highlights of my academic career, but I haven't done anything of the sort since.  The Radium's nice and small, IE compliant and has all the cool features of the Curie, like Bluetooth, 6-axis IMU and Neuron pattern recognition nodes.

For whatever reason, Intel decided to terminate their IoT-targeted endeavors.  Maybe it was the slow - and sometimes negative - response from the community.  It's also possible that the challenges in providing software support for their hardware were more monolithic than anticipated.  Either way, the Joule, Curie and Edison are gone.

For all of you who jumped on board with Intel's IoT hardware just over a year ago, I empathize with your plight.


If you're into IoT, you may have heard of LoRa, LoRaWAN and the LoRa Alliance.  It's a communication protocol for sub-GHz long range LPWANs, and it's sweeping Europe and North America's IIoT industry.  It works like this:  

You set up a Gateway. This is the equivalent of a WiFi router in your home, but the difference is these things can have a range of up to 15 km, depending on the quality of your antenna.

You deploy nodes.  These are your data acquisition points - temperature, presence detection, air quality, etc.  Whatever you need to know.  Put them where they need to be and hook them up to a battery, solar panel or hamster wheel (No hamsters were harmed in the writing of this blog post).  The idea is that they require very little power to run and can last anywhere from a week to several months on a single charge, or indefinitely with solar.  These tend to have a range of 2-5 km.

You monitor the data and use it as you see fit.

Gumstix released a gateway/concentrator and a transciever module in Geppetto, as well as a gateway dev board for both the Overo and the Raspberry Pi Compute Modules (Overo Conduit and Gumstix Pi Conduit boards), and a weather station sensor board (Strata Node).  They're in the store and available in both North American and European frequency bands.

Once I had my Gumstix Overo Conduit gateway and an RHF0M301 gateway/concentrator module in hand, I was impressed with how quick and easy it was to set up on  The Strata node I recieved was pre-release and hadn't had the bootloader flashed yet (they come pre-flashed now), so it took a little longer, but writing a sketch and setting up a project on TTN and went super-smoothly.  It just so happens that I made a bit of a quick-start video:

Arduino Stuff

Arduino is a great thing.  For artists, makers, inventors, amateur developers, and teachers, it's a great way to avoid the challenges of bare-wire programming and get physical objects doing what you want them to do.  For professionals, it's a good prototyping tool, delivering your proof of concept to the project manager in hours or days instead of weeks (or worse).

Adding the ATmega32U4 to the Geppetto library means I'll get a lot more time to play with Arduino hardware, projects, board support, and the IDE.  It also means that there will likely be more Arduino boards coming to the store and hardware modules coming to the Geppetto library.

I'm also going to have to find a quick and easy way to set up my 'arduino_pins.h' file.

Discovering Protocase

If you've seen my previous posts, chances are you've seen my low-tech enclosures, mounting brackets and test environments.  My indoor quadcopter test flight had a paracord tether tied to the rafters so that I didn't give my co-workers a hair cut.  I like to think of it as ISRU (In Situ Resource Utilization).  However, in some cases, a solid, well-made case is more than just a good idea.  When I went shopping for enclosures for my Overo Conduit board so that I could deploy it outside, my boss pointed me to  I think he just wanted me to stop asking for a 3D printer for the office.

These guys are awesome.  They're working on something for me and I can't wait to show it off.  They have a huge variety of custom products: L-shape, U-shape 5-sided, milled aluminum, and more!  They'll build from your CAD drawings and have free templates to help get started.  They even have their own design software for you to use.  If all else fails, they will work with you and design a fully customized enclosure for your device.

If you've got a prototype, an invention or a first-run for a kickstarter campaign, Protocase might be for you.  Just check out their page and see for yourself.

To Summarize:

I've been busy.  From grinding away at that internal project to working on LoRa and Arduino board support to designing enclosures to recovering from the Intel IoT fallout, I've hardly had enough time to catch my breath.  Now that things are settling down a bit, I am looking forward to spending more time telling you all about the cool stuff I'm working on.

Friday, March 17, 2017

Gumstix Pi Compute Boards are CM3-Ready

If you follow me on twitter (@gstixguru), you might know that I recently ordered an RPi CM3.  Lots of people have been contacting us to find out how well our Pi Compute boards support the new, faster module, so I found a bit of time to play around with it.  I'd worked with the original CM on our dev board for my GPS and RTK project a year ago with great success, and was looking forward to getting back to the Pi Compute boards.

First Steps

As always, my first step was to flash a brand new image onto the CM's eMMC.  I downloaded the latest Raspbian Jessie Lite ISO and mounted my CM on a Gumstix Pi FastFlash.  Next, I ran rpiboot, plugged the board into my USB hub and CROSSED MY FINGERS!

RPi CM3 on a FastFlash getting flashed. Pardon the clutter.
So what happened next?  Exactly what should:  the eMMC was mounted to my file system like any unpartitioned flash drive would be.  So I dd'ed the image, moved the module over to the Gumstix Pi Compute Dev Board and got ready to Pi.

First Boot

At first, all I wanted was proof of life.  That and I was sure the default wpa supplicant and network interfaces config would not get me on the WiFi network.  So I screen'ed in and powered up the board.  And yes, the console came to life, spewing forth those familiar Linux startup messages.  No kernel panic, no errors, no problem.  So far so good. Raspbian Lite was up and running.  Oh, all the things I should test: GPIOs, I2C, SPI....  BORING!

Let's start with USB (Oh, and get the WiFi up and running while we're at it; screen is not my friend and SSH makes me smile:).  The WiFi dongle goes into the port and lsusb shows a list of devices.  And there it is.

Bus 001 Device 002: ID 148f:5370 Ralink Technology, Corp. RT5370 Wireless Adapter

Beautiful.  I fix up /etc/network/interfaces and add the office WiFi network to wpa_supplicant.config and shut it down.  Time to set this asside and get back to my other tasks.

Day 2

Before ditching the USB console connection, I have to go into raspi-config and enable the SSH host, and reconfigure the daemon:

sudo rm /etc/ssh/ssh_host_*
sudo dpkg-reconfigure openssh_server
After a restart, ssh works fine.

Let's got straight up the food chain to the camera!  That's what I want to see!  I want to get that Sony IMX219 taking stills and recording videos.  I want to see those LVDS signals in action.  The CSI-2 camera connector is by far my favorite feature of the dev board.  So while I was in raspi-config, I made sure to enable the camera as well.

Here's my Frankenberry Pi camera rig, ready to go, I hope.
So I hooked it up, fired up the module and... nothing.  Did I forget something?  Of course I did! I needed the device tree overlay blob for the camera.  Oops.  OK, so I grab the binary, -- I get the one for both camera and display, just because I can -- copy it to the boot partition and restart.

And did it work?  See for yourself:
Me and my clipboard.
Edit: Here's me trying to pretend I'm not being recorded by the Pi Camera:


I also took a few minutes and got the USB-Ethernet board fired up, and yes, everything works great.
I am very happy.  Stay tuned!  I have a Raspberry Pi DSI display around here somewhere and I want to get that up and running too.

Friday, May 20, 2016

RTK Rover Project Chapter 1: RTK and RTKLIB

Not long ago I posted about getting the Pre-GO PPP GPS modules up and running on BeagleBone Black with our Gumstix BBB Rover cape.  Now that I have them working on both this and the Gumstix Pi Compute Dev Board, it's time to take the GPS fun to the next level.  So what can we do with two incredibly accurate GPS modules running on tiny devices?  How about Real-Time Kinematics?

RTK eliminates the jitter experienced by solitary GPS receivers using differential techniques.  It requires a base station with known co-ordinates and a mobile reciever. By using the difference in signal-to-noise (SNR) ratios and phase for common satellites, RTK algorithms can cancel out atmospheric effects that can pollute geopositioning results.  I won't go into incredible detail here since Navipedia has a great wiki on the subject.
This image shows the GPS/GNSS data in pink and the RTK results in green of a rover driving around in a  6-meter circle.

So why do we care about RTK?  It's primarily used for surveying, but there are many situations when a robotic rover may want to track its path, report its exact position or navigate to a given waypoint with a high level of accuracy.  That's what I'm excited about.  I'm going to rig an automated robot with a BBB and Rover cape, use my RPCM rig as a base station and use the GPS data to control the rover.

First we have to get some RTK software up and running.  There aren't a lot of options for this in the open-source world, but the biggest name is RTKLIB.  It's not only an open source library, but it also includes a complete set of GUI and CLI apps to get you started.

Sadly, the GUI elements are written for Windows, so there's no chance of using them on the Pi Compute dev board, and I'll have to monitor operations from my laptop.  But the str2str and rtkrcv command line programs are the two most important elements of the software suite for my needs. these applications, and eventually their source code, will be the backbone of the RTK project.  The easiest way to compile these for ARM Linux is to download the source code onto your BBB and Raspberry Pi and compile them natively.  I ran into a little linking problem after I cross-compiled the applications on my PC and tried to run them on the COMs.  In the end, it was just far less hassle to go native.

Having set a precedent with the Gumstix Pi Compute Pre-GO PPP project, I felt I had to build a fancy box for my Gumstix BBB Rover.

I got the COMs equipped with their expansion boards, Pre-GO PPPs and antennas and wrapped up in a nice package.  With the RPCM being my base station, I used a Pre-GO PPP SMA so I could use a more sensitive antenna.  This will get me a more accurate fix on the rover's position.  The antenna I'm using is the Dominator AA.161 from Taoglas.  The BBB Rover has an on-board TI WiLink8 WiFi and Bluetooth modem that requires a u.FL antenna, and I'm using the Pre-GO PPP with the built-in antenna.

With the binaries and data files on the boards, I started experimenting, streaming data from the COMs to my laptop and trying to get a fix.  I tried a myriad of config files and, after some digging, I put together this file. The commands therein are transmitted to the u-blox NEO-7P on the PPP boards and instruct them to transmit tuples that are normally blocked across the UART channel.  These strings carry the phase data of the satellite signals which RTKNAVI, the GUI I use on my laptop, uses for RTK solutions.

After some trial and error, I began to see SNR data.  It looked something like this:

The top graph is the data from the BBB, and the bottom from the RPCM.  Each bar represents the SNR from a satellite.  In order to get a solution, the two computers have to be able to get a strong fix (shown as a colored bar) on several common satellites.  Unfortunately, the window in the office only provides half a constellation.  Not nearly enough for RTK... Barely enough for a single fix.
My little computers are getting their fix.  Tux is helping.

 Clearly, I need to get outside.  That'll have to wait until next week.  In the meantime, I'm all set up, apart from a battery pack for the BBB, to do some real testing.

NEXT TIME: The great outdoors, differentially.

Monday, May 16, 2016

Gumstix Pi Pre-GO PPP Project Chapter 5

I took my equipment to the tennis court yesterday and gathered some data.  When I arrived, I was saddended to discover that the two main courts were occupied so I went to the last one. Ten minutes at each of the eight corners I'd mentioned before  gave me quite a bit of data.  When I plot it on Google Earth, it looks like this:

OK so something's wrong.  First off, the orientation Google's image is clearly incorrect. Secondly, there's that tree!  It's covering the entire back-right corner!  I might be able to go again some other time, but let's make some observations first.  Looking at the inner corners, [LBS, RBS, LFS, RFS], the dimensions are reasonably correct.

What it looks like to me is that the court sits on a slope, which I hadn't considered to be a major source of error.  I had assumed that the courts would be level but, having been there for some time, they have most likely sunk in places and bubbled in others.  I may have had more luck had I acquired access to Wimbledon,  but the fact of the matter is I'm trying to measure exact distances with chunks of metal free-falling high above the earth and no fixed point of reference on a surface with random elevations.

Here is my conclusion for this project:  The Pre-GO PPP works beautifully with the Raspberry Pi Compute Module through the Gumstix Pi's UART breakout connection. It is able to measure GPS position with decimetre-level accuracy and sub-decimetre jitter.  However, measuring distances with sub-metre-level accuracy is next to impossible using GPS coordinates alone.

There are many reasons.  First off, environmental factors, such as trees and bridges will drastically increase dilution of precision.  Reason number two is explained above.  Lastly,  I can't seem to get enough court time to collect all my data points.

Clearly, a new strategy must be employed.

Up next: BBB Rover and RTK

Thursday, April 28, 2016

The Gumstix Pi Pre-GO Project Chapter 4: Tennis Anyone?

I went to find the survey marker from and discovered that it was directly under a bridge.  It's also in the middle of a road.  I think that the coordinates they're publishing are not as accurate as I would like.  Strangely, there does not appear to be any more markers in the near vicinity of the office.  In the absence of an accurately located marker, I'm going to try and measure the dimensions of a tennis court with GPS data.   
So far, I have been very impressed with the Pre-GO PPP's performance.  I took it out for another field trip recently and had very nice 0-8 cm diameter groupings.  HDOP has been consistently near and below 1.0.  Geodetic engineers and surveyors would be pleased as punch.
I intend  to define the outer bounds of the court and the service lines within.  If I draw a 11x24m box with an 8.2x13m box smack in the middle, the test will be a success.  These measurements are based on the regulation court dimensions outlined in the image to the right.  I'm also considering measuring the accuracy of the altitude measurement.  The net is 1.6m high and if I can get that measurement from the base of the net post to the top, that will be an interesting data point as well.
The difficulty I have faced with my setup has not been the hardware itself.  This has performed perfectly throughout my experiments.  The issue has been with logging and interpreting the data.  I have been using my cellphone as an ad-hoc network router to ssh in to my Pi and during one experiment, the connection between my laptop and my GPS rig kept dropping out.  As a patchwork solution to this issue, I have added a physical connection to the RPi's system console: Just a short USB microB-to-A I can connect to with an extender cable.  If the WiFi drops out, I can just plug in.

Added to this is the fact that, in general, GPS modules spit data out once per second.  The Pre-GO PPP is no exception which means that, for a 1-hour test, there are 3600+ records to process. I'm using Python to interpret and plot the data but it still takes time.
Up next: RESULTS!

Monday, March 7, 2016

The Gumstix Pi Pre-GO Project Chapter 3: I can't Rely on Google Maps.

There was a nice break in the weather yesterday and I managed to get outside to take some readings.  I set up on an exposed hilltop with my laptop, my Pre-GO-to-go and my smartphone.  I was hoping that I might find some kind of survey marker with exact GPS coordinates at the base of the flag pole, but no such luckI fired up my Pi, gave it a few minutes to warm up, and connected it and my laptop to my phone's WiFi hotspot.

With no guarantee of clear weather, I decided to do a quick test and grab four different data snapshots over a 15 minute window.  I'll formulate some more informative tests for when the weather is better.  For now, I just want to see how accurate it is.

The PPP in Pre-GO PPP stands for Precise Point Positioning.  PPP provides centi- to decimeter-level accuracy so, even if Google doesn't drop its pin directly on the flagpole, my data points should be very close together.  I have to assume that Google Maps co-ordinates are going to be somewhat skewed.  Without an accurate geodetic survey marker, I can't be certain.

When I got back to the office, I dropped some pins on the map and here's what I came up with:

The outlier is my initial result.  The tight grouping south west of it are the three other results I recorded.  They sit about 1.5m away from the outlier but are all within 12cm of each other.

I found this blog post that confirms my assumption about Google's geodetic accuracy.  If you compare my Maps screen shot to his, it looks like the skew is about equivalent.  I trust my results over Google's now.

So I still have not concrete baseline measure of accuracy.  I really want to know if my horizontal co-ordinates, when HDOP (horizontal dilution of precision) is less than 1, are accurate at the decimetre level.

To that end, my colleague sent me a link to, where I found a survey marker nearby.  GPS enthusiasts have, thankfully, taken the time to accurately measure its geographic position.  OK great, but I have been rained out.  I guess the next test is going to have to wait awhile.  While we wait, let's see if the Pre-GO works with the BeagleBone Black and the Gumstix Rover cape.

Next Time:  Pre-GO and the BeagleBone Black Rover Cape

Thursday, March 3, 2016

The Gumstix Pi Pre-GO Project Chapter 2: Pre-GO Packaged to Go

So, while we're debugging the UART header, I thought I may as well get some results from the Pi using the FTDI cable. With the help of a USB hub, a WiFi dongle and some masking tape, I set the Pre-GO up on the window.  I figured if I was going to get any kind of signal anywhere in the office, this would be it.

I SSH'ed in and ran gpsmon. This is a great tool related to GPSD that spits out human-readable GPS data in real time.  It looks something like this:

Yep, my Pi kind of knows where it is... within 10 metres, that is.  Not good enough for a Precise Point Positioning (PPP) GPS module.  I have to get it outside to get accurate geolocation.

Good news! The UART problem was resolved with a single line:


I appended this line to /boot/config.txt and said goodbye to the FTDI converter.  With the bulky USB cable and hub gone I decided to get my gear ready for test.

A circuit board with a delicate makeshift UART connection is not easily transported.  Not to mention the need for a power cord makes taking my rig on the road a bit of a challenge.  No problem. Tape, scissors, and a shipping package, combined with a little time gives you this:



Next Up: Where am I, Precisely?

Friday, February 26, 2016

The Gumstix Pi GPS Project Chapter 1: Break it out and get it running

As my first gadget project as Gumstix Guru, I'm going to connect a Pre-GO PPP GPS to a Raspberry Pi Compute Module by way of the Gumstix Pi Compute development board, pictured below.

Getting Started

I could just build a board in Geppetto with the GPS connector on it, but I've already got my Gumstix Pi in hand.  The Pre-GO communicates over a UART connection, a header for which the Gumstix Pi has.  The trick is that I need to manually rig the connection.  Easy enough.  Let's break out the Pre-GO's header:

I made a point of labelling each one of the wires just to make life a bit easier later on.

Of minor concern is the fact that the pitch of the Pre-GO's header is considerably smaller than that of the dev board's UART header so I had to use a finer gauged wire.  Not a big deal but they aren't a good fit for my jumper wires.  My solution?  Easy:  Fold 'em.

Next I decided to forgo the extra mess of jumper wires and go straight to the jumpers.  A nice way of keeping the rat's nest to a minimum.  Oh, and my labels fell off.

First Power-Up

At this point I'm very excited.  The board's all hooked up, the Pi module is in place and it's time to plug it all in.  Hope I didn't forget anything!
Once Raspbian is up and running, I go hunting for my GPS module to no avail.  What's wrong?  Why isn't it working?

Time to go to the test bench to make sure the module works. 
  • Board configured for 3.3V - check
  • Connectors attached correctly - check
  • Waveform resembles data output - check
So I hook it up to an FTDI-UART adapter and check its output.  Looks like GPS data to me:

The Verdict

Okay so the Pi is working and the GPS module is working, they're just not talking to each other.  So the UART header isn't configured correctly.  I'll get that sorted out later.  For now, I'll just hook it up with the FTDI adapter and get some results.

Next Up:  Raspberry Pi CM and GPSD