Cut (separate a connection you already have) the power or ground wire and connect an ampere meter (or multimeter in current measuring mode) to the ends.

/Michael

PST is -8, PDST is -7 relative to UTC but that is probably not the major problem though it could be slowing things down quite a bit. It is analogous to moving your presumed position about 800 miles at your latitude. Time is used along with the almanac and your presumed position to estimate the doppler shift of the carrier and hence target the search. I don't know about the patch but a sign error (UTC +7 instead of UTC -7) would probably slow the aquisition down to several tens of minutes at least. Trying different timezone offsets could be revealing.

Fast moving cars are really slow compared to moving satellites so the caution you quote relates to obstructions that interrupt data collection not the above mentioned doppler estimate.

The spec I found stated 125 ma at 5 volts for the Rockwell version of the receiver.

At some point you may want to consider writing off your $9.50 (plus tax) and invest in a less compromised receiver

Lynn

At some point you may want to consider writing off your $9.50 (plus tax) and invest in a less compromised receiver

This is also something I have considered. Anyone have suggestions? Preferably something under $100.00.

Thought I opened up this can of worms in another thread starting with this post. I think several people recommended some options that were getting towards the $100 range, though I think some had some 5V/12V conversion problems... Never got the perfect answer I was looking for, though.

Go Sv6 or Oncore...there's rumours that someone is working on a pcb.

If true, then why didn't that timecode patch improve my acquisition times? Was it because of some kind of a timezone-off error?

The patch sends the time in UTC. The time on your player should be set in UTC in the real time clock. I sent a date binary a week ago you can use to check. Check.

Should I have set my player's timezone to GMT before trying that patch? I would have figured the patch was smart enough to convert my timezone to GMT before sending the time.

The player should have a timezone setting, which has nothing to do with the actual real time clock setting in the hardware, by the way. The patch has no business doing time zone correction, because it's a unix machine: you set the time in UTC, and the timezone setting in software shows you the correct time for the zone you have set. When you change timezones, you change your view of the time, not the actual hardware clock. That's how my player works, and I didn't do anything special.

Windows is weird and encourages you to keep your hardware clock in your local time. I have so much hatred for them.

Is there a difference between GMT and UTC?

I know it's set in GMT because I've set my timezone to US-pacific time (gmt-8) and the clock is right.

Turning off the GPS when you shut down and not moving it while it's off should be sufficient to deal with the problem you highlight. It's the same as the Earthmate hardware. As they say, it's not a cold start.

The cold start problem can be "solved' with another patch, which tweaks the GPS state to hint to it to not fall back to cold start so easily, which I will try to come up with later.

But not via NMEA is the key. Once you turn on TSIP you can do lots of stuff, but most software doesn't speak TSIP. If you only care about gpsapp, ever, sure.

For the purposes of this conversation, UTC is GMT. Note the patch uses gmtime() to deal with time.

So yes, you're good. I'll look at the other patch I alluded to probably tomorrow. I can probably provide a few other tweaks if we're willing to assume "car", which I guess if it's coded into gpsapp isn't outlandish.

