Jane, while I dont have a build to test with, my thoughts were more around the UART and buffers V “refresh” rate. e.g. if it was happening too fast, there may not be a full packet to decode…
that said, I assume this bit of code was meant to deal with ensuring enough time had passed
// Check if timeout occurred with data in buffer
if (current_time - last_data_time > timeout_ms && message_buffer.length() > 0) {
_process_buffer();
has_new_data = true;
}
But if the message_buffer was == 0 then it would skip over the time delay and check the uart buffer.
Then the other bit I was not too sure on was
// If buffer is empty or we recently received data, append to buffer
if (message_buffer.length() == 0 || current_time - last_data_time <= timeout_ms) {
message_buffer += data;
} else {
// If timeout occurred, process the old buffer first
_process_buffer();
// Then start a new buffer
message_buffer = data;
has_new_data = true;
}
If the message buffer was > 0 bytes long, then it would not append the new data, but if it was == 0, it would append the data, but not process until next time.
To be fair here, this is a high level thought as Im reading the code, but could be that way for a very good reason.
I normally process uart data in its own thread or via IRQ. so would append data as it arrived into the buffer. Then if there was at least 1 full sentence present, parse it.
Of course that is not always ideal… and there is more the one valid way to do things.
EDIT: I just want to be clear, my thought was data could get lost if not sampled at a fair rate. That does not mean that is whats happening.
