Starting new thread so as not to hijack the "Garmin Approved on GPSTC" thread. This thread about accuracy of the Apple Watch Ultra 2 relative to approved devices on GPSTC. Anyone wanting previous history of discussion to this point see page 3 of above thread.I've started looking at the FIT vs GPX data and one interesting observation early on is the Jan 6 data set. This showed glitches on the GPX positional files but the results from GPSSpeedreader still on par with other sessions. However, the FIT files which contain speed data are completely berserk for 100% of the time as per attached screenshots. GPSSpeedreader results are complete garbage.

Still no clue what may have caused this


The FIT dataset by itself


zoomed in. I'm assuming the dotted lines are positional speed and the solid is doppler speed and GPSSpeed reader just setting the scale using doppler speed causing positional speed to be off scale.


will take a bit of time to download all the FIT files and put them through GPSSpeedreader but will update when comparison done.

Select to expand quote

Flex2 said..
I've started looking at the FIT vs GPX data and one interesting observation early on is the Jan 6 data set. This showed glitches on the GPX positional files but the results from GPSSpeedreader still on par with other sessions. However, the FIT files which contain speed data are completely berserk for 100% of the time as per attached screenshots. GPSSpeedreader results are complete garbage.

Still no clue what may have caused this

6 Jan was recorded as a run, whereas the sane FIT files were recorded as a bike ride.

The suppressed speed data on 6 Jan will have been due to the filter that Apple have implemented for their run activity.

I've looked at the 4 sessions with FIT files and got a mixed bag of results. I can't write it all up right now, but I'll post two screenshots where the data isn't very good for a couple of 500 m runs. Both are out by 0.8 kts which is quite a large difference for 500 m.

The 500m runs are highlighted in yellow. ESP (green) + FIT (blue) + GPX (red)


The 500m is followed by spikes in the GPX and FIT data, coinciding with a gybe. It is clear that the positional data (red) is being filtered / smoothed by Apple during the 500m itself, but the change in FIT speed just after the run doesn't seem like a plausible measurement - 2 knots to 16 knots within 2 seconds.

Whilst the FIT file contains the speeds recorded during the bike activity, I'm not entirely convinced it is the Doppler-derived speed from the GNSS chip. It might be positional data that has gone through a different filter to the positional data. FWIW, many of the sports profiles on Garmin and COROS watches derive speed from the positional data, but using different filters for positions and speeds.


I think it would be worth collecting some test data using either Waterspeed or Hoolan. Both apps have access to Apple's location API and should therefore record the positions and speeds from the GNSS chip, with minimal filtering by Apple.

Peter made a good point about the gybes and boom mounted units in the Garmin thread. There are however some really significant differences between the ESP and the Ultra 2, sometimes up to 7 knots (shown below) or 10 knots (previous post).
The FIT speed also increases from 4 knots to 13.4 knots in 2 seconds which is a significant change.

Due to some of the oddities in these files (even when sailing in a straight line), I'm not 100% sure the cycling activity is recording the DD speeds. I think it would be worth recording some sessions using Waterspeed or Hoolan to see how the data compares.

Select to expand quote

K888 said..
FWIW, many of the sports profiles on Garmin and COROS watches derive speed from the positional data, but using different filters for positions and speeds.

This is an absolute statement that leaves no room for doubt. It this based on information you have received from Garmin and Coros, or is this based on your observations or conclusions?

Select to expand quote

K888 said..
Peter made a good point about the gybes and boom mounted units in the Garmin thread. There are however some really significant differences between the ESP and the Ultra 2, sometimes up to 7 knots (shown below) or 10 knots (previous post).
The FIT speed also increases from 4 knots to 13.4 knots in 2 seconds which is a significant change.

Not so fast, cowboy!

The differences are with the ESP on the boom, and the watch on the hand. Is the observed difference real, that is due to actual differences in how the hand and boom move? That's open to analysis and experimentation.

If Flex starts the jibe with a wide grip, then the back hand has to move about a meter to grab the boom on the new side. If he's take one second for the movement, that would give and average speed of 1 m/s, or 2 knots. The hand movement is in (roughly) opposite direction of the direction of travel, to it would reduce the measured speed on the wrist GPS by 2 knots. After gripping the new side, the mast gets pushed forward in the direction of travel, increasing the speed. This increase is expected to be a bit less (due to having to move the rig, not just the arm), so we'd see a larger speed drop and a smaller speed increase right afterwards.

