Ok, this one should fix all those satellites crowding in the first slot. Also added altitude, type of fix, horizontal dillution of precision (ask someone else what it means), and number of satellites used in the fix to the satellite signal strength display. You might notice that the signal bars don't go all the way to the top anymore. The top line is 'reserved' for the current GPS coordinates, but I didn't get to adding the code that actually draws them. Oh, and there was an off- by-one error when drawing the highlighted route.

With all of those changes there is a bit of a chance that some new and exciting bug got introduced, but 'it works for me'.

Cool. Thanks..

/me scurrys off to test..

/me too

There's still something quirky about the first satellite display jumping between two Svs for a while. But it appears to stabilise out.
Altitude is a bit off.... unless someone elevated my city by about a million feet.
HDOP appears to work - I saw values of between 2.8 and 3.7, which sounds reasonable (IIRC about HDOP).
There needs to be a charctor space between the number of satellites and SV which would make it more legible.
Shading now works great.

Is it possible to add a signal strength scale? I haven't looked to see whether the range changed, but it should be possible to fit a scale in the first column - a line of VFDSHADE_MEDIUM, with dots of VFDSHADE_BRIGHT every 10dB (starting from the first round multiple of 10dB obviously.

Oh, I suspect that once Long and Lat are added to the sat screen that elevation would probably want to be moved to top left, and long/lat kept together on the right - in line with keeping the most utilised information away from the 'fascia bug'.

Thanks again for this great app.

in line with keeping the most utilised information away from the 'fascia bug'.

Depends on who you're talking to. Personally, I would want the altitude be the most visible since I never use the lat/long numbers. Meaning I'd want elevation on the top right.

....maybe you're right.. If the long/lat are still going to be available on the route map as a toggle, then perhaps elevation should get pride of place in the sat screen

I'd still rather have the right-hand pane in the Route screen contain:

- Distance to next waypoint
- Time to next waypoint
- Elevation
- Current speed

Rather than the distance/time to the end of the journey or the arrow. I never care about the end of the journey, only the next step. Heck, if I want to see the end-of-journey data, I can twiddle the knob to the end of the list and see it.

I don't have a real appropriate "useful" reason for it, I just like seeing the speed and elevation on my GPS readout all the time.

More good (make that great) stuff

I just realized you can save some space by dimming the altitude if it isn't a current measurement and that implies a 2 D solution (I think you are already doing the dimming). For some reason GPSapp is seeing large numbers for HDOP from my TSIP source (over 100,000) so that field should probably be limited to two positions left of the decimal. Maybe TSIP puts out negative numbers to indicate inadequate geometry, I don't remember for sure!

Also the map scale could save a little space by showing the scale as the 32 pixel height of the screen and adding small serifs to the vertical line that separates the map from the text fields.

For those who are interested:

Dilutions Of Precision come in four flavors; Position, Horizontal, Vertical and Time. These are factors that can be used to estimate the degradation of acuuracy for each of these measurements that are attributable to the geometric relationship of the satellites (currently being used in the solution) to the user.

A simple calculation would take the RMS value of the URA values transmitted by the satellites in use (User Range Accuracy is part of the ephemeris message contuinuously transmitted by the satellites) and multiply it by the relavent DOP for an accuracy estimate in meters. Divide by the speed of light for TDOP to convert to seconds.

The DOPs are calculated and should be considered to be precise, however the URAs are just estimates with poor resolution, typically 2, 2.8, 4, 8 ... so the resultof the above calculation is also only an estimate.

Lynn

Also the map scale could save a little space by showing the scale as the 32 pixel height of the screen and adding small serifs to the vertical line that separates the map from the text fields.

Good idea. I actually thought of that one last week and forgot to mention it.

Don't even need the serifs. Just document in the readme that the scale represents the height of the screen and be done with it.

And just an unrelated comment about the route screen...

In the "to do list", there's mention of trying to figure out how to rotate the whole map screen instead of just rotating the arrow. But it also mentions the difficulty that causes because of the short/wide screen aspect ratio.

If map rotation ever makes it into the software, I'd want it to be optional, because I actually prefer to have the map screen stay oriented NSEW and have the arrow rotate. But for those who want the map to rotate, you could optionally make the "target direction" be sideways instead of up, and have the arrow be off-center by 30 percent, so that you can see more of what's in front of you.

If map rotation ever makes it into the software, I'd want it to be optional, because I actually prefer to have the map screen stay oriented NSEW and have the arrow rotate.


That was one of my requests...and yes I did request it as an option. Jan didn't know how feasible the whole idea was though so we might never see that...

have the arrow be off-center by 30 percent, so that you can see more of what's in front of you

That's the first time I've heard arcs measured in percents.

And as long as you're going to the trouble (if you are) of rotating the map, you might as well have the initial offset be configurable. If you're worried about space ahead, then having it 90 degrees (or is that 25%?) offset might make even more sense. And then move the ``you are here'' point to the left, so that two-thirds of the screen is ``in front''.

And then move the ``you are here'' point to the left, so that two-thirds of the screen is ``in front''.

Um, that's what I meant to begin with. I didn't mean the other thing with the arcs.

Ah.

There's still something quirky about the first satellite display jumping between two Svs for a while. But it appears to stabilize out

Got it, until there is a fix we don't have a valid gps time. fixed it.

Don't know why the elevation gives such a weird number, is it a reasonable value when you change to metric measurements?

I'm not sure how consistent the signal strength is. It looks like the range is typically 0-60, and scale it down to about 16 pixels. so each 10db would be about 2.5 pixels. I could draw a dim line every 5 pixels (20db). Yeah, that might look nice. btw. did I say how much I love vfdlib

ellweber: I noticed the unusually high hdop value on a trimble, but it quickly settles down as soon as we have a fix. I really need a linux kernel where usb-serial works again so I can look at some of these numbers with gdb.

Also the map scale could save a little space by showing the scale as the 32 pixel height of the screen and adding small serifs to the vertical line that separates the map from the text fields.

Must be my english, what are small serifs? Do you mean make the vertical scale marker a part of the vertical line between the map and text fields?

Don't know why the elevation gives such a weird number, is it a reasonable value when you change to metric measurements?

Not such outlandish numbers but my Earthmate never did seem to be able to give a useful stable elevation. No clue why. I doubt it's the same problem.

I really need a linux kernel where usb-serial works again so I can look at some of these numbers with gdb.

I need a cable modem that works again, so my laptop isn't busy being the gateway to a pcmcia modem

Must be my english, what are small serifs?

the "T" at the top and the bottom of the scale, or more correctly, the horizontal portions of the scale bar.

HeHe....that puts me at 4.2 million km elevation...brrrr....chilly.

