Select to expand quote

Cocky2 said..

Please read and understand bioresonant.com/dl/dl.htm?name=SDOP.pdf

Read this 2007 study for GT11/GT31 A few times.

Do you have this study repeated for GW52?

Do you have this study repeated for GW60
especially as it is worn on the wrist?

That study is required for devices that dont produce their own error data - it was documented and implemented for the Garmin Fortrex 201 and for the GT11. It was also done for the GT31 to verify that the device-error-data itself was a match - in fact we found that the study results inoccasionally-worse error bars (but within error-limits).

Thus the idea was to come up with a simple ruling for devices -> if they produce their own error-data, then the community is happy to not have to analyse 10's of millions of points of data per device before they can be used in a real environment [Yesthat many were done for each device becausequite a fewof people donated lots ofdata. ]

For example, if you were to use a GarminForetrex 201 today (and Foretrex 101 since they use the same chip), then youreally shouldsubtract 1.5kn from every 10 secondmax-speed posting.

As for wearing on the wrist... *that is the whole point* of using the device-error data. Since those kinds of variables are very hard to quantify and test in a meaningful way, justhave the device spit out the errors... then those errors will be known and we wont have to guess.

Select to expand quote

TGale said..
^^^^^

Seriously, though, suggestions from yourself and the likes of vosadrian seem insightful from the point of view of capturing the mood of part of the class in regard to an alternative route to Homework 3 suitable for the less-technically obsessed. It seems the committee is reticent to go there again, they appear glad to be free of the non-SDOP days and the tedium of manually checking GPS results. What the committee will no doubt be seriously considering, though, is can we afford not to go there? Should a "non-approved" device category be added to GPS Team Challenge? There is much to be said for the ease of use and robustness of mainstream products and the diversity of devices and sailors that these appeal to. The obvious downside is that it needs to be designed and the programming done. And it will cause a change - at a certain age we get more resistant to change, even change for the better!!

Very insightful, good to read. Maybe..... just maybe...... its time for things to change.

Select to expand quote

mathew said..

Cocky2 said..

Please read and understand bioresonant.com/dl/dl.htm?name=SDOP.pdf

Read this 2007 study for GT11/GT31 A few times.

Do you have this study repeated for GW52?

Do you have this study repeated for GW60
especially as it is worn on the wrist?

That study is required for devices that dont produce their own error data - it was documented and implemented for the Garmin Fortrex 201 and for the GT11. It was also done for the GT31 to verify that the device-error-data itself was a match - in fact we found that the study results inoccasionally-worse error bars (but within error-limits).

Thus the idea was to come up with a simple ruling for devices -> if they produce their own error-data, then the community is happy to not have to analyse 10's of millions of points of data per device before they can be used in a real environment [Yesthat many were done for each device becausequite a fewof people donated lots ofdata. ]

For example, if you were to use a GarminForetrex 201 today (and Foretrex 101 since they use the same chip), then youreally shouldsubtract 1.5kn from every 10 secondmax-speed posting.

As for wearing on the wrist... *that is the whole point* of using the device-error data. Since those kinds of variables are very hard to quantify and test in a meaningful way, justhave the device spit out the errors... then those errors will be known and we wont have to guess.

Not sure what your point is as the Garmin Watch that has been discussed at length in previous forums was the 920Xt forerunner which is Doppler speed and meets requirements for GPSs.

The Foretex is now a 701 and uses,GPS, Glonass and Galiceo.
No one has ever mentioned using these devices.

As no one will publish how GW52 or GW60 was tested we are all to assume ??

Select to expand quote

Cocky2 said.. >>> You can not phase out Canmore until you have a device that lasts longer than 5 hours battery for distance.

Unlike a privilege few with old GT31 that have not had to deal with GW52 and GW60 issues.

That's exactly what I said! Both the gyro and motion will do a day's sailing.

Select to expand quote

Cocky2 said. >>>> As no one will publish how GW52 or GW60 was tested we are all to assume ??

Perhaps you should read Mathew's explanation again, it was quite clear to me. The GT31 was tested to check the validity of the SDoP data. Having satisfied them selves that it was indeed reliable, all future devices with SDoP, no longer needed extensive testing!
Who is going to undertake this onerous task fora device without SDoP???????
Not me I assure you.

But the GWs were tested, I gave Andrew a hand with both the GW52 and GW60, we paid special attention to the GW60 as we were very suspicious of the underhand thing, and how arm movements in the gybe could affect alpha results. I for one was surprised that both effects were less than we feared.

