even a really crappy ebay scope is fine for most automotive work for guys like us. i have a real professional tube scope and a hantek that i think was about 50 bucks on ebay, i usually use the hantek. the software is really bad but since there are so few controls and so few options, trying to figure out why your waveform isnt showing up doesn't feel like flying the space shuttle. they're really fun to have, even just for measuring dc stuff, you can measure the quality and stability of your voltage, not just its value

as far as the checksums go, it's totally possible for random noise to break such a simple checksum and a few bad bits would slip through, but pretty unlikely as it would have to coincidently add/subtract the exact value from both the data payload and the checksum, but i would also expect noise extreme enough to fuzz that math to also cause millions of times more bad checksum events

is it possible there's a bug in eehack where the packet right before a bad checksum can slip in there? yes but i would expect other bytes to be glitching out too

is it possible that total fuzz or even occasional bit flipping in your datastream would coincidently fool the checksum so incorrect data gets through (by adding exactly the same value to one thing as it subtracts to another)? yeah, but the odds are insanely low

i actually didn't see the phantom DTC codes pop up but i also didn't really dig through the log much, what timestamp do they occur at?

oddly enough i remember seeing logs in tts datamaster with noise in the datastream, odd nonsensical DTCs would pop up and then disappear right away with no other effect in those areas as well. it could be a bug in EE itself as i've never observed that with another mask. i don't think we've ever had a proper reverse engineering of the ALDL code with regards to the checksum, and i think i remember kur4o theorizing that it's done in a chip