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.

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

serial sniffing on something with tx and rx on the same line is difficult.

the datalogger itself has to deal with the same thing, but since its sending the message, it knows to discard it when...

well i don't see much good there to help with our comms but why dont we add that to the definition for the next version.... i did write multiple device support into EEHack, and it's barely been...

there must be command sets for the ccm has anyone seen any documentation for them? a .ds file or something?

we had a conversation qutie a while ago perhaps involving kur4o where we talked about some b-body and y-body extra devices, but the only one that we deemed necessary to 'maybe' silence was the brake...

since its writing over a running datastream its hard to tell which device is misbehaving but maybe we can probe a bit. ill see what i can come up with

awesome thanks for that testing. you've confirmed it was definitely ignoring checksums in the last version. honestly given the drastic changes in the datastream code over the last few versions, and...

could you please try the latest beta out to see if you get any similar data corruption? i dont know anyone else getting that problem consistently enough to be a guinea pig

i agree that the data is corrupt for that frame, BLM cell 50 isn't a real thing.

it's either corrupt data in ram from the ECM itself or corruption on the datastream wire. i'd suspect the second,...

just for the hell of it swap ecms and see if it behaves itself on your new (working but beat up) car

appreciate you putting all this effort into trying to get it working

i have no idea why read would repeatedly fail in your case

i didn't spend much time working on or debugging flash read or...

i didn't read that part. its totally possible that the bin is just borked then. that bin sucks anyway, you should just flash back to factory and go from there. yes hypertech does odd things with...

thing is if the read always succeeds in eehack but the checksum is always wrong, could be a problem with the bin itself. have you confirmed you're running EE and not EEB?

odd for sure. just use winflash to read the bin then. you only need to do it once

do this too

http://fbodytech.com/ftdi-serial-latency-and-threaded-eehack/

no diodes and resistors necessary

eehack was mostly developed and tested with the rx and tx wires literally twisted together and hanging in mid air, from a cheap ftdi ebay board