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