T&L Publications

I have a GPS (Garmin eTrex) that streams NMEA data over RS232 if you put it in the right mode. I'm using it to map hiking trails.

Thus far, I've simply been using the track log the eTrex has built in, but the accuracy leaves something to be desired. I'd like to capture the raw NMEA values it's capable of spitting out, but I don't want to carry a laptop around with me.

What's the simplest/cheapest way to go as far as building/buying a data logger that would do this? Something that I could plug a DB9 into one end and a memory card into the other with a read/write mode switch would be perfect. In write mode, I'd have the eTrex dumping data to it. In read mode, I would stream data to my PC. Or perhaps, I'd simply unplug the memory card and read it directly leaving the data logger in need of only a write mode.

Help appreciated!

Serial UART + uController with built in local program memory + firmware + USB host controller+ connectors and case + PCBoard for SMT components. Parts cost assuming you can sample almost everything is low but like most small projects, the cost of a 4 layer prototype PCB will run you about $100 minimum (for a few).

It might be a bit easier to eliminate the flash card / USB host interface and just interface the PIC or uController to some local SRAM and read out with the serial cable at the PC later. DRAM and SDRAM may be cheap but it's hard to work with without a memory controller IC. Many FLASH memory work like SRAM and that would be ideal as you would not need to rely on a battery to hold the data.

It should take on the order of weeks to design and build a circuit and a few more weeks to months to write and debug firmware. Depending on your skill set.

Fortunately the serial codes the eTrex uses are standardized and documented. Its been a while but I saw it once.

Rather than design and build from scratch, a better starting point is to use one of those uController development kits with the USB interface already built in. These already have code development kits and part of the work is already done. YOu would just need one of these and a serial UART and that might be it. Or in a slightly different direction, most USB interface boards have some kind of UART and bus interface. Research those products for a starting point also. Some of the devel kits go as high as a few hunderd but I have seen one at just $20 (See TI's MSP430 product line for the EZ430).

Search on "USB development kits" or "microprocessor development kits" or PIC or or or

Oops Double posted

Here's a solution I found on Google:

http://wac.addr.com/ee/visor/visor.html

just so happens I've got a Visor lying around...

Alas, can't even get the parts required to build one of the devices in the link above. That era of Palm devices has gone stale.

Oh well, my Visor heads back to the junk drawer...

I think you can do this pretty easily. I'd use an SD card and drive it with a small microcontroller. it's pretty simple - lots of plans on the web. log some data, pull the card out and read it on a PC. You ought to be able to make it in a very small form factor - probably about twice the size of the SD socket.

You can simplify the writing of the SD card by creating a file system with a single file that uses up all the space on the card. Then figure out where the file starts on the card and that's the place that your micro writes.

The USB approach that hacklesup suggests will work, too. However, I'd opt for smallest size. The advantage of USB is you don;t have to fuss with a card on the PC.

I'm willing to try either method. The firmware programming part doesn't scare me as much as the circuit design does. I'm a full-time programmer and can write assembly when I have to.

Despite the added complexity of using an SD card or another flash memory type, I like the idea of not being limited to the on-board RAM amount. More than using

I guess I need to be spoon-fed the circuit design part. Have any URLs that would get me started? I'm coming up short in my Google searches.

Once you start researching the devices you need to implement this you will likely find example schematics within the data sheets for those devices. Often you can piece together sub-units from various datasheets to come up with a system.

In particular the USB sheet should show you how to interface to a uController via an address and data bus. The USB host should likewise have the interface schematic. The uController examples will be generic implementations of the busses and control lines. Each should also document the programming codes needed to put it into the various hardware operating modes.

For such a system, Circuit design, device selection and S/W high level design happen simultaniously. Your research phase should converge on a good block diagram.

If you go the Development Board route. All you need is one with a flexible controller with either SD or USB bi directional interface already built in and a serial UART. This would be all you need excepting interface connectors, power supply, case and firmware. Performance points would be low power for long battery life, high speed not needed.

I would choose a uC devel board that may have a few more features than you need for this. In this way what you learn now can be easily ported to your next project.

howabout using a Vdrive http://www.vinculum.com/prd_vdrive1.html to interface to a memory stick and something like a armmite http://www.coridiumcorp.com/ to interface to the gps.


The V drive alows you to open a file on the memory stick and write data to it you can then plug it back into a Pc and read it directally.

The yahoo user group on the armmite has some examples of connecting to the vdrive and probally some examples of reading gps data.

Colin

Check this one out
http://www.create.ucsb.edu/~dano/CUI/

Note section 2 shows it done with a DIP package and also note the table in section 4 where it says pins RC6 and RC7 can be programmed as a UART (that means RS-232 compatibility, only code needed)

Unfortunately the USB looks like a client able to connect to a PC not a host capable of connecting to another clinet like a memory stick. I may be wrong. Further research needed.

Checkout the Datasheet and AN1003 (includes source code) for more answers than questions
http://www.microchip.com/stellent/idcpl ... e=en010300

I don't think you need a USB host at all. If you insist on USB then just make it take a simple serial protocol that you make up. On the PC side you write a simple program to talk to the logger.

I'm convinced that just logging to an SD card (uses SPI, I believe) will be very simple.

googling for "spi sd pic" got this as the first hit http://www.gedanken.demon.co.uk/gps-sd-logger/

Great link, Philba. It appears I could build one of those for the same amount of money or less than what I could build a serial data logger for. Looking into sourcing the parts in the US...

The DB-9 female RS-232 interface from a Palm Hotsync cable to a PC is of the Data Set variety (like that of a modem as opposed to a Data Terminal), as is the DB-9 female RS-232 interface from the Garmin eTrek PC interface cable. Now, it may be that the Handspring Visor PDA rear connector requires signal inversions but this is certainly not the case for Palm Pilots like the III series or V series, which provide a suitable RS-232 interface with a passive pass-thru cradle.

This means I can and have connected my Garmin Legend cable thru a DB-9 null modem adapter to a Palm Hotsync cable, with the cradle powered or not, and can read and log the 4800 Baud NMEA data on the Palm. There are many Palm applications such as that at http://www.cetusgps.dk/ , that will log and transfer captured NMEA data. More may be found at http://www.gpsinformation.org/dale/Palm/pilotgps.htm .

So before building or programming anything, consider experimenting with a Palm and Palm Hotsync cradle to Garmin cable lashup thru a null modem (pins 2 and 3 get swapped, and 5 is passed thru). If you find some software to your liking, you can consider hacking a surplus cradle to simplify, shorten and make portable the cabling, and possibly to outboard power the PDA.

Sparkle. Great post! I'll give it a shot.