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.

Well, then how routes work (inside the software) would have to change from an array of names to an array of structs (or a linked link thereof, but... memory fragmentation sucks, if you're not careful)

Yeah...a dynamically allocated and sized array of structs. Could be a nightmare...

BTW, the only difference that I saw in that binary was the strength meter bars lost their fill - as if no satellite was providing fix data - but the fix appeared fine....The cursor still didn't change though

he only difference that I saw in that binary was the strength meter bars lost their fill - as if no satellite was providing fix data - but the fix appeared fine....The cursor still didn't change though

I bet Jan has better insight, so I'm not going to read the code now. I sent a patch to Jan earlier which reads settings from config.ini, and I'm about to send another which acknowledges menu changes with a visible indication.

Fair enough... Thanks for trying

Actually, can you hook the Oncore to a PC? gpsapp_host outputs the NMEA; I can send you that (the x86 binary with the minor hack) if you need it.

I could - and will if I exhaust other options first, but currently my Oncore is sealed in an empeg-serial-powered enclosure and buried in my dashboard. As I spent most of Friday putting it there, I have absolutely no desire to take it out again so soon

Actually, I have an idea, I'm going to look at something.

Actually, if the docs are to be believed, none of the interesting sentences are turned on by default. I provided another URL in the PM you got. Try it, maybe this time...

2 things about the sat screen:

-The SVee6 in NMEA mode as factory doesn't send sat info. Sending a TSIP packet to it can turn on additional sentences. But... how do we decide something is a SVee6/SVee8Plus so we can send the TSIP?
-The Magellan I have seems to output WAAS as pseudo-satellites numbered e.g. "122". Probably the right answer is to drop satellites>99?

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

I don't know how global of a problem this is, but the Magellan Gold stops sending anything other than PMGNST and GPGSV when it loses its fix, so basically the way you have to tell you lost seems to be "notice you're not seeing updates"

In reply to:

---

The SVee6 in NMEA mode as factory doesn't send sat info. Sending a TSIP packet to it can turn on additional sentences. But... how do we decide something is a SVee6/SVee8Plus so we can send the TSIP?

---

two things -

1. can you send the SVee6 a TSIP "sentence" to turn on extra NMEA sentences, while its in NMEA mode or does it need to be in TSIP mode first?
also, does anyone have a link to the TSIP manual - I don't seem to have this.

2. Why not not have a configuration setting [GPS menu option], that you tell the GPS what kind of GPS you have and it sends the GPS the "special" sentence to enable the extra sentences.
I presume you only have to do this once and the GPS remembers it from then on?
Or does it need to be sent each boot up?

doesn't a receiver ignore messages it considers invalid, and each manufacturer uses their own prefix (PRGRM for garmin, etc), so there shouldn't be any conflicts.

I think that for the SV6 (and possibly SV8) it might be best to just use TSIP all the time. For Garmin's a lot of the interesting stuff is only available in NMEA, I haven't tried to enable WAAS on garmin, but it normally shows the waas satellites as 33-36. I'm sure that we can just discard any satellite id above 32.

Currently the type of gps protocol is specified as an argument on the commandline, i.e. gpsapp nmea, or gpsapp tsip. This is set in the startup script M50gpsapp.

Many of these setting are not persistent, or might get lost when the backup battery is not connected or loses it's change, so it is safer to just reinitialize to a known state on startup.

can you send the SVee6 a TSIP "sentence" to turn on extra NMEA sentences

The docs imply you can.

http://www.dementia.org/~shadow/sv8plus_manual.pdf describes the protocol. I have actual SVee6 docs somewhere but the only difference is the hardware description; The SVee8 has 2 more channels and another serial port.

Why not not have a configuration setting [GPS menu option],
Well, it does mean that when you change GPSs if you forget you're screwed, I'd guess.

Or does it need to be sent each boot up?
Depends on the GPS. That I wasn't clear on, for the SVee6, like, does it forget when I shut off my car? I'd guess no, that it's more or less the same as the NMEA/TSIP/TAIP selection. An Earthmate or a Tripmate *will* forget. The Magellan Gold I have doesn't have a way I've found yet to configure it other than from the menu on the screen of the unit. And so on.

doesn't a receiver ignore messages it considers invalid, and each manufacturer uses their own prefix (PRGRM for garmin, etc), so there shouldn't be any conflicts.

It's a good theory. It's even held true for all like 5 receivers I've tried with so far, and should be true for all of them; That doesn't mean some cheap vendor didn't get it wrong, but all the reputable vendors should work right.

I think that for the SV6 (and possibly SV8) it might be best to just use TSIP all the time.

Probably, but I don't feel like dealing with a Windows machine to switch this one back.

In reply to:

---

In reply to:

---

(number6's question)
can you send the SVee6 a TSIP "sentence" to turn on extra NMEA sentences

---

The docs imply you can.

This document describes the protocol. I have actual SVee6 docs somewhere but the only difference is the hardware description; The SVee8 has 2 more channels and another serial port.

---

Yes, you are right, the above doc, it mentions this on Page 3-5 - quoted below.

In reply to:

---

In reply to:

---

(number6's question)
Why not not have a configuration setting [GPS menu option],

---

Well, it does mean that when you change GPSs if you forget you're screwed, I'd guess.

---

Yes, but changing the option from either config.ini (done via Emplode (and maybe jemplode?)) or from the front panel via special command are pretty simple for most folks.
Making it a command line option or something makes it harder to change.
I realise most folks are going to change their in-car GPS once or twice - about as often as they change cars to be honest, but for in-home use/testing it may well be more frequent than that.
So making it easy to send this string to your GPS as required from the GPS app makes it:

(a) easy to maintain - the code is one place for all supported GPS receivers - and this is in the program than makes use of the features.

(b) Trivial to reset in the case of a new GPS unit being plugged in.

In reply to:

---

In reply to:

---

(number6's question)
Or does it need to be sent each boot up?

---

Depends on the GPS. That I wasn't clear on, for the SVee6, like, does it forget when I shut off my car? I'd guess no, that it's more or less the same as the NMEA/TSIP/TAIP selection. An Earthmate or a Tripmate *will* forget. The Magellan Gold I have doesn't have a way I've found yet to configure it other than from the menu on the screen of the unit. And so on.

---

The SVee8 [and I assume the Svee6] appears to be able to remember the settings in permanent memory, or possibly in battery backed ram (BB Ram?)
Heres the snippet from Page 3-5 of the Svee8plus manual.

In reply to:

---

The receiver is shipped with the NMEA protocol by part number from the factory. The NMEA setting can be changed using TSIPCHAT and command 0xBC. TSIP command 0x7A changes the NMEA output sentences and output rates.

The new settings are saved to BBRAM or they can be saved to non-volatile memory using TSIP command 0x8E-26.

* Note – Although the SVeeEight Plus GPS receiver supports seven NMEA sentences that contain GPS information, the factory default setting for the receiver only outputs the GGA and VTG data strings. To change the output interval or sentence output, use TSIP Command Packet 7A.

---

The right answer is probably:
1) configure protocol (NMEA/TSIP/whatever) in config.ini. I sent Jan that patch a few hours ago and he integrated it.
2) configure things which can be turned on safely inline with proprietary sentences regardless. Again, we dealt with the Oncore last night and Jan has the patch.
3) for receivers which can be "set once" have a menu item to "initialize foo receiver". This would cover the SVee6/SVee8. I guess I'll probably do this for 0.12, unless 0.11 comes later than I expect.
4) for receivers which need to be set each time and speak NMEA (e.g. not the Earthmate, and not the Tripmate, since we know how to deal with that) deal as it comes up. We don't know of any of these yet anyway.

