decrepit said..

Dylan72 said..
>>>

2) Is there serious interest in me modifying ka72 to give a 1hr result even if you haven't sailed an hour? I can do it, just wonder what the demand is?

Cheers,

Dylan.

It does seem like a good idea.
Not calculating an hour because there isn't an hour's worth of data, is a bit strange.
I guess the idea could be, that you need to sail an hour to get a result, but all you have to do is leave the gps on for an hour, and you'll get the result.
So the only person penalised is the one who turned their unit off too early.

Exactly my thoughts!

elmo said..
the hour is not really a problem

if you sail for less than an hour then your total distance (not average speed) is the hour

Your not just a red furry face are you?

raymondw said..

I'm in contact with GP3S/Dylan

That would be Dutch Dylan, right, not me? I have a few emails, but really only concerned with ka72.com.

elmo said..

if you sail for less than an hour then your total distance (not average speed) is the hour

That's an elegant workaround. You could use a similar (with multipliers) rule of thumb for any division that is time-based. (e.g. the 2hour we have in WindWanderers, or the 30min "C Group" proposed for FreeRace.) You get a thumbs-up from me for that one!

I just received an email from Manfred at GPS-Results - "..the latest Mac-version V5.38 is now downloadable from www.gps-speed.com and it can read FIT-files. However, since there is only Dopplerspeed and no direction saved in this file-format, the Dopplertracks will be vertical lines. The normal, color coded tracks are shown from the positional data..."

The GTs register a low speed when stationary, so it's not surprising that movement is also registered.

KevinD002 said..
Is anyone having issues getting the device to turn on?

Also when it's on, it keeps registering movement. Up to a few 100 meters when I'm standing still. It's in jogging mode.
Factory reset seems to fix it but annoying to do everytime

Mine takes a press and hold for a second of the power button and then a few seconds of disconcertingly blank screen and then all ok. I haven't noticed any issues with the movement but I haven't been looking either- perhaps the filters on GPSResults are taking these out??

boardsurfr said..

sailquik said..

I was under the impression that the Canmore 102+ stopped logging when stationary?

You can set the "Log Rule" to "by distance", then it will stop logging. If you have it set to "by time", it logs even when stationary. I see a lot of 0 and 1 cm values when stationary, with occasional larger values. But there is also an "auto pause" setting that can pause logging when speed is below a customizable threshold. The auto pause default seems to be "off", though.

The GP102 does seem to stop logging when it has not satellite reception, e.g. when in the water after crashes.

Do the satellites stop rotating the earth? In other words, even when the receiver is standing still, the satellite is still travelling about 14,000kph, which is ~ 400 m/s (worst case).

Note that a "gps lock" isn't what most people think it might mean -> if you have 12 satellites in view, they first need to be receiver (aka PLL) locked. The "gps lock" in this case is when there are at least, say 5 satellites, with low chance of losing the PLL-lock and when that channel has recently received the time-code.

You should never stop logging... even without "gps lock".


Importantly, if we ever get around to post-processing the GPS data (like the do for Trimble), then the data collected while stationary can be used to determine localised atmospheric effects.

Dylan72 said..
Initial support for Canmore .FIT files has been added to www.ka72.com.

Other .FIT files that output "Record" messages with GPS coordinates should also work, but I'd be interested in any feedback from Garmin owners who experience difficulty with processing their files.

To say the API for .FIT is labrynthine is an understatement. I've never seen a file format try so hard to cater for every possible combination and permutation of sensor! So, although the new code should work fine with Canmore's GPS, it is not likely to work with others without some changes.

Cheers,

Dylan.

Thanks Dylan, great to see you keeping up the good work!

KevinD002 said..
So a friend of mine sent his .FIT converted to GPX track and I tried loading it up into GPS Results. Weird thing is when I click anything other than 2sec, it just highlights a straight line on the map. Gates don't seem to work with the file either. Conversion issue?

I use a Mac and when the Mac version was released Manfred added a couple of notes, one of which was "....However, since there is only Dopplerspeed and no direction saved in this file-format, the Dopplertracks will be vertical lines. The normal, color coded tracks are shown from the positional data..."
I dont know about the gates issue sorry, but I have always found Manfred very helpful when I have had questions so perhaps email him directly.

sailquik said..

sailquik said..

dBA said..
bioresonant.com/dl/dl.htm?name=SDOP.pdf

Basically a similar accuracy value as the HDOP, but then specifically for the Doppler based speed calculations. After scanning the PDF quickly I noticed that Tom says it's a new feature in the SiRFStar 3 chips, but I couldn't find it either in the binary protocol for the latest chip sets. It used to be a parameter in the MSG41 something which our SBN files consist of. Hope this helps...

If memory serves correct, I think the SDOP data was something that Tom directly persuaded the Sirf technicians to implement in the Sirf3 chip, and furthermore persuaded Locosys to give access to in their GT-31 output.

I surmise that Locosys managed to get an equivalent output of SDOP type data from the sirf4 chip they used in the 5hz evaluation prototype they called the GT-52 (wristwatch form) if that is the GPS chip they used. (not confirmed). A conversation I had with Tom recently led me to believe that the 'SDOP' output in that prototype was not in exactly the same format as from the Sirf3.

The Sirf company technicians may be able to help clear this up if it is possible to contact them.

