Compact Flash GPS Interface

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Guys,

I still have a few of those CF GPS cards laying around from old pocketpc's, and I thought I'd maybe use them to create a reverse-geo-caching box.

I was hoping for a simple UART interface, but it seems to be a parallel interface.

Does anyone have some info/documents on how to interface with this device ?

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

It likely acts like a 16450 compatible UART. You will have to emulate the PCMCIA/PC Card interface.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks for the input jayjay, you are correct. I've opened it up meanwhile, and found a OXCF950 (low cost asynchronous 16-bit PC card or Compact Flash UART device) in the CF card compartement, with only 5 wires going to the GPS PCB. The mcu it connects to lists those pins as 5V UART.
So I've just disposed of the CF pcb, and connected directly to the UART. It's spitting out NMEA already.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it has been running since last night and still did not get a fix.
I'm thinking ..
It's an old unit, so it might have an outdated almanac, and the clock is way off.
Reception here is pretty poor, but could i give it a boost by sending it the correct time or possibly even sending it an updated almanac ?
The thing does have flash and static RAM, so it can store data, I wonder, does it update its stored almanac, or will it always have to download the current data ?

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The almanac is updated every 24 hours and seems to be valid for only a couple of weeks at most. Downloading the almanac can take quite some time. The static RAM is to keep a copy of the almanac so you get a speedy TTFF.

Go outside with the unit.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If the clock is way off, then you have no reception at all.

What I have seen with my GPS experiments is that when one satelite is seen the time becomes correct.

ow dont forget that it is spitting out UTC time and that you have to compensate for that with 1 or 2 hours depending on summer/winter time.

if it is spitting out NMEA you should be able to see how many satelites are at least seen(note that seen is not locked onto, this confused me a couple of times... )
search the i-net for "u-blocks center" it is a nice tool that can give you more information on what is received....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I agree with JJ,

Take the unit outside where it has a good view of the sky and let it sit for a couple of hours.

Make sure, also, that you are giving it a very clean power supply.

If you send the NMEA to another uC with an LCD it is pretty easy to parse the incoming data stream for a "$" and then clear the LCD and display the first 16 characters. It is then easy to seen when the GPS has locked onto the time, and subsequently when it has lock.

JC

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Here's what it is spitting out atm :

$GPGGA,070632.00,4907.8000,N,12303.6000,W,0,00,0.0,,M,,M,,*48
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,3,1,09,25,64,090,,20,57,299,,11,35,222,,01,31,259,*75
$GPGSV,3,2,09,14,22,071,,30,15,048,,16,03,144,,07,02,301,*7B
$GPGSV,3,3,09,04,00,333,*47
$GPRMC,070633.00,V,4907.8000,N,12303.6000,W,,,160204,,,N*53

Well, 16/02/04 is quite some time ago now, and the UTC time of 07:06:32 is also way off as this was logged at 09:17:55 local time, 08:17:55 actual UTC time.

I wonder why it thinks it is in Canada ? default start-up location ? It certainly isn't the last location. I know the fix is not valid, but still why here ?
https://maps.google.com/maps?q=4...

I'm at ~ 51.28, 4.94

Anyway, good tips guys, I'll take it out this afternoon and let it sit in the sun for a while.
I'm parsing $GPRMC for the second field to change to 'A' and then light an LED or something.

About the clean power-supply, I'll have to check that, I just have it wired up to an arduino uno that I'm using for the usb/rs232 bridge only atm. This is the exact kind of situation where one of those little buggers comes in handy.
I have already noticed the USB power coming out of my box is very noisy, so that might be playing against me too.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have used an older GPS module once and we had to take it outside too, to get a fix! Sitting near the window wasn't enough unless it had been powered recently (internal battery to keep last location).

I think the location data said 00.00..., 00.00... until it had a fix (or previous fix)

- Brian

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

One other thing to be aware of if it's a really old GPS unit. The GPS signal contains a 10 bit field for week number, and that field overflowed on August 21, 1999. If the GPS was not designed to take that into account, it may behave very unpredictably, with results anywhere from a few seconds of position error to complete failure of the device.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've decided to dump details of interest in this thread for archiving purposes and future reference. Who knows, someone else might benefit from it.

Power-up proprietary NMEA string :

$PLCS,REV,PCT011016S01,040709,105853

Components on Antenna PCB :

NEC B1007 : radio frequency down-converter front-end

Components on main GPS PCB :

MS621F : Rechargeable Lithium Coin Cell Battery 3.1 Volt 5.5mAH Bare Cell 

