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