GPS Data Logging - Help!

brandonlbrewer

Hello, let me begin by thanking you for viewing my post. I am new to parallax software, but I've heard good things about it, so I decided to give it a try for my project. First, let me tell you the equipment that I will be using:

Propstick USB
MicroSD Card Holder
PMB-688 GPS

The idea is to mount this unit to an RC car and drive it around a track, use the gps unit to store the data in the sd card, then use the csv file to get the data points plotted on google maps. Does anyone have any advice on how to do this? My idea is to have a main function call the gps, get the latitude and longitude values, and store it in a file on the SD card. The gps would repeatedly save points in this same, single file until the gps is shut off. Any code, links, or advice would be greatly appreciated.

Thank you and have a great day,
Brandon

Duane Degn

Andrew Williams has information about his GPS project here.

It looks like he even posted his code.

Ragtop also has a GPS project. I didn't see any code posted as glanced through the thread.

WBA Consulting

Welcome to the forums! A GPS datalogger is a rather simple project for the Propeller. Along with the thread Duane already mentioned, here are two other threads that you should peruse:


Google Earth GPS SD Datalogger
This thread should have everything you need to create a GPS datalogger that creates Google KML files that will import directly into Google Earth (look at my zip file on post #26 and the sample KML file on post #27). I would suggest looking at the KML reference guide as there are a lot of easy tweaks you can add into the KML file that will alter the appearance in Google Earth. I saw a project somewhere that someone did for their car and the Google Earth lines were different colors based upon which gear he was in and the elevation of the path line (height above the ground) was relative to the RPM.

My Propeller based Reverse GeoCache project (the code started from the datalogger thread)

Keep in mind that the accuracy of the GPS you are using is rated at 5 meters, 2DRMS (meaning 42% of the time it will be within 5 meters of positional data received from satellites). This module does have WAAS support which will improve that but the spec sheet does not give further details of accuracy with WAAS enabled (it is enabled by default). In my experience, the repeatability of the position information is within 2 meters, which is fine for most KML datalogging. So, depending on the size of your track, your "path" in Google Earth may be clean enough to get what you want, but it may not be placed properly in the satellite imagery. There may be ways to offset the path data to correct for this if the entire set of path data is offset an equal amount.

Also, the speed of your RC car can affect your logging results, so throttle accordingly! What I mean is that the PMB-688 sends NMEA data strings once per second. It is reading satellite data and calculating position many more times than that, but only sending you a position each second. I would suggest trying a slow drive around the track versus a full speed race around the track to see what differences you come to with your path data. Perhaps several medium speed laps across your course would establish a reasonable path baseline in Google Earth for comparison data.

bomber

Welcome to the forums! I have also been experimenting with the PMB-668 on a mobile platform, and something you may want to keep in mind is that the GPS receiver is especially sensitive to EMI, so there is the possibility that EMI from the motors or motor controllers could cause interference with the GPS's signal. One other thing to check out is the Google Maps API (https://developers.google.com/maps/), which when combined with your language of choice (I use python, but any language with HTTPS support will work), can automate the task of importing the .csv file and plotting points. There is some example code for the PMB-668 here (http://learn.parallax.com/KickStart/28500), and it may be a good idea to enable constant navigation (http://learn.parallax.com/project/constant-navigation-gps), which will refresh the lat and long data consistently for best results. Good luck with the project, and if there's anything you need further help with I or one of the other forum members will be willing to help with

Duane Degn

bomber wrote: »

something you may want to keep in mind is that the GPS receiver is especially sensitive to EMI, so there is the possibility that EMI from the motors or motor controllers could cause interference with the GPS's signal.

+1

I had a GPS logging project and when I used a switching regulator in an attempt to conserve battery power, the GPS could no longer establish a lock on the satellites. I had a similar problem when I tried to add a LCD. The LCD backlight voltage booster caused too much interference for the GPS to lock.

WBA Consulting

bomber wrote: »

it may be a good idea to enable constant navigation (http://learn.parallax.com/project/constant-navigation-gps), which will refresh the lat and long data consistently for best results.

Agreed!

SRLM

Duane Degn wrote: »

+1

I had a GPS logging project and when I used a switching regulator in an attempt to conserve battery power, the GPS could no longer establish a lock on the satellites. I had a similar problem when I tried to add a LCD. The LCD backlight voltage booster caused too much interference for the GPS to lock.

Interesting. My experience is the opposite. I have a design with a GPS a switching regulator (from a 1S LiPo) and haven't had any issues. Maybe it's the low overall power draw and excessive decoupling that I did (one 1uF and 0.1uF for every IC)?