Is there a portal where GNSS full raw data can be downloaded? High precision orbitals and clock corrections too, what latency? 24hrs?
Specifically this::
Have fully operational and proven base and rover with both EspNow and LORA and have done PPK between the two.
Objective is to compare the relative PPK correction quality with PPP vs base using EspNow or LORA — counterintuitively EspNow yield better PPK solutions (Green everwhere in range upto 100meters), LORA has range but nowhere near quality (yellow everywhere upto 300meter, not airspeed limited).
PPK already has what it needs from your logs. Precise orbits and clocks are for running PPP on the base to fix its true position, and the free services pull them in for you:
How long to wait before submitting: you can submit 1 to 2 hours after you stop logging, but waiting until the next day gets you most of the accuracy. Waiting 2 to 3 weeks adds only a little more.
If you’d rather download the orbits and clocks yourself (for example to run PPP locally), the official IGS products are at https://igs.org/products/ with the files archived on NASA CDDIS (free Earthdata login required).
On EspNow vs LoRa: the radio shouldn’t matter for PPK. Base and rover each save a log and you combine them afterward, so nothing goes over the radio. If the radio changes your results, you’re looking at live RTK status. LoRa can be slow to deliver full corrections every second, which is why it floats. Distance isn’t the issue either, 300 m is nothing for RTK. Process both logs and both radios should give the same answer.
Two questions: which device are you using, and when you compare EspNow and LoRa, are you looking at the fix color on the rover during the survey, or at results after processing both logs on a computer?
Yes, but is there a workflow where I could just use PPP to determine a virtual base Lat/Lon. And then later get that GPS raw at that position which I can then apply as a virtual base to rtkPOST?
This issue is using ppk in extremely challenging environments: canyon, flowing water, forest canopy to resolve the obviously wrong multipath solutions into better ones eliminating the need for a physical real base and attending communication links. I certainly could just use the intended base as a rover (with PPP to determine 1cm accuracy in 60 seconds) and continually log gps raw while the actual rover roves — but the question is, is there a way to request that data after the fact and only require one rover in the field. When compared to the hours of survey-in required of a standard base without PPP and afterwards lack the accuracy makes it a nonstarter.
If the answer is no, then the question becomes can I make an app (or SNIP, or u-center) that simply listens to the corrections and handshakes properly as if it were a base. Yeah, a spotMini with a paintball gun guarding the base might be insuffiicent against most determined thief.
Legitimate question, on the strange results, pictorial not from the same environment. Expectation was that they would be identical, perhaps uniformity of espNow samples is the root cause or more optimization of LORA chirp and spread required (high voodoo)
Takeaway for readers is my firm belief in the technical superiority of PPP, but sitting in any one place for more than 60seconds really isn’t required if set up correctly — which it is. if so, a starlink on an ATV is all you really need if you can request GPS Raw full after the fact, or whether i could just stash a camouflaged phone/pc as the answer — that is the question: know where I am, want to use PPP to do field local PPK.
So if I’m paraphrasing correctly: you want only the rover in the field, and a way to get base data after the fact so RTKPOST can run PPK without a physical base to deploy or guard.
You can get pretty close to that workflow using CORS. Instead of creating a virtual base at a PPP-derived position, you use an existing CORS station whose position is already precisely surveyed and published. Log your rover, come home, download the matching observations from the nearest station through NGS UFCORS, NGS Map and use that station as the base in RTKPOST. I ran a test against a Colorado station to confirm; everything RTKPOST needs came back in one zip.
The reason PPP alone can’t create the base data is that knowing a precise Lat/Lon and having satellite orbit/clock information doesn’t recreate the raw observations that a receiver would have measured at that location.
On the 1 cm in 60 seconds point, I’d separate conventional post-processed PPP from real-time PPP/SSR services with convergence assistance. They work as different tools.
On ESP-NOW vs. LoRa: PPK just combines the two logs, so the radio shouldn’t matter. What jumped out: both runs stay FLOAT, never FIX. Check the base file, base position, nav file, and AR setting, or share your settings and I’ll take a look.
Given that there is no CORS near any survey area of interest let alone roads and cellular, its not too hard to envision how easy it is to collect inexplicably bad data in the field and how hard it is to reproduce the anomaly back in civilization. But below is an example of canopy obstruction, not representative of what would be done in the field — long linear steady rate traversals. Surface linear position anomalies rebder sensed depth reading less useful, even after filtering.
And yes, we are talking about two technologies, because without visualization through PPP we don’t have any realtime indication of the quality of the data —50% of the time it may be good enough. The parts that are bad can be demarcated by the mark/service button. Finding out there was “no data” collected after the fact is a nonstarter.
as to ubx and PPK, yes, it should be totally independent of base->rover communication. However, the anomaly is repeatable, it is a science project to isolate why, but suspect combination of processor load interaction with differing io bandwidth and utilization in EspNow vs Lora… the dots are real.
But thank you, you’ve confirmed
an gps chip is required to store GPS raw full data, since local CORS aren’t anywhere near or representative, it seems that a static rover fed by PPP resolves to fix (and maintain <60s) will serve much better than a survey-in base (requiring hours and still be wrong)
RTKlib has a moving base option which may be the ideal solution: fixed-rover moves with mobile rover on atv with starlink, begin survey with true rover once fixed rover reaquires fix (within seconds), collect with other rover and move on.
Sounds simple, hopefully this information might be useful for the others who want to do the same rapid high precision surveys: 1) the facet is a great product and can do it 2) PPP and second facet is the only option if time and data accuracy are essential 3) PPK is not the panacea its promotion makes it out to be.
case in point, PPK excels with long distance regular and linear paths, previous pics: it successfully filters canyon multipath and most canopies. Not what was depicted below: a single tree in a 3x3m. This is why it is hard to reproduce the anomaly in civilization. Ubx does a better job, but amazingly the PPK did locate the center of the tree at the center point
@Eximer168 , Have a look at the free HAS/E6 service. It broadcasts real-time “corrections” for both Galileo and GPS satellites simultaneously. HAS/E6 uses SSR technology to deliver a PPP service directly from the Galileo constellation.
Here’s a related video of a Base using HAS/E6 to serve a local rover:
Today, this requires ~15-20 minutes to converge. In the future, that’s expected to be reduced to ~5 minutes. A newer gnss chip than the F9P in the Facet is required, but there are many options. I believe all SparkPNT receivers can use HAS/E6.
As always, RAW logs can be saved by the base and rover to post-process with PPK if you want, to compare to the RTK output.
Seems way dated, we need to see this guy on an atv with moving base and a starlink mini doing a speed run across the no-man zone badlands.
New hardware is not the answer, understand that rig you have is
5 minute lock? Shear folly! Set WIFI and AssistNow fixes in 15s.
People talk about saving logs but not the reality of how hard it is to get there, and once there, how to normalize the results into something useful — this thread shows you can
Snarky comments aside, the day has come when services like gemini can can give cogent strategies and answers in seconds over hours of manual review of dauntingly long, fragmentary, and outdated man page documentation — ultimately you have to ask the right question. Renormalizing the obviously wrong gps path under the tree (not unlike the charlie brown kite/signal eating tree) from a prompt/description, or kml drawn on a map, becomes something in the realm of possibility.
Not only are you only provably wrong, but such is a disservice to the product, technology and community but to the very people who are genuinely looking for answers.
To that end, a genuinely outstanding solution was discovered which was neither espNow, nor LoRA nor rtkLIB. What was perviously illustrated as the signal eating tree is now exceptionally well resolved with high resolution fix
Hard to believe but true, which means that if the facet can do this every F9 chip, cca and product can achieve the same with a single rover.
The key:
Wifi access (won’t connect for hidden wifi}
Ntrip/PointPerfect defined in-facet
Having wifi present at boot, assist now renders ephemerides in15s, PointPerfect fix in 60s and most astoundingly holds precision in pedestrian/kf at speeds 3xfaster than it did before. Full rate sdcard logging wasn’t a problem, adding any connection broke or shut down the performance to less than fixed.
Two downsides: 1)Changing any mode deactivates ntripClient/PPP, 2) there is no realtime map feedback — which may not be an issue if the results can be as trustworthy as this.
solutions:
mode the code to keep it enabled or disble setup button and make changes only by isb
Use qfield (android/ios) for sat sky map and positions to facet pvtServer port 2948. Use gnss master (android) for mock positions
BaseCaster/deprecated 2025 would have been the base->rover wifi solution. Instead use usb to uCenter, and uCenter to caster, have rover use pc’s ip/port 2101 as its ntrip source
End of story; now others know how a robust solution can (and has) been fielded.
