If the device has an eeprom setting anything like position or time is useless. Looking over the zodiac docs, do you think we could run the PRWIBIT internal test and see whether the thing has something like an EEPROM/RTC/etc in the first place.

Don't have a laptop (of my own... wife rarely lets me use hers).

Me either. Work owns mine. My wife owns hers. Free tech support means she lets me use it when I want to, or she can fix it herself.

This would be so much easier if my unit were useful at the moment.

So you propose "don't send time if it has an RTC" and "don't send position, do deny cold start if it has an EEPROM"?

I'm not completely clear on how this receiver detects that it's "in use"

I forget how you said you hooked up the serial port, but DTR and/or DSR signals seem an obvious mechanism.

I'm only using TX, RX, and ground. Still seems to know.

I actually just bumped into an interesting reference by googling for streetfinder information.

Some of StreetFinder units think they are still in Asia (where they were last tested in a plant prior to shipping), and they are looking for satellites that are visible in Taiwan. After a period of time (up to 30 minutes), the unit will reset and acquire properly. If your unit fails to do so, download the GPS Meter program from here. This utility will initialize your GPS unit more quickily and provide other information regarding direction and satellite strength.

That does imply it remembers its last position, meaning disabling cold start after you've gotten a fix once you should be fine.

Yeah, very interesting. That program is palm-only, though, and my unit wasn't affected by that particular problem I don't think.

From that same website it looks like the delorme gps uses the DTR line to detect whether they are connected, but that still doesn't explain how the streetfinder figures it out. http://www.gpspilot.com/Palm-GPS.htm

It would be noce to know, maybe it doesn't really know whether it is in use or not and just chooses the 'safe option' (i.e. stay on). My guess is that when it is idling it should be able to keep it's ram fresh for a really long time on the battery.

more interesting info, the device stays on when not running off of the battery. http://www.cetusgps.dk/info/faq.html#rand

It would be noce to know, maybe it doesn't really know whether it is in use or not and just chooses the 'safe option' (i.e. stay on).

According to the documentation, it shuts itself off after being disconnected for a while. My experimentation seems to bear this out. If I pull the player, then put it back in again soon afterwards, the receiver acts like it had been on the whole time and just keeps working. But if I pull the player and go inside for an hour or so, then bring the player back out again, it seems as though the receiver had shut itself off: Cold boot cycle. Even if I have the receiver on permanent power.

The exception seems to now be:
- With Derrick's non-coldboot-patch, AND
- with the receiver on permanent power, THEN
it seems to boot up quick every time.

I haven't done a lot of testing of all the variables to be sure that's the behavior, but that's what it SEEMS to be for now.

the device stays on when not running off of the battery.

Hmm. Yesterday I left it on permanent power, went into the house with the player, came back out after a couple hours, and : Cold boot behavior. BUT... that was without Derrick's no-coldboot-patch. Now that he's got the no-coldboot-patch, it seems to be the case that it stays on.

That sounds really suspicious.

That sounds really suspicious.

You're telling me.

Then again, there's this theory: Main 12v power voltage fluctuates and perhaps even does a negative spike when I shut off my car's ignition. Unless I have the engine running, I often get the "battery icon" on the player, especially if I get a big bass hit. So maybe something is making the GPS think that it's been pulled off of mains power or something. I dunno, the thing is a real black box to me.

My guess is, the gps actually uses the DTR line to detect whether the serial port is active, from what I found on the net that would be pin 1 i.e. the opposite side of where the ground is connecting to. But it also activates similar to how the empeg detects whether it is on AC or DC, probably by breaking a ground line when the plug is inserted which makes the 'dtr' line float high with a pullup resistor. Maybe it also turns on when it sees data on the RX line. but I highly doubt that. It is more likely that with an unconnected DTR the line 'naturally' floats high, implicitly activating the receiver. But then again even that would be suspicious because that would activate the receiver whenever it is disconnected from the palm.

Perhaps the best thing to do is to connect DTR, and possibly wire it directly to the power lines on the board as it will provide a nice and regulated source without negative spikes and probably fewer dropouts. It also allows the receiver to go to standby whenever the empeg powers down or is removed.

My guess is, the gps actually uses the DTR line to detect whether the serial port is active,

That's what the Tripmate and Earthmate do.

Then why would it stay on all the time, connected to my empeg, when only the RX, TX, and GND are connected?

This page claims the DTR thing is Delorme only.

I still really don't want to solder inside my Navman; I wonder if I can find someone with a dead Palm 3 I can salvage the connector from.

More reading indicates there's a way to shut off "auto-shutdown" on the Streetfinder, which means either it is a (serial) signal being asserted or withheld, or it's a packet that the documentation I have doesn't seem to cover.

I still really don't want to solder inside my Navman; I wonder if I can find someone with a dead Palm 3 I can salvage the connector from.

Why? It's the easiest option and doesn't prevent the unit from being used with a palm. Doesn't require scrounging rare connectors, so it's a lot less hassle. I even posted a picture of which pins get soldered.

This page claims the DTR thing is Delorme only.

Not really, because the streetfinder connects directly to the palm and doesn need a palm->DB9 serial adapter. And it claims that only delorme needs to have the dtr connected in that adapter. It doesn't know what the streetfinder uses because it doesn't have to.

But If you open the receiver you can check whether the pin that should be DTR is connected to anything or if it's pad is completely isolated. If it is connected it must be used for something...

Some of the pads are isolated on one side but seem to go somewhere on the underside, and it's obscured what's what. I thought of that.

Remco Treffkorn (the author of gpsd) notes that the IPaq when you put it to sleep drops from 12v on Tx to 0v on Tx. He suggests perhaps the Navman sleeve is keying on this rather than DTR.

As far as Tony's comments that I should suck it up and solder, well, I'd need to find my soldering iron

drops from 12v on Tx to 0v on Tx. He suggests perhaps the Navman sleeve is keying on this rather than DTR.

Sounds logical.

In other news:

Consistently, leaving the GPS on permanent 12v power for several hours with the empeg unplugged and the car parked outside, then re-inserting the empeg with the no-cold-boot-patch version of GPSapp, results in instantaneous satellite re-acquisition.

The same conditions, when left overnight parked in my garage, results in a full cold boot when I come out the next morning.

Since the garage's metal roof blocks the satellite signals down to unusable levels, I wonder if the unit simply gives up the ghost at some point because of LOS and the software/timing has nothing to do with it. To that end, I have parked the car outdoors tonight to see what it does when I put the player back in tomorrow morning.

One point of the cold boot disable patch is more or less for that situation. Maybe in this case (the case of this receiver) that's the only point of it.

is more or less for that situation.

Which situation? Being left outdoors unattended for a few hours, or being left on in a no-reception location?

Are you saying it's behaving as expected, or that it should have behaved nicely even when parked under the metal roof overnight?

Left powered in a no-reception area.

Expected that if you run unpatched gpsapp and leave it powered that it behaves as it does.

Actually, I misunderstood. He *guessed* the iPaq did that.

Expected that if you run unpatched gpsapp and leave it powered that it behaves as it does.

In my experience, with unpatched GPSapp, leaving it unpowered for more than a few minutes and it does a full cold boot... Not a lot of testing done with that to be sure but it seems to be the case...

Ok, but that's not the point I was making

By the way, leaving the car parked out overnight under the stars, and then putting the player into the dash with the patched GPSapp, resulted in an "instant boot up" this morning. No waiting. So it seems that part of the equation is if the receiver can't get a satellite signal for a certain length of time.