Hi!
We are a student group and have some problems with our RTK-GPS circuit. We are using SparkFun GPS-RTK Board - NEO-M8P-2 (Qwiic) (https://www.sparkfun.com/products/15005) and followed the “GPS-RTK Hookup Guide” (https://learn.sparkfun.com/tutorials/gp … 1548748225).
We come to the point where we have connected GPS-RTK to the correction source and can send correction data from our RTCM-provider (we can see RTK LED blinking):
https://imgur.com/wmLdmgg
https://imgur.com/EDKWn42
We also get good satellite reception which we can monitor with u-center:
https://imgur.com/74yIoIh
The problem is that the RTK LED never switches off which means that the module hasn’t solved the carrier ambiguities and entered RTK fixed mode. So, we don’t get “corrected” precise position and the longitude/latitude values continue to change even if we stand still.
We don’t know whether the problem is in the configurations or there is something wrong with the circuit itself.
We run into the same problem when testing the circuit on Linux.
The .conf file we have been testing on with RTKRCV:
https://pastebin.com/XEKLZNQZ
We are by no means experts on this subject, and would appreciate any help we could get.
Hi SandroJ,
It sounds like the RTCM data is not being received by the GPS-RTK board. Before connecting the Serial Basic (or similar USB to Serial converter), is the PPS LED blinking indicating a position lock? Also, what are you using to send the RTCM data to the GPS? Have you checked those connections and made sure they are correct and secure? The Hookup Guide shows a decent “test” circuit but for the best results, soldering header pins to connect a jumper wire to or directly soldering hookup wire/jumper wires to those pins is recommended.
I hope this helps, but if all of that checks out and you are still having issues getting the NEO-M8P to receive RTCM data, please take a few photos of your circuit and include them in your response.
Hi and thanks for the reply TS-Mark,
The PPS LED does blink when we go outside to test the circuit, and we have tried to wait for the position lock before connecting the Serial Basic, and it yields the same result. We are using a NTRIP service to send RTCM data to the board. The way we do this is to connect to the NTRIP server with RTKNAVI (windows) and path the output stream to the Serial Basic board. This causes the TX LED on the board to start blinking, indicating that it is receiving data and is ready to transmit it. Then we connect the Serial Basic to the NEO-M8P-2 board and the RTK LED starts blinking, indicating that it is receiving the RTCM data and it enters FLOAT mode. We soldered the connections before we started testing.
From what I understand, the RTCM data are received by the board, but it doesn’t reach the state where the ambiguities have been resolved. I suspect it might be a misconfiguration somewhere on our part, but I’m not sure. Here are two images of the current testing setup:
https://imgur.com/I6YAfH6
https://imgur.com/xDdkHBw
Thanks in advance.
Interesting. I think you are correct that there might be something in the configuration you are missing. Have you simply tried starting from the beginning again and setting up your RTCM feed along with the GPS? When you are trying to send the RTCM data to the NEO-M8P, is the TX led blinking along with the RTK LED every ~1 second? I am going to try and get my hands on one of these modules to test here to see if there are any obvious steps we are missing. I will update you once I have tested one of these.
We’ve tried to start from the beginning several times, as well as setting up the RTCM feed along with the GPS. The TX LED does blink along with the RTK LED, but not necessarily at the exact same rate. Thanks for going out of your way to test it yourself, we appreciate it.
I spoke with the engineer who designed the board and we have a few suggestions to check. First, double-check your base station is within 10km(6mi) from where you are testing. We cover this briefly in the [What is GPS-RTK Tutorial. You can also open up the USB port in U-Center and view the messages and if you are seeing this message:
WARNING: DGNSS baseline big: 10km
That means the broadcast station is too far away and the accuracy has degraded. The GPS will still get a lock but it will not be accounting for the correction data from the base station.
Another suggestion that might help is to make sure both baud rates for your Serial Basic and the UART port you are connecting that to on your GPS are at 9600. I believe that port defaults to 115200 in U-Center so go into the port information tool in U-Center and configure that to make sure they match.
I have not had a chance to sit down with one of these just yet but I still plan on setting this up myself to identify any other possible solutions here.](What is GPS RTK? - SparkFun Learn)
Hi again SandroJ,
I was finally able to get one of these to test the issue and I ran into what I believe is the issue you had using the RTKLIB software. I simply was not seeing much progress with the RTCM data being sent through the port I had my Serial to USB board connected to.
What I found was u-Center has an NTRIP Client tool built-in to the software and you can send that correction data over USB. After entering my credentials into there, I was able to (slowly) get the NEO-M8P-2 to get an RTK fix. It does take a while to get that to fix so as long as you are seeing the accuracy reports in u-center for 2D and 3D decrease slowly, just wait and eventually it will enter RTK Fixed mode.
I hope this helps you to get your NEO-M8P to enter fixed RTK mode. If you continue to have issues, please reply to this post and we would be happy to help.
Hello again TS-Mark,
After a few days of testing various things, we managed to fix the issues we were having. We ended up using only the NEO-M8P-2 board connected via USB, without the Serial Basic board. In our case we had to configure the receiver to send raw data by enabling the messages RXM-RAWX and RXM-SFRBX on USB in the configuration view on u-center.
Our RTCM data provider uses a VRS (Virtual Reference Station), which required us to send a NMEA GGA message with our approximate location so it could generate a VRS that the rover would use. This was simply done by sending a manual position when using RTKNAVI and by enabling inpstr2-nmeareq in the configuration file for RTKRCV.
After all of this the board finally reaches RTK FIXED mode after a few minutes. I’m still working on the .cmd file for RTKRCV so that we don’t have to use u-center to configure the receiver. Thanks again for all the help, I will post a pastebin of the .conf file we used where we had successful results in case anyone wants to take a look at it.
rtk.conf file for RTKRCV:
https://pastebin.com/sk2t23ba
Hi Sandro,
That’s great to hear it is all up and running. I forgot to mention in my previous post that I tried both processed and raw RTCM data and found that the processed data was not as effective as the raw data. I believe the RTKLIB software should work with some patience and configuring but I did not have time to really dig into that in my testing. I am going to talk to the engineer who designed the board and see if they have any other input or suggestions for using that or another software.
I am sure other users would greatly appreciate any updates on your .cmd file for RTKRCV so there are more options out there for getting an RTK lock with this and our other RTK GPS breakouts.