Comparison of Swift Piksi Multi to u-blox M8T

 

I recently described an experiment in which I mounted a Tersus BX306 receiver and a u-blox M8T receiver on top of a car and collected simultaneous data while driving around in a parking lot and on residential streets.

In this post I will describe a similar experiment, this time with a Swift Piksi Multi receiver and a u-blox M8T receiver.  In the previous experiment, I had to use a CORS reference station as the base station for the Tersus receiver since I did not have a second full L2 receiver to use as a local base.  I do have two Swift receivers however, so in this experiment I was able to use matched local bases for both rover receivers.  The base receivers were both connected through an antenna splitter to a single dual frequency GPS500 antenna that comes in the Piksi evaluation kit and that was mounted on the roof of my house.

The two rover antennas were both mounted on top of my car.  The Piksi was using a Tallysman 3872 dual frequency antenna and the u-blox M8T was using a Tallysman 1421 antenna, the same antennas I used in the previous Tersus/u-blox experiment.

Here are the raw observations for both rovers, M8T on the left, and Piksi on the right.  Green indicates dual frequency measurements, yellow just a single frequency.  The red ticks indicate cycle slips.  The relatively slip-free region in the middle was collected in the parking lot with very open sky views.  The data before and after this region was collected on the residential streets with more obstructed views and hence more cycle slips.

u-blox M8T                                                                         Swift Piksi

swift_m8t2

As I mentioned before in my earlier description of the Piksi receiver, it uses the new civilian L2C code rather than the standard L2 code for the L2 measurements.  This code is only available on the newer satellites, right now about half of them support it.  Also, the Piksi firmware currently supports only the GPS satellites.  In this particular data set, four of the six GPS satellites were broadcasting L2C codes which meant the Piksi is working with ten measurements from six different satellites.  The M8T, on the other hand, with GPS, GLONASS, SBAS, and Galileo enabled had 19 measurements from 19 different satellites.  In both cases, since they were matched receivers, all measurements were available for ambiguity resolution.

Like the Tersus receiver, the Swift Piksi can only process solutions real-time, it has no capability to post-process data.   I configured the Piksi receiver to save the raw measurements to a USB drive on the receiver and to save the real-time solution in NMEA format to a PC connected to the rover over the serial port.  I set up NTRIP servers for the base stations  and used a hot spot on my cell phone for the real-time data link between receivers as I described in this post.  I then compared the Swift real-time solution to RTKLIB post-processed solutions of the Swift measurements and the u-blox measurements.  I also did run the u-blox solution in real-time and believe it was nearly identical to the post-processed solution I show here but unfortunately I overwrote the solution file with a post-process run so wasn’t able to compare them directly.  I did verify that the real-time u-blox solution had nearly 100% fix before I lost it.  I also tried to re-run a simulated real-time solution with RTKNAVI using the time-tag files but unfortunately it looks like some of the recent changes ported in from the release code have broken this capability.  I need to look into this further but it looks like while attempting to fix some existing incompatibilities in the tag files between the 32 bit and 64 bit versions of RTKLIB, the 32 bit version was broken.  In theory, the real-time solution and the post-processed solutions should be nearly identical, the only difference being the slight delay of the base data over the cell-phone link, so I don’t expect this to have a significant affect on the results.

Given that the M8T has nearly twice as many measurements to work with as the Piksi, I would expect the M8T results to be better than the Piksi and that indeed is the case.  The Swift internal RTK solution did a good job when the car was in the parking lot with nearly unobstructed views as you seen in the middle plot where the zigzag section is all fixed (green).  On the residential streets, the solution bounces back and forth between fix and float.  It is interesting that when the internal solution reverts to a float solution, it becomes quite noisy relative to the RTKLIB float solution as you can see in the z-axis.  The RTKLIB solution for the Piksi data is not as good as the internal Swift solution.  This may be a combination of an imperfect match of cycle-slip definitions between Swift and RTKLIB and RTKLIB not taking full advantage of the dual-frequency measurements.

swift_m8t3

I don’t think there were any real surprises here.  Until the Piksi receiver adds firmware support for the other satellite constellations and until more GPS satellites support the L2C codes, the Swift receiver is going to have difficulty matching the results of receivers with more measurements.  In the long-term, the L2C code is a good choice, especially for moving rovers because it is a stronger signal and a more robust code than using the encrypted L2 code, but in the short term I’m not sure I would recommend this receiver, at least for this sort of application.  It is still the least expensive dual frequency receiver available as far as I know, so it may still be the right choice for other applications.

