Using Piksi receivers with RTKLib

[Simon Treny]

Hi everyone,

I'd like to use Piksi receivers to acquire GPS RAW-data (logged as a RINEX file) and then use RTKLib to perform a post-processing RTK resolution.

In order to do so, I use the Record button in the Observation tab of the Piksi console to produce the RINEX file. So far, everything works fine.

But when I use this RINEX file as the rover observations to perform RTK resolution with RTKLib, I get a lot of single positions (83%), some float positions (16%) and almost no fixed positions (0.6%). By comparison, when I use a different receiver (Ublox M8T or NVS NV08C), I always get at least float solutions and very often fixed solutions.

When I look at the trace file produced by RTKLib, I always get the same errors resulting to single solutions:

2 10:37:46.59: large residual (sat=22- 8 L1 v=-5.436 sig=0.984)

2 10:37:46.59: large residual (sat=22-16 L1 v=-11.118 sig=0.977)

2 10:37:46.59: large residual (sat=22-18 L1 v=-9.127 sig=1.038)

2 10:37:46.79: outlier rejected (sat= 22-  4 L1 v=-655.527)

2 10:37:46.79: outlier rejected (sat= 22-  8 L1 v=-385.534)

2 10:37:46.79: outlier rejected (sat= 22- 16 L1 v=1138.948)

2 10:37:46.79: outlier rejected (sat= 22- 18 L1 v=732.305)

2 10:37:46.79: outlier rejected (sat= 22- 21 L1 v=1110.047)

2 10:37:46.79: outlier rejected (sat= 22- 26 L1 v=1432.377)

Has anyone else experienced the same issue?

Are the Piksi receivers ready for RAW-data acquisition or do they produce for now too inaccurate pseudo-range/carrier-phase measurements to be used with RTKLib ?

Thanks in advance for your help,

Cheers,

Simon

[Fergus Noble]

Hi Simon,

Unfortunately there a couple known issues with the RINEX export as well as something subtle about the way the observations are generated that makes them not compatible with RTKlib and a number of other RTK implementations, despite working well with our RTK filter.

Is there a reason not to use the built in RTK filter?

Thanks,

Fergus

--
Fergus Noble

CTO & Co-founder

Swift Navigation Inc.
2148 3rd St.
San Francisco, CA 94107

--
You received this message because you are subscribed to the Google Groups "swiftnav-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to swiftnav-discu...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Clive Turvey]

>>Has anyone else experienced the same issue?

Yes, you might want to negate the phase*. The way it handles time and rebases the pseudo-range also gives the post-processing software I use headaches. That said when I take data from an M8N and post-process that with Fixed L1 convergence numbers better than 5mm (rms) for hour long observation files.

The Piksi's work with the data they produce to deliver the 2cm (rms) numbers you'd expect from RTK, so I hardly think they are working with inaccurate measurements.

* I built a Win32 App to do that. TEQC and other RINEX tools may also be able to do that. Contact off-list if you wish to discuss further.

[Simon Treny]

Hi Fergus,

Thanks for your quick reply ! Please find my answers below.

Unfortunately there a couple known issues with the RINEX export as well as something subtle about the way the observations are generated that makes them not compatible with RTKlib and a number of other RTK implementations, despite working well with our RTK filter.

Thanks for the explanation. Would we have more luck making our own SBP-to-RINEX converter or would it give us similar results? Also, could you please elaborate further on the issues with the observations generated by Piksi that make them incompatible with RTKLib?  

Is there a reason not to use the built in RTK filter?

We are interested in Piksi receivers because low-cost receivers (UBlox or NVS to name a few) only support low dynamics. In our tests, with UBlox M8T or NVS NV08C receivers, as soon as the acceleration exceeds 4g or 5g (in our case, because of shocks on the antenna), many losses of lock occur making them pretty much useless for RTK resolution (as carrier-phase measurements are not continuous). Piksi receivers seem to handle high accelerations (< 10g) a lot better resulting in a stable solution even when the antenna endures high accelerations.

Unfortunately, in our experience, the RTK filter of Piksi could not always maintain a fixed solution for a long period of time (even while stationary) and float solutions are often off by several meters. RTKLib on the other hand seems to output more reproducible results (solutions are not always fixed but float solutions are often pretty good). That's mainly the reason why we tried to use Piksi receivers with RTKLib.

Cheers,

Simon

[Simon Treny]

Hi Clive,

Thanks for the tip!

