Quick update to let everyone know that (finally!!) fit files from Garmin devices should work properly with ka72.com

Existing uploaded tracks have been marked as unprocessed and will have their stats recalculated when viewed on the track overlay page.

Please let me know if you spot any strange results. Only limited testing has been done so far.

Dylan

That's great, thanks!

I uploaded a few test files which would previously have failed, but can now be processed:

- Garmin Forerunner 255 + APPro app
- Garmin Fenix 7 Pro Sapphire Solar + APPro app
- COROS APEX 2 Pro in speedsurfing mode which records HDOP, sats, etc.

I noticed one slight oddity. The FR 255 track is reporting a max 2 secs which is 3 knots faster than GPSResults + GPS Speedreader. I can't figure out how / why this has happened, so it might be specific to KA-72.

The track is a very light wind wingfoil session - www.ka72.com/Track/t/536108

Select to expand quote

K888 said..
>
I noticed one slight oddity. The FR 255 track is reporting a max 2 secs which is 3 knots faster than GPSResults + GPS Speedreader. I can't figure out how / why this has happened, so it might be specific to KA-72.

The track is a very light wind wingfoil session - www.ka72.com/Track/t/536108

EDIT!!!
Seems Dylan is still working on this, the old default for FIT files was to use positional data, so 3kts faster is not unexpected.
Difference in filtering perhaps?????

That's not what the GPSTC admin want to see. At the moment we are considering making KA72 posting from the Garmins mandatory, so the model, firmware and set up can be checked.

@decrepit. I could have sworn that I'd checked the non-Doppler results, but it is indeed the reason for this issue.

Select to expand quote

decrepit said..

K888 said..
>
I noticed one slight oddity. The FR 255 track is reporting a max 2 secs which is 3 knots faster than GPSResults + GPS Speedreader. I can't figure out how / why this has happened, so it might be specific to KA-72.

The track is a very light wind wingfoil session - www.ka72.com/Track/t/536108

EDIT!!!
Seems Dylan is still working on this, the old default for FIT files was to use positional data, so 3kts faster is not unexpected.
Difference in filtering perhaps?????

That's not what the GPSTC admin want to see. At the moment we are considering making KA72 posting from the Garmins mandatory, so the model, firmware and set up can be checked.

Yes you are correct. I am looking at it tonight. There will be a few tweaks over the next few days based on feedback.

Thanks so much Dylan!

Select to expand quote

K888 said..
...
The track is a very light wind wingfoil session - www.ka72.com/Track/t/536108

Thanks very much for the track link. Makes it so much easier to check. The results should be closer now. Fit files will now be analyzed with doppler data (if available) and I've also changed the firmware field to say whether the GPS setting is All + Multi-band or not, which gives an at-a-glance check on compliance for GPSTC purposes.The updated firmware code will only take effect with new uploads. Existing ones are stuck for now, I'm afraid.

Thank you for all your work Dylan.

This is great work Dylan, very much appreciated.

Yes, great stuff Dylan, you could be our saver!

Select to expand quote

Dylan72 said..

K888 said..
...
The track is a very light wind wingfoil session - www.ka72.com/Track/t/536108

Thanks very much for the track link. Makes it so much easier to check. The results should be closer now. Fit files will now be analyzed with doppler data (if available) and I've also changed the firmware field to say whether the GPS setting is All + Multi-band or not, which gives an at-a-glance check on compliance for GPSTC purposes.The updated firmware code will only take effect with new uploads. Existing ones are stuck for now, I'm afraid.

Cool. Great job!

FWIW, I've never seen a FIT file without speed, but I have seen FIT files that only contain the enhanced_speed field. The enhanced_speed (and enhanced_altitude) fields are just 32-bit versions of the 16-bit speed and altitude fields, thus capable of storing larger numbers.

You do of course have see some individual records in the FIT files without a speed field. There is also a magic number of 0xffff to be wary of in the speed field - logiqx.github.io/gps-wizard/formats/fit.html#magic-values

With regards firmware, I wonder whether it might be an idea to capture a combination of the FW + sport + GNSS config.

E.g. 17.23:43:6 to represent FW 17.23, running in windsurfing mode (43), with dual band (6). That would give a good insight into the source, regardless of the Garmin model (approved or not) without having to download and inspect the FIT manually. APPro is already saving the GNSS config, but the GPSTC datafield won't be able to unfortunately.

The sport profile has a huge impact on the speed (and positional) data recorded in the FIT. There are quite a few Garmin sport profiles which are wholely unsuitable for speed sailing, including SUP, surfing and sailing. Fortunately the firmware and sport profile are automatically recorded in all Garmin FIT files.

For anyone interested, I've documented the most useful FIT metadata at logiqx.github.io/gps-details/general/fit/