The oncore can also be initialised once similar to the Sv6/8.

I'm beginning to think that config.ini should not be used for application data - we have seen issues with the player/hijack if config.ini grows beyond a certain size (the famed 'favorite visual' bug caused this to happen).

Whilst hijack options are in config.ini, the number of those options is fairly static...I'm not sure if ir_translate has ever been known to cause file size issues or not, but that is probably the most likely candidate for significant increase of filesize. But I forsee the day that an application developer decides that *everything* about the app is tweakable via config.ini, and Strange Things Start To Happen(tm)

If we ever get a standardised /programs0 (or whatever) install paradigm with JEmplode support for point and click installs, then it would be relatively easy to tell JEmplode to edit/save /programs0/etc/gpsapp.ini rather than config.ini for this step, and I think that is the way we should go..eventually.

gpsapp actually knows how to deal if config.ini grows too large, because size limitations suck, but changing files is easy enough.

or receivers which can be "set once" have a menu item to "initialize foo receiver". This would cover the SVee6/SVee8.

Actually it seems like the SV6 doesn't reliably remember NMEA settings across reboots. So that will probably have to rely on active intialization sequences anyways. Besides I prefer to explictily set receivers into a known state rather than relying on implicit state after a reboot, that should keep things more reliable in case someone forgets to connect the backup battery, or the battery dies.