This simple analysis has one flaw and one critical assumption. The assumption is that the hand movement would take one second; but if the hand movement would take just half a second, then the average speed of the hand movement would increase to 4 knots.
The flaw in the analysis is that we used average speed. But the speed during the hand movement is 0 at the start and end, so it must have an acceleration and deceleration phase. This also means that in the middle of the movement, the hand speed is significant higher than the average speed during the entire movement.

Analysis only gets us so far, but we can experiment to get "real" data. Until someone straps a 10 hz GPS to his hand in a speed session, we can look at data from just moving the arm done in the yard. Here's what this looks like with a 10 hz GPS:


We see that:
- in these "energetic" hand movements, the top speed is above 10 knots
- the hand movement takes about 0.5 seconds
- the top speed is about 4 times the average speed (3.19 knots for the selected points)
Note that the speeds in the double peaks are in opposite direction. With a board still moving, the speed of the 1st peak (arm moved back) would be subtracted from the measured speed, and the speed of the second peak (arm moves forward) would be added to the speed. In this example, this corresponds to a speed increase of up to 25 knots over about 2 seconds! That about 2-3 times as much as in the two examples from windsurfing that K888 has shown.
Bottom line: the observed differences, including the 3-15 knot acceleration over 2 seconds, can be fully explained with hand movements in the jibe.

What's perhaps a bit puzzling is that this difference (speed drop followed by spike in the middle of a jibe) can be seen only on some jibes, and is completely absent in others. This is simple a consequence of measuring just one per second, and the arm movement taking less than one second, with the maximum speed being held for only about 0.1 to 0.2 seconds. This means that the watch will miss the top speed of the arm movements most of the time, but every now and then, it will capture it. Here's an example where arm movements were measured at 10 hz (blue) and at 1 hz (red):



In the first and 3rd peak, the watch missed the first peak completely, but measured the top speed of the second peak reasonably well. For the middle arm movement, the watch missed both peaks, but the speed at the time point where it measured matches the speed from the 10 hz data.

Fortunately, the effect of measuring arm movements affects only jibes and alphas, and the affect on alphas is quite small, since it will be averaged out over the entire 500 m run, or about 40 points for a 25 knot alpha.

Select to expand quote

boardsurfr said..

K888 said..
FWIW, many of the sports profiles on Garmin and COROS watches derive speed from the positional data, but using different filters for positions and speeds.

This is an absolute statement that leaves no room for doubt. It this based on information you have received from Garmin and Coros, or is this based on your observations or conclusions?

It's a mix of my own investigations and discussions with COROS, who try to avoid sharing too much detail. The accumlation of knowledge over the past 6-8 months leaves little room for doubt in my mind. I'll endeavour to write up the pertintent info over coming weeks and then it can be scrutinised.

Back in July last year, I did my very first activity comparison on Garmin (and COROS) watches. That particular set of tests serves as a starting point for anyone wanting to understand the difference between some common activity modes.

logiqx.github.io/gps-details/devices/garmin/activities/driving-2024-06-30/

You will notice that I mentioned a spike in the hiking data could be due to the use of PD speeds. That reference is not provided as evidence, simply to show when the possibility of PD speeds being used (for some activities) became apparent.

In the last 6 months, I've spent far more time than I'd like studing COROS screw-ups, reporting to COROS and discussing with them via e-mail. To improve my own understanding, I've also been ascertaining which activities behave in the same way for each brand (COROS + Garmin) and what they are doing. All of those tests go far beyond anything in the link above, but I haven't had time to document every test and the findings.

One of the only upsides into spending so much time looking at broken stuff, documenting it (only a tiny percentage) and discussing with COROS is that it's provided deeper insights into what their watches are actually doing. I also have e-mails from COROS describing fixes such as "speed used for statistical data has been modified to Doppler speed". I should probably write up my findings, but struggling to find the time.

Regarding Garmin, I need to collate all of the relevant data and write it up properly. I was recently working with Harry Oosterveen (creator of fitfileviewer.com) and trying to bottom out what the GPS metadata represents in Garmin FIT files. His hobby is speed skating (on ice) so his data is interesting because it's in an open-top building. He previously believed the GPS metadata was derived from PD speeds, but I've always thought it was closer to the DD speeds, albeit with unexplained dips (which have no correlation with the PD speeds). Turns out we were both right (and wrong) at the same time. Sometimes the GPS metadata follows the DD speeds, and sometimes it follows heavily smoothed PD speeds.

