ABS Hacking

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
User avatar
j_ds_au
Posts: 384
Joined: Sun Jan 25, 2015 4:21 pm
Location: Sydney

Re: ABS Hacking

Post by j_ds_au »

jlvaldez wrote:For some reason, when threading and trying to store datalogs, this throughput drops to a very inconsistent 5-10 hz. I'm finding it damn near impossible to get a python thread to consistently trigger with any timing accuracy in the low ms range. If it's running by itself, then it's decently consistent.
If "trying to store datalogs" means writing data to a file, that may explain your drop in performance. I believe that file I/O operations are computationally very expensive and can screw up realtime performance.

Joe.
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: ABS Hacking

Post by Gampy »

jlvaldez,

j_ds_au is exactly right!

You need to buffer and block write.

You will likely also need to go to a lower level language, like C/C++ or even better Assembly.
A high level language (easy to write) is just to heavy for fast intensive IO ...

One of the tricks I pull is to use compiler options to output the Assembly or something like Compiler Explorer to optimize your code ... With Compiler Explorer, it really doesn't matter what compiler you select, the idea is to look at the assembly, pretty much the fewer the instructions the better.

-Enjoy
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
jlvaldez
Posts: 155
Joined: Mon Feb 11, 2019 12:48 pm
cars: '01 - Corvette Z06
'20 - Sierra Denali
'03 - Volvo S80 T6
'16 - Accord V6
Location: DFW, Texas

Re: ABS Hacking

Post by jlvaldez »

j_ds_au wrote:
jlvaldez wrote:For some reason, when threading and trying to store datalogs, this throughput drops to a very inconsistent 5-10 hz. I'm finding it damn near impossible to get a python thread to consistently trigger with any timing accuracy in the low ms range. If it's running by itself, then it's decently consistent.
If "trying to store datalogs" means writing data to a file, that may explain your drop in performance. I believe that file I/O operations are computationally very expensive and can screw up realtime performance.

Joe.
I'm familiar with writing to file in chunks due to how slow disks are. I was storing everything in memory and write to file at the end, when I'm no longer datalogging.

I was trying to buffer in memory and write once a second but I realized that iI have enough ram to buffer everything in memory and write to disk when I stop the log.

I'm not sure which part of the program is actually taking all the time. Seems like the call to SPI is pretty slow and taking 10-15 ms to complete. Weird that by itself it takes microseconds.

I normally write this type of stuff in C on embedded devices but I'm not quite as familiar with writing close to hardware on a raspberry pi.

I also switched the library I'm using for holding data in memory, which seems to have slowed things down considerably as well. I'll at with yanking calls and seeing where the delay is.

One of my frustrations is that I cannot seem to find how to create a periodic timer that isn't affected by the function it runs. It's annoying because this is trivial to do with hardware timers in c, but I can't find a way in python lol
jlvaldez
Posts: 155
Joined: Mon Feb 11, 2019 12:48 pm
cars: '01 - Corvette Z06
'20 - Sierra Denali
'03 - Volvo S80 T6
'16 - Accord V6
Location: DFW, Texas

Re: ABS Hacking

Post by jlvaldez »

After a nights rest and coming back to it, I switch my row library to be a simple python list instead of Pandas (python library). I also moved some stuff around in the code and made a few things lighter.

I am now able to get ~150 samples/second with decent accuracy. If I renice the process to -20, timing gets more consistent. I have a flip switch input that starts and stops the datalogs.

Turns out the majority of my slow down was trying to "dynamically" put my rows together. I had a list of parameters i wanted it to log, and then it would perform an indexing function on each of them to find which index to pull the data from. This was very slow. Removing this and making it static was the single biggest speed up. I'll play with it later to have it perform indexing only once and then itll populate a list of indexes so it doesn't have to look up the index every iteration. I figured it'd be slow, but I didn't think it would affect it that much.

Python is definitely not geared for this, but it is working at lower logging rates if you put higher priority on it.
User avatar
Gampy
Posts: 2330
Joined: Sat Dec 15, 2018 7:38 am

Re: ABS Hacking

Post by Gampy »

Awe shucks, stuck my nose in where it wasn't needed ... o-wells win some, loose some!

I'll just set back and watch in amazement as you meander the paths of your endeavor ...
Intelligence is in the details!

It is easier not to learn bad habits, then it is to break them!

If I was here to win a popularity contest, their would be no point, so I wouldn't be here!
jlvaldez
Posts: 155
Joined: Mon Feb 11, 2019 12:48 pm
cars: '01 - Corvette Z06
'20 - Sierra Denali
'03 - Volvo S80 T6
'16 - Accord V6
Location: DFW, Texas

Re: ABS Hacking

Post by jlvaldez »

I like the ideas, keep em coming :) you've got a lot more experience with this type of software than I do. I deal with low level embedded stuff for work and almost never write for an OS.