Greenwich Mean Time became so popular that someone decided to rename it Coordinated Universal Time. (If you're wondering why that is acronymed to UTC, it's because the french got involved. But take a look at the second letter of the sedond word, and what would happen if they hadn't.. !)

I guess the French still haven't forgiven us for Waterloo.

The French also want to redefine the prime meridian, what with their tree line north and south from Paris. Good for them. Anyhow, here's some commentary on universal time.

GMT explained

The cold start problem can be "solved' with another patch, which tweaks the GPS state to hint to it to not fall back to cold start so easily, which I will try to come up with later.

Ah, coolness. Thanks!

Since the SV6 is a small cheap OEM module with no display of its own then I guess that is all I will use it for. If you are restricted to NMEA then you will have to make do with those limitations. For $25 (and a little soldering) my Empeg now has its own GPS with more horsepower than I'll ever need in the car

Tony,

If you read what dbrasher has said (about how your PC stores time) and what I said previously (about how your GPS aquires signals from the satellites) I think you will see that you may be sending the wrong time to your StreetFinder and that any of these time offsets could easily explain your slow aquisition symtoms.

Lynn

If you read what dbrasher has said (about how your PC stores time) and what I said previously (about how your GPS aquires signals from the satellites) I think you will see that you may be sending the wrong time to your StreetFinder and that any of these time offsets could easily explain your slow aquisition symtoms.

But I have my clock and timezone set correctly. If I need to deliberately mis-set my clock and/or timezone in order to make it work, that's fine, but then exactly how should I do that?

I may be misinterpreting this but dbrasher said:

"The player should have a timezone setting, which has nothing to do with the actual real time clock setting in the hardware, by the way. The patch has no business doing time zone correction, because it's a unix machine: you set the time in UTC, and the timezone setting in software shows you the correct time for the zone you have set. When you change timezones, you change your view of the time, not the actual hardware clock. That's how my player works, and I didn't do anything special.

Windows is weird and encourages you to keep your hardware clock in your local time. I have so much hatred for them."

This means to me that your PC in not set to UTC unless you set it to UTC and forget about local time. This agrees with my own observations as well. [I'm trying to install Linux on another disk and the Linux installer thinks UTC is our local time from the PC clock.] You then said:

"I know it's set in GMT because I've set my timezone to US-pacific time (gmt-8) and the clock is right."

Seems like you are off by 7 hours.

Maybe I am missing the point here but it seems clear to me.

Also, I don't think daylight savings is going to end until Sunday morning a 2 am so we are now on PDST which is GMT/UTC-7 hours. Maybe you have Greenwich on DST also! UTC never changes, even though local time in the UK does shift with the seasons.

You might want to try various offsets to see if it helps your SreetFinder before going too far down this path.

Good luck, I'm going back to the Linux install for a while!

Lynn

Maybe I am missing the point here but it seems clear to me.

Perhaps I'm the one missing the point, but I think he was saying the opposite of what you interpreted:

Windows computers like to have the timeclock set to the local time.

But we're not on a windows computer. We're on the empeg, which is a Unix computer. And unix computers have their timeclock set to UTC/GMT (which are the same).

The only reason the time looks correct to me is that when I'm in the player software, I have selected the timezone setting. And that timezone setting changes the displayed time to be my timezone (-8 or -7 depending on DST). But the internal clock is still set to UTC/GMT, and that's what his code was sending to the GPS. Am I right?

Now, I suppose there is a chance it could be off by one hour, i.e., we're in DST right now so when I set the thing to US Pacific (which is -8) and set the time, I'm actullay at GMT-7 or something. Anyone know the answer to that particular thing?

That could be it - GMT/UTC never changes.

In the Unix world, the clock is always supposed to be set to UTC/GMT, and the display offset changed to take account of DST.

If you set the offset to -8 and it reads the same time as your watch then you are off by one hour, your Empeg thinks that UTC is one hour later than the Royal Observatory does. That is enough to slow down your aquisition. As I said earlier, it is equvalent to an 800 mile position error for purposes of estimating the center of the doppler search for the satellite's carrier.

And yes, I was in left field about which computer was which (and I am not Barry).

Lynn

Okay, so I can try setting the clock back and hour and seeing if that work with the patch (Gonna have to do that tomorrow night anyway, ROFL).

So, Derrick, can you try making that patch again, this time against the 0.14 codebase, and throwing a binary my way?

Since the SV6 is a small cheap OEM module with no display of its own then I guess that is all I will use it for.

Except I was already using a non-display GPS with my laptop and first Hugo, then Xastir, so for me it's not necessarily true.

Timezone doesn't matter (still) and you said your clock was right. I still think you should install the date binary I provided (or build the source) and make sure it is.

Jan rolled it into the CVS so it will be in 0.15.

Meantime, try this.

This, even.

If the displayed local time is correct and the time zone is incorrect doesn't that impliy that the underlying clock is also off.

Yeah. Helps to read carefully

The player should have a timezone setting, which has nothing to do with the actual real time clock setting in the hardware, by the way. The patch has no business doing time zone correction, because it's a unix machine: you set the time in UTC, and the timezone setting in software shows you the correct time for the zone you have set.

I was under the impression the empeg RTC was UTC like it should be, but it used internal code to the player for timezone info, and not the standard Unix timezone settings. Thus Hijack has to have an offset setting to have it's clock right...

Or has this changed?

I was under the impression the empeg RTC was UTC like it should be, but it used internal code to the player for timezone info, and not the standard Unix timezone settings. Thus Hijack has to have an offset setting to have it's clock right...

If that's the case, then doesn't GPSapp still Do The Right Thing since it's just sending UTC to the GPS?

That's a timezone setting in software, isn't it?