Just as way of example, here is a test drive comparing the speed we get for windsurf / kitesurf / other against the speed in GPS metadata.



I've looked back at the problematic FR 255 and Fenix 7 data from 2022, and Garmin were replicating the somewhat freaky gps_metadata.speed in record.speed. That's why we saw really bad speed data from Garmin watches in 2022.

One might wonder what the GPS metadata actually represents, but I've got test data that shows they are splicing heavily smoothed data from activities such as SUP with the unfiltered DD data of the GNSS chip. They essentially switch between one or the other, depending on what they think is most suitable at the time.

Harry's data has been useful in that the ice rink reception is sufficiently impaired to cause inaccuraces in lat + lon (boosting PD speeds), but the DD speeds are relatively unaffected. It's thus possible to determine whether the smoothed data in GPS metadata originates from PD or DD speeds. I can't quickly demonstrate the findings in a short post, and I have further tests to complete before I write it all up properly.

However, everything points to Garmin activities such as walking, SUP, etc using filtered / smoothed PD speeds. Please bear with me in getting it documented. Busy times!

Saw the replies just as heading out, only had the shoulder unit charged but strapped that on wrist next to watch. Next session will use the T display which is 3 times smaller. Was completely underwhelming session, underpowered all the time but like when I used Waterspeed app back in the early days (5+ years ago) it was also completely underwhelming...buggy/annoying software (long rant deleted). All good though in the name of getting some good data....alas..not to be

First pass, the data way worse than the native apple recording. First is the FIT export files don't have the speed data but the CSV does? (maybe that just me?). I've put all the export option files available (Strava GPX, FIT, CSV) on the google drive link for Feb 2. Plus public "share data link" which doesn't work at all.....Here is the link waterspeedapp.web.app/activity/jrgkQsp884cemgGZpEVNOXmvcq03/4c17d175-6390-421d-b94f-38ac53f34190

Other than the first couple of runs (where there was no wind) I did not stop...the Waterspeed data says velocity drops to zero many times. This seems to go away at higher speeds. Zero crashes or underwater events for whole session.. .Will redo test tomorrow using T display and native Apple recording and chuck the shoulder unit on other wrist.

Select to expand quote

6 Jan was recorded as a run, whereas the sane FIT files were recorded as a bike ride.

The suppressed speed data on 6 Jan will have been due to the filter that Apple have implemented for their run activity.

Yes, you right, I was experimenting and did record this session as a run (possibly one or two other as a walk) to see if made any difference

Regarding the arm tests, that's consistent with near-identical tests that I did last year. I was seeing short-lived speeds of around 12 knots on a 5 Hz Motion. That was an extreme arm movement (punch / jab), far in excess of a rig rotation but showing what an arm can do.

I completely get how the boom and hand are independent, but there are times in Flex's data where random dips happen during a run, unrelated to a gybe. This one is during a 500m run where he slows down, then speeds up again. My suggestion to capture the data using a different method might just eliminate PD speeds as a possibility, identify them as a possible cause, or just baffle us for a while!

Some of the extreme sawtooth during Apple rig flips is unlike anything that I've seen from other devices, including the Garmin watches which have been demonstrated to pick up high momentary speeds. On the other hand, I've also seen extreme sawtooth during gybes (and straight line sailing) in the PD data from the Garmins. It may not be PD data in these Apple files, but worth investigating imo.

When Flex said he might be opening a can of worms, he's not wrong. The nuances of the Garmin and COROS watches have kept me busy for months and I still haven't yet finished writng up what I've learnt and think is useful in the public domain. Now we are on to Apple as well...

Thanks James. Can you export the GPX file(s) from the Waterspeed app? It provides four different GPX exports:

- Garmin
- Google
- GPSAR
- Strava

Only the Google and Strava ones are suitable for comparison with the ESP. The GPSAR one has the times wrong by an hour (well, it used to) and the Garmin one doesn't include speed. It is ironic that the Strava one contains speed, because Strava ignores it. Speedreader recognises the speed in the Waterspeed GPX files, when it is present.

There should only be one GPX export but they've all got different issues and they are all kudges to make them work on the various platforms. If they created GPX files correctly (adhering to the XSDs), one GPX would work on all platforms. I documented it years ago, but it's yet to be fixed.

