A first look at the u-blox ZED-F9T dual frequency receiver

Back in November last year, I wrote a post on my first experiments with a dual frequency u-blox F9P  based receiver.  At the time it was quite difficult for those without good connections to u-blox to get a hold of the F9P and even now, nearly three months later, it still is not readily available.  Ardusimple, the lowest price provider of F9P receivers still has all their receivers on back order till next month and low cost dual frequency antennas are even harder to get.  Hopefully all that will change fairly soon though.

Meanwhile, thanks to “clive1” and “cynfab” from the u-blox forum, I have been lucky enough to have been given a prototype receiver based on the dual frequency u-blox F9T, the next product from u-blox in the Generation 9 series.  Like the previous generation M8T, this is intended for timing uses and does not include an internal RTK engine.  Otherwise I believe the F9T hardware is nearly identical to the F9P.  In theory it should be less expensive than the F9P, just as the M8T is less expensive than the M8P but meaningful pricing is not yet available.

In many of my posts, I have focused on post-processing short baseline data sets using a local base station and identical receivers for base and rover.  For this particular  combination, I have shown that the differences between a single frequency solution and a dual frequency solution are typically fairly small.  This assumes that the single frequency solution includes Galileo and possibly SBAS while the dual-frequency solution includes only GPS and Glonass.  This makes the total number of observations fairly similar between the two cases.   At least until very recently this has been a reasonable assumption given that most existing CORS or other reference base stations and reasonably priced dual frequency receivers offered only GPS and Glonass.  It’s also true that time to first fix is longer in the single frequency solutions but post-processing with a combined solution generally eliminates the need for a fast fix.

However there are many other cases where there are definite advantages to using a dual frequency solution.  In particular the most important advantages occur for:

  • Longer baselines where linear combinations of L1 and L2 can cancel ionospheric errors
  • Use of an existing CORS or other reference base station which typically has only GPS and Glonass and hence is not an ideal match-up with a single frequency receiver using additional constellations
  • Real-time solutions where time to first fix is more critical
  • PPP (Precise Point Positioning) solutions for the same reasons as the long baseline cases.

So for my initial experiments with the F9T I focused on including some of these conditions.  In particular I ran two experiments, the first a real-time RTK solution with an existing UNAVCO reference base (P041) located 17 km away.  For the second experiment I compared an online PPP solution from the Canadian Spatial Reference System (CSRS) with an RTKLIB SSR based PPP solution.

For the first experiment, I connected the F9T receiver to the dual frequency antenna on my roof and ran a quick five minute RTKLIB real-time solution against the UNAVCO base station using the demo5 b31 RTKLIB code.  Other than changing the frequency mode from L1 to L1+L2 I used the exact same configuration file I normally use for the u-blox M8T single frequency receiver.  Even though the rover was stationary in this case, I ran the solution as kinematic for better visibility to any variation in the solution.  Here’s the result.


Overall the solution looked excellent.  First fix occurred within a few seconds, fix rate was 100% after first fix, horizontal variation was  roughly +/-0.5 cm and vertical variation was roughly +/-1 cm.

The solution residuals, both pseudorange and carrier-phase also looked very clean.


I only made a brief look at the raw observations but did not see anything unusual there either.  At only five minutes of data, it is not much more than a quick sanity check, but so far, so good.

For the second experiment I collected four hours of raw observations, again with the F9T receiver and my rooftop antenna, a ComNav AT330.  I then submitted this data to CSRS for their online PPP solution as well as running an RTKLIB SSR solution as I described in this post.  Below are the results for both solutions.  The plots are all relative to my best estimate of the location of the rooftop antenna based on previous PPP solutions with Swift and ComNav receivers as well as RTK solutions from nearby CORS stations.  The left plots shows the first hour of solution with a +/-0.25 meter vertical scale.  The right plot shows the second through fourth hours with a +/-0.06 meter vertical scale.


