Sub-meter GNSS accuracy with standard precision solutions? – a look at the Allystar 1201

Being able to get centimeter level errors with RTK or PPK solutions is a very powerful technique, but it does involve a certain amount of complexity and lack of robustness in more challenging conditions. In many cases, users don’t need quite this much accuracy and are looking for a simpler, more robust solution. In a recent post, I demonstrated that a u-blox F9P receiver can achieve sub-meter accuracy with it’s standard precision solution for static measurements and even better accuracy for dynamic measurements. This is a good choice for users who are primarily interested in a RTK/PPK solution but would like the standard precision solution as a backup. It is a relatively expensive solution however for those looking for just a standard precision solution. The Allystar 1201 dual-frequency GNSS module recently caught my eye as a possible answer for a lower cost option. It advertises sub-meter CEP standard precision solution and is available for only $35 on an EVK board or $13.50 for just the bare module in quantities of 10.

It does not have an internal RTK engine or provide access to the raw observations like the u-blox F9P does. This means that it can not be used for anything other than standard precision solutions, but if that is not a requirement, then this could be quite an attractive alternative to the F9P.

Here are the GNSS signals received and the accuracy spec for the Tau1201

Specs from Allystar 1201 datasheet

For comparison, here is the equivalent specs for the u-blox F9P

Specs from u-blox F9P datasheet

As you can see, the Tau1201 claims <1 meter CEP while the F9P claims 1.0 meter CEP. CEP stands for Circular Error Probability and is defined as the radius of a circle centered on the true value that contains 50% of the actual GNSS measurements. In other words, one half of the measurements should have an accuracy better than or equal to the CEP. Real-world performance will vary depending on atmospheric conditions, GNSS antenna, multipath conditions, satellite visibility and geometry. Neither spec lists specific test conditions but generally the specs assume good visibility, low multipath, nominal atmospheric conditions, and a reasonably high quality antenna.

I was curious to see how these two receivers compared in a real-world test so I ordered a Tau1201 EVK board from Digikey and collected some data. I ran for 24 hours with both receivers connected through an antenna splitter to a Harxon GPS500 survey grade antenna on the roof of my house. I configured both receivers to use all available constellations and output the internal solution with NMEA GGA messages.

Here are the resulting ground track plots for both receivers, u-blox F9P on the left, and the Allystar Tau1201 on the right. They are plotted with RTKPLOT and have statistics enabled from the options menu. I also set the coordinate origin in the options menu to the precise location of the antenna in WGS84 coordinates.

Ground tracks for 24 hours for the F9P and Tau1201

Here are the positions plotted versus time.

Position vs time for 24 hours for the F9P and Tau1201

The statistics may be difficult to read in the above plots, so I’ve copied them below.

u-blox F9P plot statistics
Allystar Tau1201 plot statistics

The standard deviations (STD) include only the measurement noise. The root-mean-squares (RMS) include both measurement noise and bias, so are the more relevant statistic in this case. We can combine the East and North measurements using the square root of the sum of the squares to get the horizontal RMS values (sometimes called 2drms). This gives us a value of 0.38 meters for the F9P and a value of 0.96 for the Tau1201. It is not possible to calculate the exact CEP metrics directly from the RMS values but we can estimate them assuming gaussian distributions and circular distributions. Neither of these assumptions is entirely true, but the estimate should still be reasonably accurate. Using a conversion factor of 1.19 derived in this article from GPS World, we get estimated CEP values of 0.32 for the F9P and 0.81 for the Tau1201.

In this test, both receivers achieved their advertised spec for CEP. Obviously, though, the more expensive F9P receiver outperformed the lower cost Tau1201. Exact results will vary based on some of the factor mentioned earlier (visibility, multi-path, atmospheric conditions, etc) but I would expect the relative differences between the two receivers to be fairly consistent.

These are for static measurements. The CEP values for dynamic measurements would be noticeably smaller due to the averaging out of the multipath errors as I demonstrated in the post referenced above.

Another interesting difference between the two measurements is the position errors averaged over 24 hours. The F9P average errors were less than 10 cm in both horizontal axes while the Tau1201 was small in the east direction, but was relatively large in the north direction at 63 cm. It’s hard to say from one measurement how consistent this difference would be over multiple measurements, but if it did hold up, then averaging the measurements over time to reduce the errors would be much more effective with the F9P than it would be with the Tau1201

In order to focus on the performance of the receiver, I used a relatively expensive antenna for this experiment, at least compared to the cost of the Tau1201. Although I did not repeat the test with any lower cost antennas, I would not expect significantly different results with any antenna intended for dual-frequency RTK solutions such as those from Ardusimple or DataGNSS, provided they are used with the appropriate ground plane. Even lower cost antennas, as long as they are intended for dual-frequency use, might work as well, but would require more testing and would probably have a larger effect on the results. If anybody has run a similar experiment with very low cost antennas and would like to share their results, please leave a comment below.

So, to summarize, the Tau1201 receiver is not able to match the performance of the F9P, but it is significantly less expensive, does achieve sub-meter accuracy, and combined with a low cost antenna, could be a good choice for some applications.

