GPS logger?

[Gonzzo]

hello all,

after some (late nite) investigations on the internet, I ended up here. I was researching for a cheap GPS logger .. and found many of them, but they were not affordable.

what I am looking for is a little device that would take some NMEA data from a GPS receiver mouse (5V, RS-232), eventually filter out some unneeded data (STX, ETX, etc) and save it into a file (or files) on an SD or MMX card. after some days of travel, I would get the SD-card from this device and transfer the data to my PC for postprocessing.

NMEA data looks basically like this (and that's what I would like to see in the files):

$GPRMC,131700.074,A,4628.8544,N,00716.8242,E,22.13 0221,132.60,260705,,*3E
$GPGGA,131701.074,4628.8504,N,00716.8306,E,1,05,1. 7,1080.8,M,48.1,M,9.7,0000*49
$GPGSA,A,3,08,10,29,28,26,,,,,,,,7.9,1.7,7.7*36
$GPRMC,131701.074,A,4628.8504,N,00716.8306,E,21.89 6268,133.45,260705,,*37
$GPGGA,131702.074,4628.8463,N,00716.8367,E,1,05,1. 7,1081.5,M,48.1,M,10.7,0000*79
$GPGSA,A,3,08,10,29,28,26,,,,,,,,7.9,1.7,7.7*36

(the GPS mouse can be programmed to limit the data to the GPGCA or GPRMC strings. optional postprocessing of the strings might turn each line into something like "time, latitude, longitude, altitude", but this is only needed with smaller SD-cards and very long logging. the strings come in every second. with ca. 80bytes per second, this makes about 48MB for a full week of 24h logging.)

I believe that the following HW thingy would be fullfilling my needs: http://www.compsys1.com/workbench/On...c_project.html

is this correct?

the next step is to have the right software to convert the RS-232 data stream into file(s) on the SD-card (from what I read here on the board, the filesystem on the SD/MMC card is the main challenge). then somehow this code needs to be compiled and transferred into the HW thingy.

frankly, I do not have a clou what to do next. I used to program 6809 and 8051, but that is centuries ago. and I had access to dev-environments at the company I was working for. today, I only have a pc at home...

the greatest thing that could happen is when someone of you has already done something like I want, and would share it with me.

thanks

dan

[NavMicroSystems]

Hmmm, where do I start . . .

ok, let's try to start with the NMEA protocol.

I would focus on one single sentence (like GPRMC) and discard all the others.

Right after reception of that sentence I would extract LAT, LON, etc, and discard all unneeded Bytes.

With some smart code you can squeeze TIM, LAT, LON, and ALT into a 12 Byte (or even smaller) Data Packet.
(with full accuracy!)

Now think about your logging interval:
Does it necessarily have to be one log entry per second?
(wouldn't one every 10 (or 30 or . . .) seconds do?)
And do you really have to log data 24hrs a day?
(even if there is no movement?)

with that kind of data compression and a reasonable logging interval you can minimize Storage requirements.

So some EEPROM or FRAM could probably do.

To save even more memory you could check and
cleanup the log regularly (when the system is idle)

Imagine there is an (almost) linear track from A and B at about constant speed between A to B.
So all you really need is the data for A and B, everything in between can be cleared.

Agreed,
this "cleanup" procedure will require some math that is not that easy to implement having only the Integer brain of a PIC.

However,
the active components for the Logger shoudn't be much more than about $25 (dependant on how much Memory you need)

a PIC and some EEPROM or FRAM

I can tell it is possible,
I have built many systems like that.
(NavMicroSystems)

[Gonzzo]

hi ralph,

thanks a lot for your explanations.

I see that squeezing memory is still in your (engineers) blood ;-) I did a project for a PLD device (A/C & heating controller).. uff.. decades ago, with a 4bit (nibble) processor and 4kB of ROM.. 32bit multiplication with 4bit registers... that was fun..

I would like to use the logged data with some software on the PC. most converter software (like NH-Top50Trans which is also available on PDA's) understand NMEA and will convert it into any other format that is common (e.g. GPX).

the logsize is not important because I want to have it on SD/MMC anyway. and as I mentioned before, even with 80byte/record/s I can let it run a long time until a 64MB SD/MMC would be full. if I would not have the data on SD/MMC, but in a EEPROM/FRAM on the device, I would need to have some sort of download software which also translates the data back to a common format. yet another thing that would have to be created.

I think it's easier and faster to just remove the SD/MMC and put it into the slot each PDA has (or any cardreader). then move the textfile over and use it in the standard PC software...

I still opt for the version with an SD/MMC slot. so the only code that is needed on the PIC is taking the string which comes in on RS232 and write it to a file on the SD/MMC, line by line. perhaps depending on a dip-switch (?), only log very 3 seconds or so (thus discarding all data in between). the GPS mouse can be programmed to send only one kind of string.

if the mouse has no power, there is no data coming in. so, no logging needed.
if the mouse has no reception, the string contains a certain pattern ("V" instead of "A" in the third field, and coordinates of 0, 0).
$GPRMC,104617.997,V,0000.0000,N,00000.0000,E,0.000 000,,260705,,*0E

in that case, repeating logging of that string might be senseless..

thus the code on the PIC does not need to differentiate between data types. just log all that comes in to the SD/MMC (with the exceptions above).


is the SD/MMC filesystem still such a problem?

dan

[NavMicroSystems]

...I see that squeezing memory is still in your (engineers) blood ;-)

Well that's our daily business on those micros

even with 80byte/record/s I can let it run a long time until a 64MB SD/MMC would be full.

Why store data that is to be discarded anyway ?

...if I would have the data in a EEPROM/FRAM on the device, I would need to have some sort of download software...

This is something the PIC could easily do for you.
It would simply send reassembled GPRMC sentences
and since there is a RS232 Interface on board (for the GPS)
you can use it to connect to the PC.
(You wouldn't need any extra hardware)

Of Course you could write a VB application to download the data to a PC, but even something like Hyperterm would do.

is the SD/MMC filesystem still such a problem?

I have never used SD or MMC with a PIC.
(There was actually no need to, as I always "squeeze" code and data.)
(Just to give you an idea: I have NMEA Interfaces running on 8pin PICs with INTRC clock and no external Memory at all)


I have seen PIC Projects with MMC.
So MMC can't be that much of a problem.


This is an interesting project, please keep us posted.

[NavMicroSystems]

To get started all you need is:

- 1x PIC 16F88 (or other)
- 1x EEPROM 24FC512 (or other)
- some 4k7 resistors
- 1x DB9 connector female (to PC)
- 1x DB9 connector male (to GPS)
- a piece of Veroboard or a Breadboard.

I'm almost sure it is possible to squeeze your application into the hardware mentioned above.

[Art]

I realy don't see any need to save every part of the sentences unless
you have to play them back into PC mapping software to trick it into
thinking it's connected to a GPS.

Even if the whole sentence needs to be reproduced, the pic program could
put the correct data into a blank sentence itself on playback, so that '$GPRMC' didn't need to be saved a million times.

You need to read the entire sentence in if you want to check the checksum,
but lots of data can be discarded straight after that.

Playing the data from the device you make into the PC as if it was produced
live by a GPS is one way to transfer files to a PC no matter what media the data is stored.

I am using 16 bytes per entry that includes lat,long,time, valid/invalid,
and must soon include at least part of the date.
one 16 byte entry per second gives 34 min and 10 seconds logging on a
24LC256 EEPROM, and it is easy to connect 8 of them to two wires.

It is good if your pic program can set up the GPS antenna from scratch,
since some of them can 'forget' what they are supposed to be doing.
Also, it would make it possible to connect a new GPS straight to the pic
without using a PC to configure it.
Art.