the 24X sensor value should stop updating after the PCM starts to ignore it(~1250RPM for a FWD calibration and I think 2000ish for RWD). why GM chose to split those RPM thresholds, I don't know.

I've had some FTDI boards act funny before, but it usually takes some abuse before that happens. my ALDLCable.com version lasted about a year before it started getting wonky, then I built my own. unfortunately, due to the 8192 baud speed, options are somewhat limited. the CP2102 can be made to work, but I can't really say if it's any better. at this point, my USB ports themselves are getting kind of worn out and contributing to me shallow breathing during a flash.

with a 2.1MHz clock speed, even a 250nS PROM is going to be more than fast enough for a nearly 500nS cycle. stock PROMs should be 120nS though.

the hell is it with the patch function lately? I've never seen it do that before, let alone twice with one BIN. i'll have to see if Mark can replicate it and verify it as an actual bug rather than us screwing something up.

the data given out after a crank attempt looks like typical mode 0 data(trip computer and some digital dash stuff). then for engine running, the "response" literally filling up the data queue with repeating values is certainly something else causing interference, but being that repeatable is odd, I would expect some dithering of the signal.