There is a strong correlation of corrupted hub to device data packages when a package is received during the same time one is send.
This is only apparent under rather unusual usage. In the following I am sending 32byte packages from the device to the hub at about 100Hz and sending packages from the hub to the device at about 10Hz.
Here is an example:
The top row are the bytes from the hub to the device. The row below is device to hub. The following two rows try to decode with the wrong baud rate and should be ignored. The byte EB is superfluous and breaks the package.
There is a pattern:
The arrows mark the corrupted packages. Now, there is some sort of a bug in my implementation in the device. When it receives a bad package it stops sending for some time because the both threads are in way coupled which they should not be. I kept it on purpose here because it is visually striking:
All the timeouts of the device sender are related to bad packages from the hub and all of those correlate with an incoming package at the same time.
The package I am sending from the hub to the device is always the same. The corruption was for all packages I checked also the same.
I found this behavior in the context of #2698. But I am certain that the disconnects have nothing to do with this here. I outlined how to produce this behavior above, that mode is not something which I use in normal operation with the device.
There is a strong correlation of corrupted hub to device data packages when a package is received during the same time one is send.
This is only apparent under rather unusual usage. In the following I am sending 32byte packages from the device to the hub at about 100Hz and sending packages from the hub to the device at about 10Hz.
Here is an example:
The top row are the bytes from the hub to the device. The row below is device to hub. The following two rows try to decode with the wrong baud rate and should be ignored. The byte
EBis superfluous and breaks the package.There is a pattern:
The arrows mark the corrupted packages. Now, there is some sort of a bug in my implementation in the device. When it receives a bad package it stops sending for some time because the both threads are in way coupled which they should not be. I kept it on purpose here because it is visually striking:
All the timeouts of the device sender are related to bad packages from the hub and all of those correlate with an incoming package at the same time.
The package I am sending from the hub to the device is always the same. The corruption was for all packages I checked also the same.
I found this behavior in the context of #2698. But I am certain that the disconnects have nothing to do with this here. I outlined how to produce this behavior above, that mode is not something which I use in normal operation with the device.