Interesting, that should be about 2^32-1 or -1, perhaps your gps uses that to indicate an unknown value when there is no 3D fix.

Well, I didn't get you the patch for enabling extra NMEA sentences with TSIP for 0.12, but the ACE II TSIP manual page A-11 says The CM3 didn't do 0x7A; The ACE II did. So I assume older SVeeSixes didn't either.

Still trying to find an answer.

I was suggesting that you use the vertical line between the map and text fields as a scale, using a few pixels to the right and left at the top and bottom (and possibly elsewhere along the length) to identify it as the scale marker.

-
|
|
|
|
-

Then the capital "I" looking scale marker would no longer be needed.

Lynn

Hmmm... the specs don't say. but anything else that I've seen have suggested that NULL is used when there is no data. That could throw a spanner in the works though... skip() would keep going through the following parameters. (geoidal separation, differntial data age and differential station id), but all of those should also be null.

Could be related to casting somehow? I noticed that gpsapp uses strtod for the conversion, and that gps_state.alt is a double, but draw_sat off-loads the display to formatdist that expects an unsigned int

I don't seem to be able to adjust the waypoint pointer to waypoints close to the start of the trip with the new version.
I reloaded Ver. .1 and it seems to work fine. I'm using a Garmin12, NMEA, no matter this is a great application, Thank You

As soon as I saw 'unsigned int'... You've got a perfectly valid altitude, it is just slightly negative. The double->int casts typically work as long as we don't have numbers larger or smaller than 2^31. Ofcourse casting the resulting signed integer to an unsigned int does work differently. Consider it FITNR.

You've got a perfectly valid altitude, it is just slightly negative

Well, I could argue that a slightly negative altitude isn't perfectly valid, given the fact that I live on a hill
But yes, that would tie in with what I saw when I originally used a PC to configure the Oncore, altitudes of around -12ft -> 20ft.

I'm not doing a true nearest neighbour algorithm to find where we are in the route. Right now it basically walks the route from the currently chosen 'closest' point until it finds one that is closer. As a result, the first location update after selecting a waypoint closer to the start will basically bring you back to where it was previously.

Selecting upcoming waypoints is easy because I don't search backwards for a better point. This right now is more art than science, I've tweaked that code in pretty much every release.

The version you reloaded probably has a problem that it doesn't automatically switch to the next point while you are driving if you pass the point at some distance. Another version was picking points way up ahead if there was a curve in the route, etc. Maybe I should do something like disabling the automatic search when the knob is turned and reenable it on a knob press.

using a few pixels to the right and left at the top and bottom (and possibly elsewhere along the length) to identify it as the scale marker.

I'd rather not have the marks at the top and bottom of the line. Just say in the readme that the [scale indicator == height of the screen],

Respectfully disagree. Readme dependencies are poor design practice, in my book. When you can avoid them, do it. If it looks like a "scale" and doesn't intrude on anything else then what's the downside?

Lynn

With you there...the scale marker should be the screen. You wouldn't expect to read a number on a map, and then hunt for the small print to tell you that the number refers to the size of the whole map... (ok stretched analogy, but still valid...)

We don't actually need the serifs though. If you look at most maps, the scale marker is usually drawn as a line of alterating white/black sections, where the length of each section is a known quantity, and usually correlates to grid size... eg on British 1:50000 OS maps, the section is 1km in length.. (Actually, IIRC they have an imperial scale as well, but you get the gist).

We could do a similar thing with the current dividing line - with VFDSHADE_BRIGHT and VFDSHADE_MEDIUM sections, and get the benefits of a real scale, without using any screen real-estate

I don't have a GPS receiver, but would like to get one, based on how well you guys are saying this is working. Could someone post a screenshot?

Also, where did you get your $15 receiver, Tony?

Readme dependencies are poor design practice, in my book.

Except in rare cases, such as: you're running on a device with a pathetically low screen resolution and every pixel counts.

Okay, I have a compromise: If the scale is turned off (as I now have made the default setting in my config.ini), then whatever you do for scale size indication (serifs, dashed bar, whatever) should be correspondingly turned off.

Let me tell you where I'm coming from on this:

I think that the display of the map information should be as uncluttered as possible. When I tried out the TripPilot software on the Palm, one of the deal-breakers for me was the fact that every map on the screen had an unnecessarily large scale marker, along with a "copyright (c) vicinity corp" message. And since the software showed maps of more than one "step" on the screen at the same time, this screen space was wasted more than once on the screen. It was a neat piece of software that delivered great onscreen maps, but little crap like not being able to remove the scale marker and not being able to remove the copyright text prevented me from buying it.

Good Idea, I like it. And it saves the 6-10 pixels out of 4096, that are so precious I'm all in favor of elegant simplicity and this certainly qualifies.

Of course, Jan should do what he thinks is most appropriate.

Lynn

Tony has a $9.50 Palm3 GPS from Staples, something I doubt you'll find now. The $15 unit is an Oncore from bgmicro.com, but it need an antenna and a TTL to RS232 line level converter on the serial port to be useful.

There is kind of a screenshot at the top of my gpsapp page. I just updated to include the new awfully crowded satellite overview page. Because I still don't have working serial on my laptop, the data is a bit 'faked' I pjust pushed a couple of NMEA sentences with lat/lon and satellite info through the parser to fill in a couple of the blanks.

And I absolutely refuse to have all threads in programming show up as gpsapp v0.9/gpsapp v0.10/gpsapp v0.11 etc. So I'm not going to make a new thread announcing version 0.13 (This was the announcement)

I'm going to be at a friend's wedding in Chicago this weekend. Which is probably a good thing, because I won't have access to computers and everyone gets a little break from installing a new version every day.

And I absolutely refuse to have all threads in programming show up as gpsapp v0.9/gpsapp v0.10/gpsapp v0.11 etc. So I'm not going to make a new thread announcing version 0.13 (This was the announcement)

Aw, why not? I like seeing announcements for new versions. And besides, that's what I do with LogoEdit (new version coming today probably).

/me eagerly downloads 0.13...

Also, where did you get your $15 receiver, Tony?

Like DBrashear said, it was a $9.50 closeout at Staples. The only reason it was even there at all was because my friend Tod bought it hoping it would fit his model of Palm, and it didn't, so he took it back. Since the Palm connector is essentially just an RS-232 serial connector with a funky pinout, it was very easy to make it plug into the empeg, almost a no-brainer.

It works "OK", but since it doesn't store the almanac data in its local memory, there's an issue with it taking a long time to acquire satellites. But hopefully the new features that Jan is adding will speed that up, I'm anxious to try the new version. Its reception is mediocre, I can't be inside a tunnel or a garage and have it work. But for my purposes it basically works.

