Hi Steve,
we do such a thing when testing our apps.
Let me explain - we first built a wrapper for an existing navigation application. (
http://ttncf.pp-p.com)
So we have a routine the where we have to send NMEA sentences to this navigation software. In the field we do this by receiving the
data via a serial port (you can do this easy with OpenNETCF).
The data (if you use nmea) comes in ASCII strings ended with CRLF. So it is a pretty easy format to read.
Our algo is very simple:
Read single characters from the serial port (you can also read more).
Parse the data for the beginning sign of a GPS sentences.
If found read on until CRLF is found (or to much data was readed or another start sequence was found -- use for easy comm. error
handling).
After we found the sentence this layers informs (via event) an above layer about the sentences.
This layer (I call it "Sentence layer")can
a.) parse the sentences
b.) transfer the sentence to the navigator SW
c.) record the sentence as a single line in a textfile
---or all togeather
This works fine with the device - but it is hard to debug motion data.
Of course we do debug session via laptop and an equiped car (with someone driving it) - but the practice is to work on the desktop.
I don't like emulators (since a real device is most of the time acting different) - but we have an other "problem" - on the desktop
we get only static data from the attached GPS device.
So how did we solve this?
We recorded a lot of GPS Sentences in files - with a working serial port (like OpenNETCF) a recording application is not more than
10 lines of code.
After that we take the files to the desktop - and now (after the serial communication is proofed via device tests) we don't need
real GPS.
We wrote a litte class acting below the "sentence layer". Instead of reading the serial port it reads (via timer) a recorded file
and sends the sentences (lines).
So we can:
a.) simulate real routes on the desktop
b.) change the speed by bringing the sentences in a higher frequency
c.) work with an emulator as well as with a real device
A last word for GPS enabled smartphones - take car a lot of them only have A-GPS which means "Assisted" GPS.
In other word the cell phone provider must support the positioning - if not you have extreme fxing times and often loses of GPS
fixes. Although some manufacturers handle A-GPS as something "pretty cool" it is more or less some kind of "reduced GPS".
If interrested you can see such a recorded tour on
http://aqua.pp-p.net/Tour/Over.htm (German - choose "Streckenübersicht"), or if
you have MS MapPoint 200x you can download the map ("Mappoint Datei zur Tour").
From Mappoint you than can export the data (for an example) to Excel.
By the way - this data was recorded via a webservice to a SQL Database.
Most of the time we use SQL-Stored Data when testing desktop apps - instead of reading a textfile we made some "DB-Info to GPS
sentence" class.
HTH
Manfred