Well I learned that python has a GIL which basically means multi threading doesn't work as you'd expect because only 1 thread ever runs at a time in a python interpreter. This explains why my seperate thread to handle SPI comms at a specific interval goes to complete shit once the digital inputs get loaded up.

I realized that what slows it down is the combination of the fact anytime the digital inputs switch, a call back occurs in python, where I determine frequency of wheel input and the fact that the SPI ADC calls are all blocking and I can't kick them to a separate thread like I'd expect. When these two happen together, CPU usage hits 100% (on a core) and the script gets backed up with so many call backs that it takes a while for it to do anything

This means I have 2 options:
1) write the critical code in c like I should have done from the start.
2) have multiple python threads launched separately that somehow communicate to each other.

I know doing this via C is the correct method, just sucks I'll have to rewrite all of my code :'(

Guess I'll need to look into how timers work on this thing and if I have access to them at any low level.

I shouldn't need the CPU to run at 1.5 GHz to accomplish 100 Hz sampling.

It was so easy in python... Damn :(
User avatar
NSFW
Posts: 679
Joined: Fri Feb 02, 2018 3:13 pm

Re: ABS Hacking

Post by NSFW »

That's fantastic progress!

Have you considered using an Arduino instead of a Pi? (A small one, like a Teensy or MKR-Zero.)
And then put the Arduino on the input board.
And then create an output board that mounts the solenoids in the same positions as stock.
And stuff the it all back into the EBCM housing.

Because while that sounds hard, it also kinda sounds more practical than figuring out how to reflash the factory electronics, and then reverse-engineering enough to defeat ice mode. It is trading one set of hard problems for another, of course. With with the Arduino approach the hard problems are:
- figure out how the EBCM and PCM communicate
- re-create enough of those messages to keep the PCM happy
- make PCBs that fit
- and write ABS software

Writing new OEM-quality ABS software might not be realistic, but writing ABS software that basically works does seem achievable. By "basically works" I just mean "prevents tires from flat-spotting, and doesn't try to kill me."

In other news, I got the boards out of the EBCM case, but it looks like I'll need a desoldering tool to separate the top and bottom boards.
Please don't PM me with technical questions - start a thread instead, and send me a link to it. That way I can answer in public, and help other people who have the same question. Thanks!
jlvaldez
Posts: 155
Joined: Mon Feb 11, 2019 12:48 pm
cars: '01 - Corvette Z06
'20 - Sierra Denali
'03 - Volvo S80 T6
'16 - Accord V6
Location: DFW, Texas

Re: ABS Hacking

Post by jlvaldez »

It was my original thought. I'm not much of an arduino fan, but mainly because I'm used to TI and NXP MCUs. I figured datalogging at 100 hz would be a fairly easy task for a 4 core 1.5 GHz SoC :)

Granted, I'm sure a lot of my problems are that I'm being lazy and using python.

I took a break to work on another car project. Putting an engine and transmission back in another car. 3D printed an enclosure for the setup as well. I slowed down a bit, but I haven't had much time to do programming. Work for me ramped back up and I'm writing firmware for our test ECUs (NXP MCUs) right now, so the last thing I'm wanting to do when I get off is program my own projects hahah.

Also I think i've figured out the commands between the ABS and ECU. I have been doing a good deal of sniffing. I have figured out how to datalog brake pedal pressure and steering angle from the OBDII port with a OBDLINK MX when I'm on track.
TiltedFish
Posts: 3
Joined: Thu Sep 10, 2020 7:44 am
cars: 1997 Chevrolet Camaro z28
1999 Chevrolet Corvette

Re: ABS Hacking

Post by TiltedFish »

Any progress on this? the EBCMs are discontinued and theres big demand for reparing them, i'm trying to get the logic off the boards so I can blueprint the PCBs and get them made up. (lots of people with failed EBCM modules and cant pass safety inspections with abs warning light on)
jlvaldez
Posts: 155
Joined: Mon Feb 11, 2019 12:48 pm
cars: '01 - Corvette Z06
'20 - Sierra Denali
'03 - Volvo S80 T6
'16 - Accord V6
Location: DFW, Texas

Re: ABS Hacking

Post by jlvaldez »

I was having some 3d cases printed for it as I was trying to get everything ready for my track event. Had some ABS shrinkage issues were my fault.

I've been slammed at work and with another project (trans and engine rebuild in a car I'm trying to sell. Got everything together last week only to find that it doesn't have lock up, so it's coming back apart).

Also picked up a project RX8 I plan to LS swap for the wife. So I've been working on that trying to get it cleaned up.

Haven't been able to sink much time into programming recently. I determined I'm going to try to write the wheel speed sensor code in C, and try to optimize it. It is quite frustrating how difficult of a time I'm having making a 1.5 GHz CPU read a 2 kHz signal... I could easily do this with a 16 MHz MCU with internal timers... Last time I rely on a SoC to do timing....
Post Reply