Both solutions get to below 6 cm of error in each axis after 1 hour and below 3 cm of error after four hours.  The CSRS solution gets down to almost zero error in all three axes after four hours but I don’t believe my reference is this accurate so I think this was partially luck.  The reported accuracies (95%) for the CSRS solution were 1 cm, 4 cm, and 5 cm for latitude, longitude, and height respectively.  My previous experience running RTKLIB SSR PPP solutions with other low cost dual frequency receivers is that after running many solutions, they generally all fall within +/-6 cm accuracies in all axes after four hours.  Both solutions include only GPS and Glonass observations because both the SSR correction stream I used from the CLK93 source, and the CSRS online PPP algorithm use only GPS and Glonass.

Being able to run accurate PPP static solutions can be a big advantage since it can make it much simpler to precisely locate a base station for RTK solutions with a dynamic rover, especially in more remote areas where there may not be any nearby CORS or other reference stations to run an RTK solution against.

As always, this post is intended to be just a quick snapshot and not an extended analysis of any type, but so far I have been very impressed with both the F9P and F9T and with their compatibility with RTKLIB.




47 thoughts on “A first look at the u-blox ZED-F9T dual frequency receiver”

  1. You write “Longer baselines where linear combinations of L1 and L2 can cancel ionospheric errors”
    I’ve been looking high and low for how/when this happens and it seems that’s one of the benefits of PPP (hence the requirement to use L1/L2, not sure about L1/L5) ? It doesn’t look like any DF receivers do any real-time ionospheric cancelling ?

    Of course SBAS provides Ionosphere corrections but it’s in “DGPS mode” (corrections in meters) so I’m not sure how much accuracy improvement it provides. I’ve run hours of of logging with my USB u8 receivers with/without SBAS and can only see a slight improvement in elevation, none to speak of in horizontal accuracy.


    1. Hi Webvan. Search for “ionospheric-free combination” and you should find many references to using a combination of L1 and L2 to eliminate or at least minimize the ionospheric errors. Unfortunately, this combination of L1 and L2 does not preserve the integer properties of the bias phases so is not compatible with ambiguity resolution. You can run RTK or PPK solutions this way with RTKLIB by setting the “Iono Correction” option to “Iono-Free LC”. Be sure to turn off the ambiguity resolution options to prevent false fixes.

      In RTKLIB, the SBAS ionospheric correction options are used only in PPP mode so will not affect solutions in other modes. You can run PPP solutions however with just SBAS corrections (no precise files) so if you repeat your experiment with solution mode set to PPP you may see some improvement. The SBAS ephemeris corrections are only for GPS satellites however, so the improvements you see may be small.


      1. Thanks, will try to run a PPP solution with SBAS corrections, not sure how to log these though, will look it up.

        What I meant by my comment about “L1 and L2 can cancel ionospheric errors” is that this didn’t seem to happen in real time on L1/L2 receivers but was only done after the fact in post-processing as you describe in your reply, is that right ? RT iono corrections being implemented either via the broadcast Klobuchar model or with SBAS corrections, so L1/L2 wouldn’t have an advantage over L1 receivers in RT.


        1. Hi Web Van. SBAS corrections will be logged to the .sbs file when converting from the raw binary with RTKCONV or CONVBIN. For u-blox receivers they are encoded into the UBX-SFRB messages. You will need to include this file in the input files to use the SBAS corrections in the solution.

          L1/L2 receivers will always have an advantage over L1 only receivers for both post-processing and real-time solutions. The RTKLIB solutions don’t take advantage of wide-lane L1/L2 combinations like many dual-frequency solutions do, but will still have roughly twice as many observations to work with in the ambiguity resolution algorithm.

          Liked by 1 person

  2. Hello,
    Please advise me how to measure time to first fix of GNSS receiver using RTKLIB. I am using RTKLIB 2.4.3 b33/RTKNAVI (kinematic mode) to log raw data of ZED-F9P using different dual frequency antennas such as ANN-MB-00, JCA228… Base station is Trimbe SPS855/ZEPHYR2.
    Many thanks in advance!


    1. Hi Nangsaga. Time to first fix is not specifically listed in the solution file but you can see it by plotting the solution with RTKPLOT or, since fix status for each sample is listed in the solution file, you could derive it yourself by parsing the solution file and calculating the time from the start of the data set to the first sample with fix status.


  3. I see that the ZED-F9P does not have any timepulse accuracy specification on the datasheet. Any idea how it compares to the ZED-F9T?


    1. I’ll have to review the data my local “timenut” has for this. Long term into a PLL with mHz bandwidth most of the dithering around will be averaged out. It does also report the quantization error, so that can be factored in, I’ll review the span of that as it will provide some more insight into the underlying placement clock.

      For the NEO-M9N they quote 30ns RMS, 60ns 99%, seems overly broad for the internal clocking of the core. The slowest clock in the ZEDs would be 20ns, and the fastest 2.6ns


          1. I’m not say that. The TCXO seems to have very similar performance. The F9T provides for a Timing-Differential mode, where as the F9P does not. In my use case the short term chatter/jitter in the 1PPS is less important than its long term stability. The reporting in UBX-TIM-TP allows for the quantization error to be remediated.
            The TIMEPULSE on the F9T is placed via an internal 128 MHz clock, on the NEO-M9N it is using a 64 MHz clock, I need to review what the F9P is using.
            The F9T also offers 2x TIMEPULSE, and 2x TIMEMARK/EXTINT, as well as measurement/use of SBAS


          2. F9P for a base and F9T for rover makes more sense IMO, What’syour opinion ? I didn’t get you on Jitter in the 1PPS. Do you mean F9P could be more stable than F9T ? What’s the influence of jittering on 1PPS ?
            I think you wrote an error on ns : in datasheet, it’s written 60 / 30ns for f9P and 5 / 2.5 ns for F9T


          3. I think someone shotgunned the data sheet. In a static application the 1PPS is nowhere near that bad on the F9P, and as I posted earlier the self-reporting numbers for the placement accuracy are significantly better than the data sheet numbers. The UBX-TIM-TP reflected the computation about which clock cycle to place the TIMEPULSE/1PPS. The jitter comes from which clock cycle is picked, the closest one +/- to the desired one. It will average to where it should be, so if feeding a PLL for timing applications (TELCO/RADIO) you’ll want a bandwidth that filters it out rather than react to it. You might want to check with the “timenuts” as to the relative performance of F9T vs F9P.

            TIMEPULSE can also output a FREQUENCY signal, but these aren’t directly suitable to radio applications due to the use of an NCO to generated them. In either case you’d still want to have a GNSS disciplined oscillator to get a clean frequency source.

            If doing RTK, I’d use a pair of F9P, the F9T isn’t really tailored to RTK, both can output raw measurements in the same fashion, but only the F9T outputs/tracks SBAS satellites.


          4. I need to review what the F9P is using.
            Confirmed that the F9P also uses the 128 MHz clock for the TIMEPULSE generation circuit.


  4. Can I ask what is the differences between M9T and M9P apart the standalone correction with rtcm port? If I have to use rtklib for correction are both modules the same?


      1. Presumably we’re talking about ZED-F9P and F9T, no precision/timing modules in the M9 series have been announced. The lack of GALILEO on the M8P is mostly likely driven by computational/processing ceilings, the RTK Rover is doing close to double the work.

        The DGPS and SBAS were discarded as unhelpful to the ambiguity resolution. There is some pressure to add SBAS into the ZED-F9P, perhaps from the integrity/monitoring standpoint.

        The NEW NEO-M9N on the other hand can pull L1 GPS, GALILEO, SBAS, QZSS, GLONASS and BEIDOU concurrently, and at high rates. Will get a board to Tim shortly.

        Liked by 1 person

        1. I did get Tim some UBX-RXM-RAWX capable NEO-M9N boards, and I believe they function well with his fork of RTKLIB, the form is similar to the F9 versions, but lacking L2 obviously. They support multi-constellation L1 to 25 Hz. I have some listed on eBay for those who have interest.

          I did check the TIM-TP reporting, the NEO-M9N does not report/compute the quantization error. A flag indicating the field is invalid has also been added to the interface docs.

          A new SPG 4.03 firmware for the NEO-M9N was also delivered this week.


          1. I did receive the two modified NEO-M9N receivers from Clive and have done some brief testing to verify they work well with the demo5 RTKLIB code, very much like a single frequency version of the F9T. I hope to do more testing later, but have had to delay this for the time being due to being extremely busy with consulting work at the moment.


          2. It is strange that not all m9n can output rawx message, do you know which firmware can support the rawx message?


  5. It is my expectation that the ZED-F9T will not be the least cost way of getting raw measurements in the way it was with the need for the LEA/NEO-M8T. The F9T is targeting the timing/frequency space currently served by the M8T/M8F product lines, and will be more expensive and sold in lesser volumes than the ZED-F9P.


    1. I had similar thoughts (in this page) and Tim replied that can’t be true because Ardusimple has f9p relatively low cost, however, I later noticed that Ardusimple puts a ‘generous’ VAT cost on top to say the least so it’s not that cheap (and digikey still implies today a full eval board will be at least ~$200 (since at high volumes it’s $175 for a module).
      But, another factor that plays a role here is antenna cost. It’s not directly related to an eval board itself but for the total cost to the consumer this is not a very cheap solution because in order to get a respectable professional antenna you may need more than $100 now while for L1 you could get away with some ~$20-30 patch solutions.


      1. The ZED-F9P is targeting mass market adoption, the timing product is significantly more niche, and more needful in terms of one-up user support. The RCB-F9T is in a form factor that retro fits into expensive equipment, which is why it made more sense to build a simpler board addressing our own needs, using connectors we wanted. uBlox wants to sell the RCB-F9T by the box load, I’d hope at some point there will be an EVK, but again those will likely run $180-$250.

        Professional antennas have always cost several hundred dollars, professional survey grade geodetic stuff expect to spend thousands. Equipment on Deere and Caterpillar machines runs tens of thousands.

        In meaningful quantities the ANN-MB is below $40. With the adoption of L1/L2 in the consumer space expect eBay and Alibaba hawkers to have cheaper, less engineered solutions.


        1. I used the word “professional” very loosely there. I meant that if one followed the datasheets, can end up with a 35×35 path + ~100×100 ground plane and have a relatively low cost antenna at very high performance while for +L2 I get the impression that that is not possible since good patches start at least double the price.

          PS. I hadn’t noticed the existence of RCB-F9T thanks for mentioning. Though it seems too “spartan” and I don’t know the price.


    1. Hi Zhixi. I assume you are trying to analyze some of the data I have uploaded to the rtkexplorer.com website. My rooftop antenna is located at 40.09674999, -105.14708420, 1582.247 based on some RTK and PPP solutions I have run.


  6. Hi Tim, great to see your test of F9P and F9T. Could you tell how the F9P/T performance will differ against M8T when VRS correction service is used (for both receivers) but only GPS+GLO signals are available from VRS? I am interested mainly in scenario when used on freeway (driving). This means there only would be the dual frequency advantage for F9P/T – will this receiver recover faster to fix after a signal outage (driving under overpass etc.)? Is this the main difference since with VRS the distance to base station is minimal? My VRS provider provides new VRS base once the rover moves more than 2 km from the “original” VRS base. Thanks for your comment!


    1. Hi Kozuch. To make a very rough approximation, let’s rate the strength of the solution by the number of band/freq combinations it includes but only count the Glonass freqs as 0.75 when the receivers are unmatched due to the hardware biases. We’ll also count the SBAS satellites as 0.5 when they are available. By this very simplified score, a M8T->M8T solution in North America with L1 GPS/GLO/GAL/SBAS has a strength of 3.5. In Europe it would be 3.0 because the SBAS satellites don’t contribute to the solution. An M8T->VRS solution with L1 GPS and Glonass has a strength of 1.75 since the receivers are unmatched. An F9P->VRS solution with L1/L2 GPS and Glonass would have a strength of 3.5 since the receivers are still unmatched but now L1 and L2 are available. So, by this very crude measure, the F9P->VRS solution is twice as strong as an M8T->VRS solution but roughly equivalent to an M8T->M8T solution in North America.


      1. Without being an expert on it, I got the impression after reading some comments on the u-blox forum that the L2 frequencies do not necessarily add to a solution because they originate from the exact same satellite with the L1 signal, therefore if a satellite is very clear in view, L2 may have a small or no contribution, so it’s mainly a benefit when there is multipath mainly by buildings and other obvious obstacles.

        Correct me if I’m wrong though, this is only a rough assumption.


        1. Hi Epigramx. It’s true that the additional L2 observations have less geometric diversity than additional measurements from other satellites. However, having L1 and L2 from the same satellite allows for linear combinations of the two frequencies to cancel atmospheric errors or enable wide-lane ambiguity resolution among other things. Also, more measurements should always make ambiguity resolution easier provided that poor measurements are discarded. From a sky-view robustness perspective with moving rovers, the L1 and L2 will generally be obstructed together so L2 doesn’t help much there. Overall though, the L2 measurements should always improve the robustness of the solution and will help more as the baseline increases.

          Liked by 1 person

  7. I’ve recently been messing with my ArduSimple with an F9P and with 4 hours of static data sent to OPUS in the US my accuracy is listed as:

      LAT:   XX XX 29.09033      0.009(m)        XX XX 29.12158      0.009(m)
    E LON:  XX XX 29.46314      0.006(m)       XX XX 29.44018      0.006(m)
    W LON:   XX XX 30.53686      0.006(m)       XX XX 30.55982      0.006(m)

    EL HGT: 110.435(m) 0.030(m) 109.151(m) 0.030(m)

    which is pretty incredible! I note however that it does make a difference what the weather is. This was on a sunny day with no clouds. I still haven’t been able to get my m8p running RTK with anything other than float with the source from the F9P but I need to look at that. Any suggestions would be appreciated. I think having houses and trees near the ground unit really messes it up with multi-path. I had no idea it was so sensitive there.


  8. Hello
    How to setting RTKnavi for logging the raw data
    I try with your last version 31 as ublox type, but no snr bar coming
    Please sharing your conf file


  9. (By the way, I can’t see comments on the main page for some reason.)

    Unfortunately this receiver is not going to be low cost, or so called “frugal” because digikey lists it at more than double the price of the m8t. All is subjective of course (based on personal wealth) but for DIY projects, if we’re going to reach levels in the thousands for the hardware alone the “DIY” part starts losing a bit of its appeal since low cost is a main part of it.

    I suspect that the literal cost (manufacturing) to u-blox is very low but they milk it so to speak for a while in this generation. I will not be surprised if the next generation (10?) will have the equivalent at ~$80 like the m8t. It’s an exciting new feature to have L2 but come on u-blox, this isn’t very DIY-friendly pricing.


    1. Hi Epigramx. I’m not sure the Digikey price is very meaningful at this point, especially since the quantity available at that price is zero. Given that their price for a single F9T module is higher than the price for a complete F9P receiver from Ardusimple, I think it is likely that the F9T price will drop as it starts to become available.


      1. I’m not sure, because those sites drop the price to almost half the price of a single unit if a manufacturer buys at least 100 units or so. e.g. When we buy neo-m8ts for ~$80, digikey had sold them for ~$50 to those manufacturers. (so if I see $199 for one zed-f9t module (without the board) I suspect I’ll see a ~$199 complete board).

        PS. Sure, not a gigantic cost even in that worse case scenario, but it adds up if one needs at least 2 or 3 units, and its antennas are about double the price too.


        1. I use the same DigiKey math, 1-up pricing carries 100% margin which can be used to ballpark product pricing and that a $199 board costs £199 in the UK.

          The ArduSimple boards were priced very aggressively, where as SparkFun’s are ridiculous for basically a break-out PCB. The latter presumably to carry a lot of hand-holding level support. It is one thing to be cheap if the users are actually self-sufficient/sustaining, it is a whole other to have to read existing documentation back to people repeatedly.


          1. As I implied, I’m not sure the price they show is even the price they actually want to get in practice. It seems to automatically put a VAT per country (when you go to checkout) and the postage cost isn’t too low either (there is chance it’s mainly them trying to cover customs costs; though well, if you do get customs on top of that price, it’s not cheap at all; compare that to the ~$75 m8t boards locally or slightly higher if they bundle antennas).


      2. Addendum: You’re right, I hadn’t noticed Ardusimple’s product without the antenna. I guess they will be lower cost than I thought that I would still be cautious because the “aftermarket” of ublox in general isn’t the most transparent I’ve seen.


Leave a Reply

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

WordPress.com Logo

You are commenting using your WordPress.com 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: