Enhancement request

[GoogleCodeExporter]

Feature that you'd like us to add or change you'd like us to make:

I recently development a method by which I can capture MAVLINK packets via 
Wireshark.  I also created a dissector that uses a combination of the 
common.xml and ardupilotmega.xml files in order to dissect packets correctly 
(found under /libraries/GCS_MAVLINK/message_definitions/ in your source).  From 
lines 946 through 953 of common.xml, the message "PARAM_VALUE" is defined.  In 
the xml, it says that the param_id comes first.  As I was analyzing the 
PARAM_VALUE packets that I captured in Wireshark, the param_id (a 16-character 
string) definitely did not begin until 8 bytes into the payload.  This led me 
to believe that the fields defined in the xml were out of order according to 
the mavlink message generator (or vice versa).  Please let me know if there's 
another file (instead of the .xml files in GCS_MAVLINK/message_definitions/) 
that you use to dissect the message types.  Perhaps the xml files are outdated.

Also, after further study, I could not find the param_type field anywhere in 
the payload, as the value should have been zero or one every time, but there 
was no byte in the payload that stayed at zero or one for every packet (or that 
wasn't part of a different field).  I thought that perhaps the very last byte 
of the payload (before the checksums) was the param_type, but after consulting 
the MAV_TYPES enum, I could not image why the value jumped between 0x02, 0x04, 
and 0x09 (instead of just being 0x00 or 0x01, since the firmware on my APM is 
ArduPlane 2.50), so I deemed that param_type isn't actually in the packet (or 
I'm getting a bad value).

Granted, I am using an APM 1, but it has the ArduPlane 2.50 firmware on it and 
sends a Mavlink 1.0 heartbeat, so I don't think that that has anything to do 
with it.

Anyways, I just edited my common.xml file's entry for PARAM_VALUE to the 
following (once I figured out the order of the fields):

          <message id="22" name="PARAM_VALUE">
               <description>Emit the value of a onboard parameter. The inclusion of param_count and param_index in the message allows the recipient to keep track of received parameters and allows him to re-request missing parameters after a loss or timeout.</description>
               <field type="float" name="param_value">Onboard parameter value</field>
               <!--<field type="uint8_t" name="param_type">Onboard parameter type: see MAVLINK_TYPE enum in mavlink/mavlink_types.h</field>-->
               <field type="uint16_t" name="param_count">Total number of onboard parameters</field>
               <field type="uint16_t" name="param_index">Index of this onboard parameter</field>
               <field type="char[16]" name="param_id">Onboard parameter id, terminated by NUL if the length is less than 16 human-readable chars and WITHOUT null termination (NUL) byte if the length is exactly 16 chars - applications have to provide 16+1 bytes storage if the ID is stored as string</field>
          </message>

Hope this helps improve the project!

Original issue reported on code.google.com by avidspar...@gmail.com on 2 Aug 2012 at 7:25

[GoogleCodeExporter]

I apologize for not giving an appropriate title; I'm certain I did, but it 
doesn't seem that way.

Original comment by avidspar...@gmail.com on 2 Aug 2012 at 7:42

[GoogleCodeExporter]

all packets have a 6 byte header and 2 byte checksum

Original comment by Meee...@gmail.com on 3 Aug 2012 at 1:25

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I understand that, and my dissector understands that.  An example packet looks 
like this:

0000   fe 19 46 01 01 16 00 00 00 00 ce 00 39 00 54 52
0010   49 4d 5f 50 49 54 43 48 5f 43 44 00 00 00 04 eb
0020   a1

"0xfe" is the start symbol, "0x19" is the payload length, "0x46" is the 
sequence number, "0x01" is the system id, "0x01" is the component id, "0x16" is 
the message id (PARAM_VALUE).  The payload begins at byte 6 (after the first 6 
bytes of the header, bytes 0-5).  As you can see, there are four zeroes 
starting the packet, looking suspiciously like the float field, param_value.  
"ce 00" is the little-endian encoded total "count" of parameters, and "39 00" 
is the little-endian encoded "index" of the current parameter.  Then the actual 
param_id starts at byte 14 of the whole packet.  Wireshark's ASCII 
interpretation of the packet is below:

0000   ..F.........9.TR
0010   IM_PITCH_CD.....
0020   .

As you can see, the param_id, "TRIM_PITCH_CD" doesn't start till byte 14 (since 
each ASCII character represents a byte).  And the last two bytes, you can see, 
are the checksum.

My program copies every byte of the packet correctly and in order.  So you can 
see that my analysis does include the 6 byte header and the 2 byte checksum, 
and yet the payload fields still seem to be out of order.

Original comment by avidspar...@gmail.com on 3 Aug 2012 at 2:00

[GoogleCodeExporter]

the param name is a fix length, padded with 0's aka "char[16]"

Original comment by Meee...@gmail.com on 4 Aug 2012 at 12:40

[GoogleCodeExporter]

Yes, I understand that the parameter name is a fixed length.  What I'm saying 
is the fields are out of order.  From my analysis, the fields appear as follows:

param_value (float)
param_count (int16)
param_index (int16)
param_id (char[16])

The snippet of hex that I posted was an entire Mavlink packet, including the 
6-byte header and 2-byte checksum.  This is JUST the payload:

00 00 00 00 ce 00 39 00 54 52 49 4d 5f 50 49 54 43 48 5f 43 44 00 00 00 04

So the fields are as follows:

param_value:  00 00 00 00
param_count:  ce 00
param_index:  39 00
param_id:  54 52 49 4d 5f 50 49 54 43 48 5f 43 44 00 00 00 (as you said, padded 
with 0's)

But the common.xml file says that the fields are in the following order:

param_id
param_value
param_type (this is the one I couldn't find, based on my analysis)
param_count
param_index

What I see in actual packets and what I see in the common.xml packet 
definitions are inconsistent.

Original comment by avidspar...@gmail.com on 6 Aug 2012 at 12:13

[GoogleCodeExporter]

ok, now im on the same page. The packets are reordered when converted from the 
xml to be byte aligned.Typicaly you will find they go from the the largest, 
32bit to the smallest (exluding arrays). you will need to look at the mavlink 
generator code to see how that decided to reorganise the paramaters.

Original comment by Meee...@gmail.com on 6 Aug 2012 at 11:11

[GoogleCodeExporter]

Ah, thank you for the clarification--makes a lot more sense.  Guess this thread 
can be closed!

Original comment by avidspar...@gmail.com on 7 Aug 2012 at 12:46

[GoogleCodeExporter]

Quick question--are the majority of the commands in the .xml files already in 
that byte order, or do they typically change (at least some)?  That would 
explain why I've been getting some interesting values for some of the payload 
fields.  I guess what I'm asking is if using the .xml to parse commands is 
still optimal, or if I need to change a bunch of parameters around in the .xml 
files.

Original comment by avidspar...@gmail.com on 7 Aug 2012 at 12:50

[GoogleCodeExporter]

if the packet was all int8's i dont think the packet would change. but if it 
was int8,int8,int16, the int 16 would be moved.

Original comment by Meee...@gmail.com on 9 Aug 2012 at 11:13

[GoogleCodeExporter]

Original comment by Meee...@gmail.com on 9 Aug 2012 at 11:13

• Changed state: BehavesCorrectly