But hopefully the new features that Jan is adding will speed that up

Actually, I can probably get you a patch for this tonight to try.

Oh, cool. That would have been a good place to look.

I don't think I've seen this asked, so what happens if you deviate from the course extracted from Maps on Us?

I don't think I've seen this asked, so what happens if you deviate from the course extracted from Maps on Us?

Your current-location pointer seems to drive around in the blank space outside of the MapsOnUs route, and you see a "rubber band" line indicating the direction to the next expected waypoint in the MapsOnUs route.

The software seems to do a decent job of skipping ahead/back to the correct waypoint once you've re-acquired the track and you're back on the right road. If it doesn't, a quick twist of the knob will select the appropriate waypoint and you can see the rubberband updating on the screen as you do. Rather slick, actually.

Something like this will probably help.

Cool...

Love the new co-ord display option. There's a bugette tho' - it doesn't convert -70 to 70W, but prefers to tell me that I'm at 70E. I'd guess that N/S would suffer the same issue, but I'm not going to drive to Chile to test that
Since you've moved the co-ordinate display position to the top line, it clashs with the scale display in the map....
The elevation is still broken with insane numbers. Are doubles/ints the same between Arm and x86? (Since you're testing on x86 currently..)
The signal strength meter is now the Dog's Bollocks....

Next feature requests:
Route reversal. Ok, I know that'll get Tony's back up what with one-way streets, sliproads etc, but there will still be a lot of occassions where this could be useful.
Can we get the tracklog buffer size increased, and also stop the tracklog when speed is <10 km/hr? (Currently if you sit at a red light long enough your tracklog disappears.)

And here's the binary if you want it.

Route reversal. Ok, I know that'll get Tony's back up what with one-way streets, sliproads etc, but there will still be a lot of occassions where this could be useful.

I'm OK with that. For routes where I don't know if a plain reversal will work or not, I can still tell MapsOnUs to calculate the return route (it's one click on their screen). For significant portions of any given journey, a plain reversal would probably be correct.

The only difficulty from the coding side would be: For the text directions it would have to parse out things like NORTH SOUTH EAST and WEST and change those to the opposite heading on the reverse direction. However, how's it going to know what to change and what not to change?

Examples:

a) Merge onto INTERSTATE 80 SOUTH.
b) Turn RIGHT onto SOUTH MAIN STREET.

It would need to change it in example (a) but not (b).

And here's the binary if you want it.

Is this the binary that's supposed to help my GPS start up faster because of the clock information? What do I need to know before trying this out?

s this the binary that's supposed to help my GPS start up faster because of the clock information?

Yes.

What do I need to know before trying this out?
That your clock is close to correct UTC time.

Cool, thanks!

Okay, I tried this just now, and it didn't seem to speed up the satellite acquisition time.

The usual modus operandi for this unit is (and it still does this even with the binary you sent):

- Insert player and start ignition.
- Enter GPSapp.
- Goes almost directly to "waiting for satellites" and sits there with no data for a long time.
- Long pause. Usually 2 minutes or so, but it's variable.
- One bar appears, blinks a bit as its signal strength changes.
- Long pause approx 2 minutes.
- Eight bars appear, most of which are at zero signal strength. 2-3 blinking bars but they are not white.
- Long pause approx 2 minutes.
- Finally some of the bars start to light up white and I get satellite lock and start getting intermittent data from the unit. It takes another ~2min to settle in and actually start delivering reliable data with 3-4 white bars.

Once this process has happened, I get reliable data from that point on, and I always have at least 4 bars lit (or more). So I know the GPS unit itself is working.

Interestingly, when I first go into GPSapp, I have valid lat/long numbers on the screen. The GPS itself seems to properly store and spit back the last set of Lat/Long coordinates that it recorded. So at least it's got SOME kind of memory. Perhaps it also has a realtime clock and the reason it's so slow to acquire is something unrelated to the clock? I'm sure that it doesn't store almanac data and that's probably a significant part of it.

Do you have any more insights?

bgmicro seems to have the SVee6 again.

I came to the conclusion that the NMEA mode on them is crappy, but the antenna included in the deal makes it worthwhile, so I got some more spares.

If I can come up with a quick way to make my Palm 3 GPS "road-ready" I can test this. Is there a reverse-docking-connector I can buy somewhere to build a serial adapter from?

the coordinates when enabled now slightly overlap the scale. I could perhaps live without that extra digit of precision. If you have a preference as to what to do I will send a patch.

It sounds like it takes the first 2 minutes to find the first satellite, and then 2 minutes further for the current almanac to be downloaded/decoded, after which time it starts to have a look at which of the satellites it should use - which apparantly also takes 2 minutes to decide...

6 minutes TTFF from cold, and 8 to stability... Doesn't sound great.

