Re: [gpsd-users] parsing NMEA PASHR record

[Roger Oberholtzer]

Hmmm. No responses to the original post. No one have any idea how best to add this PASHR record so that it does not mess up the report cycle?

---

From: gpsd-users [gpsd-users-bounces+address@hidden on behalf of Roger Oberholtzer address@hidden
Sent: Friday, December 01, 2017 10:19 AM
To: address@hidden
Cc: Mattias Nilsson
Subject: [gpsd-users] parsing NMEA PASHR record

We have added what we think to be the required code to parse the PASHR NMEA record in gpsd 3.17. Our goal is that the JSON ATT record should contain this information. The diff is quite simple:

--- driver_nmea0183-orig.c    2017-09-13 13:00:26.655381516 +0200
+++ driver_nmea0183.c    2017-09-13 13:00:31.403381419 +0200
@@ -1344,12 +1344,11 @@
  * $PASHDR,type[,val[,val]]*CS
  * type is an alphabetic subsentence type
  *
- * Oxford Technical Solutions (OXTS) also uses the $PASHR sentence,
+ * Oxford Technical Solutions (OxTS) also uses the $PASHR sentence,
  * but with a very different sentence contents:
  * $PASHR,HHMMSS.SSS,HHH.HH,T,RRR.RR,PPP.PP,aaa.aa,r.rrr,p.ppp,h.hhh,Q1,Q2*CS
  *
- * so field 1 in ASHTECH is always alphabetic and numeric in OXTS
- * FIXME: decode OXTS $PASHDR
+ * so field 1 in ASHTECH is always alphabetic and numeric in OxTS
  *
  */
 static gps_mask_t processPASHR(int c UNUSED, char *field[],
@@ -1424,6 +1423,35 @@
          session->gpsdata.satellites_used);
     session->gpsdata.skyview_time = NAN;
     mask |= SATELLITE_SET | USED_IS;
+    } else if (0 == strcmp("T", field[3])) { /* Assume OxTS PASHR */
+    merge_hhmmss(field[1], session);
+    register_fractional_time(field[0], field[1], session);
+    session->gpsdata.attitude.heading = safe_atof(field[2]);
+    session->gpsdata.attitude.mag_st = '\0';
+    session->gpsdata.attitude.roll = safe_atof(field[4]);
+    session->gpsdata.attitude.roll_st = '\0';
+    session->gpsdata.attitude.pitch = safe_atof(field[5]);
+    session->gpsdata.attitude.pitch_st = '\0';
+    session->gpsdata.attitude.yaw = NAN;
+    session->gpsdata.attitude.yaw_st = '\0';
+    session->gpsdata.attitude.dip = NAN;
+    session->gpsdata.attitude.mag_len = NAN;
+    session->gpsdata.attitude.mag_x = NAN;
+    session->gpsdata.attitude.mag_y = NAN;
+    session->gpsdata.attitude.mag_z = NAN;
+    session->gpsdata.attitude.acc_len = NAN;
+    session->gpsdata.attitude.acc_x = NAN;
+    session->gpsdata.attitude.acc_y = NAN;
+    session->gpsdata.attitude.acc_z = NAN;
+    session->gpsdata.attitude.gyro_x = NAN;
+    session->gpsdata.attitude.gyro_y = NAN;
+    session->gpsdata.attitude.temp = NAN;
+    session->gpsdata.attitude.depth = NAN;
+    mask |= (TIME_SET | ATTITUDE_SET);
+    gpsd_log(&session->context->errout, LOG_RAW,
+         "time %.3f, heading %lf.\n",
+         session->newdata.time,
+         session->gpsdata.attitude.heading);
     }
     return mask;
 }

We have only set roll. pitch and heading.

What we find is that the concept of a report cycle seems to have changed. That is, the values in shared memory now contain NaN for lat/long and such very often. We have not changed the NMEA stream itself. We have only added the code above to parse the PASHR data. The PASHR record is at 10 Hz. We do not want the PASHR to mess with the report cycle. But it seems we have made it do so.

What might we have done wrong or missed?

Roger Oberholtzer

 

RST Systems

 

Office: +46 (0)10-615 6020

Mobile: +46 (0)70-815 1696

address@hidden

________________________________________

 

Ramböll Sverige AB
Krukmakargatan 21
P.O. Box 17009
SE-104 62 Stockholm, Sweden
www.rambollrst.se