I’m running some experiments with man-in-the-middle-ing a U-Blox M8N gps chipset and 3DR Solo.
The machine in the middle can receive packets from the GPS in UBX and construct a valid fix. Passing these packets to the Solo does not result in a fix. My first guess was that the solo was sending configuration messages that I was ignoring, so I unconditionally passed all serial traffic toward the GPS as well, though the port settings are held constant at 38400 8N1. The GPS seems to be acking these in UBX (0xB5620501), but still no fix on the Solo.
Does anyone more familiar with the inner working of ardupilot’s GPS handling have any ideas?
I’ve not worked with the solo code explicitly (which appears to be from before I started maintaing the u-blox driver) so take the comments here with a grain of salt.
The current released versions of ArduPilot (including Copter 3.5) are pretty aggressive about configuring the u-blox GPS and will refuse to arm without configuring it completely. However the older versions (which solo is based on) are much more primitive and simply write out the settings they want on start, and then send disable packets for any GPS message it doesn’t want to receive, it will reenter the config mode (where it just blindly writes out some config) if it hasn’t recieved an update in a long enough period of time.
I’m not sure that was much help, unfortunately I’m not familiar with Solo’s inner workings there. Are you seeing the solo indicate it has lost the driver, or is it just stuck in the no fix state? (IE a GPS_FIX_TYPE of GPS_FIX_TYPE_NO_GPS vs GPS_FIX_TYPE_NO_FIX)
Mission Planner lists GPS: No GPS. If I pipe the output of my MitM software to another tool like gpsmon, I have a full 3D fix with 7-13 sats indoors sitting on my bench, so I’m fairly certain that if the Solo would cooperate the fix would be okay. I’m not sure if it would change anything, but I currently have arming checks disabled and put the Solo into “FLY” mode to make the infernal beeping stop. I didn’t notice anything in the UBX driver that this would affect, but you know that codebase far better than I do.
Currently, the behavior I’m encountering is the ability to send one message to the Solo, then the Solo regurgitates that message back at me verbatim – not a MSG_ACK_ACK – with errors beginning about fifteen bytes in. From that point on, the Solo send mostly gibberish with the very rare ublox sync bytes, but then an invalid class like 0x12. Occasionally I also get messages from the class 0x03, which aren’t present in the official UBX documentation, but seem to be trace data as they are implemented over in RTKLIB.
I’m guessing that the jump from valid data to gibberish is a baud change, but I don’t seem to get anything published from the Solo beforehand, making the jump annoying to detect. I know the most recent versions of AP set the ublox link to 115200 8N1, so I tried setting serial 3 to this speed as well as the ublox module itself, so that both communications links in my setup are operating at 115200. I believe I disabled autobauding everywhere I could. My hope was to negate the gibberish from the baud change by never actually changing baud, but this still hasn’t seemed to help. Perhaps older versions chose a different baud? Really anything that you think could maybe possibly begin to reconcile this behavior would be welcome; I’m running out of ideas.