ABS sensor scooter & arduino

The solution is to change saveData to write just one record of each type at a time. Change all these while loops:

while (WSSreadings.available()) {

... to an if test:

if (WSSreadings.available()) {

This is a quick change, and will probably fix the lost readings. However...

Almost managed just few IMU readings are missed. Grrrrrrrr :grin: :grin:

Initializing SD card...
  SD card initialized.
Press 1 to start logging, 0 to stop
Writing to data_00.txt
M,I,40435124,2
M,I,40477356,2
M,I,61146420,2
M,I,61164324,2
M,I,61185208,2
M,I,81834848,2
M,I,81876692,2
M,I,102534808,2
M,I,102576944,2
...

It is very periodic data are missed exactly every 20.7 s

I tried with a pre-allocated file size of 5 Mb the results are worse:

Initializing SD card...
  SD card initialized.
Press 1 to start logging, 0 to stop
Writing to data_02.txt
M,I,9644752,2
M,I,21767308,2
M,I,21797920,2
M,I,21847048,2
M,I,22944844,2
M,I,42456472,2
M,I,42475764,2
M,I,42497736,2
M,I,42525424,2
M,I,56494496,2
M,I,62994748,2
M,I,63156540,2
M,I,63175744,2
M,I,63197836,2
M,I,63225524,2
...

Thank you again,
Pm

Here’s the next version of the “simple” program. The primary change is to call yield after writing any record. It appears that writing the IMU or GPS record takes long enough that a reading can be missed when a second record is written.

A secondary change is to track buffer overruns in addition to missed readings. The former is simply a RAM issue (more RAM!), while the latter would point to a program issue (not sampling often enough). When you stop the logging (enter ‘0’), the total number of overruns and missed readings are displayed.

IN MY SIMULATION, no readings are missed. A long SD delay causes buffer overruns, because writing the records in HEX or DECIMAL doesn’t empty the buffers quickly enough. Writing the records in binary does not cause any overruns and does not miss any readings.

The attached program allows you to select HEX, DECIMAL or BINARY writing. It also writes a ‘T’ record when the simulated SD delay is 100 or 800ms. Most simulated delays are 1, 2 or 3ms.

I suspect that the simulated SD delays are much more than you experience with a real SD card, so that is probably why the buffers overrun in HEX or DECIMAL modes. You can try all 3 modes with your SD card to see if binary is really required.

If this works for you, then it can be modified to use the real sensors, GPS and PPS inputs. The hard-coded values go away. There are a few comments that show using the sensors, but the GPS/PPS code was totally replaced with a simulated GPS (hard-coded values, a new struct, etc.). That would have to be merged back in.

I get the following error :
call of overloaded ‘print(uint8_t*, unsigned int)’ is ambiguous

I’m not getting that error with the attached file, with or without SAVE_TO_SD enabled. You might try a different cast on the first argument:

    logfile.write( 'W' );
    logfile.write( (void *) &one, sizeof(one) );

Cheers,
/dev

RingBuffer.h (1.02 KB)

simple4.ino (22.7 KB)

Hi dev/,

Your program is just perfect, thank you a lot!

I merged it with the main sketch and even with decimal mode no missing appears! :slight_smile: :slight_smile: :slight_smile:

About the GPS, I kept the GPSreading struct and hence I wrote in saveData():

 if (gps.available()) {
    GPSreading_t one;
    one.fix = gps.read();

    if (one.fix.valid.time) { 
      
          // When the whole second rolls over, use the previously-stored PPS timestamp
      if (one.fix.dateTime_cs == 0) {
        cli();
          if (nextPPStime) { // PPS was detected
            lastPPStime = nextPPStime;
            nextPPStime = 0; // reset so we know if a PPS was detected for the next second
          } else { // no PPS detected...
            lastPPStime += 1000000UL; // ...just add one second to the last one
          }
        sei();

        one.t = lastPPStime;
        
      } else
        // Calculate an offset from the previous PPS
        one.t = lastPPStime + one.fix.dateTime_cs * 10000UL;
    }

    if (saveFlag) {
      writeGPS( one );
      wroteSomething = true;
      yield();
    }

it allows to log in binary mode if someone needs.

I am looking for a way to properly detect GPS issue.
For missing readings, I am thinking to compare one.fix.dateTime_cs with the previous one and if the results is superior to 5 ms missedGPS would be increased.
But to detect GPS overrun I am a little bit lost. Is there a way to track GPS overrun with the fix struct?

I am going to review the project on GitHub.

I have some difficulties to find someone able to help me for the steering sensor installation. It’s not so easy because I need a home made mechanical part.

Thank you again,
Pm

DataLoggerMoto_v19.ino (31.9 KB)

Is there a way to track GPS overrun with the fix struct?

Not with the fix structure, but you could check in loop:

void loop()
{
  testButtonToSave();

  readWSS();
  readSteering();
  readIMU();

  if (gps.overrun()) {
    gps.overrun( false );
    gpsOverruns++;
  }

  saveData();

}

For missing readings, I am thinking to compare one.fix.dateTime_cs with the previous one and if the results is superior to 5 ms missedGPS would be increased.

Yes, although I would step the last cs by 5 until it is >= the current cs, and add one missedGPS for each step. There is a possibility that this could step across a second (probably ok), and it would not catch more than one second of missed readings (is this ok?). It's very unlikely that you would miss a reading, because the GPS device always emits a fix, and it's handled in an interrupt (none of your code can block it).

Cheers,
/dev

Hello dev/,

Thank you again I did some tests and it is perfect no sensor reading is missed :slight_smile: :slight_smile: :slight_smile:

But I still have a problem with the NeoGPS library especially for GPS initialization. WaitForFix() still allows to break the loop even if location is zero.
I watched the last release of your library on GitHub and I think something is missing in NeoGPS_cfg.h line 75. According to the previous version:

...
#if (ARDUINO < 10606) | ((10700 <= ARDUINO) & (ARDUINO <= 107099)) <- Missing

  #define CONST_CLASS_DATA static const
  
#else

  #define CONST_CLASS_DATA static constexpr
  
#endif
...

Does anyone have any information about the filtering method used in Skytrack protocol?
As we discussed before it is not so easy to find anything about it.

Have a good day,
Pm

I watched the last release of your library on GitHub and I think something is missing in NeoGPS_cfg.h line 75.

o_O That’s weird! My local copy has the line, but the commit does not?!? There’s a (another) new version on github…

WaitForFix() still allows to break the loop even if location is zero.

I think you snuck some code in there:

 while (1) {
      if (gps.available()) {
        // get the last fix (empty the queue)
        gps_fix fix;
        do {
          fix = gps.read();
        } while (gps.available() && fix.latitudeL()==0);  <--- Hey!

:smiley:

So what data did you get? Did the first GPS record have zero lat/lon, but the rest were ok? Or did you get several records with zeroes? The lat == 0 sounds like a default fix you would get when you call read() and nothing is available.

Ok, just get rid of that nested loop. And change the next if statement:

  while (1) {
      if (gps.available()) {
        gps_fix fix = gps.read();
  
        // waiting for valid time and location
        if ( (fix.valid.status   && (fix.status >= gps_fix::STATUS_STD))
                    &&
             (fix.valid.location /* try without first: && (fix.latitudeL() != 0) && (fix.longitudeL() != 0) */ )
                    &&
             (fix.valid.time     && (fix.dateTime_cs == 0)) ) { 
          cli();

Do you get zeros with the above code? I wonder if the SkyTraq actually sends a zero location? This would get marked as valid by NeoGPS. All the GPS devices I’ve seen never send a zero, they leave the field empty (i.e., !valid).

Does anyone have any information about the filtering method used in Skytrack protocol?

This might be a good question for stackoverflow, where a non-Arduino user might know something about it. Be sure to include the vague wording from the spec.

Cheers,
/dev

So what data did you get?

with the original waitForFix() function :

static void waitForGPSFix() {
    DEBUG_PORT.println( F("Waiting for GPS fix...") );
  uint16_t lastToggle = millis();

  while (1) {
      if (gps.available()) {
        // get the last fix (empty the queue)
        gps_fix fix;
        do {
          fix = gps.read();
        } while (gps.available() );
        
        printL(DEBUG_PORT,fix.latitudeL());
        DEBUG_PORT.print('/');
        printL(DEBUG_PORT,fix.longitudeL());
        DEBUG_PORT.println(); 
          
          cli();
            if (nextPPStime) {
              lastPPStime = nextPPStime;
              nextPPStime = 0; 
              sei(); // done accessing nextPPSTime, reenable interrupts
            } else {
              sei(); // enable interrupts before printing
              lastPPStime = micros(); // a guess
            } 
          
            DEBUG_PORT.println(F("GPS ready!"));
            DEBUG_PORT.print(F("Initial Location: "));
            printL(DEBUG_PORT,fix.latitudeL());
            DEBUG_PORT.print('/');
            printL(DEBUG_PORT,fix.longitudeL());
            DEBUG_PORT.println();
       
          break;           
        }// Got it!
      
      if ((uint16_t) millis() - lastToggle > 500) {                // Slowly flash the LED until we get a fix
        lastToggle += 500;
        digitalWrite( LED, !digitalRead(LED) );
        #ifdef DEBUG_PORT
          DEBUG_PORT.write( '.' );
        #endif
      }
    }

  #ifdef DEBUG_PORT
    DEBUG_PORT.println();
  #endif

  digitalWrite( LED, LOW );

  gps.overrun( false );                                           // we had to wait a while...

} // waitForGPSFix

and the last release of your library I get:

Waiting for GPS fix...
0.0000000/0.0000000
GPS ready!
Initial Location: 0.0000000/0.0000000

Initializing SD card...
  SD card initialized.
Writing to data_11.txt
Waiting for GPS fix...
0.0000000/0.0000000
GPS ready!
Initial Location: 0.0000000/0.0000000

logfile closed.
  Total readings missed: 3
  Total readings overrun: 1

Location is zero during initialization and also during acquisition leading to missing readings.

Thank you again,
Pm

powergravity:
... I get:

Waiting for GPS fix...

...
Writing to data_11.txt
Waiting for GPS fix...
0.0000000/0.0000000
GPS ready!
Initial Location: 0.0000000/0.0000000

logfile closed.
 Total readings missed: 3
 Total readings overrun: 1

Sorry, I was asking about the first few G records in data_11.txt. Do they start as zeroes, then get a real value, or what?

...leading to missing readings.

Hmm, I'm not sure why this would lead to missed/overrun readings. What do the L records show?

Could you attach a data file? I've also got some ideas about syncing with the IMU clock that I'd like to investigate. At least 10 seconds of samples would be nice.

Good progress, though!

Cheers,
/dev

Sorry, I was asking about the first few G records in data_11.txt. Do they start as zeroes, then get a real value, or what?

Yes all recorded location are zero (somewhere in the sea :p)

Hmm, I'm not sure why this would lead to missed/overrun readings. What do the L records show?

I think I understood the problem.
The code

while (1) {
      if (gps.available()) {
        gps_fix fix = gps.read();
  
        // waiting for valid time and location
        if ( (fix.valid.status   && (fix.status >= gps_fix::STATUS_STD))
                    &&
             (fix.valid.location /* try without first: && (fix.latitudeL() != 0) && (fix.longitudeL() != 0) */ )
                    &&
             (fix.valid.time     && (fix.dateTime_cs == 0)) ) { 
          cli();

does not empty the GPS queue right? That might be the reason?

I've also got some ideas about syncing with the IMU clock that I'd like to investigate

:slight_smile:

As soon as I will be at home I will attached a recorded file longer than 10 s.

Thank you,
Pm

I did one test with the original code:

static void waitForGPSFix() {
  #ifdef DEBUG_PORT
    DEBUG_PORT.println( F("Waiting for GPS fix...") );
  #endif

  uint16_t lastToggle = millis();

  while (1) {
      if (gps.available()) {
        // get the last fix (empty the queue)
        do{
          initialFix = gps.read();
        } while(gps.available()) ;
         
        // waiting for valid time and location
        if (initialFix.valid.location && initialFix.valid.time && (initialFix.dateTime_cs == 0)  ){ 

          cli();
            if (nextPPStime) {
              lastPPStime = nextPPStime;
              nextPPStime = 0; 
              sei(); // done accessing nextPPSTime, reenable interrupts
            } else {
              sei(); // enable interrupts before printing
              lastPPStime = micros(); // a guess
            } 
           
          break;           
        }// Got it!
      }
      
      if ((uint16_t) millis() - lastToggle > 500) {                // Slowly flash the LED until we get a fix
        lastToggle += 500;
        digitalWrite( LED, !digitalRead(LED) );
        #ifdef DEBUG_PORT
          DEBUG_PORT.write( '.' );
        #endif
      }
    }

  #ifdef DEBUG_PORT
    DEBUG_PORT.println();
  #endif

  digitalWrite( LED, LOW );

  gps.overrun( false );                                           // we had to wait a while...

} // waitForGPSFix

and I obtain the attached recording. Even after 30 sec of acquisition location is still zero.

Have a good day,
Pm

data00.txt (412 KB)

Hello,

I come back after several months...
I saw that there is a new release of NeoGPS library thank you \dev for your work :slight_smile:
I saw that you have included several functions with the PPS signal. Do you think I should modify my code according to the last release of your library?

I still have some problems to receive a correct GPS signal when I start the Arduino, I mean that in WaitForFix() function:

if (initialFix.valid.location && initialFix.valid.time && (initialFix.dateTime_cs == 0)  ){ 
...
}

does not avoid zero location and adding:

if (initialFix.longitude()!=0) { // or initialFix.longitude()!=0
  if (initialFix.valid.location && initialFix.valid.time && (initialFix.dateTime_cs == 0)  ){ 
  ...
  }
}

lead to a corrupt time counter. As soon as the location is non zero (after around 1 minute) the second condition especially initialFix.dateTime_cs == 0 is never satisfied because the dateTime_cs increments as it follows: 4, 9, 14, 19 ....

The only solution is to upload several times the code until it works.
Any idea?

I am going to review the project on GitHub:

Thank you in advance,
Pm

powerGravity:
Hello,

I was just wondering how it was going! I occasionally review the IMU sample rate question. As you recall, the response time “creeps” against the Arduino sample period. It could benefit from a little code to “lock in” on the IMU’s internal 100Hz sample clock. Anyway…

the WaitForFix() function does not avoid zero location

Are you using the latest library? There was a fix that reset the valid flags in a certain condition.

I wonder if the Venus unit is actually reporting a zero location field. If it’s not empty, NeoGPS will think it’s valid. Could you try running NMEA.ino? It displays all the fields that you have configured, and it will display zero lat/lon if the GPS device is sending them.

Also, I have a version 19 of your code that has a more complicated test:

       // waiting for valid time and location
        if ( (fix.valid.status   && (fix.status >= gps_fix::STATUS_STD))
                    &&
             (fix.valid.location /* try without first: && (fix.latitudeL() != 0) && (fix.longitudeL() != 0) */ )
                    &&
             (fix.valid.time     && (fix.dateTime_cs == 0)) ) {

You could uncomment that zero lat/lon test, too.

There is no variable called initialFix in that version, so I’m not sure what code you are using.

initialFix.dateTime_cs == 0 is never satisfied because the dateTime_cs increments as it follows: 4, 9, 14, 19 …

I think you only see that when it does not have a satellite fix yet, and it is still running off the internal RTC. I have seen this on other GPS devices, too. As soon as it starts running off the received GPS time, the fixes are aligned to a “xx:xx:xx.000” boundary. Are you saying it never starts, even after getting a fix?

It seem like we talked about changing the test to

    (fix.dateTime_cs < GPS_PERIOD/1000)

That would catch a CS of 0, 1, 2, 3 or 4.

I am going to review the project on GitHub:

Review? Did you mean “renew”?

Cheers,
/dev

I was just wondering how it was going!

Fine like every day! 
I hope also you are doing well.

I had several priorities with short deadlines for my PhD so not enough time to continue the data logger project.

It could benefit from a little code to “lock in” on the IMU’s internal 100Hz sample clock.

For sure it could be useful!

Are you using the latest library?

Yes, I have downloaded the last release three days ago. You are right about a possible issue with the Venus unit because after running NMEA.ino I get:

NMEA.INO: started
  fix object size = 31
  gps object size = 673
Looking for GPS device on Serial1

GPS quiet time is assumed to begin after a RMC sentence is received.
  You should confirm this with NMEAorder.ino

Status,UTC Date/Time,Lat,Lon,Hdg,Spd,Alt,Sats,Rx ok,Rx err,Rx chars,
0,2006-06-28 12:00:09.190,0,0,0,0,,,1,0,114,
0,2006-06-28 12:00:09.250,0,0,0,0,,,2,0,186,
0,2006-06-28 12:00:09.300,0,0,0,0,,,3,0,258,
0,2006-06-28 12:00:09.340,0,0,0,0,,,4,0,330,
0,2006-06-28 12:00:09.390,0,0,0,0,,,5,0,402,
0,2006-06-28 12:00:09.450,0,0,0,0,,,6,0,474,
0,2006-06-28 12:00:09.500,0,0,0,0,,,7,0,546,
0,2006-06-28 12:00:09.550,0,0,0,0,,,8,0,618,
0,2006-06-28 12:00:09.600,0,0,0,0,,,9,0,690,
0,2006-06-28 12:00:09.640,0,0,0,0,,,10,0,762,
0,2006-06-28 12:00:09.690,0,0,0,0,,,11,0,834,
0,2006-06-28 12:00:09.750,0,0,0,0,,,12,0,906,
…

The location is not empty!

Also, I have a version 19 of your code that has a more complicated test:

There is no variable called initialFix in that version, so I’m not sure what code you are using.

Sorry it is a little bit confused. I use an initialFix variable to display the location at initial time (when WaitForFix is finished) on the small screen. The last release of the code is attached.

Are you saying it never starts, even after getting a fix?

Yes even if the location is correct the fixes are often not aligned to a “xx:xx:xx.000” boundary.

Review? Did you mean “renew”?

I Updated 

Thank you and have a good day,
Pm

DataLoggerMoto_v20.ino (34.5 KB)

You are right about a possible issue with the Venus unit

Ok, to confirm this is not a bug with NeoGPS, could you try the simple echo test:

void setup()
{
  Serial.begin( 230400 ); // or whatever
  Serial1.begin( 115200 ); //  or whatever
}

void loop()
{
  if (Serial1.available())
    Serial.write( Serial1.read() );
}

If it shows something like

    $GPRMC,120009.190,V,000.0000,E,0000000,N,,,280606,*2E

... then I'll know it's an artifact of the GPS device.

If it shows

    $GPRMC,120009.190,V,,,,,,,280606,*0B

... then there is a bug in NeoGPS. o_O I should be able to paste the output into a test program to help find the bug.

Thanks!

If it shows something like

$GPRMC,120009.190,V,000.0000,E,0000000,N,,,280606,*2E

... then I'll know it's an artifact of the GPS device.

Right:

$GPRMC,115947.450,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*72
$GPRMC,115947.500,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*76
$GPRMC,115947.549,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7B
$GPRMC,115947.599,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*76
$GPRMC,115947.650,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*70
$GPRMC,115947.700,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*74
$GPRMC,115947.749,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*79
$GPRMC,115947.799,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*74
$GPRMC,115947.850,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7E
$GPRMC,115947.900,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7A
$GPRMC,115947.950,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7F
$GPRMC,115948.000,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7C
$GPRMC,115948.049,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*71
$GPRMC,115948.099,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7C
$GPRMC,115948.150,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*78
$GPRMC,115948.200,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7E
$GPRMC,115948.249,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*73
$GPRMC,115948.299,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7E
$GPRMC,115948.350,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7A
$GPRMC,115948.400,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*78
$GPRMC,115948.450,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7D
$GPRMC,115948.500,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*79
$GPRMC,115948.549,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*74
$GPRMC,115948.599,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*79
$GPRMC,115948.650,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7F
$GPRMC,115948.700,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7B
$GPRMC,115948.749,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*76
$GPRMC,115948.799,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7B
....

Thank you again,
Pm

Take a look about what happens, there is a weird:

time:45$GPRMC,115948.599,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*79
time:55$GPRMC,115948.650,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7F
time:144$GPRMC,115948.700,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7B
time:155$GPRMC,115948.749,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*76
time:244$GPRMC,115948.799,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7B
time:256$GPRMC,115948.850,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*71
time:345$GPRMC,115948.900,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*75
time:356$GPRMC,115948.950,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*70
time:444$GPRMC,115949.000,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*7D
time:455$GPRMC,115949.049,V,0000.0000,N,00000.0000,E,000.0,000.0,280606,,,N*70
.....
time:146810$GPRMC,150029.300,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7A
time:146822$GPRMC,150029.350,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7F
time:146910$GPRMC,150029.400,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7D
time:146922$GPRMC,150029.450,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*78
time:147010$GPRMC,150029.500,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7C
time:147022$GPRMC,150029.550,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*79
time:147110$GPRMC,150029.600,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7F
time:147122$GPRMC,150029.650,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7A
time:147210$GPRMC,150029.700,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7E
time:147222$GPRMC,150029.750,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*7B
time:147310$GPRMC,150029.800,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*71
time:147321$GPRMC,150029.850,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*74
time:147475$GPRMC,150029.900,V,0000.0000,N,00000.0000,E,000.0,000.0,200417,,,N*70
time:147487$GPRMC,150030.319,V,4836.8130,N,00225.6983,E,000.0,000.0,200417,,,N*78
time:147564$GPRMC,150030.369,V,4836.8130,N,00225.6983,E,000.0,000.0,200417,,,N*7F
time:147575$GPRMC,150030.419,V,4836.8130,N,00225.6983,E,000.0,000.0,200417,,,N*7F
time:147663$GPRMC,150030.469,V,4836.8130,N,00225.6983,E,000.0,000.0,200417,,,N*78
time:147676$GPRMC,150030.519,V,4836.8073,N,00225.7037,E,000.0,000.0,200417,,,N*7F
time:147765$GPRMC,150030.569,V,4836.8130,N,00225.6983,E,000.0,000.0,200417,,,N*79
time:147776$GPRMC,150030.619,A,4836.8079,N,00225.7041,E,000.0,000.0,200417,,,A*6F
time:147865$GPRMC,150030.669,A,4836.8077,N,00225.7041,E,000.0,000.0,200417,,,A*66
time:147876$GPRMC,150030.719,A,4836.8078,N,00225.7042,E,000.0,000.0,200417,,,A*6C
time:147964$GPRMC,150030.769,A,4836.8079,N,00225.7044,E,000.0,000.0,200417,,,A*6C
time:147976$GPRMC,150030.819,A,4836.8080,N,00225.7046,E,000.0,000.0,200417,,,A*60
time:148065$GPRMC,150030.869,A,4836.8081,N,00225.7048,E,000.0,000.0,200417,,,A*68
time:148076$GPRMC,150030.919,A,4836.8080,N,00225.7049,E,000.0,000.0,200417,,,A*6E
time:148164$GPRMC,150030.969,A,4836.8079,N,00225.7050,E,000.0,000.0,200417,,,A*67
time:148175$GPRMC,150031.019,A,4836.8083,N,00225.7051,E,000.0,000.0,200417,,,A*6C
time:148264$GPRMC,150031.069,A,4836.8088,N,00225.7054,E,000.0,000.0,200417,,,A*65
time:148277$GPRMC,150031.119,A,4836.8094,N,00225.7056,E,000.0,000.0,200417,,,A*6C
time:148365$GPRMC,150031.169,A,4836.8100,N,00225.7058,E,000.0,000.0,200417,,,A*69
time:148376$GPRMC,150031.219,A,4836.8102,N,00225.7058,E,000.0,000.0,200417,,,A*6F
time:148435$GPRMC,150031.269,A,4836.8103,N,00225.7058,E,000.0,000.0,200417,,,A*69
time:148448$GPRMC,150031.319,A,4836.8103,N,00225.7058,E,000.0,000.0,200417,,,A*6F
time:148523$GPRMC,150031.369,A,4836.8103,N,00225.7058,E,000.0,000.0,200417,,,A*68
time:148534$GPRMC,150031.419,A,4836.8103,N,00225.7058,E,000.0,000.0,200417,,,A*68
time:148623$GPRMC,150031.469,A,4836.8103,N,00225.7058,E,000.0,000.0,200417,,,A*6F
...

the "time" variable is just an indicator for the elapsed time before fixing a location.

The problem about the time arrives simultaneously when the GPX fixes a correct location... :relaxed:

Thanks,
Pm

Allons donc! -_- Looks like you have to use the full, complex test with that GPS device:

        // waiting for valid time and location
        if ( (fix.valid.status   && (fix.status >= gps_fix::STATUS_STD))
                    &&
             (fix.valid.location && (fix.latitudeL() != 0) && (fix.longitudeL() != 0))
                    &&
             (fix.valid.time     && (fix.dateTime_cs < GPS_PERIOD/1000UL)) ) {

It would have quit waiting @ time 150031.019, in your sample.

Pfft.

Hello,

/dev:
Allons donc! -_- Looks like you have to use the full, complex test with that GPS device:

        // waiting for valid time and location
    if ( (fix.valid.status   && (fix.status >= gps_fix::STATUS_STD))
                &&
         (fix.valid.location && (fix.latitudeL() != 0) && (fix.longitudeL() != 0))
                &&
         (fix.valid.time     && (fix.dateTime_cs < GPS_PERIOD/1000UL)) ) {


It would have quit waiting @ time 150031.019, in your sample.

Pfft.

Yes, but I wonder why as soon as the GPS receive a valid location the fixes are no longer aligned to a “xx:xx:xx.000” boundary. Moreover, sometimes it is aligned…

I finally installed the steering sensor.

As soon as I will have free time, I would test the whole of the data logger :slight_smile:

Thank you again,
Pm

Amazing! :smiley: