Improved results with the new SwiftNav 1.4 firmware

I last took a look at the SwiftNav Piksi Multi low-cost dual-frequency receiver back in November last year when they introduced the 1.2 version of FW.  They are now up to a 1.4 version of firmware so I thought it was time to take another look.  The most significant improvement in this release is the addition of GLONASS ambiguity resolution to the internal RTK solutions but they also have made some improvements in the quality of the raw observations.

I started with a quick spin around the neighborhood on my usual test route.  The initial results looked quite good, so for the next test I expanded my route to include a drive to and around Boulder, Colorado, a small nearby city of just over 100,000.  The route included some new challenges including underpasses, urban canyons, higher velocities, and even a pass underneath a parking structure.  This is the first time I have expanded the driving test outside my local neighborhood.

My test configuration was similar to previous tests.  I used a ComNav  AT330  antenna on my house roof for the base station, and a SwiftNav GPS-500 antenna on top of my car for the rover. I split the antenna signals and in both cases, fed one side to a Piksi receiver and the other side to a  to a u-blox M8T single frequency receiver.   I ran an internal real-time RTK solution on the Piksi rover and an RTKNAVI RTK real-time solution on the M8T rover.  The M8T receivers ran a four constellation single frequency solution (GPS/GLONASS/Galileo/SBAS) to act as a baseline while the Piksi receivers ran a two constellation (GPS/GLONASS) dual frequency solution.  Both rovers were running at a 5 Hz sample rate and both bases were running at a 1 Hz sample rate.  The distance between rover and base varied from 0 to just over 13 km.  The photos below show different parts of the route.


Here are the real-time solutions for the two receiver pairs, internal Swift on the left, and RTKNAVI M8T on the right.


Both solutions had similar fix rates (79.9% for Swift, 82.6% for M8T) and in both cases the float sections occurred for the most part either in the older neighborhood with larger trees (top middle) of after underpasses (bottom left).  The higher velocity (100 km/hour) on the highway (center) did not cause any trouble for either solution.

Based on a comparison of the two solutions, accuracy was relatively good for the fix sections of both solutions.  Below on the left, is the difference between both solutions for points where both solutions had a fix.  In the center and right are plots of both solutions (Swift internal=green,M8T RTKNAVI=blue) for the two locations with the longest duration discrepancies of any magnitude.  Both look like false fixes by the Swift internal solution, based on the discontinuities.  Overall, though the errors between the two were reasonably small and of short duration.


Post-processing the Swift data with RTKLIB produced the solution on the left below with an 85.5% fix rate and a good match to the M8T solution.  The difference between both solutions for the fixed point is shown on the right.  This solution was run with continuous ambiguity resolution.



For more challenging environments like this I often add some tracking gain to the ambiguities by enabling “fix-and-hold” for the ambiguity resolution mode but setting the variance  of the feedback (input parameter pos2-varholdamb) to a fairly large number (0.1 or 1.0) to effectively de-weight the feedback and keep the tracking gain low.  For comparison, the default variance for fix-and-hold mode feedback is 0.001 which results in quite a high tracking gain.  I find that with the low tracking gain, I generally do not have an issue with fix-and-hold locking on to false fixes.

Running RTKLIB solutions for Swift and M8T with this change (fix-and-hold AR enabled, pos2-varholdamb=1.0) improved the fix ratio for the Swift RTKLIB solution from 85.5% to 91.1% and the M8T RTKLIB solution from 82.6% to 92.6% with no apparent degradation in accuracy.

Using a combined solution instead of a forward solution (only a choice for post-processing) improved the fix ratios even further, again with no apparent degradation in accuracy.  The Swift RKLIB solution increased to a 96.2% fix rate and the M8T RTKLIB solution increased to 94.1%.

Overall, the Swift RTKLIB solutions were noticeably better and more consistent than in my previous test.  Considering the difficulty of the environment, I consider all of these solutions to be very good.

In my next post, I will look specifically at how the two receivers handled going through a narrow urban canyon, underneath three underpasses and underneath a parking structure.


11 thoughts on “Improved results with the new SwiftNav 1.4 firmware”

  1. Hi Tim,

    the Piksi Multi firmware 2.0 is out since August 21st bringing full Galileo and Beidou support. Are you planning to do an evaluation of it? Maybe comparing the internal solution to RTKLIB’s one? Maybe also comparing it to M8T?


    1. Hi Kozuch. Yes, and now they have released the 2.1.14 code as well. I have not tried the very latest code but I have tested the 2.0 code and got very good results with it. I have also tested the u-blox F9P recently which also performed well, and in fact I have found the two very comparable, especially when looking at just the raw observations. I hope to post some testing for both these receivers in the fairly near future.


      1. Hi Tim, I am really looking forward to your tests! There is a lot going on in the RTK market these days and it is very exciting to watch it.


      2. PS. It is pity that SwiftNav does not seem to be rolling out a true consumer-grade end product with their Starling positioning engine and will probably only focus on very big customers.


  2. Reading the post again in full detail. It is really funny that the post-processed Swift solution is better than their internal solution (fix on 85.5% vs 79.9%) given that RTKLIB does not take advantage of the L1 vs L2 linear combinations which Swift internal solution is believed to do (maybe it does not after all?). I do not know what the linear combinations are exactly good for though (faster startup only?).

    Personally I thought Swift will perform better with dual frequency even with fewer constellations. Obviously not the case. I am surprised how relatively simple RTKLIB tweaks can make results much better.

    I have a side question – I am trying to push real world tests to the limits – want to try long distance trips by car (using RTK for ADAS – lane departure warning on highways). Obviously one has to use either multiple CORS/UNAVCO base station or some RTK correction service (Swift newly launched their Skylark service for $50/month in 5 selected US areas) when traveling 10s of miles. No GLONASS AR for non-matching receivers with RTKLIB is a problem to me here so I am looking at the NEO-M8P which accepts RTCM message 1230 for GLONASS AR from CORS. However people had very varying experience with this receiver for example on the Drotek forums:

    Also a guy “reviewed” M8P but without ground planes on GARMIN antennas (I have doubts about their quality) and he had time to fist fix of about 30 minutes which is not really standard (ublox forum users report few minutes usually). I suspect the missing ground planes may play a role at that test:

    Do you think M8P is worth trying? I mean there is nothing better in the price range anyways… I can only see the NavSpark S2525F8-GL-RTK ($80 module, $130-220 eval kit depending on output frequency) but I fear that manufacturer a bit, they do not seem to be very active since some time. NavSpark info is here: I can not see the RTCM 1230 message in their docs (neither 1033) so I wonder whether they even support non-matching base station. I will ask in their forums.


    1. It is not surprise to see the post-process result is better than the real-time result. Tim didn’t mention but I can guess he use a combined mode with is combined forward and backward processing (to my experience, backward is always(?correct me if wrong) better than forward). I think the benefit of dual frequency Swift receiver is when RTK is not available but LSE solution coming up. At that case, Swift should much better than M8T. I just find out Swift’s skylark service is only for Swift’s receiver (sad), but I can guess they may still using NTRIP protocol internally.


      1. Hi Dan. I included results for both forward and combined modes for both Swift and M8T receivers but only compared combined results to combined results and forward results to forward results. It is true that if an RTK solution is not available because of lack of a base station and a PPP solution is run instead, then the dual frequency measurements of the Swift will give it a significant advantage over the M8T.


    2. Hi Kozuch. I have no experience with the u-blox M8P so can’t really comment on it other than to say it uses the same hardware as the M8T so the raw observations should be the same.


  3. Tim,
    Great! really like the real world test. Is Swift’s fix initial Fix time is much shorter than M8T. I saw Swift start with green and M8T start with yellow. What percentage of GPS sat in your solution? Do you have those information. Any beidou sat has been used in your solution? RTKLIB has good performance and flexible. Have you run it over a long period of time? like over 24 hours.
    Your post is great. Waiting your next test. I bet next test M8T result is much better than Swift because of sat diversity


  4. Dear Tim,

    thanks for listening to my testing ideas, I am really interested in such real workd scenarios. Great post again. I am thrilled how the M8T still keeps up with much more expensive Piksi. May I ask you to list the data for download? Looking forward to the continuation :).

    I have still a project in my head for a “high definition OpenStreetMap” so this stuff is of great interest to me.


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

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

%d bloggers like this: