As I had briefly mentioned before, one potential problem with looking at speed over ground (SOG) with stationary data is that SOP is non-directional. So in theory, we could have random fluctuations in the directional speed, for example going back and forth between N and S, or varying between N, E, S, and W. In such a situation, the "net speed" when moving would be zero (or close to zero), but the measured speed over ground would always be positive. However, a look at the directional speeds (velN and velE) shows that this is not the case:

The speed (SOG) in this example section is dominated by velN, with is negative for all points. velE is usually smaller than velN, but almost always positive. That means the GPS calculated that is was moving S to SE the entire time.

Bottom line is that the observed accuracy limit is about 0.05 knots. Increasing the data rate beyond 5 Hz does not improve on that, since the error is not randomly distributed at the < 200 ms time scale.

All these have a root cause of "noise".

Let's restart three experiments earlier, when I said stationary was harder for a receiver than an human.
What do you think of this chart? It's speed accuracy versus speed, in knots. From a random windsurf log I had. 10Hz.

OK my next question, if the sat limitation starts at 10hz, what is 8hz like?
Yes I know, --- I have an 8hz fixation.

Select to expand quote

JulienLe said..
What do you think of this chart? It's speed accuracy versus speed, in knots. From a random windsurf log I had. 10Hz.

It's complete nonsense to comment on a chart without any description on how the data was captured and generated. The only thing that's certain is that in the context of a windsurf session, a speed near zero is often associated with crashes and loss of reception. When adding satellites back after re-surfacing, you've got two major sources of noise: low satellite counts, and changes in satellite counts. So the graph is in no way surprising .. or useful.

Select to expand quote

boardsurfr said..
It's complete nonsense to comment on a chart without any description on how the data was captured and generated. The only thing that's certain is that in the context of a windsurf session, a speed near zero is often associated with crashes and loss of reception. When adding satellites back after re-surfacing, you've got two major sources of noise: low satellite counts, and changes in satellite counts. So the graph is in no way surprising .. or useful.

Well, I tried. You've been wrong on everything so far and this is a word of caution to all future readers. GNSS is very important to many and as such, much research has been done and openly published about it. These "issues" you present all have basic explanations and solutions.

That graph is very interesting and useful. For one thing it supports the theory that vertical and sideways error influence is markedly reduced at higher speeds, as Boardsurfr pointed out in an earlier post. It also supports Tom Chalkos's often repeated statement that Doppler speed accuracy it better at typical windsurfer speeds than at very low speeds or geostationary.

So far we have just seen some results that suggest ONE particular 25Hz device MAY not be anymore accurate for Doppler speed @25Hz than if running it at lower Hz. Lets try not to get carried away trying to formulate a 'Grand Theory of Everything Doppler Accuracy' on such a limited sample.

Julien, can you generate the same type of graph from one of my sessions where I have no crashes and no submergences? It would be interesting to see if it is any different. I have emailed you a session from LG consisting of side by side 10Hz Motion data from my helmet.

Select to expand quote

JulienLe said..
Well, I tried. You've been wrong on everything so far

Now that's a grand statement, and unnecessarily aggressive. I have mostly posted actual data from experiments that I described in sufficient detail so that anyone willing to spend about $150 can repeat them. You have not posted a single bit of data that show disagreement with anything I've posted. You just issued categorical statements trying to discredit any stationary experiments - which is pretty amusing, considering hat much of the emphasis on requiring error estimates goes back to Tom Chalko's work .. which was heavily relied on stationary tests.

Select to expand quote

JulienLe said..
GNSS is very important to many and as such, much research has been done and openly published about it.

Yes, there are tons of scientific publications that analyze noise in GPS data. Many of them try to analyze and quantify noise, and specifically non-random noise. I could cite some results and guidelines, like "With the assumption of white noise, the time correlation in GPS datastreams leads to biased and inconsistent parameter estimates [16], especially for sampling rates above 5 Hz." (from www.ncbi.nlm.nih.gov/pmc/articles/PMC7660693/#B22-sensors-20-06050). There is plenty of research that illustrates the importance of non-random noise in GPS data. But papers that look at Doppler speed accuracy in GPS data at high data rates seem to be quite rare. If you have references or data you want to share, go ahead!

Select to expand quote

sailquik said..
So far we have just seen some results that suggest ONE particular 25Hz device MAY not be anymore accurate for Doppler speed @25Hz than if running it at lower Hz.

I agree that data from one device certainly should be verified independently, and have said so before. That's how science works, and I have a bit of background there.

But the "ONE particular 25Hz device" is a genuine u-blox 9 chip, and from the currently available GPS chips, only u-blox chips and their imitations offer the speed accuracy data that the GPSTC requires. So it's not like we can just go and use any other GPS chip out there. For the 9th generation u-blox chips, there don't even seem to be cheaper Chinese imitations around, so if you want 4 GNSS systems and/or rates above 10 Hz, you'll have to use a very similar chip. The particular chip I am using is working quite well, compared to the about 10 other chips and approved units that I have looked at recently. Some "peculiarities" like reducing the number of satellites at higher rates appear to be a characteristic of the u-blox firmware that, in all likelihood, will also be present in other comparable 9th gen u-blox chips.

I'm presenting the data I get, along with explanations about the setup (with more details on my blog then here, but I post the links here), and possible explanations of what could cause the observations. Anyone can disagree with my explanations and come up with their own, but data are data - you can't disagree with them, you can only show other data that differ (if you have them). Showing a random graph with high error estimates at low speed windsurfing does not qualify - anyone who every crashed with a GPS and looked at the SDoP values know that happens.

If Julien actually would manage to deliver on orders on time, this entire thread would not have happened. But my two Motions both have screen issues as well as corroded connectors after a pretty limited number of uses, and there were way to many posts here from people asking about units they ordered many months ago to consider buying another Motion. My current interest was actually based on hearing from others who were looking into alternatives for whatever their reasons were, and then seeing that a solderless plug-and play solution may be possible (which seems to be the case).

Now, if anyone else has data that show that u-blox devices produce more accurate data and valid error scores at high rates, please share! But excuse me for not just taking their word for it. If a GPS calculates one navigation solution based on a single measurement, there is absolutely no logical reason why the single-point error value should go down at higher data rates. It's the same signal and the same math, it should come to the same solution.

The quest for a Plug and Play GPS is a great and noble quest. If you can achieve it and help others to do the same, then that is a great achievement, and one we all will have great respect and thanks for indeed.

I am sceptical, but I don't reject, the conclusions you are putting forward from the results of your experiments into higher Hz rate Doppler speed measurement and error, and the assumptions you are drawing from very little and limited data. I'm not entirely sure about your reasoning and methodology. You may well be on the right track, but you may not be at all. I think it's great that you are exploring this stuff, but let's try not to jump to the 'Grand Theory of Everything Doppler Accuracy' too quickly.

Papers on Doppler speed measurement and Doppler speed error are, unfortunately, quite rare, very true. And studies of GPS 'Noise' related to POSITIONAL accuracy, may not be very relevant to Doppler speed error. The very reason we use Doppler speed measurement is because there are far fewer sources of error in it than in positional measurement. I note that paper quoted above was from 2014, and as such was almost certainly done with GPS system only.

Non aggressive discussion is very good. Let's agree to disagree with grace if the discussion continues.

Select to expand quote

sailquik said..>>>>
I am sceptical, but I don't reject, the conclusions you are putting forward from the results of your experiments into higher Hz rate Doppler speed measurement and error, and the assumptions you are drawing from very little and limited data. I'm not entirely sure about your reasoning and methodology. You may well be on the right track, but you may not be at all. I think it's great that you are exploring this stuff, but let's try not to jump to the 'Grand Theory of Everything Doppler Accuracy' too quickly.>>

Andrew, I think Peter explained he was not "Jumping to the grand theory of everything"
But it makes sense to me, that if the M9 chips limit sats to those overhead above 10hz, then lower frequencies that have sats closer to the horizon will have better doppler accuracy but worse positional accuracy. As his data suggest.

And Julien seems to be sending mixed messages, in one post he says there's a lot of exaggerated claims and hype and in another he's inferring, we are wasting our time trying to sort hype from fact.

Select to expand quote

boardsurfr said..

sailquik said..
So far we have just seen some results that suggest ONE particular 25Hz device MAY not be anymore accurate for Doppler speed @25Hz than if running it at lower Hz.

I agree that data from one device certainly should be verified independently, and have said so before. That's how science works, and I have a bit of background there.

But the "ONE particular 25Hz device" is a genuine u-blox 9 chip, and from the currently available GPS chips, only u-blox chips and their imitations offer the speed accuracy data that the GPSTC requires. So it's not like we can just go and use any other GPS chip out there. For the 9th generation u-blox chips, there don't even seem to be cheaper Chinese imitations around, so if you want 4 GNSS systems and/or rates above 10 Hz, you'll have to use a very similar chip. The particular chip I am using is working quite well, compared to the about 10 other chips and approved units that I have looked at recently. Some "peculiarities" like reducing the number of satellites at higher rates appear to be a characteristic of the u-blox firmware that, in all likelihood, will also be present in other comparable 9th gen u-blox chips.

I'm presenting the data I get, along with explanations about the setup (with more details on my blog then here, but I post the links here), and possible explanations of what could cause the observations. Anyone can disagree with my explanations and come up with their own, but data are data - you can't disagree with them, you can only show other data that differ (if you have them). Showing a random graph with high error estimates at low speed windsurfing does not qualify - anyone who every crashed with a GPS and looked at the SDoP values know that happens.

If Julien actually would manage to deliver on orders on time, this entire thread would not have happened. But my two Motions both have screen issues as well as corroded connectors after a pretty limited number of uses, and there were way to many posts here from people asking about units they ordered many months ago to consider buying another Motion. My current interest was actually based on hearing from others who were looking into alternatives for whatever their reasons were, and then seeing that a solderless plug-and play solution may be possible (which seems to be the case).

Now, if anyone else has data that show that u-blox devices produce more accurate data and valid error scores at high rates, please share! But excuse me for not just taking their word for it. If a GPS calculates one navigation solution based on a single measurement, there is absolutely no logical reason why the single-point error value should go down at higher data rates. It's the same signal and the same math, it should come to the same solution.

Plug and play devices dont seem to be the way to go. The higher the Hz rate the cleaner and more professional the device needs to be.The device should be super clean all wires sheilded and connections less than 3mm to avoid interference of signals.
Some of us would like to build our own gps and need all the help we can get.

Electromagnetic interference and General notes on interference issues.
Good info here On Ublox website DOC NEO-M9N-intergrationmanual-(UBX-19014286).pdf download
Section 4.6 to 4.8
(Electrical overstress (EOS) usually describes situations when the maximum input power exceeds the maximum specified ratings. EOS failure can happen if RF emitters are close to a GNSS receiver or its antenna. EOS causes damage to the chip structures. If the RF_IN is damaged by EOS, it is hard to determine whether the chip structures have been damaged by ESD or EOS. UBX-19014286 - R05 4 Design Page 76 of 94 C1-Public Early production informationNEO-M9N - Integration manual EOS protection measures as shown in the figure below are recommended for any designs combining wireless communication transceivers (e.g. GSM, GPRS) and GNSS in the same design or in close proximity. Figure 35: Active antenna EOS protection 4.6.3 Safety precautions The NEO-M9N must be supplied by an external limited power source in compliance with the clause 2.5 of the standard IEC 60950-1. In addition to external limited power source, only Separated or Safety Extra-Low Voltage (SELV) circuits are to be connected to the module including interfaces and antennas.
For more information about SELV circuits see section 2.2 in Safety standard IEC 60950-1. 4.7 Electromagnetic interference on I/O lines Any I/O signal line with a length greater than approximately 3 mm can act as an antenna and may pick up arbitrary RF signals transferring them as noise into the receiver.
This specifically applies to unshielded lines, in which the corresponding GND layer is remote or missing entirely, and lines close to the edges of the printed circuit board. If, for example, a cellular signal radiates into an unshielded high-impedance line, it is possible to generate noise in the order of volts and not only distort receiver operation but also damage it permanently.
Another type of interference can be caused by noise generated at the PIO pins that emits from unshielded I/O lines. Receiver performance may be degraded when this noise is coupled into the GNSS antenna.
EMI protection measures are particularly useful when RF emitting devices are placed next to the GNSS receiver and/or to minimize the risk of EMI degradation due to self-jamming.
An adequate layout with a robust grounding concept is essential in order to protect against EMI. Intended Use: In order to mitigate any performance degradation of a radio equipment under EMC disturbance, system integration shall adopt appropriate EMC design practice and not contain cables over three meters on signal and supply ports. 4.7.1 General notes on interference issues Received GNSSsignalpower at the antenna is very low. At thenominal receivedsignal strength(-128 dBm) it is below the thermal noise floor of -111 dBm. Due to this fact, a GNSS receiver is susceptible to interference from nearby RF sources of any kind. Two cases can be distinguished:

? Out-of-band interference: Typically any kind of wireless communications system (e.g. LTE, GSM, CDMA, 3G, WLAN, Bluetooth, etc.) may emit its specified maximum transmit power in close proximity to the GNSS receiving antenna, especially if such a system is integrated with the GNSS receiver. Even at reasonable antenna selectivity, destructive power levels may reach UBX-19014286 - R05 4 Design Page 77 of 94 C1-Public Early production informationNEO-M9N - Integration manual the RF input of the GNSS receiver. Also, larger signal interferers may generate intermodulation products inside the GNSS receiver front-end that fall into the GNSS band and contribute to inband interference.

? In-band interference: Although the GNSS band is kept free from intentional RF signal sources by radio-communications standards, many devices emit RF power into the GNSS band at levels much higher than the GNSS signal itself. One reason is that the frequency band above 1 GHz is not well regulated with regards to EMI, and even if permitted, signal levels are much higher than GNSS signal power. Notably, all types of digital equipment, such as PCs, digital cameras, LCD screens, etc. tend to emit a broad frequency spectrum up to several GHz of frequency. Also wireless transmitters may generate spurious emissions that fall into GNSS band.
As an example, GSM uses power levels of up to 2 W (+33 dBm). The absolute maximum power input at the RF input of the GNSS receiver can be +15 dBm. The GSM specification allows spurious emissions for GSM transmitters of up to +36 dBm, while the GNSS signal is less than -128 dBm. By simply comparing these numbers it is obvious that interference issues must be seriously considered in any design of a GNSS receiver.
Different design goals may be achieved through different implementations:

? The primary focus is to prevent damaging the receiver from large input signals. Here the GNSS performance under interference conditions is not important and suppression of the signal is permitted. It is sufficient to just observe the maximum RF power ratings of all of the components in the RF input path.
? GNSS performance must be guaranteed even under interference conditions. In such a case, not only the maximum power ratings of the components in the receiver RF path must be observed. Further, non-linear effects like gain compression, NF degradation (desensitization) and intermodulation must be analyzed.

Pulsed interference with a low-duty cycle such as GSM may be destructive due to the high peak power levels. 4.7.2 In-band interference mitigation With in-band interference, the signal frequency is very close to the GNSS frequency. Such interference signals are typically caused by harmonics fromdisplays,micro-controller operation, bus systems, etc. Measures against in-band interference include:
? Maintaining a good grounding concept in the design
? Shielding
? Layout optimization
? Low-pass filtering of noise sources, e.g. digital signal lines
? Remote placement of the GNSS antenna, far away from noise sources
? Adding an LTE, CDMA, GSM, WCDMA, BT band-pass filter before antenna 4.7.3 Out-of-band interference Out-of-band interference is caused by signal frequencies that are different from the GNSS carrier frequency. The main sources are wireless communication systems such as LTE, GSM, CDMA, WCDMA, Wi-Fi, BT, etc. Measures against out-of-band interference include maintaining a good grounding concept in the design and adding a GNSS band-pass filter into the antenna input line to the receiver.
For GSM applications, such as typical handset design, an isolation of approximately 20 dB can be reached with careful placement of the antennas. If this is insufficient, an additional SAW filter is required on the GNSS receiver input to block the remaining GSM transmitter energy.)


But you guys know all that .
Found this Ariel on Ebay ,The supplier has plenty of options and spec sheets are in the discriptions.
This one is a Active 35x35 with 5db gain. Most of the others are only 2db gain.
I have ordered a few different types to use with my M9N
,Its so expensive ,like more than $7

www.ebay.com.au/itm/1575-42MHz-1602MHz-35-35-4mm-Active-Patch-GPS-Antenna-Glonass-aerial/264278344789?_trkparms=aid%3D111001%26algo%3DREC.SEED%26ao%3D1%26asc%3D20160908105057%26meid%3D51c1b364d95b4b77a7d8e21e5338b6a4%26pid%3D100675%26rk%3D3%26rkt%3D15%26mehot%3Dnone%26sd%3D264278456972%26itm%3D264278344789%26pmt%3D0%26noa%3D1%26pg%3D2380057&_trksid=p2380057.c100675.m4236&_trkparms=pageci%3Aec6a6b69-96bb-11eb-8360-ce09f318d81f%7Cparentrq%3Aa68cb8611780ad396918bf42ffff5974%7Ciid%3A1


Help with U center Configuration set up for M9N would be bloody good right now, and a way to save set up so chip stops reseting to defaults,(common issue i here).
If i forgot to say HI . Hi , I wouldn't want to be offensive Peter

Andrew's files with their first idle period roughly removed. I didn't bother to make the exact same cut. The point is clear anyway.

I'm not saying you should, should not, could, could not. I'm saying pure stationary tests are a bad idea, increasing rate increases noise, reaching for the peak of what physics allows requires unavailable/expensive parts, for now.

And although Trimmer raises a good point, this is not the kind of noise causing troubles here. We're talking noise inherent to the architecture of mainstream receivers.

I'll quit replying here. I had to learn this on my own and I'm not giving out strong clues to then read the above.

Select to expand quote

sailquik said..
... but let's try not to jump to the 'Grand Theory of Everything Doppler Accuracy' too quickly.

Where exactly did you find any claims about the 'Grand Theory of Everything Doppler Accuracy'?

You're not a scientist, so let me explain the basic scientific approach to you:
1. Make observations about a thing of interest.
2. Formulate a hypothesis about the causes, based on existing knowledge and ideas.
3. Perform experiments trying to validate or reject the hypothesis.
4. Refine the hypothesis (or develop a new, different hypothesis) based on results obtained. This typical includes developing theories which explain any observed deviations.
5. Repeat steps 2 - 4 until results are consistent and reproducible.
6. Publish the results with sufficient information so that others can repeat the experiments.

With enough cycles of this, the hypothesis eventually become a "thesis" or "known fact". Which is still subject to refinement or even invalidation if new results become available.

Tom Chalko's original paper about SDoP accuracy is a good example of this. It has shows that the SDoP accuracy for Locosys data was sufficiently accurate to be useful, based on stationary tests. His results have held up quite well over time.

Analyzing GPS data always has to make assumptions about the data, which are basically hypotheses from step 2 above. The validity of these assumptions needs to be tested if you want to have any confidence that the calculated results are valid. Manfred Fuchs did this when he originally developed GPSResults. He adjusted the way the results are computed based on his results, for example by not using Gaussian error propagation when calculating the error range for GT-31 data, since the filters used in the GT-31 mean that error values of adjacent points are not independent. Unlike Tom Chalko, he did not take the extra step of writing up his results and conclusions, so he omitted step 6 above.

Developing a new GPS should include choosing the best settings for both data acquisition and data analysis (calculating speed results). There are several hypotheses that have been postulated:

1. Higher data rates are give more accurate results.
2. The speed error estimates as given by the GPS can be used to judge accuracy.
3. Speed error estimates have similar accuracy at different data rates.

There are certainly good reasons behind all these assumptions - but they still need to be validated. Which is exactly what my experiments are trying to do. And some of the results obtained so far were surprising and in disagreement with one or more of the hypothesis. Which brings us to step 4 in the general scientific approach: develop theories and refine the hypotheses.

Now, are you saying that we should not use a scientific approach to determine the best settings for a new GPS? Or are you saying that the outline of the general scientific approach I gave above is incorrect, or that you have a better way of doing this?

Oh OUCH!

I can clearly see that you are on the right track then, so carry on.

One thing for sure. GPS engineers and mathematicians and programmers at such places as Garmin should have this thread as required reading. This is good stuff, written by people who have a vested interest in both accuracy and precision in GPS recording.

Keep going.

Select to expand quote

sailquik said..
The Motions report very low error values. Would they gain anything significant using more satellites?

I still owe you an answer to this question. I ran a few side-by-side tests with two of the original Motion's today (top of the van, clear view of the sky, units a few cm from each other) that showed some interesting patterns. The overall image (speed on top, error estimate below):

There are some small differences overall, but they are mostly lower than the standard deviation, except for a speed spike or two.
In many regions, the two units are very close to each other in averages, as in the selection in this example:

But in the region before that, the first device (blue) reads higher than the red:

Average speed is a little higher (0.056 vs. 0.047), but not as much as the +/- averages (0.223 vs. 0.179 kn). Note that the blue device used 1-2 fewer satellites (19 to 20 vs. 21).
A bit further in the track, the red numbers are higher:
Again, the device that had higher errors (both actual and estimated) used one satellites less (20 vs. 21).

So that's a bit of anecdotal evidence that more satellites can reduce speed errors and error estimates.

The graphs also nicely illustrate that the noise is composed of both "white" (random) noise, and "colored" (non-random) noise. Short spikes that are in just one of the two traces are random; the longer-term trends that the last 2 images look at are non-random. In this example, the random noise is more prominent overall, but the non-random trends explain why the 10-second results fall clearly outside of the calculated +/- ranges. That's because the Gaussian propagation used to calculate the +/- values for the results assumes that all noise is random, which is not the case.

Note that all the errors shown above are quite small. If we'd take directional speeds into consideration, they would likely shrink a bit more, and become "worst case" errors for speed runs (since "error speed" that is perpendicular to the speed run would pretty much be irrelevant). The typical error from noise like shown above for a 10-second run would likely be close to (and often less than) the average error of about 0.05 knots.

But there are other sources of noise that can increase the error by a lot in a non-random way. Some that are relevant for speedsurfing are small movements of the GPS on the arm (or head), and changes in how some satellites are blocked by the body when changing directions. I'll post some details on my blog in the few days.

Select to expand quote

boardsurfr said..

sailquik said..
The Motions report very low error values. Would they gain anything significant using more satellites?

I still owe you an answer to this question. I ran a few side-by-side tests with two of the original Motion's today (top of the van, clear view of the sky, units a few cm from each other) that showed some interesting patterns. The overall image (speed on top, error estimate below):

There are some small differences overall, but they are mostly lower than the standard deviation, except for a speed spike or two.
In many regions, the two units are very close to each other in averages, as in the selection in this example:

But in the region before that, the first device (blue) reads higher than the red:

Average speed is a little higher (0.056 vs. 0.047), but not as much as the +/- averages (0.223 vs. 0.179 kn). Note that the blue device used 1-2 fewer satellites (19 to 20 vs. 21).
A bit further in the track, the red numbers are higher:
Again, the device that had higher errors (both actual and estimated) used one satellites less (20 vs. 21).

So that's a bit of anecdotal evidence that more satellites can reduce speed errors and error estimates.

The graphs also nicely illustrate that the noise is composed of both "white" (random) noise, and "colored" (non-random) noise. Short spikes that are in just one of the two traces are random; the longer-term trends that the last 2 images look at are non-random. In this example, the random noise is more prominent overall, but the non-random trends explain why the 10-second results fall clearly outside of the calculated +/- ranges. That's because the Gaussian propagation used to calculate the +/- values for the results assumes that all noise is random, which is not the case.

Note that all the errors shown above are quite small. If we'd take directional speeds into consideration, they would likely shrink a bit more, and become "worst case" errors for speed runs (since "error speed" that is perpendicular to the speed run would pretty much be irrelevant). The typical error from noise like shown above for a 10-second run would likely be close to (and often less than) the average error of about 0.05 knots.

But there are other sources of noise that can increase the error by a lot in a non-random way. Some that are relevant for speedsurfing are small movements of the GPS on the arm (or head), and changes in how some satellites are blocked by the body when changing directions. I'll post some details on my blog in the few days.

Doesnt look right ,what filters are you using. are you using any LC filters... That van has a big metal roof right...Scientist

Select to expand quote

AUS3333 said..
Doesnt look right ,what filters are you using. are you using any LC filters... That van has a big metal roof right...Scientist

The data are raw data as logged by the Motion GPS. No filters were used, other that what's on the GPS chip (and theoretically in the firmware). The GPS was about 10 cm above the roof on a wooden roof rack.

Can you perhaps specify what you mean with "Doesnt look right"?

Select to expand quote

AUS3333 said..
Doesnt look right ,what filters are you using. are you using any LC filters... That van has a big metal roof right...Scientist

Since you raised the issue that the metal roof of the van might be a cause of problems, I did another (shorter) the test with 2 Motions at 10 Hz on a plastic table on the lawn in my back yard. The overall appearance is quite similar:

Here's a closeup where error estimates in one device are higher:

It's possible that the van top location had some minor effect, but definitely not a large one.

To avoid the chance of any further accidental troll feedings, I've decided to stop posting results here, and only post on my blog at boardsurfr.blogspot.com/. There will be details about the experiments, results, analysis of the results, and possible explanations of the results.

Initial results with the Openlog Artemis and the Sparkfun chips look quite promising. The SAM-M8 chip has given some decent results in windsurf and foil tests. The Neo-M9 chip with an external active antenna look even more promising in driving tests, but that's preliminary, and I have not yet had a chance for tests in the water with this chip. The Neo-M9 with the chip antenna gave poor results in my tests, so I would advice against getting that one.

The Neo-M9 should work with the Sparkfun GNSS firmware without changes. The M8 chips require some changes for logging to binary files, so you'd need to either modify the firmware, or contact me to get a copy of my changes. Updating firmware on the Openlog Artemis is reasonably easy, similar to updating firmware on pre-Motion GPS units.

Today I finally managed to get out on the water for a test of my home made device (M8Logger)
Here are the results:



The Mini Motion generally had 17 or 18 sats
My M8Logger generally had 22-24 sats

My logger had 10 missed points, which were all during a single crash.

Both devices worn high on the arm. Motion on a strap and M8Logger in a little waterproof box and then in an aquapac.

Not much more to say.

Nice neat job Andrew, all you need now is to get it approved, send the motion and the M8Logger files to the GPSTC, we'll probably want a few sessions. But sounds like there won't be a problem. The advisory guys will give final approval

Select to expand quote

tbwonder said..
Today I finally managed to get out on the water for a test of my home made device (M8Logger)
Here are the results:



The Mini Motion generally had 17 or 18 sats
My M8Logger generally had 22-24 sats

My logger had 10 missed points, which were all during a single crash.

Both devices worn high on the arm. Motion on a strap and M8Logger in a little waterproof box and then in an aquapac.

Not much more to say.

Awsome Andrew, what hz rate did you use?
Are you still going to try to get this to send data to garmin watch? .

Select to expand quote

TRIMMER said..
Awsome Andrew, what hz rate did you use?
Are you still going to try to get this to send data to garmin watch? .

I am using 10hz and 19200 transfer rate to the logger.

In a way it would be nice to get the data to a Garmin watch. But it may be beyond my skills. I did have a look at using the ANT+ system but couldn't find any easy to understand examples of how to do it.

The Garmin watch is so close nearly all the time that I am not sure it is worth the trouble.

Select to expand quote

tbwonder said..
Today I finally managed to get out on the water for a test of my home made device (M8Logger)
Here are the results:



The Mini Motion generally had 17 or 18 sats
My M8Logger generally had 22-24 sats

My logger had 10 missed points, which were all during a single crash.

Both devices worn high on the arm. Motion on a strap and M8Logger in a little waterproof box and then in an aquapac.

Not much more to say.

Andrew, what are the dimensions of the M8Logger?

How did you download your log?

I currently have it installed in a case that is 11cm by 7cm by 2cm. Its a similar size to a GT31. It would fit in a much smaller case, but it is just one I happened to have. The case has a flip lid, so it is easy to pop out the micro SD card to read the file. Just like we all used to with the GT31 in the old days - except it uses micro SD rather than standard SD. It is much quicker than messing around with the mini motion, turning on Wifi waiting for it to connect, then downloading.

I've just had a look at Andrew's 2 files, and noticed an anomaly I can't explain.


Blue is the motion Red Andrew's M8logger. Andrew's logger and the motion are close to identical for the whole session except here. Neither of them have any marked change to the accuracy data. But the motion has these 3, 5kt peak to peak exceptions at a frequency of about 1hz.

Andrew are both units on the same arm?

Different arm movements could conceivably cause this. But if they're close on the same arm, I'm at a loss.

Just had a closer look

So do you see what I see? The red line goes a bit smoother where the blue line peaks.
There certainly seems to be a difference in the general sawtooth pattern, the blue line is in general smoother.
I've no idea what this means, but so far the take away message is that the M8logger is doing OK

Select to expand quote

decrepit said..
I've just had a look at Andrew's 2 files, and noticed an anomaly I can't explain.


Blue is the motion Red Andrew's M8logger. Andrew's logger and the motion are close to identical for the whole session except here. Neither of them have any marked change to the accuracy data. But the motion has these 3, 5kt peak to peak exceptions at a frequency of about 1hz.

Andrew are both units on the same arm?

Different arm movements could conceivably cause this. But if they're close on the same arm, I'm at a loss.

Just had a closer look

So do you see what I see? The red line goes a bit smoother where the blue line peaks.
There certainly seems to be a difference in the general sawtooth pattern, the blue line is in general smoother.
I've no idea what this means, but so far the take away message is that the M8logger is doing OK

Hi, is this comparison based on the native .ubx output from both the Motion and the M8logger ?

I have a strong hunch on this one, I'll release a new firmware friday. Nice find, thank you.