Mathew, wasn't there a leap second adjustment recently? Is it possible one the the GPSs is updated the other isn't
Select to expand quoteboardsurfr said.. mathew said..
Thus GNSS calculation producing Doppler-speed, also produces the error estimate. ie: implying it has units (m/s, knots, etc) as the speed-value.
xDOP... aka the TDOP, PDOP, GDOP, VDOP, HDOP, etc... are all unit less.
Certainly true for HDOP etc., but not for SDOP.
You left off the previous two paragraphs which say exactly that - are you restating the same thing as a confirmation ?
Select to expand quoteboardsurfr said..
Two questionable conclusions. A statement by the chip companies what they are trying to give us in the accuracy estimates would be a very good start, but I don't think we'll get that. But we can go and characterize the data that we are getting. That's not really easy, but can be done. Tom Chalko's original work indicated that the error estimates that Sirf chips give are higher than one or two standard deviations; in 81,493 data points, he did not find a single point were SDOP underestimated the actual error. If SDOP was 2 standard deviations, we'd expect about 2,000 points where SDOP is too low, so this points towards SDOP being > 4 SDs (a bit simplified). I have looked into this just a little bit, but my first impression for ublox data was that the ublox speed accuracy estimate is closer to 1 SD or 2 SD. If that is indeed the case, then the numbers are not the same.
Tom's analysis - and thus the Sirf error-values - *are* 4 SD.... the analysis targeted > 99 percentile, so that we could be extremely confident of the error-bounds. Your work here, supports the work Tom and Manfred have done previously regarding the GT-31.
The thread-context was whether the error-value of a given instantaneous speed measurement, is comparative between EHVE and SDOP -> the 2 or 4 SD is irrelevant in that context.... what matters is that the error-value has a scalar-velocity-unit (m/s,knots,kph,etc - ignoring transposing from one to another).
The 2|4 SD difference matters when we try use it to determine accuracy of the specific speed data-point. ie: if we chart all the data, these 2|4 SD's are just error-bars on each value.
... and that is why the GPS-windsurfing community came up with idea of "claimed speed"... that way any GPS hardware irrespective of its age/quality/etc can be used, *provided the hardware can supply an error-value* -> we subtract the worst-case error and thus claim at least that minimum speed.
... thus they *are* the same [ and so allowing for claimed-speed for measuring records ]. To use some other technique, such as blinding trusting the value printed on the screen (....say by using a GPS device which hasn't had this rigour applied) is disingenuous to your friends whom have made the effort to sail fast and claim their speed.
Select to expand quoteboardsurfr said..
But this analysis is a bit to simplistic. Tom's analysis of stationary (or, more accurately, constant speed) data did not take into account errors that can arise from speed changes at frequencies above the sampling rate (more or less - theory will add a factor of 2 here). Such changes could introduce "aliasing" errors, which is a reason why GPSResults does not use Gaussian error propagation for 1 Hz data (which are presumed to be GT31 data). To what extend that is still justified for 1 Hz GW-52 data is a different question. I am waiting for a few more GW-52s and ublox8 toys to look into this a bit more. Even if we did have a full specification of what SDOP and "Speed accuracy estimate" are supposed to be, and even if we did have the entire firmware source code and could understand it, we'd still need to do an empirical validation to see if the data we get are indeed what they are supposed to be.
Tom and Manfred's info specifically describe aliasing - all digital hardware has aliasing... it is an artefact of digital technology [ Gaussian distribution has absolutely nothing to do with digital sampling - one is a function of how your real-world data varies over time, the other is how fast you run your sampling hardware. ]
This is why the GPS-windsurfing community want high-Hz sampling -> so that we can better understand what is really happening sub-second. [ It just so happens analysis like yours, is driving the windsurfing community well ahead of other sports. ]
Gaussian was chosen, because after best-fitting various algorithms over *lots* of data and errors, the distribution of looks Gaussian. The first suggestion was a Sinc function due to its use in Fourier analysis.
Hello Mathew,
I buffer just the bare minimum what is needed to fill 1 SD card block.
This is really necessary, without it there will be missing GPS points.
The buffer is filled every 0.07 to 0.15sec, writing takes approx 0.2sec.
But I can't imagine the time will change in that process, it could be something within the GPS FW or GPS software.
What would you like to see in the picture?
You can also look at the data yourself, I don't mind to upload a GT-31 and Gyro track to Wetransfer.
Select to expand quoteraymondw said..
Hello Mathew,
I buffer just the bare minimum what is needed to fill 1 SD card block.
This is really necessary, without it there will be missing GPS points.
The buffer is filled every 0.07 to 0.15sec, writing takes approx 0.2sec.
But I can't imagine the time will change in that process, it could be something within the GPS FW or GPS software.
What would you like to see in the picture?
You can also look at the data yourself, I don't mind to upload a GT-31 and Gyro track to Wetransfer.
During a card-write, the card's smallest block size will determine the absolute minimum that should be written, so that the card's onboard controller wont need to do an extra read of the block. (ie: the read-update-write cycle). On a 1GB memory card, using FAT32, that is 1024 bytes. 2048 bytes for 2GB.
In previous work with USB memory cards -> I killed a few cards within only a couple of weeks, while using once-per-second sync of about 200 bytes of data. If you write data smaller than that, the card-controller will probably remap that block elsewhere to evenly distribute writes to the cells (ie: wear-levelling). To much wear-levelling can quickly kill a card. [ Took a few months of testing to find this bug - I now only write+sync once per minute in that project. ] So it becomes a question of what is a suitable buffer size?
As you know, writing data to the card will consume some cpu-cycles... this may impact your GPS-data-collection, possibly resulting in lost data points. Ideally you want to be able to send the data to the card, without CPU waiting for a response... but we live in the non-ideal world, so too big a buffer may result in lost data.
Some cards write faster than others, making the buffer-size choice less relevant; some cards have an internal block size that will be optimal for buffering. On CPU with DMA, your code wont need to wait for the buffer to be written; on an Arduino you have to wait. ... thus buffering is a hardware limitation / trade off...
How do you determine the card's block size ?
mathew,
Time comes from the GPS, not the SD card
If I create a very large buffer and only use that (GW52?) time will stay the same.
You also wrote that you log once a minute .
The mismatch is not the logging...
As far as the SD code goes, I don't rewrite or (re)allocate blocks during logging.
In the FreeRTOS domain there is a lot of cool code that I used for my driver.