Phew! I have been wading through the SIRF Binary Protocol and the updated SIRF Binary OSP Protocol and it is tough going for an old bloke!

Message 41 has a part called 'estimated horizontal velocity error': EHVE in m/s x 102(SiRFDRive only)

It is apparently only normally available in the SIRFDRive firmware version if Surf GPS modules.

It seems to fit what I have been told that Tom/Locosys may have persuaded SIRF to make a firmware change in the SIRF111 Chip they used so as to capture this message.

There is also this message: Navigation Subsystem - Message ID 48, Sub ID 3

It also appears to contain the same speed error calculation, but it us not clear to me if this message is also specific to the SIRFDRive firmware.

If you have more insight I'd love to hear it.

Update. I think I have finally got to the bottom of SDOP in the SIFR111 GT-31.

Tom managed to convince Locosys and SIRF to use to use the SDK (SIRF Development Kit) to extract the speed error data from the chip and process it in the Locosys firmware to produce SDOP.

This SDK allows GPS manufacturers to program a specific message of their own.

So it seems they didn't use the MID 41 as it is a blank field in the SIRF111 chip they used. I assume the SIRFIV chip has the same issue and it would take a bit of effort and cooperation between Sirf and the GPS manufacturer to implement SDOP.

It remains to be seen if we can get Canmore to implement this. I have asked them. Waiting for a reply.

That leaves us with the UBlox chips which, as I understand it, do output the speed error calculations in their standard binary .UBX file format.

dBA said..
That makes a lot of sense, since I haven't been able to find *any* mention of SDOP in all of the SiRF binary protocols I've been plowing through.

As for the U-blox chips: message 0x01 0x12 (NAV-VELNED) contains a parameter called 'sAcc' or Speed Accuracy Estimate, which is the U-Blox equivalent of the SDOP value for SiRF.

Yes. UBX sAcc is the equivalent of SIRF EHSE (Estimated horizontal speed error) which is available in some SIRF firmware versions of SIRF binary Protocol, but apparently not the versions they supply to the consumer GPS manufacturers. It's a great failure of SIRF that they don't make that message data easily available in every version for out point of view. It's still a mystery to me why SIRF just didn't supply Locosys with the appropriate firmware the fill message ID 41. SDOP is not a abbreviation used by SIRF, so you will not find it in their Manuals, but as far as I can tell, EHSE (Estimated horizontal speed error) is the same thing.

geoITA said..
Brief report about my experience with the Canmore GP-102+.
Among other pros: first fix is very quick.
Among other cons: definitely is NOT IPX6 water resistant, it took just a few drops of water (almost humidity rather than water) inside a slightly leaky bag and my first unit is gone.

Remember that if you submerge that flexible bag, the pressure is transferred to the GPS through the bag. It's not the amount of water around the device that is the problem, it's the pressure it is under that forces water into the joins in the case.

geoITA said..WHEN will anybody produce a truly water resistant device? Is it realy that difficult?

Probably when a manufacturer sees a market advantage. And, yes. It is difficult in the sense that it is very costly for the tooling and design.

geoITA said..
Brief report about my experience with the Canmore GP-102+.
Among other pros: first fix is very quick.
Among other cons: definitely is NOT IPX6 water resistant, it took just a few drops of water (almost humidity rather than water) inside a slightly leaky bag and my first unit is gone.

WHEN will anybody produce a truly water resistant device? Is it really that difficult?

I believe the only way is to make it like the Garmin 201.
They had no openings at all just gold plated terminals to connect for charging & downloading in a clip in cradle.
I guess the downside might be memory capacity as there would be no card.

kato said..

Paul Kelf said..

geoITA said..


WHEN will anybody produce a truly water resistant device? Is it really that difficult?

I believe the only way is to make it like the Garmin 201.
They had no openings at all just gold plated terminals to connect for charging & downloading in a clip in cradle.
I guess the downside might be memory capacity as there would be no card.

Please DON,T. The 201 wasn't even close to waterproof. Killed 5 until I made a proper case for it and the downloading was very random. Love having a card that works every time. We'll get the right device.

+1 above. I killed at least 3 until I finally decided I needed to put them in plastic bags!

They have the same waterproof rating as the GT-11/31's

I actually think it is quite a low priority to make the GPS's completely waterproof. It is very costly and it's just better to put them in a good bag like the Paqua. Then there are no problems at all and you have a convenient way of wearing them.

kato said..

Paul Kelf said..

geoITA said..
Brief report about my experience with the Canmore GP-102+.
Among other pros: first fix is very quick.
Among other cons: definitely is NOT IPX6 water resistant, it took just a few drops of water (almost humidity rather than water) inside a slightly leaky bag and my first unit is gone.

WHEN will anybody produce a truly water resistant device? Is it really that difficult?

I believe the only way is to make it like the Garmin 201.
They had no openings at all just gold plated terminals to connect for charging & downloading in a clip in cradle.
I guess the downside might be memory capacity as there would be no card.

Please DON,T. The 201 wasn't even close to waterproof. Killed 5 until I made a proper case for it and the downloading was very random. Love having a card that works every time. We'll get the right device.

I had 2 Garmins with no problems for years, but having said that I haven't had any problems with the GT31s either except for rusting screws so maybe I just don't drown them as much as other people