GPS recording at interval +1s

Yesterday I received my watches and so far I like them.

Want to develop my own app and during the first testing I've noticed a strange behavior.
When recording GPS data the watch always records time +1 sec.
Created a custom repo to test some things and used GPS Setup and GPS Recorder
GPS Setup has PMOO and 1s as parameters
GPS Recording just has 1s

When logging a file
1s = 2s
5s = 6s
10s = 11s

Anybody with a suggestion?

Thanks! Sorry about that - not sure how I missed it!

Just fixed hopefully - the change required was this:

https://github.com/espruino/BangleApps/commit/5aa11ef71e78d965445993ddbb037e2187dcda61

It's not live on banglejs.com/apps right now, but you can install version 0.21 from https://espruino.github.io/BangleApps/

Good observation.

Yesterday I tested during a perfect afternoon on the water and it runs great at 1hz/1sec!
Not a second went wrong :)

Unfortunately the data itself contains several strange spikes in speed.
Need to check if this is due to the quality of the recorded data or something else.

How is speed calculated? The GPS recorder doesn't record speed, so chances are it is calculated from the difference in locations over time.

The GPS position can wander slightly over time, and I guess if the data is used without filtering then that could be what's causing the spike you are seeing.

The GPS recorder could easily average the last X seconds worth of data for each reading it wrote which would help with this (we could make that an option) but I've been hesitant to do that as it might have the effect of 'blurring' the data that has been recorded.

With no averaging, you're going to see only points on the track that you followed, but with the averaging you're going to see yourself at locations that you may not ever have been at (for instance if you turn a sharp corner during the averaging interval). Maybe that's not an issue though

Hi Gordon,
I've designed and programmed my personal GPS devices based on M8N and M9N.
Data from a Ublox chip normally is very accurate, but I use the binary protocol and not NMEA.

Attached are 2 files, 1 is data from the Bangle, the other is from my own logger at 5hz.
I've highlighted the suspicious part in the Bangle screenshot.

When I look at the track points

  <trkpt lat="52.477275" lon="5.065324">
    <ele>-5.9</ele>
    <time>2021-06-22T14:50:57.000Z</time>
  </trkpt>

  <trkpt lat="52.477113" lon="5.065425">
    <ele>-12.3</ele>
    <time>2021-06-22T14:50:58.000Z</time>
  </trkpt>

There is 19m between them, 19m/s = 68,4km/h

For my personal devices I use double for lat/lon data, it almost looks like the current grid is not dense enough.

I used km/h NMEA data from the Ublox on another Bangle and it is spot on! (other wrist)
So I really suspect the lat/lon data from the recorded file.

The Ublox spec has 8 digits, the recorded file 6 (page 141)
https://www.u-blox.com/en/docs/UBX-13003221

Could it be the difference between 32 and 64 bit?

2 Attachments

Does the GPS Recorder 0.21 affect updating, retaining, or using GPS time? (Sorry, novice here.) Will it be incorporated into something else eventually, so that the Recorder app isn't needed?

Thanks for digging down into it!

I just checked and the code that converts NMEA data into lat/lon for Espruino does use doubles, so I don't think that is the source of your inaccuracy.

The NMEA speed value is actually reported in the GPS event, I guess it's just not logged by the gpsrec widget. With some minor changes to the JS you could export that value though, if that's what you're specifically interested in?

I guess if this is reproducable it'd be pretty easy to log the full NMEA sentences, so you can check those and see if there are problems?

Does the GPS Recorder 0.21 affect updating, retaining, or using GPS time

It doesn't, no... Literally all it does is choose which GPS fix to record, but it doesn't modify them.

I did another windsurf session yesterday and it shows the same.
Big dips and huge peaks.
Not related to swell, super flat behind the sand bars.
On the second watch I used the NMEA speed value and it is spot on compared to my own build units.
(custom code I wrote to see 1s, 2s and 10s average speed)
The software we use to analyze our session only likes coordinates, recording speed is not a thing we would use.

Looked at the code with NMEA and it does indeed use doubles.
Need to think about this, maybe it is something silly with the output from the Ublox in this watch.
I'll put the recorder on the other watch also to check if it is a specific watch issue or setting.

Alright, not something I was hoping for, but there is a difference between the 2 units.

I played with the first one due to the GPS 1s not being 1s. (name with B)
The other one (name with C) was standard.
This morning I had to take the car for maintenance and logged a car track.
B has the jitters and jumps in speed.
Model C has very nice curves and no big jumps (car and rain, there where some expected spikes)

@Gordon Are there specific settings when the units are programmed?
Or can I just throw a reset to default at the Ublox chip?

There aren't any specific setting programmed into the chips as far as I know, no...

If it possible you'd uploaded AGPS data to one of them? Or maybe used the GPS Setup app to adjust the mode that it runs in to a low power one?

Fixed it :)
Don't know really what was set where, so I used a reset command I found in a threat AND I used the reset command I use for my own custom Ublox device.
After another car ride (same ride as above to pickup the van) it looks nice!
No more jitters and speed jumps!

To be completely sure I "need" another session windsurfing, but the wind prediction is quite bad.
So I probably continue working on my custom code and test somewhere in the next week.

Below is the code I used via the web ide to reset the Ublox.

function log_debug(o) {
  let timestamp = new Date().getTime();
  console.log(timestamp + " : " + o);
}

function writeGPScmd(cmd) {
  var d = [0xB5,0x62]; // sync chars
  d = d.concat(cmd);
  var a=0,b=0;
  for (var i=2;i<d.length;i++) {
    a += d[i];
    b += a;
  }
  d.push(a&255,b&255);
  Serial1.write(d);
}

function UBX_CFG_RESET() {
  log_debug("UBX_CFG_RESET()");
  writeGPScmd([0x06,0x09,
               0x0D,0x00,
               0xFF,0xFF,0x00,0x00,
               0x00,0x00,0x00,0x00,
               0xFF,0xFF,0x00,0x00,
               0x07]);
}

function UBX_CFG_RESET2() {
  log_debug("UBX_CFG_RESET2()");
  writeGPScmd([0x06, 0x09,   // class id
               0x0D, 0x00,
               0xFF, 0xFB, 0x00, 0x00,  // clear mask
               0x00, 0x00, 0x00, 0x00,  // save mask
               0xFF, 0xFF, 0x00, 0x00,  // load mask
               0x17]);
}

function setupGPS() {
  Bangle.setGPSPower(1);
  UBX_CFG_RESET();
  //wait(100);
  UBX_CFG_RESET2();
  setTimeout('console.log("Hello World");', 1000);
  setTimeout('Bangle.setGPSPower(0);', 1000);
}

setupGPS();

Cool - thanks! And there didn't seem to be any adverse effects? I guess we could add this to the GPS Setup app?