Raspberry, failure?

What the f*!! When trying another raspberry pi3b, together with a Mega board, suddently* the communication between the board and the raspberry stopt working. The connection is made up by an apc220, TTL to USB converter. I tried several different MEGA boards with the same result. Another raspberry is working correct, and is not showing this behaviour (working correct). The software on the Pi's is exactly the same. So, it must be something in the hardware... So when this problem occured, i build additional logging in the python script. Conclusion: after some time, the normal received ascii characters by the raspberry are replaced by corrupted bit strings like 'b/x00/x00 types. The python script is not accepting these information and the HMI screen is stalled. Information is still received but cannot be processed by the raspberry to fill the beautiful HMI screen.

The procedure for receiving and processign the data on the raspberry:

a special thread is receiving data from the USB port as long as there is data available. The thread is looking for special terminator characters and then strings (MEGA2560 messages) are put into a queue, to be processed by the main thread for the HMI screen.

the main thread is looking at the queue and is processing the queue messages when there are message available. After reading from the queue, the HMI screen is updated or whatever action is required

I analyzed from the logging after the moment the communication seems to be currupted, that i got an error reading the message queue; the qsize seems to be greater than 0, while reading from the queue results in an error; queue.empty is true!

Workaround:I know, it's a work around... but after the error, reading the queue, the serial communication channel is now closed and opened again; everything is working again, but some messages must be lost between closing and opening the connection.... The new software release is available in the first week of october 2018 on the download page.

Remark:"Suddently" is not so random, it seems to be a fixed time of 90 seconds (the same time at different baudrates of 9600 and 115200)... if someone has the answer to this communication problem, help!