LOCSENSE LS4000 : 12 channel C/A code baseband correlation processor.
TMTECH T15N1024A : 128K X 8 LOW POWER CMOS STATIC RAM

RDC R8820LV : 16-Bit RISC Microcontroller
SST 39VF020 : 256K X 8 CMOS Multi-Purpose Flash

I'm connecting to UART0 on the RDC (pins 24, 25 on a LQFP100). Frame type is 4800 bps, 8N1.

The battery still seems to be recharging, as it was dead the first time I measured it. It was at 2.3V immediately after disconnecting it, but is dropping fast to 2.1V after only 30 minutes, so I'm guessing it's as good as dead.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

meslomp wrote:
search the i-net for "u-blocks center" it is a nice tool that can give you more information on what is received....
This seems to be quite a nice tool indeed. Thanks for the tip.
http://www.u-blox.de/en/evaluati...
It can apparently update the clock and almanac, but the supported protocol is probably proprietary for u-blox devices only. I get a time-out when I try.

Mouse wrote:
One other thing to be aware of if it's a really old GPS unit. The GPS signal contains a 10 bit field for week number, and that field overflowed on August 21, 1999. If the GPS was not designed to take that into account, it may behave very unpredictably, with results anywhere from a few seconds of position error to complete failure of the device.
I don't think it's THAT old, I think I might of gotten this device around 2004 or so, and it did work back then. I have another one that might be from around 2000 though, but it also used to "work" back then. But good to know nevertheless.

Geronimo wrote:
I think the location data said 00.00..., 00.00... until it had a fix (or previous fix)
Yes, that's what I would expect too.
I was in Portland, Oregon in 2004, which is "close" to those coordinates, but that is probably just a coincidence, I certainly didn't bring it along.

I haven't had any opportunity yet to put it outside, so no news on that front. It's still sitting in the window, probably listening on the wrong channels because of the invalid date/time and outdated almanac.

The problem now seems that WHEN and IF it gets a fix, that, with the dead battery, it will probably not remember the updated time/almanac. So i might want to help it out each time it cold starts by sending it at least the current time.
Is there a standard NMEA input sentence that can set the UTC time/date ? Or is this always a proprietary protocol by the manufacturer.

Attachment(s): 

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If your receiver had the last good lock on that location it might be that it stored that in flash to ensure a quick start-up when next time powered or perhaps even stored the coordinates in flash when the battery ran out, again to have faster start-up times.

you could just add a 10uF cap on the supply to see if that makes things better.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Well, it sat outside all night, in a relatively open area, but still no dice.

I'd really like to be able to send it updated data, or time in the very least, but the startup string isn't revealing anything about which (proprietary) input protocol should be used. I've tried SiRF, Evergreen, Garmin, u-blox, and a few others, but the unit keeps ignoring all commands. Communication IS possible though as it does echo the first part of some $PUBX messages, but it ignores most of the input that I've thrown at it. It also replies to a GxDTM message (and a few others) with "$EIGNQ,DTM*25", and I think I've seen it reply with something like "$EIGLQ" too.

The unit had "HI-302E" (Haitec?) marked on it, which is not listed anywhere. Some sources suggest it uses SiRF, but this doesn't seem to be the case.

The battery only has 1.4V left after being without power for the day. So I guess I'll just order a new one so that WHEN it finally gets a fix, it will be able to do a warm start on the next runs.

Quote:
If your receiver had the last good lock on that location it might be that it stored that in flash to ensure a quick start-up when next time powered or perhaps even stored the coordinates in flash when the battery ran out, again to have faster start-up times.

you could just add a 10uF cap on the supply to see if that makes things better.


Well the thing is that I'm quite certain that I was never at that location, it's in the middle of a river actually, so I'm guessing it's OR the factory default (seems unlikely for a unit from Taiwan) OR it is some sort of memory corruption, but then I'd assume that would be checksummed.

I'm making the setup a bit more sturdy atm, it was just wires pushed into pinheaders, so that's not really inspiring confidence. I'm making the wires a bit longer too so it can sit a bit farther from the AVR. Currently it was almost lying on top of it. I will add that 10uF to the power, and let it sit outside all night again, hopefully this time with results.

"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it"

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I've been spoiled; I'm using the Ublox 6 for my high altitude balloon rocket launcher. It's a lovely little chipset, and telling it to use its own format makes for a simple parse. The method I'm using requires a position request from the AVR and waits until the next second before anything happens.