I think most would agree the GW60 data logging was tested at length and results discussed openly on here in the early GW60 thread last year in great detail. Sure there were problems with them in the early days and watchstraps that broke, Im onto my second one and its functioning perfectly. I bought a BGT31 recently as well for the longer lasting battery. It was cheaper than a new fin. Im also a fan of my suunto watch and can see why people want to use the garmin, but its been explained pretty well why its not going to be approved, and there are some other options to explore first.

Thanks to Decrepit for all your efforts on the GPSTC devices, like someone else said earlier your patience on these threads is amazing, and you've done a huge amount for the GPSTC. The debates on alternative devices need to be had but we also need to be respectful of all the voluntary work that has been done to date.

Select to expand quote

Dezza said..>>> Thanks to Decrepit for all your efforts on the GPSTC devices, like someone else said earlier your patience on these threads is amazing, and you've done a huge amount for the GPSTC. The debates on alternative devices need to be had but we also need to be respectful of all the voluntary work that has been done to date.

Thanks Dezza, but I'm not the only one, I'm just crazier than most, going public.

Select to expand quote

decrepit said..
Cocky. if you look at the speeds, they drop to 0 directly after the 33kts, looks like a big crash to me. And the GPS probably had a big dunking at the same time.

Yes I agree the file is a mess, probably because of a very bad sky view.

This is my last attempt at this one.
For each of the GPS Lat long you get the following Altitude stats.
Min altitude. 164 m below sea level.

21.6% between -164m to -5.
16.5% between -5 to + 5.
61.9% between 5 and 122.4m

Max altitude. 122.4 above sea level.

Checked one of my good Canmore files from same location and all within + or - 10m.

Screen shot of data for 2 sec peak in question .




Screen shoot of track pinning the GPS coordinates in Google earth from file.

There is no logic to the a possible sailing path shown from Lat long coordinates.

Select to expand quote

Cocky2 said.. >>>>Screen shot of data for 2 sec peak in question .

Doesn't look anything like the 2s I looked at, go have a look at the screen shot I posted, back on page one at the bottom.
The 33kt 2s peak was at 1658:53

Select to expand quote

John340 said..
At what point does this thread come under the category of "Flogging a dead horse". I suspect we reached that point early in page 1.

If you actually read the statement below no one has ever said that the link should be removed as we do not use GPSs rules.
Personally it is not good to Bold something, however for you I have.


This link is in the GPSTC current rule page and is in Bold and does not state ignore the bold link below.
They actually have an approval process documented for new devices.
There are many GPS products in the market that are superior to the current approved list.
They may not supply the end user with SDOP and error data but are no way low grade GPS.

If the link is not relevant then remove it from the rules

If you click on "info on other devices" in Rules page of GPSTC it takes you to

www.gps-speedsurfing.com/default.aspx?mnu=item&item=gpsother

They have a Certification process for new devices as well as different requirements for devices for average surf session.

Select to expand quote

decrepit said..

Cocky2 said.. >>>>Screen shot of data for 2 sec peak in question .

Doesn't look anything like the 2s I looked at, go have a look at the screen shot I posted, back on page one at the bottom.
The 33kt 2s peak was at 1658:53

Thought you would have had a little more detailed look at data before making the comment you have.

If you take the track KM speed you will note it is exacting the same speeds in knots as the time in question.

The screen shot of the file in question is from Excel is saved from GPS results as a CSV file.
The file has then been opened with Excel for stats and that is the format you see in the screen shoot.

Maybe you could explain to me why the time only shows up as it does , not GMT or AEST?

The precision of the lat/long numbers in the screen shot you show (4 digits after the period) is about 10 m. This is may be an artifact of going through .csv files. Not having enough precision adds rounding artifacts which make plotting the data with Google Earth meaningless.

You may want to instead convert the .fit file directly to a .gpx file (using GPSBabel) and import that in Google Earth. This will work better since .gpx files use 9 digits after the period. You could manually edit the .gpx file to remove most points except for the area in question.

Even simpler, use GPS Action Replay Pro and compare the speed graph and the doppler speed graph. Again, feed it a .gpx file generated with GPSBabel.

Theoretically, "jumpy" lat/long coordinates could be an indication of artifacts. But there is no indication of that in the numbers in your screen shot. Lat and long numbers up to the crash always change by 0.0001 or 0.0002 (or 0). Considering rounding error due to insufficient number of digits, this is pretty smooth.

