ABS Hacking

They go by many names, P01, P59, VPW, '0411 etc . Circa 1999 to 2006. All VPW OBD2 PCMs.
User avatar
Posts: 331
Joined: Sun Jan 25, 2015 4:21 pm
Location: Sydney

Re: ABS Hacking

Postby j_ds_au » Fri Jul 31, 2020 10:45 pm

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.

Posts: 698
Joined: Sat Dec 15, 2018 7:38 am

Re: ABS Hacking

Postby Gampy » Sat Aug 01, 2020 12:52 am

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
Temporary is a permanent problem!

Posts: 106
Joined: Mon Feb 11, 2019 12:48 pm
Location: DFW, Texas

Re: ABS Hacking

Postby jlvaldez » Sat Aug 01, 2020 2:14 am

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

Posts: 106
Joined: Mon Feb 11, 2019 12:48 pm
Location: DFW, Texas

Re: ABS Hacking

Postby jlvaldez » Sat Aug 01, 2020 3:37 am

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.

Posts: 698
Joined: Sat Dec 15, 2018 7:38 am

Re: ABS Hacking

Postby Gampy » Sat Aug 01, 2020 4:06 am

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 ...
Temporary is a permanent problem!

Posts: 106
Joined: Mon Feb 11, 2019 12:48 pm
Location: DFW, Texas

Re: ABS Hacking

Postby jlvaldez » Sun Aug 02, 2020 9:17 am

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
Posts: 423
Joined: Fri Feb 02, 2018 3:13 pm

Re: ABS Hacking

Postby NSFW » Sun Aug 16, 2020 1:16 pm

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 questions about tuning or flashing - start a thread instead. Thanks!

Posts: 106
Joined: Mon Feb 11, 2019 12:48 pm
Location: DFW, Texas

Re: ABS Hacking

Postby jlvaldez » Tue Sep 01, 2020 5:16 pm

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.

Posts: 1
Joined: Thu Sep 10, 2020 7:44 am

Re: ABS Hacking

Postby TiltedFish » Thu Sep 10, 2020 7:47 am

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)

Posts: 106
Joined: Mon Feb 11, 2019 12:48 pm
Location: DFW, Texas

Re: ABS Hacking

Postby jlvaldez » Tue Sep 22, 2020 1:30 pm

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....

PreviousNext

Return to GM LS1 512Kbyte and 1Mbyte

Who is online

Users browsing this forum: No registered users and 6 guests