Here+ does not "hold" RTK Fixed status reliably - Help please!

camti · June 12, 2019, 9:49am

Hello,
I have been battling my Here+ for some weeks trying to get a consistent fix state and would be very grateful for assistance in getting this working - reliably.

Consider this setup for a UAV application (using Ublox fw 1.4):

Here+ Base station
situated in open clear skies,
mounted on a 13cm dia metallic ground plane,
about 1.8m above ground,
default/ stock Taoglass antenna,
connected to PC via USB
low kp values (1-2)
good signal strength (13 sats above 40)
two GNSS units mounted on UAV (Here+ (GPS1) + Here (GPS2))
Mission Planner (v 1.3.66 build 1.3.7100)
UAV connected via 3DR modems @57600 bd
M8P autoconfig: checked

The base (while connected to U-Center and using an NTRIP server), can in principle achieve RTK Fix (at times though vacillating and dropping to Float or even 3D states).

After disconnecting from U-center, I take the coordinates acquired in 3. and enter them in the GPS inject dialog in Mission Planner as a fixed position and choose “Use”.
Then “Using Fixed LLA” is displayed, (with the coordinates previously entered).

Yet even under these circumstances, the GPS status of the relevant GPS regularly only shows as 5/ rtk Float.
For seconds at a time, it will jump to “Fixed”, but for 99.5% of the time it stays at “Float” - see image:

For my particular application, I need the accuracy of “Fixed”. But having read every doc, post, hint and resource I could find, I am simply at a loss how to achieve it, and would need some competent guidance from the makers of this hardware to get to the accuracy advertised in a reliable way.

For starters, a suitable Ublox config for the module might be helpful, to get a correct reference setup to quickly achieve a fix using a NTRIP correction source.
(I have tried a variety of params, then reset, and also re-flashed fw1.4, but am not certain of the best setup, e.g. TMODE3. At times I can get to “Fixed” fast, other times, it takes minutes, even with NTRIP corrections streaming in).
Therefore, a reference, tested config to upload from U-center seems helpful.

Secondly, it is inexplicable to me, how a fixed solution (in U-Center) would drop to primarily Float when connected in MP, and why the Fixed state is not held under the conditions outlined above.

Thirdly, I wonder if (using port 500) and connecting U-Center to MP via tcp (in order to continue to stream NTRIP corrections) could do any good to improve this dilemma.
(It seems that once I have entered correct and fixed coordinates for the base in the MP dialog, that should be sufficient.)

I need to get the system working to centimeter accuracy and am looking forward to competent advice to get there - let me know if more info is needed. Thank you!

philip · June 12, 2019, 3:15pm

@Michael_Oborne

Michael_Oborne · June 13, 2019, 1:39am

just as a test, could you change your system to use “.” instead of “,” just to eliminate any issues on that front?

camti · June 13, 2019, 8:48am

@Michael_Oborne I have tested as suggested, but observed no improvement in behaviour as it relates to rtkFloat. The position as reported on the sat map vacillates in ranges unacceptable for my application - since the fix status is rarely, if ever, reached.
(Nevertheless, there are some incongruencies regarding regional settings “.” and “,” in this dialog, which surface when pasting values and applying them. But such errors can be caught on the right, in the “FixedLLA” section, and don’t think have been the root cause for the problem I am facing.)

@philip As mentioned, in my experience the Here+ from Hex very rarely remains in the “fixed” state, but mostly drops to float. Therefore I have variations of at least 70-90 cms when trying to hit the same waypoints repeatedly (with a multirotor).
(This unsuccessful experience is shared by colleagues (who have purchased multiple Here+ units) and is also discussed e.g. here and here.)

Nevertheless, according to the Ublox webinar “ZED-F9P technology deep dive” when comparing the ZED-F9P with the M8P, they apparently were able to achieve reasonable results with the M8P, at least in conditions as outlined above.

So therefore my guess is, that the hardware of Here+ (in conducive conditions) might be capable to perform as advertised in achieving absolute accuracy, but maybe some settings are keeping things from working optimally?
Settings do seem to be critical:

