I am a beginner with mavlink and even pixahawk. I need to just parse mavlink data coming from pixahawk. (Mavlink v1, pixahawk v5plus), on Linux PC (Ubuntu). I have 2 processes in context of this question. (The Pixahwak is already cofigured to send some messages HEARTBEAT, ATTITUDE etc).

I have written C code that reads serial port data which gets mavlink v1 data from telemetry1 port of pixhackv5plus and saves each byte by byte in shared memory segment created using shmget()/shmat(). That shared memory segment remains intact even after this process exits.

Now, I run another process that reads data from this shared memory buffer and parses byte by byte. This parser process has not been completely written by me but I took code from
https://github.com/mavlink/c_uart_interface_example and for mavlink v1, reusing c library from https://github.com/mavlink/c_library_v1 (My pixahawk sends Mavlink v1 data).
In file serial_port.cpp in c uart example above, I have removed code that calls read(fd..) but taking shared memory data byte by byte and passing to mavlink_parse_char(). This is not working, I am getting msgReceived as false through out, though I know this data contains valid mavlink messages.

Am I right in this methodology? Please guide. Once this works, I have to replicate parser on an embedded platform, in C.

Code for reading serial data from pixhack at:

Code where data(each byte) is read from shared memory and fed to mavlink_parse_char() is at: https://github.com/developb/mavlinkv1_parse_v0/blob/master/serial_port.cpp

Here, this is the line I modify that makes each byte be taken from shared memory instead of serial port:

 int result = _read_port(cp);
 //cp = (unsigned char)(*(unsigned char*)shm_current_addr_temp);
  • $\begingroup$ Most would do this using file io. Particularly on Linux where all the infrastructure is designed around file manipulation. Is there a reason you are using shared memory? Why not a pipe? Why not dump to storage and read from storage? $\endgroup$
    – hauptmech
    Aug 6, 2019 at 20:27
  • $\begingroup$ Shared memory gives more control, so I used that. I can run read and buffer as a process, and then parse as another process independently.I can make sure I don't miss any byte due to any processing latency and focus on buffering data to get each and every byte. I can at any point of time use gdb and check by debugging, the values in shared memory... $\endgroup$
    – DevBee
    Aug 6, 2019 at 21:30
  • $\begingroup$ You'll get better help if you link your code. $\endgroup$
    – hauptmech
    Aug 7, 2019 at 1:23
  • $\begingroup$ Does the embedded platform you eventually want to use support this kind of "shared memory" ? $\endgroup$
    – David Cary
    Jan 4, 2021 at 17:34

1 Answer 1


To use file parsing functions with in-memory data, you need to make sure the memory layout matches the file layout.

Likely problem sources are leaving out header info or using data structures optimized for memory (all c structures that have not been packed) when providing data to the parser.

  • $\begingroup$ I have copied each byte as it arrives to shm (checked sequence number of messages). The header byte (0xfe) is also copied into shm as is. So, it should be same as receiving data from serial port directly. I will have to delve deeper into code to resolve this, as I have reused existing code. I wanted to confirm my methodology is correct or not in achieving offline parsing, and any inputs are welcome, to do it in C specifically. $\endgroup$
    – DevBee
    Aug 7, 2019 at 10:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.