Thought I'd start a new thread, since the 0.12 thread is getting rather long.

Derrick, regarding your time-sending patch:

Tried it today, with my clock set to non-DST time (i.e. winter months time). The time to display the very first satellite, and the time to acquire a group of satellites (i.e., all 8 bars appear although not all of them with signals), seemed to be much improved. Both of those things were almost immediate, at least within the first 90 seconds, when in the past those things would take up to four minutes.

The final stage, where I'm waiting for the bars to turn white, still seemed to take the same amount of time. But any bootup speed improvement is a good thing, so I'm happy.

Now the question is... Starting at midnight tonight, My empeg clock will be on correct UTC -8 for and this time patch will work. But what about six months from now when we go back into daylight savings time (spring/summer months)?

Or do I have it wrong and the player already does automatic DST correction? I forget. I always get confused this time of year.

Jan, GPSapp operation notes:

I've notice that in recent versions, if I go off-track, it doesn't seem to re-acquire the track once I'm back "on" as easily as it used to. Example:



With the above example, in the past, it seemed to track me correctly, even though I took a "short-cut" around the (faulty) MapsOnUs waypoint. When I re-acquired the track, it would skip ahead to the next waypoint. In the current software, it seems to "stick" on the missed waypoint, and I have to twiddle the knob before it re-acquires my track and starts behaving as expected again.

Another comment to come in the next message, but it requires another attachment...

Next comment: Told to turn left when I should have been going straight.

Tonight I was told to turn left onto a road that I was already on. I was on ridge road, and then I reached a straight 4-way intersection (basically shaped like a "+" sign, the roads crossed at almost right-angles) where I should have proceeded straight across the intersection. GPSapp told me to turn left onto Ridge road.



At worst it was a slight (and I mean very slight) bear left onto Ridge Road. But from the driver's seat it looked like a straight shot.

I think the problem is that MapsOnUs inserted a waypoint there. But the raw data didn't indicate the cross-street information so GPSapp had no choice but to interpret it as a turn. I think my beef is that it told me to "turn left" when it really wasn't a turn at all.

I don't know how to fix this situation exactly. If you want the raw data of that particular route, I can email you my route file.

Again, you should really download the date binary I sent, put it on your player, and make sure the hardware has the correct UTC time. That and a correct time zone setting should be all you need, it should do the DST for you.

I did. All of that. I'm saying it did improve the boot up speed. Just the first two phases, not the third.

The problem is, to do it, I had to set the time to a non-DST time. Unless you're saying that in the LAST binary you ALSO added code to DST correct that I didn't know about...

Follow-up...

This morning the player seemed to adjust itself to the DST change (went back an hour).

Question: did it do this by changing its internal clock (windows-style) or did it leave the internal clock as-is and simply display a non-DST-corrected time (unix-style)?

It did it the 'proper' way.

Like any linux system, the empeg has a copy of the (compiled) timezone files in /usr/share/zoneinfo/. These files tell libc (the library responsible for time functions) how to interpret the system clock (UTC) for local display, based upon the current chosen timezone. The timezone files include such information as when the clocks go forward and back.

Hmm. Then when I seemed to notice it acquiring faster with the patch, it actually was a fluke because I had really set the thing an hour off.

/me tries again with the correct time setting...

You know, if things remain quirky, then we should at consider the possibility of a player bug. Linux normally uses timeconfig to set the timezone, and date to set the time. The empeg has neither, so that functionality has to be in the player software.

I'll have to think this one through - whether that possibility could cause such an effect without being obviously noticeable.

Nah, I don't think there's anything wrong with the player, I think it's just a POS piece of GPS hardware.

I just did some messing around with it, and I think the real determining factor in the whole equation is simply how long it's been since the last time the GPS was powered up. I tried starting it up with the correct time set on the clock, and after 12 minutes it still hadn't acquired any satellites. But then I started messing with the clock settings and starting/stopping (pulling the sled) and it acquired within 4 minutes. And now it's fully acquired the moment I go into the software, regardless of the time setting.

I'll bet it's a battery thing. It's got a 4-hour Lithium-ion battery, and I'll be the whole problem is that the battery goes dead after it sits overnight or all day. And then it only gets charge when I've got the player in the unit ('cause I've hooked it to Amp Rem).

I think it's time for me to look at whether I can permanently wire it to +12v. I'm heading out to do that now.

I'm going to test its current draw. What should I consider excessive (i.e., I shouldn't 't leave it on permanent +12v if it draws X amps)?

I'm going to test its current draw. What should I consider excessive (i.e., I shouldn't 't leave it on permanent +12v if it draws X amps)?

Never mind, can't test its current draw. My little multi-tester thingamajig doesn't seem to have that capability, there's no "amps" setting on it, only ohms and volts.

Interestingly, when I pulled the power from the GPS, it stopped sending data to the player on the serial port. I thought it would keep going as long as there was a little charge in its battery. So I'm thinking maybe the battery in this thing is shot (it did sit on the shelf for a long time before being sold).

So I'm going to wire this thing to permanent 12v in the car. Anyone think this will result in a dead car battery? Anyone have any idea what this unit draws, and how long I'd have to leave it in the car to make it drain the car battery?

The gpsapp change uses the UTC time. UTC never has any daylight savings component, ever. It's monatomically increasing(*)

(*) We'll entirely ignore the issue of leap seconds.

It doesn't say in the packaging somewhere? Actually, my packaging is about 10 feet from me. I'll find out.

