As I mentioned earlier in this thread, I replaced both the base and rover radios yesterday - same model - but appear to have newer firmware. No change in the problem - so I’m guessing that eliminates the noisy radio problem.
As I also mentioned - it’s uncertain that the saturated transmission buffer is the cause of the GPS glitches - it was just something that was proposed. As Yuri noted also above in this thread, he has an F9P RTK rover running fine with a saturated transmission buffer.
I would like to know why one of my copters has a saturated transmission buffer and the other does not. The radio setup is identical. I have only one base radio - so I set all my “rovers” up to match it. You’ll also notice from the thread above that I shut down almost all the telemetry threads on Mission Planner - so it’s a mystery at this point as to what’s going out over the telemetry radios.
As I asked on your facebook response to my post, I’d also like to know how is it that the ArduPilot firmware knows and logs the radio’s transmission buffer percentage.
By the way - before attempting RTK I typically use my telemetry radios to link to Qgroundcontrol running on an Android tablet - just for situational awareness - and as a backup. I use Yaapu, so my primary telemetry information is displayed on my control radio. Anyway - I’ve never had issues with the telemetry link to either of my copters with the Qgroundcontrol ground station.
If you have time, I’d appreciate it if you’d read through this entire thread, and maybe look at some of the logs. I’ve uploaded the entire SD card contents of both my copter’s logs up on Dropbox.
Thank you for staying in the loop. As this problem came to light because the GPS glitches were so severe that it caused a EKF Failsafe, I’m guessing lots of people would benefit from knowing what’s happening here.
Regarding the radios TxBuf, the significance of the buffer being full depends on whether the GCS is using hardware flow control to the radio.
The radio has (or should have!) 6 wires that go to the GCS. They are RX, TX, GND, 5V, RTS and CTS. The RTS and CTS pins are “hardware flow control”.
In the RFD900x the radio sets the CTS pin high when there are less than 17 bytes free in the buffer and sets it back to 0 when there are more than 34 bytes free. If the GCS software (presumably mission planner) sees this as high then it should stop writing to the serial port. This matters as if it keeps writing then the data will be lost as the radio has nowhere to put it.
Note that there is a RTSCTS option in the radio. That controls whether the radio looks at the RTS pin to determine if it is able to write bytes to the GCS. The radio sets the CTS pin to 1 when the TxBuf is full regardless of the setting of RTSCTS.
The reason I mention all this is that it is possible that either MissionPlanner is not correctly looking at the CTS pin, or the CTS pin isn’t being carried through whatever USB serial adapter you are using. That would cause the effect you’re seeing, where packets being sent to the aircraft are corrupted.
The way you check these things is with a logic analyser looking at the RX and CTS pins on the radio. If the RX pin shows serial data being sent (ie. data from GCS → radio) while CTS is high then you know that hardware flow control is not working.
Cheers, Tridge
On the Mission Planner screen for setting SiK radio parameters there is a check box “RTS CTS” on both radios. Both these check boxes are blank.
Should I check them?
My physical connections to the carrier board on the copter and to the PC running Mission Planner are ordinary, common, and not configurable to the best of my knowledge.
On the copter, I use the cable/harness that comes with the SiK radios designed to connect to a carrier board Telem port.
On the ground station, I have the SiK radio mounted in a BASK Aerospace “AeroLink Base” that holds the RFD900’s and has it’s own FDTI between the radio’s serial connections an an external USB connector.
the RTSCTS options in the radio don’t matter in this case, as that is what stops the radio from sending data when the recipient isn’t ready, but the issue you are presumably seeing is the GCS sending data when the radio isn’t ready.
I’m not familiar with the BASK AeroLink Base. I would hope it connects the RTS and CTS pins, but it is possible they saved 2 wires and left them out. You’d need to open it up to check.
The problem turned out to be with the firmware I’d upgraded to - and perhaps it’s parameters. By reverting to the firmware that came on the F9P receiver (which was three versions old) the problem was resolved.
I also found a way to reduce TxBuf - and I’m still researching that further. But I’m not sure that issue influenced the problem.
Sorting through the F9P RTK issues, Yuri suggested doing the U-Center function that resets the firmware parameters to their defaults. He said that had cleared up problems for him in the past.
I thought I had read that when loading new firmware, the old parameters would be cleared and re-loaded with the defaults for that version of firmware. I upgraded my Holybro F9P Helix receiver from 1.30 to 1.32 and found that even after the upgrade I needed to do the parameter reset to their defaults in U-Center. The F9P receiver wouldn’t function properly in RTK without it. Who knows what else it wouldn’t do.
I think this is an important point because I don’t recall reading anywhere about resetting parameters to their defaults when upgrading u-Blox firmware. Thank you Yuri for suggesting it…
I didn’t latch on to your comment when it came through - My apologies.
While this problem had a couple of dimensions - you were spot on regarding one of them.
On advice from the u-Blox support portal, I configured the receiver (via ArduPilot parameters) to only use GPS and Glonass - as you suggested in the first place. I was also advised to disable SBAS - which I did.
The results were spectacular. I was able to set the refresh rate to 10Hz, and I get a RTK-FIXED lock almost immediately on power up.