14 thoughts on “Sub-meter GNSS accuracy with standard precision solutions? – a look at the Allystar 1201”

  1. Hello, good morning, I find the article very interesting regarding the medicine and comparison of the ALLYSTAR TAU1301 model but at this time today they launched this new product reference which indicates to be compatible with RTK, it would be interesting to see if this new reference if it can present better performance “ALLYSTAR TAU1312 RTK”

    Like

  2. Hola buenos dias, me parece muy interesante el articulo con respecto a la medicion y comparacion del modelo ALLYSTAR TAU1301 pero en estos momentos al dia de hoy ellos lanzaron esta nueva referencia de producto la cual indica ser compatible con RTK, seria interesante ver si esa nueva referencia si puede presentar unmejor desempeno “ALLYSTAR TAU1312 RTK”

    Like

  3. Hello, I bought an Allystar 1201 module and encountered a problem: it is impossible to enable SBAS! When you press and save, the SBAS flag disappears! And I really wanted to test the DGNSS (Green) mode!! The documentation indicates that there is SBAS support! Does anyone know what’s wrong???
    My video on YouTube: https://youtu.be/CAZuR0MPcHA

    Liked by 1 person

  4. Hi, I bought a Samsung S21 Ultra 5G because of its dual frequency GPS inside. I was able to verified that I am getting the L1,L5 and E1,E5a signals using GPStest. Ideally, I am looking for a reference for setting up my internal GPS to GeoTag photos taken with the internal 103 Mpix cammera with RTK or PPP solutions into the EXIF of the images I take for photogrammetry? I would settle for logging RTK or PPP precision solutions from my internal GPS chip at a high sampling rate to post process into my photogrammetry workflow. I have not been able to work my way through this use case with any kind of success because of lapses in my detailed understanding of all the technologies involved. Surely, somebody out there has doe this. I just need some help replicating their process.

    Like

    1. Hi Ranald. At this point in time, using precision GNSS (RTK or PPP) with cell phones for any practical application probably does not make sense because the internal phone GNSS antennas are not yet capable enough. You will have much better results with a u-blox M8T or F9P receiver.

      Like

      1. I am confused. Can I use rtklib with L1/L5 to achieve centimeterish accuracy provided I configured a basestation that has an L1/L5 gps to provide correction data (which I assume I can use rtklib for that) the closest correction service is 15miles and only provides L1/L2. provided I can get raw data from the L1/L5 gps module? or is there something I am missing or simply not understanding?

        I want a precision rover, but rtk receiver modules are well out of my budget especially for this project. I have seen almost nothing on getting centimeter accuracy using L1/L5, but yet if you use L1 alone you can achieve it provided you get the raw data.

        Like

        1. Yes, you can get centimeter accuracy from an RTK solution with L1/L5 assuming you have a base station that provides L1/L5. In fact the L5 signals are superior to the L2 signals so in general the L1/L5 solutions will be more robust than the L1/L2 solutions. However, it is currently difficult to find low cost L1/L5 receivers that provide raw observations, other than in smartphones. The smartphone antennas are very poor though so do not make a good platform for RKT solutions.

          Like

  5. Hi, im searching for a gnss modules for my application, a imu-gnss sensor fusion, and i have found from the datasheet that the TAU1201 actually delivers raw data, but you have said that it doesn’t deliver, so i’m in doubt about who is right, since the datasheet just mention this information in one small place at the beginning of it.

    Like

    1. Hi Bruno. Reviewing the module descriptions for all of the Allystar GNSS modules on their website, only the TAU1302 is listed as supporting raw observations. However, as you mention, there is a note on the TAU1201 datasheet mentioning that raw observations are available with custom firmware. I assume you would need to communicate directly with Allystar to obtain this version of firmware.

      Like

      1. So, I saw this in their technical data as well. I reached out to inquire about any firmware that would allow for raw data. Allystar forwarded the message to their distributor, gnss.store, who politely informed me that no such firmware had been made, and there were no plans to develop one unless it was for someone who wanted to place a sizeable order.

        I’m curious though, is this a feature that can be enabled in sat-tracker (the Allystar equivalent of UCenter).

        So basically it’s possible but not according to anyone I spoke to.

        Like

  6. I did a similar 24 hour test with a F9P receiver and a Ublox ANN-MB antenna on a 10 cm diameter ground plane. It was mounted on a survey pole in a good, but not perfect GNSS receiving area. No big surprises. The performance was similar to your experiment.

    I used the true position coordinates calculated later from the carrier phase data to look at the actual error of the internally computed position every 5 seconds. 98.6% of the positions had a horizontal error of less than one meter. The 50% horizontal error level was 0.38 meters, the 95% level was 0.84 meters, and the maximum error was 1.78 meters.

    The average solution was biased about 24 cm to the north and 2 cm to the east.

    The vertical accuracy wasn’t quite as good. The 50% accuracy level was 1.1 meters, the 95% level 2.2 meters, and the maximum error was 4 meters. There was a average upward bias of 1.2 meters. Most of the computed positions were above the true height. It seems that was also the case with your F9P test while the other receiver wasn’t as biased.

    Like

Leave a comment

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