I have just completed my implementation of of using the MAVLink XML to setup decom tables to process the MAVLink 1.0 stream. In the process of checking out the decom process I noticed that Messige ID 25 is not properly populated. Looking at the attached file 07201700.lis which is a hex dump of some message ID 25 frames you will see that fields satellite_prn, satellite_used, and satellite_elevation are not properly populated. Fields satellite_azimuth and sattellite_snr are suspect, The attached file 25.lis is an excerpt from the MAVLink header file defining message ID 25. I checked it and it matches the MAVLink XML message definition. This message ID is useful in determining the geometry of the GPS fix.
Thanks,
Warren
Replies
Hieu,
Nice to hear that, can't wait to see.
Seth
Sorry for late response, pls give me some time to extract the Mavlink proc from a bigger project.
Hieu.
Hi Warren,
Could you please tell me how to get the .lis files? I'm trying to parse the Mavlink 1.0 packages as you have done, but can not figure out what structure do these packages have. Would be very appreciated if you could let me know where I can get such info.
Thanks,
Hieu.
Our gps drivers do not provide values for all fields that exist in the MAVlink message. I don't remember off the top of my head, but I don't think we are decoding any quality metrics other than the fix type, number of satellites used in the fix, and hdop, pdop and vdop. Very few users are interested in things like the satellite elevations and azimuths, and adding that capability would take resources from other things.
If it is important for your use you can always branch the code and modify your branch. You could submit a patch for this for inclusion in the trunk which may or may not get incorporated based on the resources it consumes.