Above, 5.9km baseline. Torch (UM980) shows ~14mm HPA. Facet (ZED-F9P) shows ~10mm HPA. Note, the Facet display was showing 14mm HPA. This is because SW Maps is running a different calculation based on the NMEA data. The Facet HPA never waivers. The Torch HPA does change up/down over time. Also note, I did not think to mark the exact spot I was taking so don’t compare Lat/Lon/Alt between devices - I was inches apart.
Above, 11km baseline. Torch shows ~22mm HPA, Facet continues to report 10mm. I’m not sure if I trust what the ZED is reporting WRT HPA. So for the pictures above, I made very sure my ARPs and pole lengths were accounted for. I didn’t use tilt compensation, but used a bubble to free hand the vertical so I should be measuring the pole tip, but with human added inaccuracy (slight tilts) while I took the screen shots.
Above, I converted LLA from the 11km test to ECEF and compared the RMS. We can see the two points are within 21mm of each other. I consider this pretty phenomenal. With a 11km baseline, with two completely different receivers, ARPs, and setups, we can get repeatable shots with 2cm variance.
Hello people. I’ve been watching the Facet’s behavior in terms of reporting position error and it’s almost always 14mm or so regardless of baseline length. We know that it shouldn’t be like this. In other professional teams that have it, the position error estimated by the team increases noticeably as the length of the baseline increases.
Some time ago I generated a discussion on the subject.
I commented on this in that discussion at the time.
"I have gone further with the study of precisions using Facet and went on to study the RTK positions.
I placed the Facet at a well-known fixed point and got corrections from 3 ntrip stations from my country’s ntrip network, the IGM Uruguay network.
The first ntrip station is Leica GR10 and corrects only in GPS and Glonass, it was 2 km away and I got excellent results, the screen indicated 0.014 m and indeed the position obtained was around 2 cm with normal vision conditions, not excellent.
The second station was 50 km away, it only corrects GPS and Glonass and I obtained fixed positions with results on the screen of 0.02 m but the position differed somewhat more, reaching discrepancies of 0.10 cm.
The third ntrip station is 105 km away, it is a Leica GR30 station with the 4 constellations. I obtained relatively fast fixed results with the Facet, with 0.035 m on the screen, but they are misleading, since the position difference reached 0.25 m. Other equipment from another brand was fixed in a longer time and informed me of 0.28 m of horizontal error. Very similar to the actual error obtained.
Preliminary conclusions.
a) In normal conditions and short distances to the base, less than 10 km, the results are very good and the precision reported is similar to the real results of position difference.
b) In normal conditions or less than that, with distances to the base greater than 30 km even though the Facet says fixed position and the horizontal precision values indicated on the screen are small, such as 0.014 or 0.02 m, you must be careful and take the point repeatedly.
In this situation the actual position differences were much larger than the horizontal precision reported on the screen.
P.S. I love Facet and have spent a lot of time on it, reviewing and commenting on its firmware, both here and on Github.
I would like what is reported on the screen to be more credible, in order to work calmer with respect to the data collected in the field.
I know that the reported data comes from the Zed f9p and that already depends on the company that builds it and not Sparkfun.
I appreciate you diving in! I was able to get the tilt mode to work when using SWMaps for the Bluetooth and Ntrip connection, but when using the Lefebure Ntrip Client app it is still not working. Seems like it isn’t passing the correct mock location into SWMaps or Qfield when in tilt mode. If you have any thoughts on this I would appreciate it!
I was curious how the advertised 14mm accuracy was conceived for the Facet when the Ublox datasheet indicates 0.01m. I’m interested because I know you had mentioned the 8mm for the Torch was based off of the Unicore datasheet.
Have you had a chance to see how the Facet vs Torch compare to an NGS control point? When I did this I was finding the Facet to be about 0.05 feet from the point while the Torch was 0.10 feet from the point (averaged 5 shots with both). I was approximately 13km from the base station when taking these readings. This is what caused me to dive in a bit more to the accuracy. To get the NGS points I got the shapefile and placed it in the same CRS that I was plotting the points.
Great thread… but I wanted to remind us that the Error and Accuracy Estimates are only Estimates.
Take them with a “grain of salt”.
The GNSS device doesn’t know it’s true position to calculate the Accuracy.
Here’s something easy that I like to do:
Find a good location and drive a Mag Nail in concrete or asphalt.
Use a 2M rod, a bipod or tripod, and store the point with proper field technique.
“Dump” the antenna (point it at the ground and cover it with your hand) and repeat to collect 5 points.
The 5 positions will all be slightly different (IE the inherent Precision), but determine your best fit.
Come back tomorrow and do the same thing. Tomorrows value will also be different.
I feel like this exercise gives the user a much better understanding verses the reported estimates.
To get a decent idea on Accuracy, you can easily establish your own control point w/ PPP (although it takes some time) to have confidence in the position from a Controls standpoint.
Great thread… but I wanted to remind us that the Error and Accuracy Estimates are only Estimates. Take them with a “grain of salt”. The GNSS device doesn’t know it’s true position to calculate the Accuracy.
So true. Thanks rftop!
I was curious how the advertised 14mm accuracy was conceived for the Facet when the Ublox datasheet indicates 0.01m. I’m interested because I know you had mentioned the 8mm for the Torch was based off of the Unicore datasheet.
This was me hedging because I had never see the HPA register display 10mm, only ever 14mm. Also, what’s 4mm between friends? Now I know it matters to many people.
but when using the Lefebure Ntrip Client app it is still not working. Seems like it isn’t passing the correct mock location into SWMaps or Qfield when in tilt mode. If you have any thoughts on this I would appreciate it!
Ah, that’s the problem. You’re using Lefebure to connect to the device over Bluetooth SPP to provide corrections. If that’s true, you cannot also connect an app to the RTK device over another Bluetooth connection. There’s a few ways to get this setup:
SW Maps is what we like to use. But if he wants to use QField (which doesn’t have a built-in NTRIP client) then we have to work around the single Bluetooth connection limit.
SW Maps now shows a HPA of 11mm with a 19km baseline!
Took some shots this morning. Averaged 600 shots over a 20 minute period, three times over two hours. The result was ~7mm of variance horizontally and 19mm vertically between the three points. Not bad!
@ssmcd Thank you for sharing this. I updated the Torch and UM980 firmware and it has made a world of difference. The Torch is performing incredibly well now, as you shared. I’m getting within 0.05ft of control points that I couldn’t get any better than 0.1ft before. I’ll be interested to hear your results with control points.
@sparky When using Lefebure I’m allowing it to mock location so in Qfield I just leave it to internal antenna and it picks up the mock location so as I understand I’m not trying to setup a duplicate Bluetooth connection. Thanks to the updates I have resolved all of the accuracy issues that I was running into previously. I am however still having the issue of losing position in Qfield when enabling tilt mode. It works fine up until the IMU initialization is complete. Do you have any other thoughts on what might be causing this? Is there any log information that I could share to try and determine the issue?
I do like Qfield because of the ability to use Qfield cloud and sync to QGIS easily. I’m hoping they will build NTRIP into it someday.
@rftop Thank you for sharing your methodology. I’ll definitely try that out!
Sounds like QGIS does not like the tilt-compensated NMEA data for some reason. I’ll try to replicate the issue and then capture some tilt compensated NMEA data. From there I should be able to run (and re-run) it through QGIS.
Sorry, this QField issue got lost and should be opened in a new thread. Please note that we had a reported bug and fix performed early today that may have been affecting your QField readings (https://github.com/sparkfun/SparkFun_RT … issues/334). I recommend trying the release candidate from today (June 12) and start a new thread or issue on the repo if you continue to experience problems.
I have a similar problem in that the internal NTRIP client only gets an accuracy of 33 mm horizontally and 62 mm vertically, but if I switch off the internal NTRIP and e.g. Using swmaps Ntrip correction with the same caster I get an accuracy of 10mm horizontally and 18mm vertically. Can I use any settings to improve the internal results of the NTRIP? :shock:
That sounds suspiciously like a level of accuracy from Galileo HAS (https://docs.sparkfun.com/SparkFun_RTK_ … alileo-has). How long did you wait to achieve that accuracy? If you waited 10+ minutes, that’s HAS. Are you in RTK Float when you get 33/62? If not, then that’s HAS. I suspect your internal NTRIP caster is not actually connected to the internet. Make sure that if the Torch is using WiFi to connect to NTRIP, that you are within WiFi range and/or your phone’s hot spot is on.
Have you, or can you, post a tutorial on how to do this for a complete beginner? I have been unsuccessful in setting up a Base Station to produce better than 1-2m accuracy to a known NGS Reference Point using my FACET. I have followed the SparkFun Tutorials yet still no luck. I am unfamiliar with “PPP” - there seems to be several definitions of this term so I’m not even sure what you think it means. Thanks in advance!
