GPS project: caught up?

The last post brings us up to speed on this project. I have quite a bit more work to do over the next few weeks to get it finished up:

  • I need to finish up the hardware side of the project: This will happen over the next few days, as I have a large order of small parts coming from Sparkfun today!
  • I have to get the rest of the menu options worked out, and functioning.
  • I have to extend some of the functions from the underlying SD card library out to the sketch, so that I can delete files from the Arduino, open and read files, etc.
  • I want to write a helper app for the PC side. It will need to be able to send a few commands via serial, and then stream the file data back to the PC side, parsing the NMEA sentences, and splitting out the way points that I have added via the button menu. Writing the app will simple, but I would like to get it working on mono, so that it is usable on multiple platforms.
  • I would like to make the way points based on some standard system so that they can be easily imported into Google Earth, or other geo aware apps.
  • I want an enclosure! This has been a particularly frustrating part of this project, and one that I’m quite positive I’ll have some lengthy posts on in the near future.

GPS project: portable power percentages

My next task was to get the partially functioning battery monitoring code worked out. I made several different attempts to work out something that I was happy with, before finally settling on the current solution, which may get changed yet again!

Basically the monitor pin on the Lithium Backpack outputs the current voltage of the battery. Knowing that this is approximately 2 – 4.5v I decided to try to use the full range of the analog pin, but build a voltage divider to get a 4.5v reference voltage. I’m not an electronics guy, although I’m learning fast, so sometimes I still get excited about the little victories. Needless to say I was excited about getting a little circuit made out of resistors working! A little math in the code, and I had a somewhat accurate display of the percentage of battery remaining. Well kind of, that is until the voltage dropped. With the bottom end of the voltage range being ~2v instead of 0, the percentage was only partially accurate through the top half of the range.

I decided to use raw numbers instead, and map them to known high and low values. I set up a test sketch to send the analog output to the Bluetooth (so I could stay on battery power, and not plug into the USB), and built a quick and dirty .NET app that would log the data to a text file. I then left the unit running overnight and logged the values from fully charged to shutdown. I ran it again the next day while I was working, and took the lowest / highest values from those two runs as my base points for mapping the % of battery remaining.

I should point out that I’m pretty sure that this is not a 100% accurate method. I bet that if I charted the results I would see that the voltage drop is not constant over the life of the charge. Implementing my current solution only requires a call to map(), where implementing a more accurate solution would require a lookup table with time and voltage parameters, or some math that I’m really not in the mood to deal with at this point!. At the end of the project, if there is memory left on the Arduino, I will come back to this particular feature and investigate a more thorough solution.

I also added a routine to average the percentage; the output of voltage jumps around quite a bit, and once it is mapped and converted to a percentage it tends to constantly hover in a +-3% area. By averaging the last 10 reads I was able to slow the “flutter” down a bit. I may increase the sample rate on this as I refine the code.