Harry's GPS Suite Forum

I've used iPhone + Dual XGPS 160 for several years and suddenly it doesn't work. It chops up the lap in roughly 12 s pieces. It is on an airfield track, Ljungbyhed (Sweden) with good signal and about 10 GPS + 10 GNS satellites received. I updated the firmware on the Dual, but no improvement. I then switched to the iPhone internal GPS receiver and for some laps the same thing happened, but for most it worked. Talked to another Harrys user, with no external devices and he was fine. Another guy had issues and stopped using Harrys.

I attach some screen dumps.

And another picture ..

Any clue about what could be wrong?

I have been there twice the last two week and will go there again tomorrow, so a new chance to sort out the problem.

It seems like I solved the issue today. 3/4 of the track day spent on this. At least three tracks existed in the App, whereof one was a different track layout and the other two were the same but one were kind of obsolete and didn't show up in the list of selectable tracks, but for some reason Harrys recognized the POI's since I had used it many times before. First after I had erased 127 laps from the obsolete set of POI's and restarted the app (again..), then it started to record.

What I described above seems to be the result of the logging jumping between different sets of POI's, even though I had selected the valid one (Ljungbyhed Track Day), not the old one (Ljungbyhed), I found a lot of "patches" recorded last week on the non-selected Track, as well as for the selected.

That's a misunderstanding on who actually "selects" the track set used. It is LapTimer, not you. When loading a track set, you make it available for LapTimer, you do not select it. Once you drive, LapTimer will switch to whatever trigger's track set it passes. This is the reason why overlapping configuration are shown as conflicts and will disturb LapTimer operation. LapTimer will switch between track sets all the time and probably leave you with segments like yours.

So what is actually designed as something that should improve resilience of LapTimer operation (auto switching instead of sticking with a wrong track set), turns to the opposite when ignoring the conflict warning.

So in case you drive a track with multiple configuration, purge all other POIs for triggers not used currently. The easiest way is to reload the configuration driven. Once LapTimer warns you of a conflict, allow it to purge the other configuration's POIs. You will not loose lap data, it is just the track definition.

Please let your peer group know about this too.

- Harry

Thanks Harry, that explains a lot.

I think i need to read your reply a few times to really understand how to deal with it, but interesting is that the only guy who didn’t experience any problem was someone who hadn’t driven their a few years back when another POI set was standard.

I think i need to understand 1) How to realise that this problem exists (readiness not green!?) 2) what to dobin which sequence 3) What to do when a certain message pops up.

Actually there are two scenarios:

#1 users driving multiple tracks with a single configuration each: just load all the tracks you drive and let LapTimer do the selection work
#2 users driving multiple configurations of a single track: load the configuration driven ahead of your track day; let LapTimer purge all other configurations when asked

- Harry