Here're some interesting links on battery life:

http://www.uuhome.de/william.darden/carfaq10.htm
http://www.uuhome.de/william.darden/dcfaq11.htm

So, anything greater than 120MA would be bad?

Hm, that kind of sucks.

Couldn't find it. But, we know it's no more than 300mA at 12v, since that's what their AC brick supplies. We also know that it uses the lithium battery in 4-6 hours, and I'm sure it can be calculated from that.

Well, I've just wired the GPS to permanent 12v. It's got a switch so that I can turn it off when the car will be sitting for a weekend or whatever.

Maybe I could figure out how to do a one-shot timer relay that lasts 12 hours or something... Hmmm...

Still would be nice to know how much current draw this thing is pulling...

Have you guys seen this?

DigiTraveler™ Personal GPS Navigation System for PDA from RadioShack...I thought that might throw some more inspiration into the GPS arena.

Hmm, interesting. $99.00. Looks like it's 4.5v rather than 12v, but still....

Argh, wiring the unit to constant 12v power didn't do any good.

If I leave the player out of the dash for any length of time, I guess it assumes nothing is connected and it shuts itself down. Next time I insert the player, it has to go through the long "cold boot" re-acquisition of satellites.

Is there any way I can fake out the serial port so that it thinks there is still something connected even if there isn't? Like jumpering two pins or something?

As I said, cold start can be disabled in software, and if you wait eventually I'll have a patch to do it.

But I need to figure out what my jemplode problem is first, because at the moment I'm losing rather badly.

As I said, cold start can be disabled in software, and if you wait eventually I'll have a patch to do it.

Cool, that would rock.

Tracking was interfering heavily with hand selecting previous/next waypoints. The only way out I can see right now is to make knob press toggle the auto-tracking off completely. I can try to make the auto-tracking more stingy at the cost of more CPU usage, or perhaps I should switch to using a quadtree based index instead of linear search to find the nearest neighbour.

Basically I used to exhaustively search for the nearest waypoint, and then scan all 'shape' points between the previous and next waypoints. But that would always pull us back to the last point we considered closest. So hand-tweaking didn't really help at all. Right now the search is more limited where it searches only a few points based on the currently selected 'closest' point. And although this allows us to more easily select previous/next waypoints, it also forgets to track us in some cases.

As far as the directions are concerned. I'm using the angle between the 'current bearing' and the direction of the road after the turn. However at low speeds the measurements we get from the GPS are not reliable. I'm probably freezing the current bearing too late and it already started wandering. I've noticed that even when I'm not moving the bearing pointer sometimes jumps. So the GPS is for some reason assuming I'm moving faster than 2km/h while waiting at a traffic light

Tracking was interfering heavily with hand selecting previous/next waypoints. The only way out I can see right now is to make knob press toggle the auto-tracking off completely.

Sounds like a good compromise. Either that or do nothing...

As it stands right now, it only becomes an issue if we go off-track. As long as I'm directly on the route, it seems to work well and select the next waypoint for me automatically. And it's not tough to twiddle the knob to get us back on track. And the new rubber band behavior makes it really easy to see whether or not we've twiddled the knob to the correct waypoint.

At the same time, though, a map error of a few hundred feet seems to be enough for it to skip the waypoint. The illustration I gave above for the missed waypoint was caused by a map discrepancy of only a few hundred feet.

So perhaps it's just a question of tweaking the radius of how far off you have to be from the waypoint. But that opens another can of worms, which is what if you've got a group of waypoints that are very close together. Code the radius too loosely and it might automatically skip ahead two or three waypoints, and not give you the correct turns as you reach them. The Palm software I was trying had this problem.


As far as the directions are concerned. I'm using the angle between the 'current bearing' and the direction of the road after the turn. However at low speeds the measurements we get from the GPS are not reliable.

Well, in my case, I was looking at the arrow and my bearing was correct, and speed had nothing to do with it since I was cruising when I noticed the error in the instruction. Besides, I thought you'd already changed it so that it used the road intersection data rather than the vehicle bearing for its L/R calculator anyway.

At the same time, though, a map error of a few hundred feet seems to be enough for it to skip the waypoint. The illustration I gave above for the missed waypoint was caused by a map discrepancy of only a few hundred feet.

Most software seems to lock the position to the nearest road segment that approximately goes in the right direction. When we have full street level info that might be a solution that will actually fix a lot of these 'off by a hundred feet' issues.

Besides, I thought you'd already changed it so that it used the road intersection data rather than the vehicle bearing for its L/R calculator anyway.

No I was using the current position wrt to the waypoint instead of the bearing from the gps. And because waypoints are never really exactly where the turn is, the resulting directions were almost as good as random.

FYI, Derrick, last night, I left the car in the garage overnight and when I inserted the player in the morning, the satellite acquisition was instant. Usually it went through cold-boot if I left the car in the garage under the metal roof.

With or without patch?

With. (Sorry.)

This is with hard power, though, yes? Ok, so the patch works as expected in that case, which is good. I guess I'll clean it up, create an option and send it to Jan.

Yes, this is with the GPS receiver being powered 100 percent of the time. It's been working as expected all week. MOST of the time when I park in the garage, it doesn't get an instant satellite lock the next morning. Just that one time I went to work and it had the instant lock. Dunno why.

And while I'm here, does anyone yet have any clue as to how much current the StreetFinder unit is drawing off of my car's battery?