Ok, if you haven't already read through this page do so: http://qgroundcontrol.org/mavlink/crc_extra_calculation. The field reordering caused me more then a few headaches. (The fact that I had 3 three days to make this work before a group of highschool students would be using it for a robotics summer camp didn't help either). Anyway, the gps parse may or may not be correct for the default gps message that is sent. I remember I was messing around with the rover code as well to get everything working but that shouldn't be a big deal. Also I had disabled all of the failsafes on the rover side because I didn't have time to implement the heartbeat.
Anyway on to the code.
Assuming you have read the table at the bottom of the "start" page on the wiki and understand the message header packet setup, lets begin.
CRC VI:
First off, in my code it was easier for me to implement the checksum as a dll call, though I believe there are pure labview implementations of it around, Because of this and the fact that the checksum does not include the start bit (0xFE) the CRC vi accepts a message, determines the correct MAVLINK_CRC_EXTRA number, calculates the checksum and adds both the start bit and checksum to the output message. The VI will also verify that a received message has a valid checksum
initialize VI:
all this one does is turn off all data streams, then turn on the ones that I needed. Remember System ID 255 is a groundstation and my component ID was 190
Read VI:
First read one byte, if its a start byte read the next 5 (the message header), than read the rest of the message based on the payload length in the header plus 2 bytes for the checksum. After a message is read check the CRC, if its valid put the message into the queue, if not ignore it.
Parse VI: (the one you probably care the most about)
Pull one message out the queue, add the ID to the list of received IDs if not already there.
Based on the message ID parse the message. This is were things get hairy. Because the messages are dealt with at bytewise level you have to convert the string to a byte array first. After this you have to split the array based on what data type in the message it is. (uint8 is one byte, uint16 is two and so on) Then you need to reconstruct the data into labview types that you can do something with. This is were the field reordering and the fact that everything is little endian come into play. This can be handled in any number of ways but the easiest in my opinion is using array subset, then reverse the subset array (I didn't always do this because as soon as something started working I moved on to the next one.), then typecast the array into the data type defined in the message. I don't think the RAW IMU parse is correct because we didn't used it, so I never fixed it. Heartbeat, System Status, RC, GPS, and Attitude should all be good though.
Also remember that any messages you send need to be little endian and field reordered as well.