But bear in mind also that time of day can affect TTFF - if you happen to be in a location that can only see 6 satellites at a particular time, and 2 of those are blocked by buildings, then TTFF is going to increase. (Nominally you should be able to see 8 SVs or more - but the constellation isn't perfect)
ie, retest that binary in a couple of hours time in a wide open space and see if that changes anything.

Yeah I screwed up on E/W and the minute and second ticks aren't right either. Didn't notice it at all until ellweber pointed it out to me in a PM. I thought the coordinates managed to (barely) avoid collision with the scale. Maybe I should split the map screen coordinates to two lines again.

Tracking already stops when we're not moving, I guess there is just enough jitter that there are still updates even when stopped. I'll move the logging into the if (gps_speed >= 2000) /* 2km/h */ section that tried to block updating the bearing pointer when we're stopped.

There are already 512 track log points, and with one measurement per second that should be almost 9 minutes. Do we really need more, considering that there is no way to save the data.

Route reversal... Just plan the reverse route offline and upload that as well. It just seems like a bit to much work for no real gains. i.e. there already is a perfectly working way to do it that actually handles one-ways etc, and doesn't complicate the code. And I would rather start playing with actual vector map data.

If I can come up with a quick way to make my Palm 3 GPS "road-ready" I can test this. Is there a reverse-docking-connector I can buy somewhere to build a serial adapter from?

Oh, God, don't bother with that. Just open the thing and solder GND, RX, and TX straight to the PCB. It's dead-obvious which pins are which when you get in there. On the back side of the PCB (opposite side to the connector) you can see which pin is GND (it's one on the end and you can see it's GND pretty clearly from what it's soldered to) and the RX and TX are thoe only two other obvious traces on that side. Slight amount of trial-and-error for RX and TX ordering, and you're done.

Assuming your PCB is the same as mine was, of course.

Oh, and you need 12v to the power plug if you want to actually use it in the car. I just snipped off the connector end of the cigarette lighter cord at the point where it started to go from straight to coiled (this gave me about 6 inches of straight cable and the connector) and soldered the loose ends to the AmpRem and GND wires on my car's wiring harness adapter. And then I plugged that into the regular jack on the GPS unit. Or you could pull 12v and GND from the sled serial plug if your sled's serial plug is properly wired.

But if you're just doing it for testing purposes indoors, then just use the AC adapter for 12v, don't bother with power connections.

Well, yes, but the idea was to avoid opening it in case I came up with a palm3.

Well, yes, but the idea was to avoid opening it in case I came up with a palm3.

You won't be doing anything that will damage your ability to hook it up to a palm3. If you do a nice job of making a clean hole for the serial cable, you'll have a nice StreetFinder with a dangling serial cable that can connect to either a Palm or the Empeg, whichever you like.

But I have to say that GPSapp is already better than any of the Palm software I tried, so there's no point in bothering with it.

But I have to say that GPSapp is already better than any of the Palm software I tried, so there's no point in bothering with it.

Well, yes, if you have an empeg with you.

I think I found a bug in the mapsonus parser. It is trying to parse for <xmp></xmp>, but the html I am getting from their site has those in caps <XMP></XMP> so the parse if failing. This was working a day or two ago so I don't know if the parse changed or their site did.

-Mike

God, I hate case-sensitivity.

You never know, maybe at some point I might just 'port' gpsapp to run on my Handera 330. But seriously, palms are even more challenging to develop for, no unix environment and battery life becomes a big issue, so you can't really run the (slow) CPU at full throttle all the time.

Ok, redid it so that now it isn't depending on <XMP> </XMP> tags. as a result we can now even parse the dump when it was saved as plain text.

Is that version up yet?

I just synced the CVS archive, give me 10 seconds...

Ok, v0.14 is up.

Does 14 also contain that clock patch posted earlier in this thread?

Route reversal... Just plan the reverse route offline and upload that as well. It just seems like a bit to much work for no real gains. i.e. there already is a perfectly working way to do it that actually handles one-ways etc, and doesn't complicate the code. And I would rather start playing with actual vector map data.


Fair play...it was just a thought, but I wouldn't want to distract you away from something that will be far more valuable. And of course, you're right, my need for reverse routes would only be based upon my laziness

wrt track points. I wonder if now is the time to consider what we might eventually want to see gpsapp write out to disk. Considering that it has to run 'root' anyway, getting gpsapp to remount /programs0 (or /programs1 if it exists) should be trivial.

No, I thought you said it didn't make any difference.

No, I thought you said it didn't make any difference.

Didn't SEEM to, but the timing of that thing is always variable.

wrt track points. I wonder if now is the time to consider what we might eventually want to see gpsapp write out to disk. Considering that it has to run 'root' anyway, getting gpsapp to remount /programs0 (or /programs1 if it exists) should be trivial.

Although track points are the last thing I'd want written out to disk, I could envision some other things it might write out to disk that would be useful...

Is it possible to write out the almanac data to the disk (only when I say so from a menu item) and then feed it back into the GPS at boot up? Does the GPSapp even get the almanac data or is that only internal to the GPS?

DBrashear, here's a photo of my StreetFinder opened up and wired for serial. You can see which pins are which pretty easily.

In this configuration, I was able to close up the case and just stick those pins into a female serial cable.

But later, I completely got rid of the plastic casing so that I could stealth mount it and position the antenna wherever I wanted. I wrapped the whole thing in electrical tape and soldered a proper serial cable to the PCB instead of the loose pins.

You don't have to go this far if you still want to use it with the palm3.

In reply to:

---

Although track points are the last thing I'd want written out to disk, I could envision some other things it might write out to disk that would be useful...

---

I have a suggestion that it should be possible to build a route up from scratch simply by driving it & marking key places/waypoints as you drive (gpsapp could even do this automatically as well using each turn you do more than X degrees from the last heading as a "waypoint").

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Doing this requires that we be able to save these waypoints somewhere - now I don't like the idea of running my Empeg with rw mounted disks anymore than anyone else, so maybe we could look at creating a small ext3 filesystem somewhere that can be left rw mounted permanently for apps like the GPs one to save stuff to as and when required.

Either that or we dust off the old talk from some time ago about a special "raw" disk driver that reads and writes disk blocks itself directly [no need for mounting the special filesystem then.

Given that The latest hijack now includes ext3 support, maybe this is the time to make use of it?

Can't think of any other way to get permanent storage on the Empeg can you?

AFAIK, most receivers will output and allow input of almanac data, but generally only in their own binary protocol. How long the almanac remains valid for is another matter that I'm sure that Derrick could answer.

Writing track points out to disk could have uses:
Survey - although the receivers/antennas we are typically using aren't up to the accuracy of proper survery units, it still might be useful/fun.
Map making/calibration.
Road Trip Logging.
If live routing ever becomes a possibility (the map data issue obviously needs to be resolved first), then track logs may be useful for retroactive routing validation.
It'd be cool to be able to 'mark' a place for attention, much like you'd mark a track for attention. How many times do you see an unusual place or shop and think "Must remember that's there...", only to forget exactly where it was? Or stop on vacation and take a photo of a wonderful vista, only to forget exactly where. If JEmplode could check a known directory, and find a date/time/position log, and the route taken to it, then you could process that information, give it a name and reupload it as a normal route, or use it to help label your photos.
Custom route creation - if you know a better route from Exit X of I95 to your house/church/whatever, than mapquest/mapsonus/whatever can find, then you could drive that route, and then retroactively use it to create driving directions for friends/relatives/whoever - including typical timings.

So many possibilities.

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Well you could use google and find in a couple of seconds programs like
www.gartrip.de and http://home.t-online.de/home/gpsinfo/ which allow you to create tracks and routes based on digitized topographic maps by tracing the track you want to follow.

If you're from england and rather not use those german programs, www.gpsu.co.uk does similar stuff.

Either that or we dust off the old talk from some time ago about a special "raw" disk driver that reads and writes disk blocks itself directly [no need for mounting the special filesystem then.

Writing to the disk is writing to the disk, whether you use a filesystem or write the blocks yourself. i.e. you could create a single large file without holes in any given filesystem and as long as it doesn't change it size the access is equivalent to writing to a raw device.

However, it is simply the actual process of writing bits to the disk that is dangerous. I believe some recent IBM 3.5" IDE drive was renowned for writing even when the power was cut so it would scribble over low level data between the tracks. This basically turned the disks into a brick that could be shipped back to the factory.

How long the almanac remains valid for is another matter that I'm sure that Derrick could answer.

Well, the almanac data is rough anyway, it's an idea of where in the sky to look for what, so basically, you can use it for months, with decreasing accuracy, but that's ok.

Ephemeris data is what's interesting, but I don't know what receivers cache it.

Actually,. I bet one of
Joe Mehaffey, or [url=http://www.edu-observatory.org/gps/gps.html]Sam Wormley[/url[ have a good explanation. I'm merely a somewhat enlightened amateur (though before selective availability was turned off, the quest for accuracy meant I learned a lot more than I would probably bother to today; for that matter, I also learned about datum shift bother using Molodensky and a shift table, and why for NAD27 to NAD83 you want a table, for instance, because I have maps calibrated in both, and wanted to use them all together, usefully)

Writing out track info to disk could be very useful, and at the same time, it opens the "read/write disk" can of worms. The thing that I want, probably, is a network attached disk external to the player, possibly CF based. The problem is, network attached disk (it doesn't need to be secure in my car unless I'm dumb enough to use wireless, can anyone say reverse wardriving?) isn't really cheap enough that you'd throw CF in a device and use it for this sort of thing... yet.

But basically I want it external to my empeg, so it doesn't use up either IDE channel that I could use for real data, and slow access is ok. Serial would probably be ok, except for that "out of ports" bit.

Writing out track info to disk could be very useful, and at the same time, it opens the "read/write disk" can of worms.


Maybe it's me, but sometimes I think that we all get a bit carried away about this. Yes, the empeg guys did a fantastic job of protecting our drives in their daily use - both in HW (choosing laptop drives, shock mounting) and in SW (keeping the disks spun down as much as possible, only mounting read-only), and I am both impressed with and grateful for their design ingenuity.

But the fact remains - these are laptop drives, and they are shock mounted. Millions of people use laptops with RW disks spinning in cars, on aeroplanes etc, carrying them around and plonking them down on hard desks without regard to whether they are going to crash their heads. I suppose one might argue that when being used on a lap in a car, that the person provides some shock mounting for the laptop as a whole, but that isn't the only modus operandi.

I'm not saying that we should mount all the paritions RW, and leave the disks spinning all the time. But I do wonder whether our collective paranoia is un-necessary. I'm tempted to interface an accelerometer to my empeg, and attach it to the drive caddy. The only problem is that I'd need the disks RW to log the results

I don't think that we should write data constantly either - but we could cache data to be written, thus minimizing risks as far as possible.

Mark Lord has talked about making a disk writing feature available in Hijack. As mentioned, it would operate on a few sectors in-place, and could be done while the drives are mounted r/o. The kind of features you guys are talking about are definitely good uses for this kind of thing, at least, better uses than high scores for empacman or favorite trivia categories for emptriv.

Hopefully as the weather gets colder we'll see Mark around here more, and he'll make this happen. I agree, the "thou shalt not write while in the car" thing is a bit overboard, and we should allow for at least a limited write-while-driving API in Hijack.

In reply to:

---

That way for those of us outside the US who cannot find a MapsonXXX equivalent we can record/create routes we use simply and easily.

Well you could use google and find in a couple of seconds programs like
www.gartrip.de and http://home.t-online.de/home/gpsinfo/ which allow you to create tracks and routes based on digitized topographic maps by tracing the track you want to follow.

If you're from england and rather not use those german programs, www.gpsu.co.uk does similar stuff.

---

Yes, I realise all this, but my point is that not everyone has the same common "solution" for all countries, so there will be a lot of "home-brew" type setups out there, therefore allowing the building of routes by "driving them" is always useful.

Personally, I'm using TUMONZ (The Ultimate Map of New Zealand) which is all 100% vector based maps with route information & planning and it only costs $100 (about $USD50) and allows uploading/downloading routes/waypoints to Garmin & Magellan GPS units.
It also comes with "aerial photographs which you can "drape" over your map to allow you to merge actual aerial photos the landscape with the topography - see the opening screenshot on the TUMONZ website for an example.

Considering the price this is pretty amazing stuff.

But, you need a Windows PC to run it, and its not much use to anyone outside of New Zealand (unless you're Mark Lord and want to plan your next mountain expedition).

In reply to:

---

Writing to the disk is writing to the disk, whether you use a filesystem or write the blocks yourself. i.e. you could create a single large file without holes in any given filesystem and as long as it doesn't change it size the access is equivalent to writing to a raw device.

However, it is simply the actual process of writing bits to the disk that is dangerous. I believe some recent IBM 3.5" IDE drive was renowned for writing even when the power was cut so it would scribble over low level data between the tracks. This basically turned the disks into a brick that could be shipped back to the factory

---

I agree, but my idea is only bringing up something that Mark Lord mentioned a long time ago when some form of permanent rw storage was mentioned.

While Network Attached storage sounds really useful, I am not sure of the life span of any hard disks in a mobile environment when kept powered up all the time.

Ideally we need a solution that uses solid state [flash] RAM - something like one of those USB Flash based "disk drives" would be exactly right -
but you would need a USB **master** device between that and the Empeg (This is required [to act as a master device and go-between between the USB slavees to "route/mirror" all copy data requests from empeg (on USB Slave Port A) to USB data device (on USB Slave port B) and/or "route" read requests from Empeg on Slave USB A to data device on USB slave B.)

In addition we'd need a way to get the USB ports to dock/undock reliably/easily in the car - something which could be done if there was a USB master device in a small portable chip - and thats a bit of a tall order right now.

Either that or we come up with a simple solution that can "clip" onto the rear of the Empeg and plugs into the USB port on the back and "fills up"/uses the space between the rear of the Empeg and the rear of the sled - preferably something that could take a USB flash device.
I'm thinking something sized and designed like the Nomad Muvo here [but again thats only a USB slave device].

There are multiple problems that affect reliability of drives. One is vibration, the heads are floating close to the platters too much vibration could disrupt the airflow causing the heads to hit the platters. The airflow also disappears when the drive spins down, so it is very important to move the head away. Another factor is that te spinning platter works like a gyroscope, moving sideways or rotating it in the horizontal plane is pretty much ok. Moving it vertically is a bit worse, but twisting is rough on the bearings. Laptops typically spin their disks down quite often. This is not to save power, as it costs more energy to spin a drive back up and seek to the correct track than just leaving the disk spinning at a constant rotation. So this is to avoid the possibility of head crashes and perhaps even wear to the bearings.

A big factor however is power loss. Laptops only predictably lose power, their battery runs low and the system suspends/hibernates itself before we completely run out. However in a car we have possible power dips and loss due to starting the engine, pulling the player out of the sled, a bad alternator/battery, etc. And when the power cuts out, the platter slows down and and the heads have to be moved off the platter as soon as possible. With the drives I mentioned before, when a write was in progress at this time, it wasn't aborted during the 'emergency head park' and so the bits got written in a sweeping arc across the disk.

Laptop drives are typically better protected for the mechanical wear and tear of mobile devices, but are definitely not designed for sudden power failure. They'll probably be able to handle it to a point, but where that point is exactly...

It's not the shock mount, it's the fscking, that concerns me. I trust the hardware.

It's not the shock mount, it's the fscking, that concerns me. I trust the hardware.

I trust neither, and I especially don't trust that the power will be there from the beginning of the write to the end of the write.

But if we're talking about just unlocking /programs0 to write one file and the locking it again, I don't see a problem with doing that as long as it's user-triggered.

I would be perfectly happy if there were a menu option in GPSapp that says "Write data to disk now", and when I hit it, it saves everything all at once: Track history data, almanac/ephemeris data, whatever. It would then indicate when it was done on the screen somehow.

That way, if the data was important to me, I could make sure to do it and be sure it was done with the write before I turn off the ignition and pull the player out of the dash. And only when the car wasn't going over bumpy roads.

I wouldn't care about mounting anything read/write, or adding hijack hacks to update ext2 even when the filesystem is mounted readonly.

Just open("/dev/hda6", O_RDWR) (yes the swap partition), and you can just write blocks directly, add a checksum so that we can later tell whether the block was completely written or not. The player won't be using the swap in the car, and because the swap partition is as far as I can see on the outer tracks of the drive, I'm assuming it requires a smaller seek to park the head and in the worst case you'd only be trashing across the unused swap partition. Maybe even open it O_SYNC to keep actual writes as short as possible. There wouldn't be any metadata that could become inconsistent. I guess this is similar to how the player uses it's raw partition.

As long as we don't damage the first sector which contains the signature for the swap partition and recover the data when we're back on AC somewhere before the player starts an fsck.

Not all receivers support giving the user the almanac. The rockwell in the Palm 3 unit might; The SVee6 doesn't.

I still think parsing Tiger data is far more exciting than this. Other free apps do this; If Jan gets autorouting working he'll be the first open source author to do so

Just open("/dev/hda6", O_RDWR) (yes the swap partition)

Ew.

I guess I should bother to see if it adds the swap partition from the second disk. If not, and you have 2 disks, that's less worrisome.

Actually, no almanac from the Rockwell, either. However, looking at the Zodiac doc reminded me... are your slow starts in weak coverage areas?

are your slow starts in weak coverage areas?

No, I live on a mountaintop with wide open skies in all directions. And once the satellites lock, I get pretty consistent solid coverage from several sats.

Everything I've read says that with these particular devices (StreetFinders), it's normal for it to take a long time to get a lock like that because the units don't have any local storage. I'm just curious what we can do in empeg software support to speed it up since we've got the storage if we really need it.

Actually the SV6 does support almanac and ephemeris exchange with the attached device but not via NMEA. The SV6 from BGMicro was an OEM product that has a limited subset of NMEA implemented with lots of fail-safe provisions, probably used for vehicle tracking or ?? The NMEA mode in these SV6s doesn't allow much, if any configuration.

If you reflash it to TSIP you get a much richer interface that allows upload and downlod of ephemeris, almanac, initial position and time along with customizing many other of its modes of operation. For example, you can set it to provide an overdetermined solution where it will use more than 4 SV to improve the precision of the nav solution. You can also set it to track the highest 8 SV or the highest 6, change the mask parameters, dynamics filters, operate in MSL or geoidal height modes, etc. It is a real luxury for Trimble GPS users that Jan has included the TSIP parser in GPSapp.

NMEA, per se, doesn't allow almanac or ephemeris interchange. Individual manufacturers have defined proprietary NMEA-like sentences that are then useable for expanded functions. Unfortunately, these are different for each manufacturer's GPS so the interface to use them gets almost as complex as providing for the various binary protocols.

NMEA was originally intended to interconnect marine electronics such as speed logs, compasses, auto pilots, LORAN etc. GPS came later and was added as the $GPxxx series along with a provision for manufacturers proprietary messages in the $Pyyyx series, where YYY denotes the manufacturer (such as GRM for Garmin).

When all is said and done the almanac/ephemeris functions really belong in the GPS. If a GPS receiver (designed for navigation use) doesn't store these then it is most likely a hardware fault (bad battery or "Gold Cap" or BBRAM). I don't know of any decent nav receiver that doesn't store this data by design. Dependency on an external device is devistating to performance.

If a GPS receiver (designed for navigation use) doesn't store these then it is most likely a hardware fault (bad battery or "Gold Cap" or BBRAM). I don't know of any nav receiver that doesn't store this data by design.

The StreetFinder, I'm told, doesn't store this data permanently after it's been shut off. It only keeps it as long as it's on.

After a good bit of searching I did find a little bit of info on the StreetFinder's receiver. Link follows:

http://www.gpsnuts.com/myGPS/GPS/Hardware%20reviews/RandMcNally/rand_mcnally_gps.htm

If this is the same receiver you have, it would appear that the RTC is not loaded. Probably a cost saving measure that relied on the Palm for initialization. Too bad they cut this corner as it is probably an otherwise ok receiver.

This guy seems to think you can upload initial position and time but implicitly NOT ephemeris data. Your Time To First Fix will probably never get better than 90 seconds or so as the receiver would not output any solution until it collects a valid ephemeris from each satellite it is going to use. Add some overhead and latancy to the 30 second long data message and allow for an occasional satellite selection challenge and...

Looking further for info onthe Rockwell Zodiac receiver I found a spec for a related version here:

www.navchina.com/right/product/pdf/zodiac_dg_gps_33.pdf

This seems to imply that almanac and last known position data (and more) are stored in EEPROM, not requiring a battery (see page 6-12, 13). If this applies to your receiver then all that is needed is time initialization.

Receivers that store recent ephemeris have an advantage in reaquisition (only after short losses of power) as the validity of the ephemeris is relatively short, it changes at least once per hour. Some receivers may use an old ephemeris for a short time while collecting a new one but that is risky in terms of accuracy and detecting faults in the satellites.

Lynn

I did find a little bit of info on the StreetFinder's receiver. Link follows:

The review you linked was for a laptop-connected "mouse shaped" model. I do not know if its guts are in any way related to the Palm3 model I got.

Probably a cost saving measure that relied on the Palm for initialization.

Even when I used the Palm software, this thing had long acqusition times. It's even in the manual for the Palm software as being "normal".

Your Time To First Fix will probably never get better than 90 seconds or so as the receiver would not output any solution until it collects a valid ephemeris from each satellite it is going to use.

90 seconds would be a dream.

This seems to imply that almanac and last known position data (and more) are stored in EEPROM, not requiring a battery (see page 6-12, 13).

Well, I know that the receiver instantly spits back its last known position as soon as it starts talking to the serial port. So that part is true for sure. Dunno about the almanac/ephemeris data.

If this applies to your receiver then all that is needed is time initialization.

If true, then why didn't that timecode patch improve my acquisition times? Was it because of some kind of a timezone-off error? For example, my player's timezone is set to GMT-8 which is PDT. 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.

Interesting. I just peeked at the navman web site (the StreetFinder for Palm3 is a Navman product) and saw this. Note the highlighted text, I didn't realize this...

Question/Symptom:
What can I do to improve my Time To First Fix (TTFF)? The unit takes to long to acquire a fix when first turned on.

Answer/Solution:
There are several issues that can effect GPS acquisition. The receiver will often be blamed for poor reception or greater than average Time To First Fix (TTFF) in cases where user education can fix the problem. Realizing the limitations of the GPS system and utilizing your device for maximum performance will solve any problems you might be having.

1. View of the Sky- A GPS will typically take several minutes to acquire its initial position fix if it has not had a fix in your location on the planet previously. This is called a cold start. To obtain a cold start the GPS must have a view of the sky sufficient to 'see' four to five satellites continuously for about 45 seconds. It takes this long for the GPS receiver to download a data set from the satellites which is used to acquire a fix more rapidly on a future start (warm start). You must be located in an area with a clear view of the horizon around you. Buildings, houses, trees and other object will all affect this process. For Navman systems used in vehicles, they will typically be able to get a 'cold start' fix from inside the vehicle, but the vehicle can NOT be moving for the initial cold start. If the vehicle is moving it constantly changes the view of the sky and prevents the GPS from having a view of those same 4-5 satellites for 45 seconds.

2. Keep the GPS off- The GPS will acquire a fix more rapidly if it has an estimated position to work with. The GPS remembers where it was turned off and uses that position as a starting point. This is called a warm start or a hot start. The Navman GPS3420 has an integrated GPS expansion pack that is on (using power from the iPAQ) whenever a piece of software is looking at data from the allocated COM port. That is, when the SmartST Professional application is open then the GPS is on. If you leave the GPS on indoors for more than three minutes then it will go into a cold start mode. If it is left on then it thinks it can not 'see' the satellites it thinks it should. The GPS then believes it has been transplanted to a different part of the world and will try and start over doing a 'cold start'. This will cause it to have a longer time to first fix (TTFF) as if it has just been taken out of the box.
To Do:
-Make sure that you are stationary when initially turning on the GPS. You must have a clear view of the sky. The fix should not take long and you should see some progress from the GPS Status or GPS info screens.
- make sure that the SmartST Professional application is minimized or closed when the GPS is indoors or is not in a position to acquire.
-On the iPAQ, make sure all other applications have been shut down. The design of the Pocket PC is such that just clicking on the X in the corner doesn't really shutdown most applications. Many may still be running in the background. In some cases you might even want this, such as when listening to music while doing something else but for gps use shut everything down. Shutting down everything is not easy on a pocket pc. Method one is to use the Start menu and traverse to the shutdown command with 'start menu -> Settings -> System -> memory -> Running Program -> Stop All'. The second method is to use the iTask hardware key on the bottom right. This will list running programs and you can tap and hold to choose 'close all tasks'. Of course a soft reset also works.

How much power does the receiver really pull? Maybe you could just tie it to your always-on lead and never let it turn off. You could put a switch somewhere for those times when you know you'll not be in the car for a loooong time. Or maybe even figure out a way to build a timer that will turn it off after two or three days.

You're right. I'm seriously considering trying this.

How would I measure its load on my car's charging system?

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?

No really, the GPS wants UTC. It's not an arguable point, the documentation says as much.

I was just asking randomly as it seemed people here were poking at the time code again. My main irritation has been my forgetfulness to set the hijack offset properly, and was hoping it wasn't needed anymore.

I never understood exactly why it was, and some work with strace never revealed anything useful. I haven't actually bothered to see if my clock is still correct, despite the player having the correct UTC time.

There's definately something quirky about the player<->RTC clock interactions.

I've just installed Roger's base-tar distribution so that I could set up ntpdate, and when testing 'date' from the command line, I get:

"Thu Apr 27 21:49:29 /home/empeg/arm 2034"

and this is about 3 minutes after having set the date and clock right.
Now, the "home/empeg/arm" entry definately looks dodgy. It should return the timezone, but appears to be returning the start of a path.

And then when I run ntpdate, I get:
"27 Oct 21:54:57 ntpdate[43]: Can't adjust the time of day: Invalid argument" due to the year being so out of whack.

Then running:
sh-2.03# date 102817582002
Mon Oct 28 17:58:00 /home/empeg/arm 2002
sh-2.03# date
Mon Oct 28 17:58:02 /home/empeg/arm 2002
sh-2.03# ntpdate ntp_server
28 Oct 17:57:22 ntpdate[49]: step time server 192.168.1.1 offset -46.919752 se

resets the date correctly, but still results in the wrong TZ being presented by 'date'.

I just grabbed a copy of libc from the empeg and ran it through strings and grep..

/home/empeg/arm-empeg-linux-new/etc/localtime

Badly set up cross compilation environment, or a messed up glibc configure script. Because this path doesn't exist, none of the userspace binaries in the developer image can find timezone information. Either rebuilding libc6 with the correct paths or creating a symlink should fix it.

mkdir -p /home/empeg
ln -s / /home/empeg/arm-empeg-linux-new

Yeah, I tried that at the time, and it didn't help. I still have the symlink on that player (my wife's).

Of course, I think I discovered later some alternate reason why it didn't help, and probably it works fine now.

I haven't tried this yet, at all. I will, shortly. It won't blow up your GPS receiver or any such thing, but it's conceivable it might core.

If you don't have a Zodiac GPS receiver, this is useless to you, so if you don't have what Tony has, there's no point.

And if you care, here's the diff. Not ready for prime-time, I intend to change some stuff before I give it to Jan.

/me downloads anxiously...

And on the plus side it doesn't affect a Magellan Gold. I'll try an SVee6 (NMEA mode) later; If someone with a Garmin could see if this binary (which sends binary data your receiver can't use, but again it won't let the magic smoke out) in any way confuses their receiver, I'd appreciate it.

It may be smarter to use a config.ini option to enable this anyway, since you don't "need" it if you set the wrong option you should still be ok.

Rock. Seems to work. Satellite acquisition is almost instantaneous. Rock rock rock.

Agreed about the config.ini option, just make sure to let me know what the option *is* when the time comes that it gets rolled into the main codebase.

Question: Does this mean I can put the unit back on Amp.Rem power instead of constant power?

THANK YOU!!!

What happens if you run ``TZ=EST5EDT date''?

I'll include a patch to the README, but if it's harmless to just send the Zodiac stuff, there's no reason not to just send the Zodiac stuff always.

Hopefully someone with a Garmin can comment.

It also should enable optimization for "car" mode (as opposed to plane, boat, pedestrian, or static, for instance).

It also should enable optimization for "car" mode (as opposed to plane, boat, pedestrian, or static, for instance).

Wow, didn't know there was an option for that. Wonder what it does differently?

Question: Does this mean I can put the unit back on Amp.Rem power instead of constant power?

Forgot to answer this. Yeah, it should be safe. Basically the optimizations should put the Zodiac in the same mode it would be in if your automaker had mounted the unit in the car, at least if I understand the documentation.

I'm a bit displeased with doing everything in words instead of bytes, but I guess it's not that big a deal. I still need to clean up sequence number allocation, not that that should matter, either, but it would be nice to be technically correct.

I should probably also document some of the quirks about the zodiac_send interface which were again coded that way to conserve memory.

If you still have the base-tar dist install, could you check whether the following helps...

Make sure /etc/localtime is linked to the correct /usr/share/zoneinfo/.../... file. As I', not entirely sure whether the player app uses this link when changing the timezone so it might be missing. And set the TZDIR environment variable to override the incorrect search path for timezone files.

Something like,

ln -s /usr/share/zoneinfo/US/Eastern /etc/localtime

export TZDIR=/usr/share/zoneinfo

date or ntpdate

If this works, we're one step closer to getting the clock right. If this works well I can easily add the setting of TZDIR to the empeg specific initialization in empeg_ui.c.

Too cool.

It's unfortunate that the people who wrote the original Palm software for the unit didn't take this into account. All of the software that came with the unit (and all of the third party apps I tried) let it cold boot every time. So already, GPSapp is better for this unit than any of the commercial software. Thanks again!

No clue. The documentation only says it "adjusts the receiver's dynamics"

Wouldn't it be more useful to check whether sending the approximate location in the initialization sentence helps the startup time?

Wouldn't it be more useful to check whether sending the approximate location in the initialization sentence helps the startup time?

In my particular case, the receiver already has the approximate location at startup. It doesn't need any help from the software application to do this. The instant the software starts talking to the receiver, it spits back its last recorded location as Lat/Long coordinates. So my particular receiver doesn't need this information.

Seems as though all it needed was the appropriate instruction to just boot quickly (using the existing stored information from its last session) instead of cold-boot.

Question: Does this mean I can put the unit back on Amp.Rem power instead of constant power?

Forgot to answer this. Yeah, it should be safe. Basically the optimizations should put the Zodiac in the same mode it would be in if your automaker had mounted the unit in the car, at least if I understand the documentation.

Initial tests seem to indicate that I must leave the receiver fully powered in order to get the fast-startup benefit. I'm still curious about finding out how much current it draws and whether I'm going to drain my battery with it.

Ofcourse it 'starts fast' when you leave the receiver fully powered. gpsapp doesn't turn the receiver on or off, so the receiver just keeps tracking the satellites. The interesting part is what happens when receiver comes up from nothing. i.e. even the internal battery is drained. Does it remember the coordinates in that case?

Measuring current is can be done by measuring the voltage drop over a known resistance. Assuming a current draw between 100 and 250 ma, the voltage over a 5 ohm resistor in the power feed should drop between 0.5 and 1.25 volts. Most resistors should be able to handle the 0.4W of dissipated heat if I'm at all correct with my estimates.

Most resistors should be able to handle the 0.4W of dissipated heat if I'm at all correct with my estimates.


For a short while - long enough to take a quick measurement anyway. But most resistors available in RatShack are going to be either 1/8W or 1/4W. They do stock a few values in 1/2W, IIRC.

As opposed to turning off cold start? Well, how do you remember the approximate location? gpsd has switches to allow that, but it requires user input. Where do we get the input?

i.e. even the internal battery is drained. Does it remember the coordinates in that case?

If the hardware is like the Earthmate, yes (that or whatever backing store they use uses a very small amount of power and I never left it off long enough to matter, but it ran from AA batteries and powered off when the serial port wasn't open, so it seems like they won't try to charge something from those).

But maybe the hardware isn't.

I was thinking of allowing lat/long in config.ini. As long as we're correct within a couple of hundred miles that should be enough, so someone could put their home address in there, or maybe use whatever value the last point in a route called 'home' has.

I actually looked at the cold-start process of the SV6 when there is no backup battery. As it doesn't know time or place, it randomly scans for satellites. Once it finds one it pretty much immediately has a reasonable approximate time estimate and starts downloading the almanacs for all satellites. Once it has the almanac of the current satellite, it assumes this satellite is located approximately directly overhead and from that location estimate starts scanning for other visible satellites. As I was testing from inside the satellite it saw first was in fact at the horizon, so it really had a hard time finding my real location.

But a reasonable time estimate is something that we seem to get pretty much as soon as we hear from any single satellite, while location takes a lot more time and effort as the location estimate affects which satellites are assumed to be visible.

I considered that, but it makes me sort of leery. It's not that hard to do. It's still worth turning on the "car" optimization.

What should I do?

Ofcourse it 'starts fast' when you leave the receiver fully powered. gpsapp doesn't turn the receiver on or off, so the receiver just keeps tracking the satellites.

Actually, with my particular receiver, once something has been disconnected from the serial port for any length of time, it supposedly turns the receiver off. I think its timeout is 90 seconds. That's what was happening to me, any time the player has been unplugged for a while, it would cold boot again. So it doesn't "just keep tracking the satellites" as long as it has power, it also has to be connected to something. At least that seems to be case in the behavior I've observed. I have no idea how it "knows", but it seems to.

The interesting part is what happens when receiver comes up from nothing. i.e. even the internal battery is drained. Does it remember the coordinates in that case?

Yes, it seems to save the coordinates and spit them back out just fine, even after a complete drain.

However, after the internal battery is drained, it seems to go into the cold boot on the next power application anyway. I am not certain that this is the behavior, but it seems to be the case. I've only tried it once since getting Derrick's patch.

I've got a hunch that my unit's battery may be old and decrepit, as it doesn't seem to hold a charge for long. If I turn off the power feed to the receiver, it still sends data to the player for a little while but it eventually shuts off completely. Or maybe that's the 90-second timeout I'm experiencing, not sure. I'm not completely clear on how this receiver detects that it's "in use" and what its expected behavior is.

Can you let the battery drain and then attach it to a laptop and capture the NMEA in hyperterm or something as it's powered on?

I was never able to successfully get the thing working on a PC connection, and it's installed pretty deeply in my dash now. Don't have a laptop (of my own... wife rarely lets me use hers).

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"?