After the crash, the lat/long numbers will often jump around because the GPS has lost reception. Even that does not seem to be much of an issue here, though, if you take into account the differences in elapsed time (for example 3 seconds between the first and second zero).

Select to expand quote

boardsurfr said..
The precision of the lat/long numbers in the screen shot you show (4 digits after the period) is about 10 m. This is may be an artifact of going through .csv files. Not having enough precision adds rounding artifacts which make plotting the data with Google Earth meaningless.

You may want to instead convert the .fit file directly to a .gpx file (using GPSBabel) and import that in Google Earth. This will work better since .gpx files use 9 digits after the period. You could manually edit the .gpx file to remove most points except for the area in question.

Even simpler, use GPS Action Replay Pro and compare the speed graph and the doppler speed graph. Again, feed it a .gpx file generated with GPSBabel.

Theoretically, "jumpy" lat/long coordinates could be an indication of artifacts. But there is no indication of that in the numbers in your screen shot. Lat and long numbers up to the crash always change by 0.0001 or 0.0002 (or 0). Considering rounding error due to insufficient number of digits, this is pretty smooth.

After the crash, the lat/long numbers will often jump around because the GPS has lost reception. Even that does not seem to be much of an issue here, though, if you take into account the differences in elapsed time (for example 3 seconds between the first and second zero).

Thanks for giving some good information to help those interested in learning how to analyse data.

Please explain why the entire file is full of bad Altitude's.
My FIT file from the same day, same time, same location has none.

Please explain how you worked out there was a crash.

Dont know how you can say there was a crash from 33 to zero then the speed is 26 knots again in 6 sec.
Must be a record water start and acceleration in the 6 second period.

Again thanks for helping others understand.

Select to expand quote

Seriously, though, suggestions from yourself and the likes of vosadrian seem insightful from the point of view of capturing the mood of part of the class in regard to an alternative route to Homework 3 suitable for the less-technically obsessed. It seems the committee is reticent to go there again, they appear glad to be free of the non-SDOP days and the tedium of manually checking GPS results. What the committee will no doubt be seriously considering, though, is can we afford not to go there? Should a "non-approved" device category be added to GPS Team Challenge? There is much to be said for the ease of use and robustness of mainstream products and the diversity of devices and sailors that these appeal to. The obvious downside is that it needs to be designed and the programming done. And it will cause a change - at a certain age we get more resistant to change, even change for the better!!

Now this is what I am talking about..... I have never suggested that non-SDOP devices be approved for records etc. I have suggested that non-SDOP devices be allowed to be included for inclusiveness which is the GPSTC philosophy. Clearly preventing anyone from being involved unless they buy the one approved device when that device is of questionable quality and minimal support is NOT inclusive.

Since there is already a category for legacy devices to be included in the GPSTC even without SDOP, we are already doing it. It is literally zero effort to allow newer devices to be involved in the GPSTC in the same way legacy devices are currently. It would be even better if we could do a little work to formally allow all sessions to be identified as approved device or not, and then for that to be handled accordingly.

As mentioned previously, Strava have a great way of handling this. Activities can be flagged. This is done for a number of reasons, but typical reasons are GPS errors and the activity was clearly done in a vehicle that is not a bike. The flagged user can then choose to appeal if they think the flag is unjustified in which case, someone would look at the files, but most of the time flagging is only done if it is a genuine error that the user allowed to be posted.

maybe if you dont like rules ,start your own team challenge, then i can whinge about it when i retire and make lots of tech questions to alienate my self from people who cant be bothered reading forums because of this crap.
please go fishing Ian.
Same questions same Answers Same people,, bla bla bla

Do you guys get to actually enjoy sailing?

So can I use my Garmin watch ?

Select to expand quote

AUS729 said..
So can I use my Garmin watch ?

Check with Cocky2

Hey Guys, I was just informed of the continuing discussion around my dodgy first ever GPS track with the Canmore. It was given to me for free so I could get started. Immediately after I was told it produced a dodgy track, I splurged on a locosys GW 60 (I think thats what it is). I've since only just been able to just kiss 30kn so the 33kn seems inaccurate. At the time I posted the track I had no idea what sort of speed I was capable of. Not ever using a GPS before, I had no way of judging a dodgy result. So I'm going to delete the track as I'd like an accurate representation of my progress.

Cheers

Callan

Select to expand quote

