I have a Bad-Elf Surveyor (with what I’m pretty sure is a ublox Neo-7P module) and am experimenting with the kind of accuracy I can get from it by collecting raw data logs (RINEX) from the Bad-Elf app. I’ve figured out how to apply post-processing corrections using RTKLib’s RTKPost, which I’ve described at What will post-process differentially correct raw Bad-Elf Surveyor U-Blox NMEA/raw UBX?.
However.
The Bad-Elf page claims that optimal accuracy can be achieved by implementing GPS+PPP+SBAS. The ublox page says, “u‑blox’ PPP technology is made possible by stabilizing measurements of the distance between GNSS satellites and the receiver (pseudo‑ranges) using carrier phase tracking. Additional accuracy is achieved from ionospheric correctional data received from satellite‑based augmentation systems.” The NEO-7P product page says that “u‑blox has implemented PPP in its NEO‑7P GNSS module.” (Emphasis mine.)
The Bad-Elf statement seems to imply that optimal accuracy requires that data be collected while WAAS/SBAS corrections are being received and implemented by the receiver itself and subsequently post-processed using PPP (ephemera and clock inputs). The ublox page seems to suggest that should post-processing should be done with clock and ephemera files, and then the SBAS information used for ionosphere corrections. The 7P product description seems to suggest some sort of mysterious internal PPP algorithm correcting the position readings in the chip itself.
Does anyone know which, if any, of the above three concepts is correct?
Best Answer
This Bad Elf statement on the "Performance" tab of your link to https://bad-elf.com/pages/be-gps-3300-detail :
... means the stand-alone BadElf/uBlox NEO-7P module's internal calculations of the position are most accurate when using GPS+SBAS+PPP signals. It does not speak to the accuracy of post-processed raw data.
The ublox statement is also about the stand-alone in-module calculation solutions.
Post-processing the raw data is a different situation, and would be a parallel calculation and solution independent of the module's calculation and solution. I doubt that the raw data used for postprocessing is modified by the magical internal calcs. You can get better orbital, clock, and ionospheric data from the IGS post-processed products versus what is available for the module can use from the real-time SBAS data, and then use the raw data to do a post-processing PPP solution. I would expect the post-processed PPP solution with the re-analyzed satellite and atmospheric data to improve on the real-time in-module PPP solutions.