Select to expand quote

K888 said.
APPro is already saving the GNSS config, but the GPSTC datafield won't be able to unfortunately.

Isn't the info that the watch is in "All Systems + Multiband" enough GNSS info, for the GPSTC????
We aren't the Weymouth speed event.
I don't want to exclude Andrew's Datafield on those grounds.
I think we have sufficient info for our purposes.

Select to expand quote

decrepit said..

K888 said.
APPro is already saving the GNSS config, but the GPSTC datafield won't be able to unfortunately.

Isn't the info that the watch is in "All Systems + Multiband" enough GNSS info, for the GPSTC????
We aren't the Weymouth speed event.
I don't want to exclude Andrew's Datafield on those grounds.
I think we have sufficient info for our purposes.

AFAIK, datafields cannot ascertain whether the watch is running in "All Systems + Multiband". Garmin apps get to choose their GNSS setting, hence they can log their choice in the FIT. Datafields inherit the GNSS setting the user has chosen as their watch default, or activity setting, or power mode. Unfortunately data fields cannot ascertain the GNSS setting, unless I've missed that in the Garmin API / SDK.

developer.garmin.com/connect-iq/connect-iq-basics/app-types/

Aside from using standard GPS the activity mode is by far the most significant setting that users can unwittingly get wrong, imho. For example, alphas can be boosted by the SUP (and surfing) profile which don't tend to pick up the lows. All watches behave in the same way with respect activity modes as it is Garmin-specific filtering. This example is a vivoactive 3 (MediaTek), vivoactive 4 (Sony), and FR 255 (Airoha) versus a Motion Mini.



The actual firmware version will be very useful if (heaven forbid) we ever see Garmin do what COROS did and break specific versions of their firmware. Some of the early shipments of watches like the Fenix 7 and FR-255 had horrible filtering (which COROS have recently adopted), so it could be handy to identify those issues without even downloading the track.

It's obviously just my opinion that these 3 attributes could prove useful; firmware version, sport profile, and GNSS setting. They are all stored in the FIT, but a little more time consuming to download and inspect manually.

Select to expand quote

decrepit said..

K888 said.
APPro is already saving the GNSS config, but the GPSTC datafield won't be able to unfortunately.

Isn't the info that the watch is in "All Systems + Multiband" enough GNSS info, for the GPSTC????
We aren't the Weymouth speed event.
I don't want to exclude Andrew's Datafield on those grounds.
I think we have sufficient info for our purposes.

FWIW, I don't think the GPSTC datafield should be excluded either.

Since the GNSS setting cannot be ascertained + recorded by a datafield, you'll probably have to trust the riders in this respect.

Fortunately, GPSTC has the big advantage that it is a close community and people can help + advise other participants.

When setting up the DataField, I get the option to choose between GPS Only, All Systems, All + Multi-Band, Auto Select and Ultra Track.
If I select GPS Only and go for a run, When I look in FIT File Viewer I get this.
mode GPS only.

If I then set the logger up with All + Multi-Bandand go for a run, FIT File Viewer shows this


So we know it's been set up in All + Multi Band.
But do you know what the UltrTrac Trigger is doing, and what are mode 3 and 25?

The Datafield itself cannot see the GNSS information, but the Activity automatically saves it to the FIT file. That is how KA72 is reading the "All +Multiband" setting. This is now operational in KA72.

The Activity type is also recorded in the standard FIT file. So we have all the information needed.

And KA72 has this.

decrepit

Olive Reserve, WA, AU - Tuesday, December 17, 2024

Location Distance Top Speed Olive Reserve, WA, AU 0.05km 5.432 GPS Type Firmware Time Zone Number of Points
Garmin.Fr255Music Full + Multi-band
7.5 57
MeasureResult 2 Second Peak (kts):5.432 5x10 Average (kts):0.765 Top 5 5x10 speeds: (1)3.825 Total Distance (km):0.051

Select to expand quote

tbwonder said..
The Datafield itself cannot see the GNSS information, but the Activity automatically saves it to the FIT file. That is how KA72 is reading the "All +Multiband" setting. This is now operational in KA72.

The Activity type is also recorded in the standard FIT file. So we have all the information needed.

Ah, nice. What tool are you both using to view the events and timestamps in the FIT file?

I've been using www.fitfileviewer.com which is hiding any messages + fields that are not recognised. The GNSS events listed above must be amongst the fields not recognised by the fitviewer.com.

UltraTrac itself is a feature that only turns on the GPS once per minute to save power during multi-day events. Maybe the UltraTrac event wakes up every minute, regardless of whether it is active.

The FIT SDK lists these event types. 3 appears to be a marker, but no mention of 25 and I assume that others are also missing:

Some thing strange I'm also using.
www.fitfileviewer.com/

Select to expand quote

decrepit said..
Some thing strange I'm also using.
www.fitfileviewer.com/

Aha... same URL but different browser, completely different application!

Left = chrome, right = firefox


GPS Events don't appear in the Chrome version that I was using... doh!

I was curious about what the mode values represent, so I decided to figure out the bit structure. This information is only going to be of interest to very few people, but I have documented what I discovered.

logiqx.github.io/gps-details/devices/garmin/developer/gps-events.html

It is worth noting the difference between native activities and Connect IQ apps. This will almost certainly be QZSS, based on the capabilities of the Airoha and the content of the protocol specification.

Great job K888 decoding that. Once I worked out that 'ALL + Multiband' was 15571. I lost interest and moved on. But it is great to have your documented description.
Thanks.

Great investigation K888. I was not looking forward to having to take the gps out in the field once with each setting to try and determine all the possible values.

Auto select could be a problem. At the moment ka72 will effectively only report the last GPSEvent value, as normally there is only one. If SatIQ throws multiple events that needs some extra thought (though of course we probably want to avoid that mode since it will only use multiband in locations where presumably windsurfing is quite challenging, like in the middle of cities.)

Select to expand quote

tbwonder said..
Great job K888 decoding that. Once I worked out that 'ALL + Multiband' was 15571. I lost interest and moved on. But it is great to have your documented description.
Thanks.

Thanks. I might have skipped over it as well, but with such different modes in my files the temptation to decode them was too great.

I also discovered an old cookie for fitfileviewer.com which was affecting Chrome. Now that I've deleted the cookie, I get the newer version of the app. Another mystery solved. :D

Select to expand quote

Dylan72 said..
Great investigation K888. I was not looking forward to having to take the gps out in the field once with each setting to try and determine all the possible values.

Auto select could be a problem. At the moment ka72 will effectively only report the last GPSEvent value, as normally there is only one. If SatIQ throws multiple events that needs some extra thought (though of course we probably want to avoid that mode since it will only use multiband in locations where presumably windsurfing is quite challenging, like in the middle of cities.)

Thanks, no worries.

One of sailquik's first sessions turned out to be in auto select. It was flicking between all systems and multi-band on both of his watches. Multi-band was rarely (if ever) active during actual runs, and tended to come on when coming to a stop, or inbetween runs.

In terms of processing, I guess there are two approaches. The simplest is to look at the "worst" mode during the session and flag the whole session as invalid. The second is to use the mode as an additional filter for valid points, if so inclined.

AS far as the GPSTC is concerned, if it isn't locked into "all + Multi-Band" it's an invalid file.

And Dylan, if you need a hand testing different iterations, I'm more than happy to be involved.

Select to expand quote

Dylan72 said..
At the moment ka72 will effectively only report the last GPSEvent value, as normally there is only one.

I've noticed that some Connect IQ apps select their desired mode (e.g. multi-band) at the beginning of the session, then as they exit some lesser mode gets selected. This would trip up my idea of considering the "worst" mode, since the actual session was all recorded in multi-band. One might argue that the app developer should fix such behaviour though.

Select to expand quote

decrepit said..
AS far as the GPSTC is concerned, if it isn't locked into "all + Multi-Band" it's an invalid file.

That makes sense, simple but effective.

KA-72 should probably check the mode using the appropriate bit mask(s), instead of expecting one or two specific values. The test for GPS L1 + L5, GLONASS, Galileo E1 + E5a, BeiDou B1I + B2a would be "mode & 0x1cc3 == 0x1cc3"

GPS events are an undocumented feature, so we can't assume that Garmin won't use some of the other bits in the future. I've now listed the unknown / unused bits in my document for the sake of clarity.

Select to expand quote

decrepit said..
AS far as the GPSTC is concerned, if it isn't locked into "all + Multi-Band" it's an invalid file.

And Dylan, if you need a hand testing different iterations, I'm more than happy to be involved.

I'm sorry if I am misreading this. Is the GPSTC considering allowing the use of Garmin watches in some capacity?

Yes I believe the advisory panel is considering allowing certain modern Garmin watches that have multifrequency technology.
For example the Garmin 255.
Initial testing is showing that these modern watches are considerably more accurate than the older models, providing they are set up correctly.

Select to expand quote

vosadrian said..

decrepit said..
AS far as the GPSTC is concerned, if it isn't locked into "all + Multi-Band" it's an invalid file.

And Dylan, if you need a hand testing different iterations, I'm more than happy to be involved.

I'm sorry if I am misreading this. Is the GPSTC considering allowing the use of Garmin watches in some capacity?

Follow the leader :) -> www.gps-speedsurfing.com/default.aspx?mnu=forum&forum=1&val=223129