$EEHack Read Failure Every Time?

[steveo]

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

[steveo]

also waiting around until the buffer is 'more full' has nothing to do with noise rejection. reading one big buffer full of noise or lots of short buffers of noise will give you identical results.

[NomakeWan]

Fair enough. I went looking for differences based on bus communication, led by the repeatable, consistent results of tests via a serial comm sniffer. I will be the first person to say that I have no firm grasp on the underpinnings of serial communication, as my knowledge only goes as far as picking the protocol rules (baud, 8N1, etc) and sending hex bits and getting hex bits in return. So I was going through the logged data with only 'pattern recognition' rather than an actual understanding of what was happening.

I do agree, based on the verbose output, that random bits appear to be being flipped for no reason. And that, as discussed before, there is something inherent to this particular chassis that is causing that to happen. Both things most certainly point to the ALDL bus being noisy or otherwise unreliable in terms of level state. Sadly I don't yet have an oscilliscope to do waveform analysis, but I suppose starting over and inspecting every ground on the car starting with removing the battery and inspecting the PCM wiring more thoroughly is in order.

I finally have quality Corvette time this weekend thanks to our race car stuff being finished, so I intend to get a bunch done. I'll report back if anything changes. :) Thank you once more, steveo, for making a fantastic program. I know it seems like I must be bashing it but seriously, I'm not--I just wish I could use it as much on my '94 as I already do on my '95, because it really is that good.