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.
- 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!
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.
"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!