As mentioned above, the base has a groundplane, and the rover is mounted on a thin plastic canopy, which has copper shielding inside, which to my understanding should act as a ground plane then.
Additionally, I have not noticed EKF issues - I am plenty “green” there, with low values, a good compass calibration as well as good Compass Motor Calibration.
Also, as outlined, I am acquiring the precise location (using NTRIP), and then am using this static position in MP.
Trouble is, as mentioned above, for my application I cannot operate with post-processing.
Additionally, I need to fly low to the ground.
How have you configured your base and rover? Would you be willing to share the config files for your Here+ modules (exported from u-center)?
When using a L1/L2 base stations from Septentrio, I can get a fix in well under 20 secs. My NTRIP provider (geared towards state surveying) has a high density of stations and notes that with the augmentation of VRS the baselines in effect are very minimal and able to achieve very high accuracy throughout the territory covered.
I do see a reference in their docs to making use of NMEA 0183 GGA/ bidirectional communication, if that info is of any help.
Gladly. Except that this is likely something the manufacturer will need to work out directly with u-blox, as I can’t see getting a direct response from them for a firmware update.
@mtnsurveyor thanks for running these tests and sharing the result.
I will try to reproduce this in u-center - but am reliant on @philip to have this implemented in the firmware, so that it can be used in the Mission Planner/ Ardupilot universe.
What is the “s&r mask”? Where do I find that? Do you mean the dbHz value in C/NO Threshold?
These settings also have to be changed on the rover, correct?
@Leon_Dwyer thanks for pitching in.
For my accuracy needs, I seem to observe a considerable drop from fix to float in terms of a steady position. Plus being higher in the air is not a viable option for my application, nor are GCPs, as I cannot use PPK.
I mentioned the post processing because it is the same in terms of getting accurate results. The 12 minutes + 2 minutes per KM is a formula from Ashtec tech support many years ago. It applies to L1 kinematic fixes only. L1 & L2 GNSS will fix in under 10 seconds and almost works everywhere it is great stuff now.
Your rover wont work with any SV’s that your base does not have. If your base has 10 but your rover has 15 It can only use 10. In short you want you base getting everything. More open and a slightly lower cutoff is better.
I am still messing with the best elevation mask for these L1 units. 15 deg is a bit high however the float results are better than 5 or 10 deg mark and the fix is pretty solid. I think 13deg may be a better but I don’t know yet.
The Signal to Noise ratio has a cut off too. It is a bit confusing in Ucenter & I thought MP had a max value of 40 for SV use but you see the red line at 30 on the RTKinject. I do not know if changing these setting are helpful or the right thing to do. The Ucenter should have better default settings. Most of the parameter values are at 0 and I do not find help on the settings. I don’t know how Philip could implement something in Ucenter.?
Yes, I can’t find anything useful either - and there are many of them…
Well, he won’t in U-Center, but if there are more suitable values for a stable fix, then I assume these can be implemented in AP/ MP. When you check the M8P autoconfig box in the GPS inject window, I assume it would take over a set of tested values. According to your findings and statements maybe those could be improved upon (?) - but this is beyond my current scope of knowledge and presumably this would need to be worked out with the aid of experts/ u-blox.
Likely Philip’s/ Hex’s efforts are currently focused on HerePro/ ZED-F9P, so I have little hope of this happening in the near future. But I am always open for surprises
And am still hoping for somebody more knowledgeable to post a proven config file with suitable base/ rover settings that get this product running in a reliable way for a setup as outlined in the first post…
Elevation mask settings are not something I came up with. These settings come from GPS manufactures like Trimble, Novatel, Topcon, Leica ect… Not sure why Ublox don’t know this?
Monitorting the Emlid forums are very useful because the Here+ and the Emlid Reach RS+ and M+ units use practically the same Ublox receiver. Technically they use the T version and another processor to achieve the RTK Fix, however the general important settings are the same.
From my experience, there are 4 primary settings on these L1 receivers.
Constellations enabled
Resultant update rate achievable
Elevation angle cutoff.
SNR (signal to noise ratio?) cutoff - basically signal strength before filtering.
Once those are tuned in, you should receive Fixes reliably in low multipath, clear-sky, short baseline environments.
Thanks @Naterater for pitching in. I have at times also browsed through Emlid resources.
This starts to get promising and I am getting my hopes up.
You are mentioning 4 areas worth looking at.
Would you be so kind to make it concrete and translate this pointer to actual suitable values (for particular configuration options) to be used with the Here+?
I think you have seriously misunderstood how Ardupilot works…
we are reliant on you to find what works and make pull requests with code modifications.
We are not responsible for firmware (though we do contribute to ardupilot). Incorrect parameters are an ardupilot issue, and you can make a pull request to fix any of them.
If you are using the Neo-M8P you must use firmware 1.4, 1.3 introduced a bug that slowed the fix. I have the M8P on a Harris Aerial hybrid and it works fine. I have been working with this chip for sometime now and have integrated it into a survey controller with SurvCE. The base MUST have access to all satellites, the rover can only use what is seen by the base.
@philip then there was a misunderstanding, I apologize. I was under the impression that if Hex/ ProfiCNC sells such a (non-beta) product geared towards the Ardupilot cosmos, they would likely be the ones to have access to u-blox engineering support to best configure a GNSS and in turn be interested to supply suitable parameters/ values to the codebase so that their product can perform optimally. I’m glad to contribute if I find out something, but to expect this from the average end-user is a lot to ask, it seems.
Also consider the statement
This does not relate to AP params, yet may have an impact on performance, and is likely something to be worked out with u-blox. As much as I like to dive deeper into various subjects and gain understanding, there are limits and here I can’t quite see how I as a non-expert customer should or could get in the middle of matters I don’t grasp enough… (AP Devs aim to enable the creation … of trusted… unmanned vehicles.)
I am just trying to get a component to work in line with what I thought it would deliver.
So maybe somebody more knowledgeable than I has already found settings which achieved considerable performance gains and is willing to share them here.
Satellites lower than set elevation will be excluded from the computation. The default setting is 15 degrees. Usually, satellites with a lower elevation provide too noisy measurements.
Satellites with low SNR will be excluded from the computation. The default setting is 35.
If this is correct for the Here+ I cannot judge.
Still, in another place a seemingly knowledgeable (Emlid) user provides a host of settings, yet then asks/ reports:
“how can I get the system to FIX? I have experimented with all available ReachView settings with no luck.The few FIX points I have achieved are poor, about 1 meter away from the surveyed location.”
Good info thank you!
I see the EMLID default is 15 deg and 35 snr ratio. The Here+ default is 5 deg and 0 SNR…
This setting difference is the reason we are having issue.
Other settings? there is a fix reliability setting. (Emlid calls it 1,2 & 3)
Ublox has 68%, 95%, 99.9%, 99.99% & even 99.999% in the settings.
95% for this settings should be good enough but this is a personal choice.
Minimum epoch # for fix this may be the 200 the writer is confused about.
What would be cool if we had control of these settings in MP on the RTK inject page.
I would also like to know what control MP has over these settings?
@mtnsurveyor Have you had a chance to do anymore testing with this unit to nail down suitable parameters to get the accuracy desired - reliably? If so, it’d be great if you could make them available, so that others can compare.
I have been working up from 10 deg. (too low) I am getting float/fix solutions fluctuating constantly. At 12 deg. (still too low) I get fixed about 75% - 90% of the time the x,y positions are pretty good but I see fixed vertical error over 1.5 meters through the day.
15 deg. had the best float positions but I had trouble getting fixed parts of the day.
Now I am set at 13 deg & also have a F9P on the bench, so I am anxious to get these tested & refined.
Best news is I found how to adjust the elevation mask in MP (full parameter tree).This will make testing easier.
I could not find how to adjust the S/R in MP but it could be there somewhere.?
Thank you very much for sharing those findings.
So from those results done by a surveyor I take it that some minor improvements can be achieved by playing with the Elevation mask angle - yet overall a solid, dependable RTK fix and accurate performance cannot be reliably reached with the HERE+ RTK, and your sights are set towards the F9P…
Is this a fair assessment?
L1 kinematic has always had issues. We use it because it is cheap. I have paid $4500 for 2- L1
receivers just 15 years ago. A carrier phase(for my static work) & RTK capable receiver pair for $600 was/is irresistible. L1 static gets 1" vertical repeatability, I do not think we will see that in any RTK for a while. I still get 1/2 foot vertical errors under canopy with my Trimble GNSS.
I bought the F9P because it was cheaper than the here+ & I am a GPS geek. It’s for a mower project that needs to work under canopy +/- a foot. Yes, it’s a much faster GPS than any L1.
The Here+ is very good for a aircraft flying 20 minutes and it has a compass. The fixed deviation is just 15cm+/- for that typical time, that can be tuned further. I will continue to do so and send you the best results after the holiday. I do not think we will get CM accurate flights with GNSS. To get that we must use GCP’s or… an airborne prism tracked by a robotic total station (just thinking).
The Here Pro should be better than just the F9P for flights. We are still looking at much lower accuracy than advertised @ ubloc.
Thanks very much for those insights. I could probably live with the fixed deviation as referenced - if only I could get a stable fix…
Am looking forward to hear more of what you are able to find - have a good holiday.
