your analysis of how eehack recieves data is totally incorrect with regards to timing. it doesn't demand anything but correct data. it receives all available data with at least a 1 second per request timeout until the packet length that is expected is recieved. of course a packet that's the wrong length is definitely in error so it's rejected immediately, and it does retry the last request in most cases, which is the only logic that will work to continue operating, as the ECM doesn't have any knowledge that the request has failed.

it also has things like dynamic garbage collection in place which stops sending packets for a short time after a major error and discards any out-of-band bytes which is a great way to reject noise which is a momentary issue and maintain a good datalogging rate, this is something i tested by causing deliberate serial interference and it's necessary to not nuke a datastream as the serial interface will happily buffer the noise and the datalogger will eat it right up. every valid packet will decrease the time spent collecting leftover serial noise between packets, every erroneous packet increases it.

the analysis you're doing could yield interesting things but you should stop looking for a software solution to your problem which is 100% in hardware somewhere (i base this on the fact that nobody else having this problem....).

most of the eehack users that say 'hey eehack doesnt flash my car but winflash does' end up having winflash brick their car later. maybe it's nice my software is a bit more bitchy and gives up more easily when there's so much noise on the bus. think of it as a feature not a bug