I guess I'll probably do this for 0.12, unless 0.11 comes later than I expect.

0.12 it will have to be. I just drove home with 0.11 running and it seemed to work, so I just pointed the gpsapp webpage at the new version.

Edit: I guess I can just turn this into the new announcement.

GPSapp v0.11 is out. It contains a whole bunch of useful updates from dbrashear.

- untested earthmate support.
- reads default settings from config.ini.
- shows which 'toggle state' got selected from the menu
- Oncore init sequences

And ofcourse I couldn't help but add some things myself, so any bugs are definitely mine.

Besides I prefer to explictily set receivers into a known state

I agree, but do we know that for instance if you send TSIP to every non-Trimble NMEA unit they stay happy? They *should*...

so any bugs are definitely mine.

Actually, the Earthmate bugs are probably all mine.

Is the format for the config.ini settings "param: value" or "param=value"? If I understand the readme you are using the first format, but you might want to use the second instead since everything else that uses config.ini uses the second sentax.

-Mike

Thanks for the config.ini addition. Big step in useability

I have not been able to get the new M50... script to run, I get the following shell report:

kftpd: listening on port 21
player.cpp : 385:empeg-car 2.00-beta13 2002/07/24.
: No such file or directoryacman: /programs0/empacman
: command not foundd/M50gpsapp:
: command not foundd/M50gpsapp: exit
: No such file or directoryapp: /programs0/gpsapp
: command not foundd/M50gpsapp:
Prolux 4 empeg car - 2.1434 Jul 24 2002

and no GPSapp in the Hijack menu.

However, the previous version, with the $Protocol statement does work fine. I have added the protocol=tsip ("=" seems to be right for the other options) statement to config.ini but ??? Seems like Preinit doesn't like something - any clues?

Also, the satellite signal strength change is probably not helpful for Trimble receivers, could this be protocol dependent to at least retain the old scaling with TSIP?

Lynn

Ahh, nevermind. Trial and error shows that it is using the equals syntax. Cool.

-Mike

Do you have 'incar' installed?

The second. The readme just explains what the values are. My fault.

Incidentally I had considered including in the README patch a suggestion to put gpsapp lines at the end, since the code was explicitly written to be able to parse large files. It's evil, too. I started with some of the hijack code, and rewrote to support the twisted ends I wanted for the parsing.

A more generic parser for config.ini is available LGPL'd in Wine, but this is customized for GPSapp and I attempted to keep it small.

