I simply adore all work you all have done with this code, it’s amazing!!!
The “minor” issue now is Piksi - Pixhawk communication. It works but status is not stable although Piksi software seems stable.
It’s not related to dual GPS issue, I have read about, as it also happens when I disconnect the uBlox GPS and only have the Piksi connected.
It is NOT related to communication! When I set the Piksi in simulation mode status is very stable!
As the Piksi console shows stable values, as the rover dont move, I guess it is an issue in the function.
Hi Anders. I have only just got my Piksi’s working and haven’t had a chance for a comprehensive test.
I’m not quite sure what the problem is your having. I believe your saying the GPS position moves around alot when the Rover is stationary and you only have the Piksi - is that correct? Do you have a dataflash log from when this occurs so we can have a look?
I can fix that. No! in the status tab of Mission planner GPS Status 2 jumps from N to 1 and back to N but Nr of satellites remain and Piksi Consol shows stable results.
If I disconnect the primary GPS the PixHawk LED toggles between Blue and Green as if I was toggeling a switch.
On either side some improvement is needed as RTK isn’t usable.
My setup is as below.
Piksi and 3DRadio indoor with External GPS antenna on a metal plate
Piksi with the external antenna on a metal plate standing still a few meters away
Piksi console viewing result from indoor Piksi (floating but very stable positioning)
Missionplanner, via 3DRadio, viewing status of GPS 2.
I think your problem is inconsistent corrections communication. Piksi will stop computing an RTK solution momentarily if it hasn’t received corrections information for 1 second. The driver, in turn, will drop down into GPSSTATUS2 = 1 if the solution is suppressed for 500 milliseconds. Thus, even though the piksi console is showing stable results, I hypothesize that there are some short drop-outs on those results which are causing the status flipping that you are experiencing. I can actually verify that through your logfile. Below is the plot of interval between successive RTK messages being sent from Piksi to Pixhawk.
As shown on this line of the driver the way it is currently implemented, if the time between messages exceeds 500 milliseconds than the driver says the mode is “no solution” which corresponds to a GPSSTATUS of 1 in the telemetry feed.
For mitigation strategies, you first need to make sure the corrections are delivered in a timely and consistent manner. Make sure that you have configured your corrections strategy in one of the recommended configurations from the Swift integration guide.
Second, you need to make sure that the antennas have good enough signal conditions to track a high number of satellites. Below I plot the number of satellites during your short datafile. This is too few satellites for consistent RTK performance. Make sure your antenna is mounted far from noise components and you operate in an area with good skyview.
Thank you very much for your detailed answer Dennis!
I have a nice blue sky today and both Piksies receive 8 to 9 satellites each but the issue remains.
Both antennas are far away from other electronics and are placed on a big metallic plate.
Simulation mode shows stable GPS Status 2! That should mean no communication issues Right?!
The Piksies today have stable Fixed RTK and the dot hardly moves at all in the console.
I’ve been over the settings again with no sucess. Trying “soln freq” 10 (default) made no change.
I have standard Piksi - Pixhawk cable from 3DR and have also tried to replace it (bought 10 pcs)
As neighter Piksi nor Pixhawk uses RTS/CTS there isn’t likely a cable problem.
Piksi console -> Advanced
UART A has a lot of CRC errors (on both piksies) but UART B has none!