When I re-flash the fw on the Here+ base (and presumably end up with default settings), and then run it with NTRIP in U-Center, things are moving rather slow to reach acceptable accuracy.
Whereas when I upload settings from a ublox configuration file by a colleague, the fix is achieved much faster.
So they seem to have it setup better, but the trouble is when using their config, a prompt comes up warning of a differing FIS version (but seems to work).

Therefore I ask whether you could supply an up-to-date, correct, suitable ublox config file to upload to my Here+ - so that it can be optimally augmented by NTRIP (to acquire a fixed, absolute position), and then serve as a base to the Here+ rover, using Mission Planner.
(Due to (subscription) costs and possible connection issues, I do not want to receive NTRIP corrections continuously, but rather acquire a fix for the base only once, using U-Center, then feed corrections from base to rover.)

I do realize that the ZED-F9P/ Here Pro is coming up and Tridge’s tests in a recent blog post finds:
“for most of the 5 hour test the F9P kept a RTK-FIxed solution, whereas the M8P only occasionally managed a RTK-Fixed, but did keep a RTK-Float solution.”

Yet having spend considerable money on a Here+ to get the accuracy as advertised, and with u-blox saying it should be possible in such optimal conditions, I am really hoping to make good use of this investment, and am asking for help from the dev/ maker.
Thanks in advance for your help!

Michael_Oborne · June 13, 2019, 9:37am

from what ive seen the base seems ok.

what i guess is happening is your rover side is experiencing interference from other things attached. like telem radios etc to close to the antenna. or none clear sky view

camti · June 13, 2019, 12:16pm

Hi Michael,
If I only run the base in u-center, I already only rarely get a fix. So as long as that is not stable, the other components are unlikely to perform as expected.

I also tested the base with telemetry radios unplugged, and there have been no improvements or stability gains observable. I have also tested a second set of hardware which I had borrowed to see the impact. For a number of tests, there was also a very clear sky. Same problem: rarely a fix, and if so, only short.

Therefore my thought and request to @philip to first obtain a suitable u-blox gnss configuration file for the base, which regularly acquires a stable fix.

hdtechk · June 13, 2019, 8:05pm

http://ardupilot.org/copter/docs/common-here-plus-gps.html

camti · June 13, 2019, 8:46pm

@hdtechk I have read the linked document multiple times.
As far as I can see, it does not contain a suitable u-blox config that can be uploaded to the base, nor does it take into account the use of NTRIP corrections to the base and an absolute position setup for the base as I outlined above

In yet another test earlier today, I actually obtained a rtx Fix within U-center (after a long time, like an hour or more, with NTRIP corrections applied). On disconnecting from u-center and connecting to Mission Planner, the status dropped to Float. (I don’t know if this status displayed in the HUD applies to the base? or the rover/ both?)
The Here+ rover is mounted on a thin plastic canopy, which has copper shielding inside, which to my understanding should act as a ground plane then.

So the issue remains: I cannot reach a reliable, steady rtk fix status…

Duncan_Hine · June 13, 2019, 9:13pm

We have had pretty much the same experience as you with the here + using ntrip.

We’ve given up burning any more time trying to get it to work and bought a drotek f9p module and now get a fix all day long in seconds.

camti · June 14, 2019, 5:55am

Thanks for pitching in. Seeing the reports, I was afraid of that - needing to spend more money and having a 600$ item - advertised to achieve cm accuracy - laying around useless, therefore my efforts.

Maybe Hex will consider a discounted upgrade/ trade-in program for Here+ customers once the HerePro is out?

mtnsurveyor · June 14, 2019, 9:21pm

I do not think we have a $600 useless items. L1 does work and I get 2 cm results daily using static post-processing. To get a fix you need 12 minutes plus 2 minutes per KM for your base line. If you are using NTRIP your baselines will be very long. If you set up a base you will have shorter baselines and better results. There is something off with the M8P settings and I think we need a good set of starting parameters from ublox. For one the default elevation mask is way too low at 5deg. SV’s at that low elevation will only confuse a receiver, it is much better to maintain a lock on 8sv’s than to intermittently get 15-20 sv’s. You will get bad fixes using low sv’s and the only way to catch the error is to repeat the survey which we can’t precisely do in the air.
The wife said NO to the L2 upgrade so for now I am committed to getting the M8P to work. It will especially on a drone flying above most obstructions. I will share any parameters I find that work & lets not call it a paper weight yet.
Start by setting the elevation cut off at 10-15 deg.
If anyone on this site needs a good base position I would processes it for you. I would need your Rinex files .19o & .19n

