When writing the code for receiving files, I set 400 ms emergency timeout for receiving UAVCAN_PROTOCOL_FILE_READ_ID.
After testing the reception of files for about a week, I thought that I coped with this task. But after half a year of work, errors began to appear when receiving files.
Due to the delay of the data transmission channel (PC-> USB-> CAN + internal optimization of the transmission systems for data caching), the response can sometimes come with a delay. After the timeout is triggered, I form a repeat of the UAVCAN_PROTOCOL_FILE_READ_ID command with the previous offset value and send the request again, I have 5 such repeats.
After a time when the system (PC-> USB) caching channels go back to normal, I get several responses from the system cache, at the same time, I get confused with the data received in a row, I cannot easily identify them, the response does not contain information about the current segment.
If each response had an additional offset field, then we can understand which part of the file came.
For the time being, I have fixed this by increasing the packet timeout sufficiently.
In this case, it would be nice to add an offset field in the response structure uavcan_protocol_file_ReadResponse, I think so.
// uint32_t offset; <- as a package identifier
uint8_t * data;
I also encountered the problem of transferring files to WINDOWS 10, with similar symptoms. Everything works well on WINDOWS 7.
Can you advise on the correct algorithm for receiving files ?!