A lot of changes. I hope not too much got broken, but moderate testing didn't really turn up any bugs. The satellite signals should be stable now and a bunch of other goodies.

Jan

I should have (untested; My Earthmate is still dead) earthmate support for you shortly.

Eagerly downloading... Thanks!

Well I don't know how much more you want to do with MapsOnUs but I think I broke it! All still works with my other smaller and simpler routes. I have a trip up into the Plumas National Forest this weekend and I thought I would try to process a route from home through Sacramento, Oroville and Quincy to Blairsden. The html from MapsOnUs is about 62k and is attached. The Python error message is as follows:

File "C:\Python21\Pythonwin\pywin\framework\scriptutils.py", line 301, in RunScript
exec codeObject in __main__.__dict__
File "C:\Lynn's\GPS and NMEA\gpsapp\route_files\parse_mapsonus.py", line 91, in ?
wpoints = parse(sys.argv[1])
File "C:\Lynn's\GPS and NMEA\gpsapp\route_files\parse_mapsonus.py", line 44, in parse
long = float(parts[2])
ValueError: invalid literal for float(): onto
>>>

If this is beyond where we should be going with this map data then that is fine with me. I can still read a paper map and am delighted with what we have. Of course coordinates in degrees and decimal minutes along with speed and heading and... would be welcome

Lynn

Jan, love all the improvements. Satellite screen doesn't blink any more, etc.

So, what do the colors and bars represent in the satellite screen now? (Perhaps could be in a future revision of the readme?)

Also, I notice that sometimes the satellite info screen will draw one of the "bar graph" lines below the baseline, right through one of the numbers. Is it supposed to do that?

The problem is that the saved html file doesn't seem to have preserved the line breaks in normal places (such at at the end of the line). So the parser cannot tell where the text-description ends and the next waypoint description starts.

I modified the parser so that it uses things like START and END as 'start of line markers'. Attached is the parsed route.

Have a nice trip

Solid bar indicates that this satellite was used in the last position calculation. Open bar indicates that it wasn't used. The colors in the right hand side match this so that dimmed satellites were not used for the fix.

The bars themselves are colored according to the 'age' of the last measurement we got from the satellite. If we haven't heard anything for about 2 seconds the bar is dimmed.

Drawing below the baseline is possible, satellite signal strength seems to be a 'magic value' and all the data I saw the lowest value was around 30 while the highest was appx 54-56. So I subtracted 30 from the value to get it to nicely scale into the 24 pixels that are available.

So I subtracted 30 from the value to get it to nicely scale into the 24 pixels that are available.

So what happens if the magic value goes past the screen boundaries? Page fault?

Perhaps you should trim the values before drawing them.

Nahh, vfdlib is perfect, it automatically clips anything that is drawn out of the screen.

From my very limited experience, I have seen 20s - 60s, and given that in car antennas attenuate significantly compared to roof-top antennas, and that signals are going to be far lower in the city/mountains than in the plains/desert, maybe displaying 20-68 would be a better solution...ie subtract 20 and divide by 2.

Just a thought.

Cool, trivial, done

Speaking of antenna signal strength....

There's no chance that I could plug this into my car's FM antenna and expect it to work and get better reception, is there?

I went to a lot of trouble to get the thing's little disc antenna mounted in my dash under the windshield, but it was tricky and I'm getting slightly lower reception than when I had it on top of the dash.

I noticed it was a shielded coaxial cable connecting the disc antenna to the PCB, and I didn't want to de-solder it to extend the cable length.

GPS signals are at 1575.42 MHz, right hand circular polorized. If you got anything out of your FM antenna it would be a fluke

Thanks Jan,

I thought I had used the same "save as HTML" process as before but perhaps not.

Lynn

Wow, it's impressive how much new posts and action I see after one week of not visting the forum - especially in the programming section. Thanks alot Jan.

Hey Jan,

More feature requests:

Can we get the map cursor changed? I'm thinking of something a bit more arrow-like that would point in the current perceived direction of travel. I appreciate that the cursor has to be small.

Is it possible to also change the cursors' brightness based upon the quality of the fix? ie, if we only have a 2D fix, dim it one level. And if we lose the fix, maybe change it's shape and brightness to make that clear.

And can we also get a fix statistics display? Something along the lines of reporting 3D fixes, 2D fixes and lost fixes seen in the past X minutes, and a reset stats option. Along with the excellent signal strength meter, that will be useful for testing antenna positions - Mount the antenna somewhere that looks like it has a good signal, drive around a 2 mile route and check the stats. Move the antenna and repeat..

Thanks once again for this great app!