Callan85 said..
Hey Guys, I was just informed of the continuing discussion around my dodgy first ever GPS track with the Canmore. It was given to me for free so I could get started. Immediately after I was told it produced a dodgy track, I splurged on a locosys GW 60 (I think thats what it is). I've since only just been able to just kiss 30kn so the 33kn seems inaccurate. At the time I posted the track I had no idea what sort of speed I was capable of. Not ever using a GPS before, I had no way of judging a dodgy result. So I'm going to delete the track as I'd like an accurate representation of my progress.

Cheers

Callan

Welcome to the madness . Don't stress too much about numbers n stuff just enjoy the rush. One of the great things of this sport is being able to look back at the sessions ,remember the day and get amped for the next one. .

Always good early on to get someone with some gps experience to gide you through some of the tricks of spotting something NQR. Enjoy

Hi Callan, sorry mate unless Nebs can do it for you, that result is locked in concrete.
So just to help resolve the issue, did you have a big off, you'd know about a sudden stop at 33kts. If you didn't then the result is definitely wrong.

Select to expand quote

Cocky2 said..
Please explain why the entire file is full of bad Altitude's.
My FIT file from the same day, same time, same location has none.

Well, that's asked a bit much, since the only data I have are the screen shots Mike and you posted, but I'll try my best.
The GPS obviously had poor reception. As I stated before, the most likely causes are the armband slipping, and/or the unit going bad. If the armband slipped so that the GPS was on the under side of the arm, the GPS would only have reception from a few satellites near the horizon, while the ones directly above would be blocked (or noisy from multi-path signals). Without sats above, altitude triangulation (which is always less accurate than horizontal positioning) is prone to very large errors. This will be most pronounced whenever the number of satellites changes.

Select to expand quote

Cocky2 said..
Please explain how you worked out there was a crash.

Dont know how you can say there was a crash from 33 to zero then the speed is 26 knots again in 6 sec.
Must be a record water start and acceleration in the 6 second period.

When the speed suddenly drops to zero in speedsurfing, it's usually a crash. Seeing higher speeds again right afterwards is by no means unusual, and also happens quite often with Locosys units. Sometimes it's just a single point, sometimes it's a stretch up to 10 seconds long. Here's an example from my last windsurfing session (using a GW-52):


That's a single-point example. For examples from a GW-60 that spans 2 seconds or longer, check boardsurfr.blogspot.com/2017/05/overstating-speed-by-4-knots.html and boardsurfr.blogspot.com/2017/05/60-knots-new-speedrecord.html
--
I was not there, nor do I have the file in question, so I cannot possibly know what was going on. However, I can say that I have seen similar artifacts that clearly were linked to crashes, both in my own files and in files that I downloaded from ka72.com to specifically search for problems. I have looked at more than 1000 of my own files over the years (usually in GPSAR Pro, but sometimes also with GPSResults and custom software that specifically searches for problems), and several hundred files downloaded from ka72.com. These artifacts that I have seen occurred with various GPS devices that were functioning properly otherwise. But that does not mean the Canmore was not defective - that conclusion would require more data were some variables (like slipping armbands) are excluded.

Select to expand quote

boardsurfr said..

Cocky2 said..
Please explain why the entire file is full of bad Altitude's.
My FIT file from the same day, same time, same location has none.

Well, that's asked a bit much, since the only data I have are the screen shots Mike and you posted, but I'll try my best.
The GPS obviously had poor reception. As I stated before, the most likely causes are the armband slipping, and/or the unit going bad. If the armband slipped so that the GPS was on the under side of the arm, the GPS would only have reception from a few satellites near the horizon, while the ones directly above would be blocked (or noisy from multi-path signals). Without sats above, altitude triangulation (which is always less accurate than horizontal positioning) is prone to very large errors. This will be most pronounced whenever the number of satellites changes.

Cocky2 said..
Please explain how you worked out there was a crash.

Dont know how you can say there was a crash from 33 to zero then the speed is 26 knots again in 6 sec.
Must be a record water start and acceleration in the 6 second period.

When the speed suddenly drops to zero in speedsurfing, it's usually a crash. Seeing higher speeds again right afterwards is by no means unusual, and also happens quite often with Locosys units. Sometimes it's just a single point, sometimes it's a stretch up to 10 seconds long. Here's an example from my last windsurfing session (using a GW-52):