I have no access to the recordings right now, but I'll try tomorrow to negate the carrier-phase measurements before inputing it to RTKLib. I'll let you know if it makes things better!

[Clive Turvey]

You could certainly fix the phase issue with your own SBP-to-RINEX, we've done that here along with UBLX-to-SBP and ASHTECH-to-SBP real-time transcoders. There's a direct one-to-one relationship between the data in the SBP and what goes out in the RINEX record. There's some decoding, but no fixing/smoothing/adjusting type stuff.

I'd have to go over my notes, but as I recall phase expressed in RTCM is negated compared to your typical RINEX sense, although there are a lot of broken implementations too.

My pragmatic, rather than academic, view on the data is that the time stamp doesn't reflect the exact time of the measurements, the first thing the SwiftNav code does on receiving the observations is to apply satellite clock error corrections, and then computes the clock bias for the receiver. I suspect this is larger than most receivers, and the expected range of post-processing software. The pseudo-range is also problematic because it gets disassociated from the time stamp, so instead of being an absolute time-of-travel in the receivers perspective, it now just correct in the satellite relative sense, and the time at the receiver has to be figured out to get them to a range in the more usual sense. This disassociation is also per-epoch, so it has to be constantly re-evaluated.

The estimated antenna location is also fixed and bogus. It's best dropped completely, but some of the software I use expects the Base antenna location to be valid, as it projects the Rover location from that in a relative sense.

Most consumer GPS receivers are going to be limited to 4G due to the longer integration times. The 10Hz/10G high-dynamic receiver I have, has a significantly shorter integration time, so the signal doesn't wing out the end of the correlator's window, but this tends to degrade the CNo numbers. The simulator says it can get to 20G but I suspect other physical effects on the crystal, et al, would place a lower ceiling on it.

[Simon Treny]

Thanks Clive for your detailed reply!

I was able to feed negated phase measurements to RTKLib and the results are a lot better: all the positions are either float (95%) or fixed (5%).

The accuracy is not that good though, positions are in a 2 meter radius circle as you can see in the plot below:

Do you think we could achieve better accuracy by cancelling out the clock error corrections that are applied by Piksi's firmware?

Here are my findings. The RINEX 2.11 format specifies that:

- Time of week should be the receiver time of the measurement, so satellite clock offset should not be applied

- Pseudorange is defined as : PR = distance + c * (receiver clock offset - satellite clock offset + other biases)

After taking a look at Piksi source-code (libswiftnav/src/track.c), I've found the following lines that could make observations not "RINEX compliant":

• track.c:801 : nav_meas[i]->raw_pseudorange = (min_TOF - TOTs[i])*GPS_C + GPS_NOMINAL_RANGE;
  
• raw_pseudorange does not contain satellite clock correction while it should (raw_pseudorange is used in the SBP format, not pseudorange)
• track.c:807 : nav_meas[i]->tot.tow -= clock_err[i];
• tow contains satellite clock correction while it should not according to RINEX specs

Is there anything else I have missed?

@Fergus You mentioned subtle differences that make RINEX produced by the Piksi console not compatible with RTKLib. Were you thinking about this or did you have anything else in mind?

Cheers,

Simon

[Simon Treny]

Hi all,

I modified the firmware to try to output directly RTKLib-compatible observations (as detailed in my previous post) but now RTKLib is not even able to output Single solutions from the RINEX files so I guess GNSS is a bit more subtle that what I initially thought ;)

I would really appreciate if Fergus, Clive or someone else could give me more details about what make Piksi-made observations not 100% compatible with RTKLib. Negating the carrier-phase measurements definitely helped but during all my tests, I was never able to get durable fixed positions. Also, even while stationary, the positions always seemed to drift away with time, as you can see in the following plot (stationary for 30 min, with a Novatel GPS-701-GG antenna).

Cheers,

Simon Treny

BeTomorrow

[Michael Oborne]

Simon, have a look at my app here

https://github.com/meee1/piksi/commits/master

using this you should be able to feed in sbp, and output rtcm to rtklib that will accept. there is still issues, but may help.

The issue i believe is around rx clock drift. carrier phase has the clock drift, however because the pseudo-range is relative to each other, the rx clock drift is indeterminate. The pseduo-range clock drift can be calced from the pvt, and this is what my app is doing, adding the pvt rx bias to the raw pseudo-range output by the piksi. There hoeever is still some factor that i am not correcting for that give a small constant offset.

ie 

pr delta should equal cp delta. (give or take sign.)

however there is still a constant shift in these values at the moment that i cant track down.

Michael