Right now the map cursor is a bitmap, there are 17 different ones, N NNE NE ENE..., and a diamond shape for 'unknown. So it isn't too hard to change it to something else.

Is is too unclear where it is pointing to, or too large, or does it obscure our current location too much?

Right now the cursor 'should' turn into a diamond shape when the fix is lost, but that doesn't seem to be working too well

Interesting idea about fix statistics. I just wonder how to implement it. In some cases I'm just polling the receiver once in a while, so I can't really tell wheter a fix was lost in between the polls. Well, I can always give it a try and see if the resulting data makes any sense.

Is is too unclear where it is pointing to, or too large, or does it obscure our current location too much?


I think the current cursor is possibly the best trade off of direction vs real-estate. I've only ever seen it point up though :confused:

Please don't dim the cursor. When there is a lot of ambient sunlight, I can only read the brightest white pixels on the display, and can't see the gray shades.

In fact, I was going to request two things related to this:

1) Enlarge the cursor and give it some kind of a more directional outline.

2) Have the "Rubber Band" hilghlight the route to the next waypoint instead of drawing a straight line to the next waypoint.

Here's a picture of what I'm talking about:

The cursor should point in whatever bearing I'm getting from the gps. Maybe I'm not parsing the sentences your gps gives right. Could you capture some of the gps output and send it to me?

I'll have a look at changing the cursor, right now the way I store the bitmaps is a bit time-consuming to modify. Maybe I'll make it read a ppm file on startup, so people coud create custom cursors, a flying penguin, or a little hand or finger. I'm not that good of an artist

My cursor properly indicates direction on mine. It of course doesn't read correctly until I've been moving, since it can only indicate direction by comparing past readings with current readings. But when I'm moving, the arrow is always accurate.

I'll have to think how to do that - my GPS is kinda buried in the car now...and I don't have ethernet there.

It's an Oncore running in NMEA mode, Software command set available here. (Warning 2.5M pdf). The NMEA command set starts at page 142.

I don't know if the software I used to configure NMEA mode turned on GPVTG or not, which is what gpsapp appears to be using (from a quick glance at the source anyway). Does gpsapp deal with this, or doe it expect to find the messages already being spat out?

Which Oncore?

5.3 says GPVTG is on the GT, SL and M12, not the UT and M12T.

It looks like on 5.153 you need to send $PMOTG,VTG,0001 (with optional checksum) to for example enable 1 per second GPVTG messages. If you want I'll build you a custom gpsapp to try which sends this and you can see if it works for you?

Just checked the docs... GT.

I will gladly take up that offer. Thanks! I literally spent Friday ripping my dash apart to bury the receiver, thinking I was done with configuration...Guess I was wrong

I'm thinking that receiver configuration is something that would be useful to be able to do from the empeg anyway, maybe we could utilise the route loading function - if the first line matches a magic string, then the following lines are configuration messages for the receiver? That'd keep the configuration a 'hidden' option..

By the way, while I remember, route_load doesn't deal well with a subdir in /programs0/routes/. It appears to let you 'load' the route, but doesn't really do anything. It doesn't let you dig into the subdir (which would probably be a useful thing to do)

Hey, not a bad idea. Support a tree structure under "Routes" to organize your sets of directions. Kind of like hierarchical playlists.

Yeah, but if some fscker puts them on Random-Shuffle Repeat-All mode so I end up drinving around the country for a pack of cigarettes then I'm going to be one pissed off bunny.

But in all seriousness, it'd be useful to be able to dump a road trips worth of routes into a single subdir to avoid clutter..

Give me a few minutes; I have a patch to send to Jan first which hopefully implements reading options at startup from config.ini. (It works for me, but..)

I'm thinking that receiver configuration is something that would be useful to be able to do from the empeg anyway

Ideally you'd just ask for the sentences you know you need based on what you know the receiver you're talking to can do, but with NMEA that's hard.

I think though that it's safe to just send the requests regardless of what you're attached to.

By the way, while I remember, route_load doesn't deal well with a subdir in /programs0/routes/

It's Jan's program, so I think it's Jan's call, but this isn't a huge surprise. The contents of /programs0/routes/ are traversed and put into an array without checking for e.g. ISREG. If it's not going to deal with directories maybe it should at least do that, but since it's all traversed up-front, and the name of the file is the name of the route, the simplest way of dealing would result in routes named e.g. foo/bar. Is that reasonable? What happens if the name is bigger than the display is wide?

I don't think that seeing eg foo/bar as a route is desirable - the main usefulness of subdirs would be to hide away routes that weren't commonly used, or to organise routes.