1G Does low tire pressure trigger ABS?

[XC92]

A few days ago my Talon's ABS suddenly started pulsing on and off every second or two while (thankfully) driving at a slow speed right after pulling out of a parking space. I pulled over, turned the car off, waited a few seconds, started it up again, and it went away, only to reappear a bit later.

So I pulled over again, popped the hood and tried to remove the ABS fuse by the battery, but it was on too tight to pull out so I just pushed it back in, thinking that maybe it was loose. This SEEMED to have solved this issue, but of course it reappeared again eventually. This happened a bunch of times.

I finally realized that it might be due to low tire pressure. The front driver's side tire has had a slow leak due to a bent rim that I haven't taken care of, and if I don't refill the air every few days it gets pretty low. The very cold weather also compresses the air. So I filled it back up to proper pressure, and the ABS issue went away. Perhaps this was a coincidence, but I'm guessing that this was the cause.

What I'm wondering is why this would happen. Would very low tire pressure on just one tire cause the ECU or ABS computer to pulse the ABS, and if so why? Does the low tire pressure result in smaller (or perhaps greater) dynamic tire circumference when the car is moving, making it spin slightly faster (or slower) and fooling the ABS into thinking that it's slipping? Or is it something else?

Btw, is the software code in the ECU or ABS computer publicly (and legally) available, either through being officially released or by being reverse engineered, and what language was used to write it? Given that we're talking 80's tech, C or perhaps C++ comes to mind. I have a tech background so I'm curious how it works.

Btw the car's otherwise running pretty well, although it still has some (hopefully relatively minor) issues that I need to deal with, aside from the bent rim(s), especially a high and fluctuating idle, occasional rough start, and a bunch of non-critical wiring issues causing the sound system to barely function and the auto door locks to behave oddly (and why I always carry a spare set of keys on me). But the work I did on the car appears to have succeeded, specifically the trans rebuild and complete replacement of everything timing, seal and belt-related.

 

[jesse12345]

A bad wheel bearing can cause your symptoms. I'd jack the car up and make sure there's nothing loose first. Others can chime in if they have had abs issues relation to something else, but that's all I can give on advice.

 

[XC92]

I recently replaced the front wheel bearings and nothing seemed off about them, no weird vibrations at speed or that high-pitched howling sound, but next chance I get I'll jack the front up to see if there's any wobble or play.

I suspect that it's the low pressure, but just confirming it here.

 

[jesse12345]

I honestly have never heard of low tire pressure causing the abs to kick in. Do you have rear disk brakes and have those bearings been replaced also? It could be something else causing it to the most obvious that I have found is bad wheel bearing.

 

[XC92]

I'll be overhauling the entire rear end this spring so I'll definitely check out the bearings, but, again, no issues with bearings on either end.

 

[jesse12345]

I hope someone else can chime in that knows more about the abs system on these cars, but I know tire pressure won't cause abs to kick in.

 

[fourgsixty3]

Check abs sensors and the sensor rings on the axles. Sometimes they get crusty and must be cleaned. Sensors can also fail and must be replaced.

 

[XC92]

I recently thoroughly cleaned the tone rings and sensors and cleaned or replaced everything else, bearings, seals, knuckles, etc. The fact that putting air in the tire made this go away would indicate that it was low tire pressure. I'm just trying to find out why.

 

[fourgsixty3]

I'm just trying to find out why.

I'm pretty sure you were on the right track and answered it in the original post.

 

[motomattx]

There could have been snow or ice on the ring or on the sensor tip itself causing the problem. The code used in the module are not publicly available and it would have been written in machine code hex based.

 

[XC92]

There could have been snow or ice on the ring or on the sensor tip itself causing the problem. The code used in the module are not publicly available and it would have been written in machine code hex based.

If so, I wonder if the low tire pressure could have somehow made this more likely and restoring pressure fixed it.

And, machine code in mid-80's? I majored in CS in the 80's and even assembly code was pretty rare in commercial applications. PROM and ROM memory was pretty small and expensive back then but not THAT much.

I find it hard to believe that it wasn't written in some high-level language like C or PL/1 or even FORTRAN and then compiled into machine code.

...So I did a little research and, based on my VERY cursory understanding of ECU-based tuning, it does indeed look like people who do this sort of tuning generally do it on a machine or assembly level.

But I'm guessing that this is more because the original source code has never been released or otherwise "found" (and if it has been "found" then a lot of legal pressure was used to suppress it, since it's proprietary), than because it wasn't written in a high level language.