If the GPX files exported by Waterspeed also have a "snap to zero" then it's Waterspeed that is doing it. When I was comparing Garmin and Apple data for Hoolan the Hoolan data did not contain those artefacts.

ok, all 4 GPX export options from Waterspeed exported as requested to Google drive Feb 2..folder name "various GPX".. I named them accordingly

I've just had a look at the CSV which provides some hope, but difficult to work with.

Low speeds are not obvious snapped to zero, but it uses a form of "smart" recording where the time interval varies. For this reason, it's not quick and easy for me to compare those speeds to the ESP.

The native GPX exports (Google and / or Strava) will make comparison with the ESP practical.

Select to expand quote

Flex2 said..
ok, all 4 GPX export options from Waterspeed exported as requested to Google drive Feb 2..folder name "various GPX".. I named them accordingly

Thanks. The waterspeed data looks pretty rubbish, so that can be ditched for future tests. Low speeds are snapped to zero and there is an abundance of repeated speeds.

Can you try Hoolan? I know the author is recording the DD speeds from the Apple location API and creating his GPX files correctly. I think the GPX export is one of the free features.

www.hoolan.app/help/apple-help/exporting-data-from-hoolan-iphone

I recall some comments you had made a while ago that the Apple watches used different GPS units internally. Does this happen within the same model, or only between different models? Garmin releases lots of new models every year, and it seems safe to assume that they don't switch the GPS chip in a given model. But Apple pretty much has a "once-a-year" release schedule, and the GPS function is not nearly as central as it is in the Garmin watches.

Such "silent" switches of the internal GPS in watches would be a big argument against allowing a watch for GPSTC postings.

Select to expand quote

boardsurfr said..
I recall some comments you had made a while ago that the Apple watches used different GPS units internally. Does this happen within the same model, or only between different models? Garmin releases lots of new models every year, and it seems safe to assume that they don't switch the GPS chip in a given model. But Apple pretty much has a "once-a-year" release schedule, and the GPS function is not nearly as central as it is in the Garmin watches.

Such "silent" switches of the internal GPS in watches would be a big argument against allowing a watch for GPSTC postings.

It's really hard to be sure what is inside many of the models. I'll paste my personal notes, but nobody has been publishing public teardowns since the SE (gen 2). It basically requires people to decap the SiP assembly and the companies who do that charge for the content of their teardowns.

To summarise, some watches have definitely contained a dedicated GNSS chip (e.g. series 6 and 7) made by Broadcom. Some watches don't contain a dedicated GNSS chip and appear to use the RF frontend + baseband processor, which would be much like many modern phones afaik. Qualcomm supplied the baseband processors up to Series 3, but since the Series 4 they it has been an Intel chip.

I have no clue whether there is a dedicated GNSS chip inside the series 8 and onwards, which includes the Ultra and Ultra 2. They might be sharing the baseband processor with the cellular capabilities, much like a lot of modern phones. On the other hand, some of the premium models with dual-band may include a dedicated GNSS chip, possibly from Broadcom.

Series 3 (Sep 2017) - suspect the Qualcomm baseband processor
Baseband processor is the Qualcomm MDM9635M

Series 4 (Sep 2018) - suspect the Intel baseband processor
Baseband processor is the Intel PMB9955 which contains an Intel XMM7560

Series 5 (Sep 2019) - suspect the Intel baseband processor
Baseband processor is the Intel PMB9955 which contains an Intel XMM7560

SE "1st Gen" (Sep 2020) - suspect the Intel baseband processor
Baseband processor is the Intel PMB9955 which contains an Intel XMM7560
Same systems supported as the iPhone 8 / X - GPS, GLONASS, Galileo, and QZSS

Series 6 (Sep 2020) - confirmed as Broadcom BCM47754
Baseband processor is the Intel PMB9955 which contains an Intel XMM7560
Skyworks LNA / filter + Broadcom BCM47754 in teardown

Series 7 (Oct 2021) - confirmed as Broadcom BCM47764
Baseband processor is the Intel PMB9955 which contains an Intel XMM7560
Skyworks RF power amplifier + Broadcom BCM47764 in teardown
The multi-band capability of the BCM47764 is not utilized

