Good afternoon. I have a zed-f9p and I moved to another antenna and now I cannot get a PPP solution. CSRS keeps rejecting my uploads as having bad data.
Background:
I have the ZED-F9P (I will call it F9P)
I also have a RTK-Surveyor. (I will call it RTK)
I plugged the ZED-F9P into one computer and the RTK-Surveyor into another with two separate fixed antennas 10 feet from each other.
I turned TMODE3 to mode 0 on the F9P
My troubleshooting has indicated that the F9P thinks it is getting corrections from somewhere I think
When I turn on U-Center on the F9P it is showing Fix Mode as “3D/DGNSS” and the Lat and Long don’t drift much
When I turn on U-Center on the RTK it is showing a fix type as “3D” and the lat long drift wildly
What do I need to do to get the F9P to go back to regular/rover mode?
I found the UBX>CFG>CFG “Restore to defaults” and burned it into everything. Ugh. Thanks
This does not seem to have fixed the issue
Please have a look at ‘how to build a diy gnss reference station’ tutorial here: https://learn.sparkfun.com/tutorials/ho … tation/all
You’ll need to configure your ZED-F9P in RAWX+SFRBX mode for at least a few hours before submitting to CSRS. I recommend doing a ‘Restore to Defaults’ before starting your log so that there’s no other settings that get in the way.
The RTK Surveyor is very different. The internal ESP32 will configure the ZED F9P at every power on according to the stored settings. If you’d like to return to defaults for the Surveyor, please see the ‘Factory Reset’ option: https://docs.sparkfun.com/SparkFun_RTK_ … tory-reset Once the device has been reset, you’ll need to enable the RAWX and SFRBX messages: https://docs.sparkfun.com/SparkFun_RTK_ … _messages/
The 3D vs 3D/DGNSS is an indication of fix quality and not necessarily that RTCM corrections are being received. The better check is to look at the UBX->NAV->PVT message. This message will show 3D, 3D/DGNSS as well as RTK Float and RTK Fix indicators.
I am still receiving poor results from CSRS-PPP and OPUS won’t even accept the files.
Here is my workflow:
Take U-Center and plug in the antenna
Collect 24 hours of data: https://drive.google.com/file/d/1oQaqUu … sp=sharing
Use RTKLib RTKConv.exe to convert to Rinex https://drive.google.com/file/d/1oQaqUu … share_link
CSRS will still not take this file as it has empty epocs
Run through gfzrnx_2.0-8219_win10_64.exe with the command -finp ABOVE .obs -fout BELOW -kv -chk
I take this file and send it to CSRS-PPP https://drive.google.com/file/d/19VJEG9 … share_link
The last OBS is significantly smaller and I am sure it is missing a bunch of data
Anyone have any idea what I might be doing wrong here? It worked like gangbusters the first time i followed the instruction on the sparkfun.com “How to Build a DIY GNSS Reference Station”
Is there a possibility it could be the cable? I am using a new cable which runs a small distance.
Do I have something incorrect set up when I am recording the data?
Here is the console output: https://drive.google.com/file/d/1JyMzS0 … sp=sharing
I forgot to mention: This gets me 3/4 of a meter precision. and I have the same results if I send the RTK to CSRS or i get from sending the F9P logs.
The antenna is either the Top106 or your other antenna, I have tried both with the same result.
What is an HPA?
Is this what you are looking for?
![]()
I used the hacked version of RTKLib and just sent GPS on L1, L2 & L3 and got the solution to the position of the satellite. For anyone looking for an answer: try this.
Collect 24 hours of info in U-Center
Use RTKLibExplorer’s version of the software
Wait 24-48 hours and use RTKConv to create an .OBS from the .UBX
Send the OBS to CSRS-CCC and wait an hour or two.
I think the issue mainly was that I was trying to send GLONAS and/or BeiDou and getting errors in my OBS file causing me to have to reconvert the OBS with gfzrnx which introduced bad data or decimated the data to an unrecognizable state.
