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?