SE "2nd Gen" (Sep 2022) - confirmed as the Intel baseband processor
Baseband processor is the Intel PMB9955 which contains an Intel XMM7560
Same systems as the iPhone 8 / X - GPS, GLONASS, Galileo, and QZSS
Skyworks front-end module + Intel baseband processor in teardown
Skyworks GPS LNA with filter and LB (low band) front-end module
Intel baseband processors/RF transceiver

Series 8 onwards... far too speculative, so I'll keep my notes private.

Related info about iPhones
medium.com/@ilyakorogodin/where-is-a-navigation-chip-in-my-iphone-92ab55a61863

ok, got the Hoolan App loaded and quick test..works but totally not obvious how to output data (Edit_ok, GPX from Hoolan can do)..... Seems wrong (overload the unit) but run native and Waterspeed/Hoolan synchro??

Regarding switching chips within a model, not to my knowledge. Watches contain a SiP such as the Apple S9 inside the Ultra 2.

There were periods when Apple released two near-identical phones containing different chips (Qualcomm or Intel), but that was due to patent disputes between Apple and Qualcomm.

medium.com/@ilyakorogodin/where-is-a-navigation-chip-in-my-iphone-92ab55a61863

I guess I'm mainly interested in understanding how well the Ultra 2 can perform, how to maximise its GNSS performance, and what not to do in terms of apps, formats, etc. I'm a long way from forming an opinion about how well it performs, and how often it can mess up.

Any comments that I have made so far are just my initial observations. It will be interesting to contrast the Waterspeed and Hoolan data.

Select to expand quote

Flex2 said..
ok, got the Hoolan App loaded and quick test..works but totally not obvious how to output data (Edit_ok, GPX from Hoolan can do)..... Seems wrong (overload the unit) but run native and Waterspeed/Hoolan synchro??

Cool. I'd suggest you only run Hoolan for the next test. I wasn't envisaging Waterspeed running at the same time.

I've now seen enough artefacts in the Waterspeed data to know whether they are present in Hoolan data, or not.

One last post for the day.

The Waterspeed data contains what appears to be unfiltered positional data. This is far more desirable than the native cycling activity which applies heavy filtering. Obvious inadequacies in the Waterspeed data are the "snap to zero" (not shown in this screenshot) and identical speeds for multiple seconds (typically 2 or 3 seconds).

Will be interesting to see what comes out of Hoolan.

ok, uploaded todays data from Hoolan to Feb 3 drive.google.com/drive/folders/1XEKgqQaQqEhJ9wu0uCtQo9S9LR1HEdKI?usp=sharing

Native app GPX export and FIT export via the health app. Appears no velocity data???? and a few glitches on positional. No crashes during session..just one stop to check the T1 working (as forgot had set the display to turn off above 1m/s). Calling it early but native cycle recording at least doesn't glitch like the dedicated apps do. Like K888 says though purpose of this discussion just want to know the best way to record a session if you have this thing and how accurate it is.

Had the T1 unit strapped to wrist next to Apple Ultra2 as per pic.

Just a quick 10 minute review. This appears to be the best recording method so far, if you look past some minor glitches.

Good

- Positional + speed data not being filtered / smoothed (unlike cycling and Waterspeed)
- Speeds not frozen for 2 or 3 seconds (unlike Waterspeed), so it is really 1 Hz
- Fixed lag behind the ESP (unlike Waterspeed)
- No crazy rig-flip artefacts (unlike cycling)
- No snap to zero for low speeds (unlike Waterspeed)

Glitches

- A few frozen timestamps and some 2 second jumps. Presumably related as typically quite close together
- A few frozen positions (Garmin-esque). Maybe related to timestamps, no time to check now.
- A few points where the speed drops to zero, although clearly moving at speed. May be fake points due to the timestamp glitches.

I'll discuss the timestamps and zero speeds with Nathan @ Hoolan. That may not be for a few days though. If you can continue to collect data via Hoolan, I'll send him some relevant examples.

The lat + lon data from the native cycling app has undesirable filtering, and I'm not even sure it's recording the Doppler speed. I don't seen any of the gybe artefacts that were apparent with cycling in the data from Hoolan.

Tweaks to Hoolan are probably going to be the best way forward, imo.

I've create a hacked GPX which overcomes the timestamp issues.

drive.google.com/drive/folders/1tnr45yMgUAKZb4VCyEvl9vgSI3NqZWJ_?usp=sharing

Hacking the timestamps resolved all of the glitches that I mentioned earlier, so it allows for review of the general data quality.

