Dedicated onboard GPS Tracker

Discussion in 'Mapping & Navigation' started by krussell, Jan 8, 2018.

  1. krussell

    krussell Long timer

    Nov 19, 2009
    Portland, Oregon
    I confess to doing a really poor job of keeping track of my tracks. I’ll grab them off a GPS if I want to share right then, and I’ve got some in basecamp. That would be some in basecamp on my home laptop, and a few on my work laptop too. Then there are some on facebook, and posted to advrider, and saved in google maps. Oh, and then there’s some in spotwalla. Plus all my inreach history @ inreach.

    But the bottom line is I don’t have all my tracks in one place, anywhere. That’s a real bummer, as they are quite an asset. I’ve been frustrated with this for a while, and have tried various ways of doing ‘better’, but things are still a mess. I’ve thought about various phone based apps, but never found any that worked the way I wanted them to. The GPS captures everything nicely, but to save it or share it I’ve got to hook things up, merge track segments, have the right computer at the right time.

    What I really want is for this to be fully automated. I want to be able to go ride, not think about it, and when I’m done for the day I want to go to the web and be able to download a track, or view it in google maps, and store it safely forever. I want full resolution, not a summary, and I want access as GPX or KML. I’d like to pull the inreach data as well, without going to inreach to get it. And for all the tracks I have captured and saved over the years, I want them in the same place.

    There’s bits and pieces of solutions that do this, or most of it, in one way or another. But I’m convinced to get what I want, with the level of automation I want, that I’m going to have to do it myself. I’ve thought about it for a while, and I think it shouldn’t be too hard and there’s some learning opportunity along the way. So I’m going for it. There’s going to be three parts.

    - An onboard tracker that gets built into each bike, and leverages my cell phone hotspot to send track data to the cloud.
    - Track storage in the cloud, with some background processing to organize things, and to pull from inreach.
    - A web application that allows visualization of a riding period, and provides the ability to download tracks as GPX or KML.

    The GPS tracker will use commodity hardware to run Linux. I’ve built it and done some testing with good results. I’ve got to work out a case, but otherwise I’m pretty well set. Hardware includes:

    - Raspberry PI 3
    - Mausberry Circuits Car Supply
    - GPS HAT (I’m using a BerryGPS w/IMU at this point but may move to Adafruit to get HW real time clock.)
    - SD Card for Data Storage

    In order to upload data to the cloud I’m using my cellphone as a bluetooth hotspot. I get 10GB of hotspot data per mo w/Verizon, and don’t really use it for anything else, so that part is free.

    The tracker uses the gpsd library to obtain gps fixes. The script pulls fixes from gpsd and inserts them into a sqlite3 database. The script periodically queries the database and uploads blobs of track points to google cloud storage formatted as json. Bluetooth is enabled only for the duration of the upload transaction to minimize phone power consumption. I know, I should just power the phone, but I don’t typically. Once a set of points are uploaded they are deleted from the database. I’m currently logging position every second and doing an upload cycle every five minutes, but that’s configurable.

    I need to work on making sure the upload works reliably in the absence of cell coverage. It only deletes points once the upload has completed, but I haven’t tested to make sure it fails nicely when there is no cell coverage.

    The Mausberry Car Supply handles converting bike power to 5V for the Raspberry Pi, and has a script ( and some control circuitry that allows a clean shutdown on the RPi when the bike is shut off.

    For track storage in the cloud I’m using Google Cloud Storage, but I could just as well have used Amazon S3 or equivalent offerings from others. The Google choice was based on their free usage quotas. I should be able to store all my data, transfer as needed, and perform background processing entirely within their free usage quotas.

    There’s some background processing that I’m currently doing at home, but will move to a virtual machine at Google soon. The hardware tracker just uploads blobs of track points periodically, the background processing coalesces them into daily blobs.

    The web app hasn’t been started at this point, and this is where I’ll be learning the most. Everything else is stuff I know how to do, the web app will be more of a challenge.

    I know there’s been a lot of folks that have done this, but I wanted to give it a shot. My plan is to share enough hw details and all of the code so that others can replicate if desired. I’m doing this for the fun of it, and it’s a spare time sort of thing. I’m not sure how long it will take to do everything, but I definitely plan on having the logging and storage parts in place quickly so that I can start building track history ASAP. I’m new to github, but my plan is to share all the code there.

    Longer term I’ll likely play with CAN bus monitoring, and IMU data logging, but right now I’ve got a track problem, and I want to very robustly solve that before pursuing other data.

    Here's the current HW block diagram:


    And a very high level SW block diagram of the on board tracker:


    And the hardware on my desk, waiting for a case:

  2. ohgood

    ohgood Just givver tha berries !!!

    Sep 21, 2010
    that's a LOT of track data to cull/sort, after the fact. i've found it's a really good practice to immediately name and sort tracks/waypoints directly after recording them, instead of trying to put it all together a day/week/month later. mostly this is because of the number of tracks, waypoints, audio notes, geotagged photos, etc that has to be sorted through.

    it would make life a lot easier to store your waypoints / tracks in a temporary (by definition) database entry like "TODAY" and then cull them directly after stopping the track. if the track is just a milk run, uninteresting ride to blah, or similar, it gets culled immediately. doing this has cut my track count for a months of riding/driving/hiking down from 100's to 5 or 10. of those 5 or 10, 1 or 2 might be share worthy/desirable.

    the database is MUCH smaller now, and has higher value. instead of 1500 tracks and 5,000 waypoints, it's 10% of that.

    all of which is of course uploaded to google drive, mega, gpsies, googlemymaps, and other online hosts, twice or three times a week. i don't remember, it's automatic ;-)

    no matter what you use to record hardware wise, and store software wise, the real issue is the culling process. dumping all of them from one bucket to another is super easy/fast, but having them culled and descriptive beforehand, that's the important part.

    just dump all your tracks into one bucket , take the time to make their names descriptive, sort if you want, and then mirror that to online storage. then each time you record one that matters, upload it AFTER its named and sorted. smaller database, higher value.

    btw- keeping all my tracks (that matter) on my phone is the easiest, most portable, and easily backed up solution I've found so far.