copilot · June 14, 2019, 10:16pm

Same here… made the mistake of buying 3 of the Here+ units!
After days of frustration not getting more than a few seconds worth of steady RTK fix in a clear open field we finally gave it up. In the end settled for the Septentrio which was not cheap but the RTK fix is rock steady! Due to the nature of the project we could afford it but I really feel bad for the guys that spend their hard earned cash of these units, which I consider very optimistically being sold as RTK units…
Anyway @camti if you ever find the solution I would be all ears since we still have 3 of them laying around…

philip · June 14, 2019, 10:24pm

Accuracy around a waypoint is not only defined by the gps itself.

philip · June 14, 2019, 10:28pm

Keen to get better parameters for uBlox if possible, let’s see if we can identify any areas for improvement and get them into the next firmware

camti · June 15, 2019, 6:57am

@philip
I‘d gladly be enlightened what else contributes to accuracy around the waypoint!

I have reigned in the param WPNAV_RADIUS to 10 cm and give it a couple of seconds at the waypoint to settle in position.
What are other things to improve real time (not PPK) accuracy?

Mathew_Herbert · June 15, 2019, 12:45pm

We had similar issues with the Here+ initially.
Two big things to remember if you want a reliable fix:

Ground plane both ends.
The fix state in mission planner is very dependent on the health of the EKF (in particular the heath of the compass in our case). If everything else is not in tip top shape getting an RTK fix is difficult to achieve reliably.

Our application was a very large rover (150kg’s) and it had to steer within 5cm to remain within a set of plant rows. once we sorted out our compass we were all good.

Another thing that we found useful was to log the Here+ base then ppk process the location and punch that into mission planner. It saves a lot of time surveying in and gives you the best absolute accuracy.

Dont despair the unit is completely capable of what you are looking for t just needs a healthy environment.

philip · June 15, 2019, 2:37pm

Have a look at Mathew’s post above.

mtnsurveyor · June 15, 2019, 3:17pm

I ran 3 test with good results using 10 and 15 degree sv mask
60% - 80% open sky with 20% horizon view, 50 year old trees on my lot and all adjacent 0.2 acres lots, not an open field.

10 degree mask took 5 minutes to fix. then float - fix for 2 minuted until a solid fix for 7 minutes. after that I lost the fix and position was only about 1 -2 feet accurate for the next 20 minutes.
this 1st test held 16 -17 sv’s

15 deg mask took 4 minutes to first fix then float fix for 5 minutes at an accuracy of about 0.5 feet, at 10 minutes it fixed and held a solid fix for 45 minutes.
I also set the s&r mask to 30
this 2nd test had 15 -16 sv’s

test 3 same as test 2 I got a 2 minute fix, it stayed fixed

Yes! the Here+ works just like a survey grade L1 receiver should work.

Leon_Dwyer · June 16, 2019, 5:30am

Have been using the here + for a while now. and use it with NTRIP
Like all L1 rtk gps recivers it will take up to 10 min to get a fix, if to turn it on it side it will lose fix.
You get a fix more easily when in the air. so maybe take off and loiter.
I limit my bank angle to 30 deg so as not to lose lock in the turns.

If it does drops to float while on mission I don’t worry to much, it seem pretty close to what FIXED is anyway.

And I never do a survey with out at lease 5 GCPs on the ground, and only rely on RTK when you really can’t get on the ground.

All in all its a good unit. and can’t wait for the l1 l2 here pro

camti · June 16, 2019, 12:52pm

@Corrado_Steri I understand that many people are impressed with the F9P, and that multiband receivers have many benefits. At the same time I have spent considerable money on the Here+ M8P already, therefore have an interest in getting it working as advertised, and am trying to sort through the various reports of people encountering the same problems I have (and have given up), and meshing them with others who are saying it is usable…