Like my previous comparison, this was all based on a single set of data and is not intended to be a comprehensive analysis, more of a first impression.  If anyone disagrees with any of this or can add more details, please respond in the comment section below.

If anybody would like to compare the data themselves, I have uploaded the data and the config files I used to process the data to the “Sample Data Set” section of my website.

11 thoughts on “Comparison of Swift Piksi Multi to u-blox M8T”

  1. I just found your site today and your tests are simply great! Keep up the good work!

    I would like to start community high definition mapping project (say an HD version of OpenStreetMap) so I really appreciate any real world urban scenario tests of affordable RTK gear.

    Today partial GLONASS support was added to Piksi Multi via firmware release 1.2. GLONASS integer ambiguities are not resolved but float is possible and also raw G1/G2 measurements for PPK. What do you think about the new firmware? Would you mind running some real world (urban driving scenario) tests again? That would be great! The update news is here: http://downloads.swiftnav.com/piksi_multi/firmware/v1.2.14_2017-10-26/PiksiMulti-v1.2.14-ReleaseNotes.pdf

    I am looking to spend some $$$ on another RTK gear myself, so far I have two M8T receivers and ran just a quick RTKLIB test myslef (and got fix solution in the fields but not in urban space) but I dont have the resources to deal with RTKLIB so I like end-to-end RTK solutions like Emlid Reach, NEO-M8P or Navspark HS-HP because of possible ease of use but I have not got any of those yet.

    Hope to hear from you!

    Regards,
    Jan

    Like

    1. Hi Jan. Thanks for the heads up on the new Piksi firmware. I should be able to give it a try in the next week or two and post how it goes. I would describe my test environments as more “suburban” rather than “urban”. True urban environments are very challenging for low cost RTK/PPK so I’m not surprised you had trouble there. By the way, the Emlid Reach units use RTKLIB for their RTK solutions and have incorporated many of my improvements into their code so they are a good choice if you want the flexibility of RTKLIB in a more end-to-end solution.

      Like

      1. Hello again,

        I have one more question – did your M8T have the 3.01 Galileo-ready firmware from factory or did you update it yourself with the free SPG firmware? I have a pair of pretty old (December 2015) NEO-M8Ts and just realized few people confirm online that they flashed the units with the free SPG firmware and are still getting raw messages (including Galileo). I messaged the user MichaelEFlip from Emlid forum about the update rate with SPG, but have not yet a reply.

        That user reported success in raw Galileo here:
        https://community.emlid.com/t/galileo-m8t-firmware-is-now-available/2543/20

        The user clive1 on ublox forum also confirmed raw after update:
        https://forum.u-blox.com/index.php?qa=3329&qa_1=what-actual-firmware-version-lea-m8t-the-european-online-shop&show=14708#c14708

        So I am just about to flash the SPG (namely UBX_M8_301_SPG.911f2b77b649eb90f4be14ce56717b49.bin downloaded today from ublox) to my units but verification on possible update rates would be nice.

        Like

        1. Hi Jan. I don’t have any experience with the free SPG firmware on the M8T but if Clive says it works, I would believe him. I have found him to be very knowledgeable on the u-blox receivers.

          Like

      2. PS. The official 3.01 “timing grade” fw for M8T will most likely not be released publicly (only via certain support channels) by ublox that is why I am mad about the free SPG fw, but you know probably :).

        Like

  2. Where the Piksi already could score are somwhat lonegr static observations with longer baseline…. as the two frequencies could help to reduce error from ionospheric delays

    Like

    1. Hi Johannes. Yes, the dual frequency measurements will definitely provide more advantage as the baseline increases, especially in static measurements where management of cycle slips is less important. This is true of the RTK solutions and even more true of PPP solutions.

      Like

  3. Does RTKLIB support frequency linear combination? If so, PiKsi can have more measurements to 19 or more. PiKsi maybe win. I am not sure the linear combination is totally independent or not. Please advice

    Like

    1. Hi Dan. Linear combinations of the existing measurements will not be independent. Still I believe there is opportunity to take better advantage of the linear combinations than RTKLIB presently does, particularly in the area of partial ambiguity resolution. However, as a couple of readers have pointed out, the LAMBDA ambiguity resolution algorithm that RTKLIB uses will inherently find optimal linear combinations of the total ambiguity set, so to some extent, this is already built in.

      Like

  4. Nice and interesting results!
    Just one quick question. Did you have the Piksi collecting raw data at 20Hz vs. M8T at 5Hz?

    Like

Leave a reply to Jan Kucera (Kozuch) Cancel reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.