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

#4

@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!

#5

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

1 Like
#6

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.

#7

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

#8

@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…

#9

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.

2 Likes
#10

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?

#11

It is not a problem with Here+ in particular, i have had here+ and reach from emlid. Both struggle to get and keep a fix on a stand alone test rig, let alone a flying drone, M8 is very limited due to its single frequency support.
F9P is the only way to go, double frequency is a must if you want to have reliable and quick rtk fix. I am impatiently waiting for the new Here Pro and will get it on day one if it is uavcan. The perfect solution wold be to have a 3100 compass on it too but i doubt it will.

#12

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

1 Like
#13

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…

#14

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

#15

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

#16

@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?

#17

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

  1. Ground plane both ends.
  2. 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.

1 Like
#18

Have a look at Mathew’s post above.

#19

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.
ucenter1

1 Like
#20

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

#21

@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…

#22

@Mathew_Herbert thanks for pitching in.

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.

#23

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.