gpsd-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[gpsd-users] parsing NMEA PASHR record


From: Roger Oberholtzer
Subject: [gpsd-users] parsing NMEA PASHR record
Date: Fri, 1 Dec 2017 09:19:43 +0000

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]