Before I buy, I’d love a sanity check from people who actually run this hardware.
I’m a hobbyist, not a surveyor.
I want a pocketable GNSS track logger for hiking and mountaineering Alps, where there’s often no mobile signal. It feeds a side project that overlays the recorded track back onto photos of the terrain (optionally projected through a DEM), so the drawn line follows the ridges and paths you actually see. That alignment lives or dies on the track’s positional accuracy, and it’s all done at home afterwards, so I mostly care about post-processed accuracy, not real-time.
My plan: RTK Postcard (Quectel LG290P, quad-band L1/L2/L5/E6) + Portability Shield for microSD self-logging, with a ELT0244 full-band helical puck on a 50 cm SMA. Log raw to the card, then PPK in RTKLIB against free reference data (EPN/RGP/RING, or BEV/APOS in Austria). I know the nearest free base in e.g. the Swiss alps will be ~40–100 km away and ~2 km lower, so I’m expecting for Float / decimetre rather than fixed-cm there.
Two things I’d really value input on:
Is this realistic, and would you do anything differently? For PPK over those long baselines, is decimetre the honest expectation? Any obvious flaws in the setup before I commit to it?
Antenna in the pack lid. I’d like the puck to ride inside the top lid pocket of the pack, sky-facing, held by its magnetic base through the fabric. Will a layer of pack fabric over it meaningfully hurt multi-band / E6 reception, or should I mount it fully exposed on top instead?
I tried an experiment years ago where I used a pair of u-blox NEO-M8T GNSS receivers to log ‘raw’ GNSS data. One acted as a fixed Base, one as a Rover mounted on a rotating arm. I post-processed the results using RTKLIB. The results were very pleasing.
So, yes, it can be done. For the NEO-M8T, I was logging the ‘raw’ GNSS data in u-blox UBX RAWX and SFRBX format. For the LG290P, you would need to log the equivalent RTCM messages. I would suggest trying RTCM 1074, 1084, 1094 and 1124 every 1 second, plus 1019, 1020, 1042 and 1046 every 5 seconds.
But, the latest LG290P firmware also supports Galileo HAS (E6). Maybe the accuracy provided by HAS - approximately 20cm - will be good enough for your application? That way you would avoid needing a separate Base and Post-Processing.
Hi Paul, thanks a lot for your replies, and your pointers on what to log specifically! I am glad to hear that my overall plan seems somewhat reasonable
And these are indeed some quite impressive results. I actually considered the base-station path as well, but decided against it because apart from the extra investment it would also be too big of a hassle to place this somewhere at the start of the hike, and it would not easily work for multi-day hikes at all.
I am aware of the possibility of Galileo HAS, and do plan to at least try it. But as I understand it its not guaranteed / very likely to maintain that accuracy e.g. when half of the sky is obstructed by a rock wall or in a forest.
And I think I will not really mind the post-processing step. I guess I will see how well PPK will work with a public base station which is somewhat far away, and if not satisfactory use PPP, which I understand should outperform HAS.
One more question I have is whether anyone has experience on how much of a difference a metal base plate makes in practice? I will probably use one to attach the antenna magenetically through the fabric, but it is quite a bit of extra weight..
You can easily do Both
Log the RTK float NMEA positions (HAS/E6 corrected) in real-time, and the RTCM messages for PPK later (as a backup plan).
Also, you might be surprised by HAS and the mountains…since all Galileo Sats broadcast the HAS corrections for Galileo and GPS on the E6 band. You only need to “see” one of those sats for the corrections.
Personally, I’d guess HAS will work fine for what you want to do.
You can also “drape” the track over a DEM/TIN/LiDaR/etc with tools like Global Mapper (and several others) to generate an impressive 3D view with terrain and aerial imagery. Then you wont get upset if HAS/E6 Convergence is lost during portions of the hike, because you are “snapping” the elevations of the track to the terrain data source.
I’d also agree that using a 2’nd PostCard as your own base isn’t a bad idea. It doesn’t take much of a battery to operate a PostCard as a temporary Base… or a permanent PostCard base at your house ?
Yes it’s realistic, but with anything GNSS it depends on the (GNSS) environment. Odds are sometimes things will work quite well, sometimes marginal, and sometimes quite poorly. But just because it won’t work 100% of the time doesn’t mean you shouldn’t try.
An autonomous multi-constellation solution might actually work well enough in the areas that you get decent data. Differential/PPP processing may or may not help that much though of course it will be more fun to try.
As for accuracy on longer baselines, RTKLIB can model the atmosphere so as long as the GNSS data is “good enough” there is no problem with decimeter or even sub-decimeter accuracy over 40-100 km baselines. How accurately can you hike a path multiple times? A couple decimeters seems more than good enough.
You’ve picked some kind of helical antenna? They are designed to work without a groundplane so no need to add one.
One thing to check after you have the equipment. Run QGNSS software for the LG290P with the antenna outside in a clear environment and monitor the satellite signal strength. Ideally sats high in the sky will have strength numbers near 50. Those closer to the horizon might be in the low 30s. Signal strength isn’t everything, but it’s a good indicator of how post processing will go. Generally useful sats will be at 35+. If your zenith sats aren’t near 50 a different antenna might be advisable.
Monitoring signal strength is quite useful as you can test if material over the antenna limits the reception or not. What if it is wet? Does it matter? Could you have a cm of water pool above it? That probably will matter.
You can also check groundplanes this way. With a patch antenna a groundplane will likely add several dBs of gain to some sats. You can see this in real time by adding or removing an aluminum disk below the antenna. Remember your body blocks the GNSS frequencies so monitor the values after moving away.
Two weeks ago, we made a cave entrances survey, mostly to asses more precisely entrances elevations. In fact, area was completely off grid. I recorded RAW data with RTK Express (F9P). Then I did post-processing using RTKLib-EX with a reference station 25 km away. Although the tree cover was not that strong, it was mostly impossible to get fix. Overall, fix with RTKLib is much more difficult than with internal F9P engine. We also get noisy tracks in the forest.
Thank you all for your input! I think this will be really helpful. I have now ordered the core electronics and am exited to test it out I will share results once I have tested it in the field, which might be in a month or so.
@rftop Good to hear that you are hopeful about HAS! I have already been “draping” tracks over a DEM, but (a) good DEMs are sometimes tricky to find and (b) Especically for glacier travel not that accurate if outdated. That’s why I would ideally want to remove it from the pipeline. I will check out Global Mapper though!
@jpb Thanks for your assessment! Overall, I will be very happy if most of the time the accuracy is much better than with my (not very current) smartphone. We will see
I have picked this helical antenna, and will check the signal strength!
@Eric_S Thanks for sharing! I would have intuitively expected post-processing to have the edge, especially if it has access to better correction data than what the F9P engine has live, as I understand was the case in your example. Just so I understand correctly, the main reason this could be is that the F9P uses better algorithms than RTKLib-EX, right?
Personally, I mostly hike above the tree line, so at least foilage should not be a problem. But rock walls can also be problematic from what I have read, so I guess I will see.
I also remember the M8T days and the rtklib solutions…
What I observed is that the library had numerous variables to set, in addition to the fact that some versions gave unexpected results compared to others: I am talking about the rtklib5demo variant…
At the time, I was helped by comparing different approaches, logically found on the various forums that were now unobtainable…floating point computing power on gnss chips effectively supplanted rtklib on the pc.
My personal opinion = No, a gnss chip’s internal algorithms are not more sophisticated than post processing with RTKLib. Post Processing has the added benefit of looking forwards and backwards in time for the entire dataset - RTK cant.
I don’t think RTK will ever have higher mathematical accuracy than PPK under identical conditions, but RTK does have major advantages. RTK is naturally easier and allows for in-field quality control.
The trick is: no amount of post-processing can make “marginal” quality data magically great data. Tree canopy (or any multi-path) will hurt your accuracy, and the GNSS receiver doesn’t always know it’s happening.
One thing we all need to remember is that any GNSS device is only guessing at the accuracy estimate. When you are using RTK observation data from a far away Base, the accuracy estimate is basically worthless. Multi-path is similar… the receiver doesn’t know that it has guessed the wrong wavelength integer. I’ve had $30,000+ receivers confidently “think” they are producing cm accurate RTK results, when the solution is actually half a meter in error.
[Sorry, I got way beyond the context of logging a hike ]
Interesting..
Just to make sure that I understand correctly: Fundamentally, the GNSS receiver does not utilize more information than what is logged or otherwise accessible (e.g. base station data) post-hoc, right? (except maybe for potential correction sources which are only available live, but let’s exclude those / assume they are also logged).
If so, one could in principle (if the software were available) run the receiver algorithm post-hoc, and (as @rftop points out) additionally use advantages such as forward and backward processing. If RTKLib then really was worse, it would be because of a worse algorithm.
Or is the receiver using some information which is not available post-hoc?
Be careful, rtk and ppk are different beasts…
I was referring, however, to the direct comparison between rtk via rtlklib and the alg. on the chip, so emlid started with M8T (with an embedded rtklib on an external MCU); while to say you’ve set up a correct ppk, according to Tim Everett’s guides you also need to enter (and not only) the data provided by IGS: the final (or precise) ones,having more accurate data you get best results…
Well…that discussion has to be expanded to ensure clarity.
There are various methods to correct GNSS data, and those differ if you’re dealing with static or Kinematic Data.
RTK: (Kinematic Data) The receiver is actively moving, or at least treated as though it can move at any second. The algorithm must calculate a brand-new, unique position coordinate at every single epoch. Individual epochs don’t get the benefit of relying on long-term time averaging…because by definition - the receiver can be moved.
Post-processing can be Kinematic or Static Double-Differencing utilizing an OSR (Observation Space Representation) framework (which requires a local physical or virtual base station), or Kinematic or Static PPP Zero-Differencing utilizing an SSR (State Space Representation) framework (which requires global precise orbit and clock files).
It’s easy to botch a Post Processing mission in the office, so it’s not really fair to ever think RTKLib was worse because of a bad algorithm.
@imagirom , after you get your PostCard - install some permanent threads for your antenna as a test site. Log RTCM for 24 hours and submit to CSRS-PPP. You will have very accurate coordinates for that antenna location. Then in the future you can compare to HAS/E6, any RTK base station or correction service, RTKLib Kinematic and Static Processing, etc.
Warning: You will soon want a 2’nd PostCard to use at your permanent antenna threads to test your own Base Station and compare RTK points to PPK, etc.
25km is also very far for a reference station. With a base within 10km the claimed accuracy is valid when using the F9P in an area without obstructions between the satellites/receiver
50 km baseline is usable for dual frequency RTK (10 km for single frequency). In the last picture, baseline was of 3 km.
But the point is that the F9P is telling in real time that accuracy is of 0.014 m (on RTK Express screen or through Ntrip client) although it is pointing a couple of meters away.
@Eric_S, a while ago I spent a little time testing the LG290P under tree canopy. It was almost impossible to quantify the canopy impacts, because there’s no way to easily reference the “amount” of canopy for any particular situation.
One thing I found interesting was using the GBS NMEA sentence for Integrity Monitoring, by comparing the GBS Estimated Position Error against the Final RTK Position RMS to identify false fixes under the canopy.
I “think” the GBS sentence is available from the F9P also, if you ever want to play around with it.
I will share results once I have tested it in the field, which might be in a month or so.
