ABS Hacking

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ABS Hacking

Post by antus »

Oops a bit late back to this thread, but I just read the problems above. I dont think you do need to have multiple threads but you might need to set up your program differently, and more along the lines of how the GM ECUs do it. That is, have different groups of code that run at different frequency. You might also be prepared to drop some data while the pi does something else, because machine time is way faster than wheel speed. Perhaps you could have the trigger call backs just writing timing info to an array, and then every so often perhaps 1000 wheel triggers, the interupt code, disables interupts, does the spi write, then re-enables interrupts and goes again. You might get a rising edge and loose a falling edge so you'd need to be able to handle two, say, rising edges depending how your code works, but you'd probably still have some pretty good data for what the wheels were doing.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
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 »

antus wrote:Oops a bit late back to this thread, but I just read the problems above. I dont think you do need to have multiple threads but you might need to set up your program differently, and more along the lines of how the GM ECUs do it. That is, have different groups of code that run at different frequency. You might also be prepared to drop some data while the pi does something else, because machine time is way faster than wheel speed. Perhaps you could have the trigger call backs just writing timing info to an array, and then every so often perhaps 1000 wheel triggers, the interupt code, disables interupts, does the spi write, then re-enables interrupts and goes again. You might get a rising edge and loose a falling edge so you'd need to be able to handle two, say, rising edges depending how your code works, but you'd probably still have some pretty good data for what the wheels were doing.

I like the thought, but I'm not sure if it's possible. the Raspi library for GPIOs allows me to setup interrupts for any state change on a GPIO. This is what seems to screw me over, when I have 4 inputs togglign at 2 kHz. It's a callback function, where I count the difference in time between consecutive events and throw them into a circular buffer for some basic filtering.

I don't get to control when the function gets called. I tried doing a polling approach, but I cannot accurately control when the function is called. If this were embedded C, I'd use timers and a circular buffer with interrupts that trip on edge changes. Doesn't seem to be an option with this API.

I'm thinking my best option is going to be to either use a separate python script for wheel speed interpreting and it communicates to the main datalogger with a socket (since polling for wheel speed only happens at the datalogging rate, which is 100 Hz), and let it do its thing. Or I rewrite the daemon in C, and have it automatically determine frequency of input signals and keep that in some buffer that can be polled whenever, letting the daemon handle it and python merely polls for frequency info.

I've never tried to do timing sensitive things in python before. Figured I'd use this as an excuse to learn, but that was a dumb idea.


Right now I'm writing firmware for a MCU to emulate wheel speed sensors and torque request to make debugging the RasPi easier...
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ABS Hacking

Post by antus »

i mean turn off the callbacks while you do the SPI write, accept you will loose a couple of samples, but the SPI might work and then you get enough data (hopefully).
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
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 »

Thats a thought. The call backs happen at any point, like an interrupt as far as I'm aware, so I don't know if I can do that? Thought call backs were asynchronous like interrupts
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ABS Hacking

Post by antus »

I have a device using gpio on pi, and I init the callbacks with the following code:

Code: Select all

    GPIO.setup(pin, GPIO.IN, pull_up_down=GPIO.PUD_UP)
    GPIO.add_event_detect(pin, GPIO.BOTH, bouncetime=2000)
    GPIO.add_event_callback(pin, statechange)
I imagine you can update the detect to set it to none, then do your thing, then set it back to BOTH or whatever you need.

you could probably do it inside the callback either side of the i2c call.

I agree the correct way to do it would be to get a small arduino and get it to monitor the inputs and send timing data back via TTL serial to the pi, then the UART on the pi can buffer that timing data and is free to do whatever it needs to for storage. It just depends on the time you want to invest. There are also the arduinos with arm core running linux and the small atmel on board, for that type of setup.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
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'll take a look at how the call backs are initialized with that library. My memory is fuzzy on those details. I got distracted and went to play some games yesterday instead of finishing my MCU firmware to emulate some sensors. haah

Edit: Actually I just thought of one issue with that. At low speeds, when your wheel speed is toggling at like 5 hz. The way the counter works is it keeps a circular buffer of time stamps for each state change and gets the time diffs. If I pause it to do SPI, when I reenable call backs, I have to clear/reset the buffer otherwise there will be too far a difference between pulses. That's the high speed issue. The low speed issue is that if I'm constsantly doing this, I might not ever get enough samples to calculate wheel speed.


Thinking through it as I'm typing this, I think implementing some sort of "max callbacks per second" type of code would help and avoid me having to work around SPI. Simply keeping track of the last X number of samples and if my time diff from 5 samples prior is < 1 second, then I've exceeded my 5 sample per second threshold, and I simply disable interrupts until I fall under this threshold.

Shame pythons timing functions seem to be absolutely inconsistent when trying to do short timing things.
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ABS Hacking

Post by antus »

Yeah, i'd do a main loop which gets some data, then saves some data

and getdata would turn on call backs, collect data on all wheels for 10ms? 20ms? 50ms? then turn off callbacks. average those samples and save the average to ram, or could average as it goes.
then the save data writes out over i2c
then go again.

but at the end of it, it might not be fast enough, so it might be worth adding input hardware to handle the time sensitive parts outside of the main code.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
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 »

Yeah, the idea is to sample when your wheel locks up, and if i'm tryign to sample at 100 Hz, I need pretty quick responses. Thinking about it, 5 samples/sec max is going to be WAYYYYY too slow to detect a lock up from high speed.

I'm playing around with a MCU now. Simple little 16 MHz MCU with a few timers. It at least has hardware I2C/SPI modules that I could use as a slave. Made my Pi Hat with headers so I could intercept the outputs of the wheel sensors if needed. More testing to be done. I've just really been lacking the motivation recently as all my cars have kicked me in the stomach recently and I'm more tempted to say to hell with it all lol

1) My 2500 HD with the P59 I was testing on blew its engine. It was a cammed LQ4. I ended up selling it a few months ago and bought a 2020 Sierra Denali since I'm sick of dealing with unreliable dailies. Just need something to tow the track car.
2) My vette has been pretty ok, but it does have issues with overheating every single track day. I cannot keep my oil temps below 285F at all, even with a massive 72 row cooler. Needs more air ducting
3) A Volvo rebuild (engine and trans) I'd been working on for ~3 years finally got it all back together. Shifts great, drives good, but it doesn't have lock up for some reason, so I have to pull the trans back out. I'm extremely demotivated about this
4) Acquired a RX8 for the wife since she's always liked those, and she wants to learn manual (the track vette isn't newb friendly with the mods), and that's been wanting lots of work since the previous owner was a kid that didn't know much about them. Bought it cheap knowing the engine was near the end of its life, but still got work to get some emissions codes sorted out and repair what the kid screwed up.

and we're in the middle of having the house renovated due to termite damage...

TIME IS NOT ON MY SIDE!

But I remember the end goal is to prevent my ABS module preventing me from slowing down at 140 mph again because I got super lucky I had room to slow down, and no one was on track ahead of me [youtube]https://www.youtube.com/watch?v=p1RsStyVrPU[/youtube]
User avatar
antus
Site Admin
Posts: 8237
Joined: Sat Feb 28, 2009 8:34 pm
cars: TX Gemini 2L Twincam
TX Gemini SR20 18psi
Datsun 1200 Ute
Subaru Blitzen '06 EZ30 4th gen, 3.0R Spec B
Contact:

Re: ABS Hacking

Post by antus »

I know the feeling! There are parallels to my life which I wont go in to on most of those things! A dedicated mcu will save time in the long run. Thats a good vid....

Last track day I did my wastegate had failed, and the car was boosting at 32psi instead of 18 on e85. It was going so quick I was watching the road wondering why it seemed to have less stability. Now I have shredded semi-slicks, and a wastegate issue to look in to. I only noticed the crazy boost when I saw the gauge on the in car footage after the track day. Its a standard engine, lucky it survived the day.
Have you read the FAQ? For lots of information and links to significant threads see here: http://pcmhacking.net/forums/viewtopic.php?f=7&t=1396
User avatar
Gampy
Posts: 2331
Joined: Sat Dec 15, 2018 7:38 am

Re: ABS Hacking

Post by Gampy »

jlvaldez wrote:TIME IS NOT ON MY SIDE!
You ought just be thankful you can still attack your TODO list ... There are so many that no longer can!

I assure you it's many many times more frustrating!
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!
Post Reply