The next question is (when we're ready) does it make sense for every app to have a config file, or one for all apps?

From the truncated names it actually looks like you are running empeg-preinit v6 or something, which has a slight problem with a too short buffer.

On the other hand, it does look a lot like the errors that occured when there were DOS line endings, are you sure winzip didn't try to be smart?

Oh and satellite signal strength seems to be working fine on my SV6, which is running TSIP.

The next question is (when we're ready) does it make sense for every app to have a config file, or one for all apps?

Not sure, I initially added the options because (a) I didn't know beforehand how much processing time would be needed to draw things like the tracklog. (b) I wasn't sure exactly how much information on the small screen would make it too cluttered.

I guess many people will probably end up never changing a couple of the options. My guess is that the track trail, highlighting the route to the next waypoint and the map scale will pretty much always be on, so we can just remove those options completely.

Meters/Miles and GPS protocol are pretty much static settings that won't change over time. They are useful as config.ini options, but not really in the menu.

Popups are probably one of the few really 'personal preferences' that will differ per user and having both the config.ini and the menu option is probably the right thing.

This only leaves us with the gps coordinates, which will probably end up in the satellite overview screen, and the ETE, which already was suggested should probably (along with speed) replace the nifty pointer on the right hand side.

So in the end there will probably not be that much to customize at all, which would make config.ini the better place because Emplode already allows for easy editing of that file.

I never thought of ETE as useful, but I guess it can't be unless you have speed limit data to play with.

GPS protocol is only static if you assume most things speak NMEA (which may well be true)

Otherwise, I could see 2 cars having different receiver models.

And as to meters/miles, i think it's one of those deals where if you have more than one driver and one empeg a quick way to change is probably useful. In one car I can deal with meters since the speedometer has km/h calibration; The other does not, so it's harder to think that way.

Sorry for the false alarms. I now understand what is happening and it only seems to screw up text files. My editor is ok but I hadn't edited the M50.. file this time so it was left with Winzip debris as you surmised. I do have Preinit v7 and incar working properly.

My signal strengths seem to have recovered as well.

Oh, I like the "nifty pointer on the right hand side" of the screen, much more useful than ETE for me. ETE is really hard to make meaningful in traffic. There seems to be space for speed to be added without removing the pointer.

Also, the new way of showing rubberbands is a big improvement.

Lynn

The next question is (when we're ready) does it make sense for every app to have a config file, or one for all apps?

(a) per-application .ini
Each application needs to parse a file - parsing times would be shorter with specific .ini files.
Would enable each application to have several [headings] - allowing flexibility without confusion or conflicts
Might make a common parser more complex.
JEmplode would need to be clever enough to hunt for application_name.ini and edit it.

(b) One .ini
Each application would have to parse the same file looking for smallish pieces of information. Doesn't scale well to many applications.
Common parser might be easier to write.
[headings] would have be unique - realistically speaking, that means one [heading] per application.
JEmplode only has to deal with one file.


The parsing is key here. Ideally we could have one config_parse.c file to handle config.ini files, and that could be built into each application. If the parser was smart, it would enable developers to do something along the lines of hijacks config.ini parsing:

static const config_option_t config_options[] {
/* option text, variable, default, min, max */
{ "my_option1", &my_option1, 2, 0, 4 },
{ "my_label", &my_label, (int)"Hello World", 0, sizeof(my_label)-1 },
{ "my_option2", &my_option2, 42, 0, 100 },
...
};

parse_config("myini.ini", "heading", &config_options);


and the parser over-rides anything valid that it finds. Whether we need to consider the AC/DC or home/work capability is another question for debate. (Actually, I'm not sure if home/work is made visible to userland in anyway at the moment.)

I find hijacks way of adding options rather easy to understand and work with - as a C newbie I was quickly able to work out how to add stuff. Having consistency (with HJ) in the way that the option code works will also aid end users - they already know how to make hijacks options AC/DC/home/work dependant.

I haven't really looked at how hijack deals with different headings in config.ini, or how much code complexity that might add.

I suggested a structure like this (config_option_t) in email to Jan yesterday; I didn't do it because I was trying to keep the parser small. It's not a bad idea, though.

I guess many people will probably end up never changing a couple of the options. My guess is that the track trail, highlighting the route to the next waypoint and the map scale will pretty much always be on, so we can just remove those options completely.

Actually, I'd rather turn the track trail off most of the time (and at startup), but would occasionally want to activate it on the fly. So don't remove that as an option.

Also, the new way of showing rubberbands is a big improvement.

Wait, did I miss a release? I'm still on 0.10

Argh, yes I did. One of my ideas gets implemented, and I don't even know about it. Jan, announce these things will ya?

/me eagerly downloads 0.11...

Wasn't ackownledging which way a toggle has been "set", as well as permanent popups, your idea? Those both happened, also.

Cool. Can't wait to try it.

Incidentally, the first version of the "send 0x7A packet while in NMEA mode to turn on more sentences" patch seems to have failed. I'm going to try again shortly.

You might have to wait until the receiver has finished initializing before it accepts commands. Perhaps hook it in tsip_82_dgps_fix, which marks the end of an initialization sequence when initialized is false. The other way to test it is with TSIPCHAT.EXE. Although that does require a reboot into windows, which makes it far less attractive.

Perhaps hook it in tsip_82_dgps_fix, which marks the end of an initialization sequence when initialized is false.

That won't happen in NMEA mode, though, will it?

Although that does require a reboot into windows, which makes it far less attractive.

I'm not even sure my Windows install still boots.

I just tried out 0.11 and the new features work great, they're the business.

However, I think there's a bug. The Satellite Info screen no longer shows eight bars worth of satellites, it just blinks different numbers of one satellite in the lower left corner without any bar.

I still was able to track my position and everything, so the software was getting good data from the satellites, it's just that the Satellite Info screen didn't reflect it.

Yeah, I've been looking at this tonight too!

The azimuth/elevation data suffers from the same problem - ie only one satellite is shown, so I think that gps->sat[i] isn't getting populated correctly somewhere - but I haven't been able to trace where...still looking.

(This is with NMEA btw.)

Weird, must have been a recent change.

If I can get my cable modem working usefully I'll go back downstairs and try to figure it out.

Anyone know anything about SB3100 cable modems?

Strange, but then I again, I only tested the last couple of changes against TSIP. I'll give NMEA a spin tomorrow, it probably is something really silly.

I am having the same problem with only 1 satellite showing up. I also had it "crash" on my once. It actually remained running, but long/lat, routes, etc stopped updating. Until I pulled the empeg out of the dash and reinserted it.

-Mike

I think that it's gps_protocol.c in new_sat()

In reply to:

---

if (old == -1 || gps->sats.time < old_time) {
old = i;
old_time = gps->sats.time;

---

old_time is zero at the first invocation of the function, and all of gps->sat[i].time are also zero. Thus old always = 0, and old_time always = gps->sats[0].time for subsequent invocations of new_sat.

Try this patch.

You must have beat me by mere seconds, but I included the fix

Anyhow, I guess it's now on to fixing my TSIP problem, and trying JEmplode some more.

Cable modem still unhappy, Adelphia coming tomorrow to replace it.

Some unfinished but not relevant work crept into the diff, but it's still valid (and was working for me before I posted it)

Yeah, but I had to work out how it was supposed to work first
And I have to go outside to test any change I make

BTW, that fixes that issue. The other little issue that crept in (and was also in that test binary last night) is that the bars always appear to be 'not used in fix solution' shade, even when their corresponding azm/elv svn is showing as being used.

The actual bug is even dumber than that. I was passing a global 'timestamp' to new_sat, but this is never initialized (it should have been gps->time).

Ofcourse we can look for an empty slot, but that won't do much good as soon as we've seen more than 8 satellites, in which case we would go back to the broken behaviour.

The shade of the bars and the shade of the azm/elv are not the same anymore. The bars are shaded according to whether we received an update from the satellite less than 3 seconds ago. I was afraid it might become visually confusing. Maybe I should stay with using the shade to show if the satellite/measurement is used, and use the 'open bar' to indicate that it is a stale measurement.

That wouldn't be a crash. When the application dies hijack typically removes all bindings and throws us back in the player application. Also because gpsapp is not threaded, as long as it responds to buttons, it is just fine. It just might not be getting any data off of the serial port. I've seen it happen, and leaving/re-entering gpsapp typically fixes it for me. It merely causes gpsapp to close and reopen the serial port.

Ofcourse we can look for an empty slot, but that won't do much good as soon as we've seen more than 8 satellites, in which case we would go back to the broken behaviour.


Yeah, my instincts flared when I saw the fix, but I didn't chase it
wrt to the shading - what I'm saying is that I always see VFDSHADE_MEDIUM, and never _BRIGHT, so doesn't appear to be working how you hoped. But is probably also due to timestamp never being initialised - the comparison is based on gps->time and gps->sat[i].time, and we've realised that the latter is always wrong.

But, I'd prefer knowing which sats are being used in the solution - as you've described, BRIGHT for used, MEDIUM for current but unused, and open for stale.

In reply to:

---

That wouldn't be a crash.

---

Well, regardless of what you want to call it it stopped working as advertised, I haven't been able to reproduce it so I am more than willing to blame it on aliens, sunspots, the satellites owned by MLB that have been watching me, or whatever. I did try leaving and re-entering gpsapp a couple of times and it didn't make a difference though.

-Mike

I'm sure there is something wrong, I noticed the apparent loss of serial port input as well. Maybe a wrong fd is closed, or there is a bad memory reference, or perhaps the player is reinitializing the serial port to 115200 once in a while, even when it is started with the -s- option.

Although alien's abducting the satellites sounds like a good theory as well

Bug report for v0.10 (I know, I'm behind and so this may not apply)

Put the empeg in the car, turn the car to accessory. Allow the empeg to boot, then run GPSApp from Hijack. GPS app sits at the waiting for GPS screen (since I don't have the GPS wired up in the car yet). Start the car, empeg goes into low power mode for a second, comes back up to the player app. Hold down knob for hijack, GPSApp is not in the list.

Not sure if it's crashing during the powerfail or what is happening.

I know I reported it at the time. I should try again with v300 hijack and modern gpsapp and confirm it's gone.

I had a similar thing happen on 0.14 this morning, and without any ignition on/off intervention.

GPSapp was tracking my progress on the selected route. But I exited out of GPSapp for a while (GPSapp still runs I think, just doesn't grab the screen). I went back into GPSapp and it was still tracking correctly with the right map, but twiddling the knob to change waypoints did not work. It was almost like the processor was busy doing something more important than responding to my knob commands. So I exited out of GPSapp and tried to go back in again and it was gone.

No it's not gone, and it is not a gpsapp problem. There are some cases where hijack 'forgets' there is a userland application running. My guess is that the application restarts, or hijack tries to popup some message and the redirections are removed.

You'll notice that whenever you enter the hijack menu, gpsapp 'ghosts' through for a second, it is still running fine and trying to update the screen and listen for buttonpresses that are not redirected anymore.

That sound like something completely different. I've noticed stalls when returning to gpsapp. I still have to put vmstat on my player to that I can check my theory. I'm guessing gpsapp is paged out because the player is trying to use all available memory so every memory access causes a pagefault and it takes a while before the gpsapp is considered more active than the player.

You'll notice that whenever you enter the hijack menu, gpsapp 'ghosts' through for a second, it is still running fine and trying to update the screen and listen for buttonpresses that are not redirected anymore.

Yes, you are right, that is exactly the behavior I had this morning.

It's the first time it's happened to me, though, so it's not a very common bug.

Paged out to where? There's no swap space active when in the car.

Clean code pages are removed as a result of memory pressure as they can be faulted back in from the executable file. I explicitly didn't say swapped out which is what happens to dirty pages and anonymous memory. The fact that the disks spin up when returning to gpsapp is kind of a giveaway, the program only accesses the disk before it even binds to the hijack menu and when loading a new route.

Good point.

Can someone please help me with the python script as I know nothing about it? I need a complete walkthrough after installation. I currently have the newest version of ActiveState Python and a downloaded htm file for the route. I need to know how to get the parse_mapsonus.py file to work because all I get is:
File "<stdin>", line1
python parse_mapsonus.py test.htm

SyntaxError: invalid syntax

There is a carat underneath the last s on mapsonus. I am running Win2k.
Thanks in advance,
Justin

I had the same problem, make sure you have both the "parse_mapsonus.py" and "convert.py" in the same directory....

Tried that but, still no dice.

I never run windows, so I don't really know what I'm talking about here. But maybe it doesn't like the unix end-of-line characters?

Sorry I forgot to post. I tried it under cygwin (I downloaded python for it) and it worked, so good news for me, and another good use for cygwin for windows users.