And, either efforts to reverse engineer it back to some high level or meta language haven't been successful, or they have been, but the people who did it understandably want to capitalize on their hard work and have kept it to themselves, e.g. DSMlink.

But it just doesn't stand to reason that code this critical, upon which not only the performance of a car but its engine and other critical parts' well-being and even survival, and more importantly the well-being and lives of anyone in the car or in its vicinity, would be written in machine language, at least by the mid-80's, by which time memory was no longer so scarce and expensive as to really require the efficiency of machine code, at least not for cars selling for tens of thousands of dollars, as opposed to scientific calculators or embedded microcontrollers.

Furthermore, my research also indicated that by no later than the mid-90's, ECU code was generally written in C or C++. Given that C had already been in wide use for decades before then (it was invented in 1972), it stands to reason that it would have been used for at least a decade prior for ECU coding.

Anyway, this is all a tangent to my original issue. But it's also very interesting to me as I have a CS/IT background, not practiced in many years, and have tinkered with Arduinos and Raspberry Pi's, and have been toying with the idea of building a simple ODB1 reader. That of course wouldn't require access to the ECU's code, but it's a natural progression from that to actually accessing the ECU's code.

 

[motomattx]

Keep in mind that cars of this vintage used the same basic processor that my Heathkit Hero1 robot uses, 6800 based, the Hero 1 also gets programed in hex machine language, I have a love for old robots and old electronics and electromechanical things like pinball machines when you could still work on them and the parts were not microscopic and unobtainable.

Motorola 6800 - Wikipedia

en.wikipedia.org

You must be logged in to view this image or video.

 

[steve]

When you look at code derived from compiled languages you can see patterns that are clues to the language and tools used and by extension if the code was written in the processors assembly language. Even C code which tends to be as close as your going to get on a high-level assembly leaves traces in it's calling conventions, code optimations, and data structures.

I haven't looked at the ABS ECU or it's code. ABS wasn't available with rear LSD in '91. The 2G DTM or the 3S TM don't reference checking (that I found) for tire pressure like modern systems do in absence of TPMS in the wheels.

It would be interesting getting the fault code from the ABS ECU when it happens but I haven't read everything to see how you do so without a MUT.

 

[XC92]

I haven't looked at a lick of DSM code but it just makes sense that it was mostly written in C, which as you said is as close to assembly as mainstream high level languages get, especially back then, and compiles to object code pretty tightly if well-written on a good compiler.

I did read that it runs on a CPU that was also used in arcade games of that era, which makes sense as there was no separate GPU back then so a CPU had to process input, video and game action in real time with no hiccups, same as a car's ECU has to when driven (no video of course and the inputs are mostly the various sensors throughout the car, way more of them than in an arcade game).

It would be interesting to see the code, but if a quick search doesn't yield it then it must be pretty proprietary and very hard to obtain (legally), both the original code and any decent attempts at decompiling it. Of course I have no intention of modifying it, but seeing it might give me a better idea of what's really going on and how to interpret various error codes.

 

[DSMTunedKvMan]

Low tire pressure cause different spinning ratio on ecu triggering ABS function then light

 

[steve]

I haven't looked at a lick of DSM code but it just makes sense that it was mostly written in C, which as you said is as close to assembly as mainstream high level languages get, especially back then, and compiles to object code pretty tightly if well-written on a good compiler.

The 1G code is all in 6800 family assembly code. I'm betting the 2g code is too. From what I've seen the Flash based ECUs were written in C or another high level language.

 

[XC92]

The 1G code is all in 6800 family assembly code. I'm betting the 2g code is too. From what I've seen the Flash based ECUs were written in C or another high level language.

Is the code publicly available? I haven't looked at assembly in decades but it might be interesting and even useful, to see what's going on. And has anyone translated it into a high level language or at least pseudocode?

The 6800 goes back to the mid-70's and as I'm sure you know what the basis of the original Apple I & II and a bunch of other early microcomputers, and was hugely popular, so surely there are decent decompilers for it.

As for the 2G, I think I read that by the mid-90's they were using C, since 90's microcontrollers & CPUs were much more powerful with much more memory than 90's ones, so there wasn't a need to use assembly to keep the byte count down.

Funny how a thread about tire pressure and ABS led to a discussion of ECUs and assembly code. But the latter is the key to understanding the relationship of the former to each other. The code tells everything (assuming the speed sensors and tone wheels are ok and working properly).