I posted the same question on github on the px4 forum (https://github.com/PX4/Firmware/issues/13728#issue-536289955), but it should get some attention here as well.
I’m currently trying to integrate a GPS module controlled by an stm32 onto my drone and make it communicate with the flight controller (holybro kakute f7) via Mavlink. To do this the stm32 will read and process all GPS data and send a Mavlink message, currently a GPS_RAW_INT message with message ID 24. (see discussion What MAVlink messages are used for the GPS toolbar indicator?)
The code to create and send a test message with baud rate 57600, 8bit message and 1 bit stop bit on the stm32 is the following:
uint8_t buf[160];
volatile uint16_t n;
mavlink_message_t msg;
while (1){
for(int i=0; i<160; i++){
buf[i]=0;
}
n= mavlink_msg_gps_raw_int_pack(1,220,&msg, HAL_GetTick()*1000.0, 3, 100, 100, -20, 1, 2, 3,4, 10, 0, 00,00,00,1*00000.0);
n = mavlink_msg_to_send_buffer(buf, &msg);
volatile int xx=0;
while(xx<n){
sendserial( (uint8_t*) &buf[xx], (n-xx>10) ? 10 : n-xx);
xx=xx+10;
}
}
When sniffing the serial output of the stm device baud rate 57600 I get something along the lines of the following hex output:
fd 1e 00 00 64 01 dc 18 00 00 60 c3 3f 01 00 00 00 00 64 00 00 00 64 00 00 00 ec ff ff ff 01 00 02 00 03 00 04 00 03 0a 52 fe
Decoding it shows me that it is the correct message, the serial port is also configured correctly, with the start being fd, sysid set as 1, compid at 220, and so forth. However, when attaching QGroundControl to my flight controller with the stm32 attached and sending shows no messages with ID 24 as incoming. The GPS indicator also shows no change.
The next step I took was analyzing the traffic between the flight controller and QGC. To do this I sniffed my serial in/outputs on the corresponding ports. The incoming packets (on my PC) looked like they corresponded to the Mavlink messages being sent by the flight controller to QGC, which were also the packets being shown in the Mavlink inspector widget. Analyzing the outgoing traffic showed me the following:
fd 09 00 00 99 ff 00 00 00 00 00 00 00 00 06 08 c0 04 03 15 3c
fd 0e 00 00 9a ff 00 04 00 00 89 28 cb 07 00 00 00 00 0c 00 00 00 01 01 a8 0a
fd 09 00 00 9b ff 00 00 00 00 00 00 00 00 06 08 c0 04 03 24 28
I haven’t gotten around to deciphering that, but it only looks like a hearbeat message from the QGC to me, something which a flight controller would not NEED to operate by itself. Furthermore, when I try to manually arm the drone using QGC the command constantly gets rejected. There is no clear reason for this. The setting for disabling the requirement for GPS lock is set and I’m using a fresh battery. I will have to check each of the onboard sensors tomorrow to check if one of them is causing the issue, however to me it seems right now that the flight controller is not accepting Mavlink messages correctly right now.
Essentially I have two questions right now: Are Mavlink messages being randomly rejected by the flight controller, including command messages as well as GPS messages, and if that is not the case why does the flight controller not react to the incoming message from the stm32, giving it all the GPS information it needs. In that case, does the flight controller not listen to Mavlink messages but instead only to the NMEA protocol?