Close

TI-86 OBDing Revisited

A project log for Vintage Z80 palmtop compy hackery (TI-86)

It even has a keyboard!

eric-hertzEric Hertz 03/11/2023 at 21:250 Comments

I started peeking back into my TI-86 OBD-reader yesterday... Van's acting-up again, a little. I was surprisingly far with it, already able to send-then-receive via the bitbanged UART, but it's a weird path I went down...

Thing is, my van has two of the many possible OBD2 protocols... One allegedly invented by the manufacturer, the other allegedly never even used in vehicles by this manufacturer(?!). The former has data going constantly. But it's far too fast to be processed in realtime with my bitbanging. In fact, it's so fast the ons and offs are only registerable if I use the tightest loop possible, using the dedicated "sample input, store in memory, repeat" instruction. So, even though there's a complementary "write-output from memory, repeat" instruction, bitbanging output is basically not an option, because the protocol also requires monitoring the bus for collisions *while* transmitting.

Weirdly, as far as I can tell, the system components are nearly exclusively wired directly, not via a serial bus of any sort. So, I don't understand why there's so much chatter on that serial bus. There's one weird exception, which frankly makes little sense. It seems the analog output of the oil-pressure sensor feeds directly into the dashboard circuitry, wherein there's a microcontroller used to drive the stepper-motor for the oil-pressure needle. LOL. Why not just use a standard analog gauge? I *think* it's to do with the sensor's not actually outputting analog at all, it seems to be merely off and on. So, then, I guess the microcontroller interprets pulses (caused by fluctuations in oil pressure? Where do those come from? Something to do with the movement of cams?) and tries to convert those pulses into an analog-ish reading. But information on the matter is weird. Some claim the gauge actually does nothing but show if there is no oil pressure, that it simply sits at some arbitrary position unless it's too low, then sits in the red and turns on the light. Weird. But why's this relevant? Because as far as I can tell, that microcontroller also talks via serial to the computer... but since all the other gauges are directly-wired, it seems to suggest the high-speed "bus" is only communicating oil-pressure readings to the computer! And that, it would seem, is the /only/ chatter on the bus(?!) and a lot of it!

Anyhow, the other serial bus is silent. Which makes more sense for a "request-then-response" protocol like OBD...

So, basically, I wrote my entire TI-86 assembly program and libraries (over nearly a year) based on the presumption that that bus was "the one", which it turns out is a bus nowhere-I've-seen documented as ever being used by my vehicle's manufacturer. Heh.

So far I don't even know enough detail about the packet-protocol... And experimenting with that, in assembly, would be quite an ordeal. Especially if there's no No-Acknowledge if I get something wrong (like the "address" of the computer, or the CRC algorithm, or the header bytes).

So, really, I put a HUGE effort, over nearly a year, into something that may give zero indication that it never would've worked in the first place (e.g. again, why would this bus even be implemented by this manufacturer? I mean, the pins and idle-voltage are there, which is weird-enough).

And, then, the fact is that if it does work in this system, I could've saved myself (could still) a *ton* of effort by programming it in C on a fast computer, where data logging is an option.

I really have no idea what I was thinking doing all that in assembly on a tiny screen with a tiny RAM and awkward "keyboard."

But: After stepping away for a year or more, I was able to compile my old code without a hitch (I think I swapped the batteries once or twice in the meantime)... And, I guess, if my presumption that that bus is usable is actually true, then it's really only a tiny matter to actually try a request and see if there's a response. The request-response mechanism is already implemented, the UART bitbanging already functions, the bitbang timing is already measured from the chatter on the other bus. At this point, It's just the matter of figuring out how to formulate that request. Who knows, maybe it will NAK if I got it wrong, and I'll at least know I'm not barking up the wrongest tree.

So, why not try it? Heh. (Why didn't I way back when?)

Discussions