The Ultra 2 may prove to be a decent device with the right app(s). This latest data seems to suggest it has potential, even if only for personal use. The reliance on GPX limits possibilities for competition use, since GPX is so hackable. I'll enquire whether Hoolan has any plans for a FIT export.

Something still needs to be done about the eratic timestamps. Ideally this would be handled in the Hoolan App, but also possible in post-processing. Waterspeed also has some issues to overcome, if they want it to capture speeds properly.

Nice to be gaining some insights into how to get the best out of this watch. I don't have an iPhone and I think my iPad was first used by Fred Flinstone, so I won't be looking to acquire an Apple Watch any time soon!

Perhaps worth showing the impact of the timestamp issue (and fix).

Before fix:



After fix:

Nathan is happy to send me the raw data to investigate, once Jim has given his permission.

Very interesting, what I'd normally put down to "bad watch" is really inappropriate processing, that you smart people can bypass.

Select to expand quote

K888 said..
I'll enquire whether Hoolan has any plans for a FIT export.

If the Holan author has to code stuff, you may want to also mention other possible binary formats, like .gpy or .sbp. I find the FIT format a bit of a pain to deal with, and the FIT libraries don't help much. If he wants to add stuff like heart rate to .gpy files, that would be a good reason to revisit expandability as we had discussed a couple of years ago.

Interesting stuff, otherwise. Thanks for the clarification about the GPS changes.

Nice work K888, since it's looking more like an app issue not a device issue the next obvious question is the lower spec Apple Watch any good. Just so happens upgraded wifey to the latest series 10 when I got my Ultra. Borrowed it off her today and strapped to right wrist with the T1 strapped alongside. Ultra2 on left wrist and usual 2 boom units. Data uploaded to google drive (Feb 4). First look is cannot see any difference between Ultra2 and Series 10 data. Still some time stamp issues on both units. However the glitches occur at exactly the same time but randomly on both watches from first glance if that is any help. Edit: both sessions on watch recored using Hoolan. Nathan and Lucy from Hoolan both responded too and super keen to work any issues out...you should have full access to all my raw data.

Interesting info re the apps. I tried Waterspeed and Hoolan on my Ultra, but went to Waterspeed because I preferred their display. Sounds like I should go back to Hoolan for more accurate results. Have you tried contacting Massimiliano at Waterspeed re fixes? I've found him reasonably responsive to dealing with issues

Progress report:

- The raw session data from Hoolan was enough to confirm the cause of the glitch.
- The underlying data is fine, and it was just a small quirk in the GPX export.
- Nathan has fixed it and I've confirmed that the resultant GPX is fine.
- Jim will be receiving the test build so that he can start making use of it immediately.

Jim's latest session:

- I've manually patched the GPX files and uploaded to Drive.
- The results are really good from both watches.

I'm not going to make a habit of posting single session reviews but as a one-off, I will show this one. In the absence of "the truth", I've simply aligned the runs and averaged the 3 ESPs to give a baseline. One ESP mile has been excluded because there was a submersion that distorted the results.

So, I retain the same thoughts as yesterday. There is plenty of promise in these devices and Hoolan records the data that we desire.

Patched GPX files and Excel at drive.google.com/drive/folders/1tnr45yMgUAKZb4VCyEvl9vgSI3NqZWJ_?usp=drive_link

Select to expand quote

decrepit said..
Very interesting, what I'd normally put down to "bad watch" is really inappropriate processing, that you smart people can bypass.

I guess it just goes to show how "out the box" is almost always unsuitable for our niche sport, even with good watches. Bad watches have the added complication that the processing by Apple / Garmin / COROS / whoever masks underlying issues and once in a while, they drop a real clanger!

Select to expand quote

boardsurfr said..
Thanks for the clarification about the GPS changes.

I've written up my notes as something that is a lot easier to digest. I suspect that over time we'll see data from more Apple watches which will add some clarity and perhaps fill in some of the blanks.

logiqx.github.io/gps-details/devices/apple/gnss/

Select to expand quote

Stretchy said..
Have you tried contacting Massimiliano at Waterspeed re fixes? I've found him reasonably responsive to dealing with issues

A long time ago, I reported the nature of the GPX issues and how to create a single universal GPX.

I followed it up a couple of times, but then lost interest since I don't use the app.

I haven't discussed the speed data because it's only the last couple of days that highlighted an app issue.