That's a single-point example. For examples from a GW-60 that spans 2 seconds or longer, check boardsurfr.blogspot.com/2017/05/overstating-speed-by-4-knots.html and boardsurfr.blogspot.com/2017/05/60-knots-new-speedrecord.html
--
I was not there, nor do I have the file in question, so I cannot possibly know what was going on. However, I can say that I have seen similar artifacts that clearly were linked to crashes, both in my own files and in files that I downloaded from ka72.com to specifically search for problems. I have looked at more than 1000 of my own files over the years (usually in GPSAR Pro, but sometimes also with GPSResults and custom software that specifically searches for problems), and several hundred files downloaded from ka72.com. These artifacts that I have seen occurred with various GPS devices that were functioning properly otherwise. But that does not mean the Canmore was not defective - that conclusion would require more data were some variables (like slipping armbands) are excluded.

Thanks again.

You will find a link to this file in an earlier post I made in the Topic.

www.ka72.com/Track/t/328687

Another thing with this track is it never showed the normal data for 2 , 5x10, of Alpha on Goggle Maps which has never happened to the over 1000 of tracks I of have viewed from KA.

Select to expand quote

decrepit said..
Hi Callan, sorry mate unless Nebs can do it for you, that result is locked in concrete.
So just to help resolve the issue, did you have a big off, you'd know about a sudden stop at 33kts. If you didn't then the result is definitely wrong.

Reply from GPS TC on a previous track that I found locally from another Team on a public file on KA past the end of the month cut off.
Results posted in GPSTC did not match KA data for file posted. This is part of the response I received as the public track confirmed incorrect data posted.
So yes data can be changed.

"Ben is of the opinion it's best to have the data base accurate, so he's adjusted that post to the GPSResults figures"

Select to expand quote

kato said..

AUS729 said..
So can I use my Garmin watch ?

Check with Cocky2

He said NO, NO, NO, NO, NO !

Select to expand quote

Cocky2 said. So yes data can be changed.

"Ben is of the opinion it's best to have the data base accurate, so he's adjusted that post to the GPSResults figures"

Yes data can be changed, but admin can't do it.
Ben is a very busy man I hate to pass stuff onto him unless it's really necessary.
But if Callan confirms he didn't crash that's what I'll do.

OK, John Scott has convinced me there was no crash, and the run in question was almost square. So I have to admit to making a mistake with this result. So I've forwarded the file on to Ben, along with John's email to me.

Select to expand quote

decrepit said..
OK, John Scott has convinced me there was no crash, and the run in question was almost square. So I have to admit to making a mistake with this result. So I've forwarded the file on to Ben, along with John's email to me.

Good news for Callan , now he will get a new PB no worries.

Ben's just removed Callan's whole post for the 21/2/18

Select to expand quote

Cocky2 said..
You will find a link to this file in an earlier post I made in the Topic.

Sorry I had missed that, thanks for posting it again. Here's a few things I noticed looking at the track. First, a comparison of the doppler and positional speeds for the entire track:

The "33 knot" region is where the green line is. What jumps out is that there are many spots where the positional speed is much higher than the doppler speed, up to 100 knots. That's unusual - for comparison, here is a recent Canmore track where there are only small differences:




It is quite common to see spikes in the speed graph during crash/swim episodes. Here is an example from another recent Canmore file (I used the Canmores as loaners for GPS competition at our East Coast Windsurfing Festival last week):




As theGPSlooses and gains reception, the position jumps a lot, and this sometimes "goes through" to doppler speeds. Similar artifacts while swimming/crashing can be seen with Locosys andu-bloxGPS units.

During the first hour of Callan's session, there are just two speed spikes, and they both seem linked to crashes (the first one is a "maybe"). Here is the second crash:

This is a clearcut case of a crash in a jibe, and did not affect doppler speed.

Now to the "33 knot" region:





This does not seem linked to a crash (Mike was correct in this assessment). But the speeds are quite spiky before the "33 knots", with large differences between positional speed and doppler speed. This indicates that the GPS did not get a good reception. The run was after a longer break or swim. There is a 60 knot spike in the speed graph about 80 seconds earlier, probably because the upper arm was completely in the water. It's likely that the armband moved during this break/swim so the GPS was below the arm, and/or that water got into the GPS.

Overall, though, the picture is quite simple. The amount of missing data points in the file (about 30%) is way too large. There are 332 missing single points with doppler speeds above 10 knots, that's roughly one every 30 seconds (I got the numbers by copying the track points table data from GPSAR, pasting them into a spreadsheet, and sorting by time difference and speed). So the decision to remove the post completely was definitely appropriate.