ABS Hacking

They go by many names, P01, P59, VPW, '0411 etc. Also covering E38 and newer here.
MudDuck514
Posts: 397
Joined: Wed Jul 05, 2017 8:30 am
cars: 2001 Pontiac Grand AM SE
LD9 2.4l I4, 4T40E
2005 Chevrolet Venture
LA1 3400 V6, 4T65E
Location: North TX, USA

Re: ABS Hacking

Post by MudDuck514 »

jlvaldez wrote: I've got some bad news, mainly for me, is that my data server caught fire this morning. My 48 TB array seems intact but it fried my OS drive so I'm missing all my diagrams. This might cause some delay as I need to bring my server back online, and a lot of my custom stuff was for the OS hadn't been backed up fully yet.

So if any of you have the molded Molex to SATA power connectors, toss them in the trash. This is apparently a common issue when googling. I've ordered proper adapters but hope this is the only damage to my machine. I've got an off-site backup of all my data but it's in Houston at my dad's lol. Would take too long to transfer ~30 TB of data over the internet.
Hi all;

Ouch, I know exactly how you feel.
Lost a couple of drives myself over the years but NEVER like that.

Mike
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 »

Alright. With the new connector, I went out and logged the requested torque and delivered torque signals to see their freq and duty cycle. Looks to be ~128 Hz on both channels.

I played with the yaw sensor. You can see me shaking the yaw sensor back and forth, pause for a moment, then hit the sensor tilting forward. Was trying to see the maximum frequency that it might have to determine what frequency I shoudl sample at. Looks like anything > 250 Hz is plenty for this.
Attachments
tek00005.png
tek00005.png (21.23 KiB) Viewed 3203 times
tek00003.png
tek00003.png (19.75 KiB) Viewed 3203 times
tek00002.png
tek00002.png (24.3 KiB) Viewed 3203 times
ReqAndDelivTorq.png
ReqAndDelivTorq.png (24.2 KiB) Viewed 3203 times
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 »

Alright, So after inspecting the signals, I decided to drop the low pass filters to save room and had to switch a few components out to have JLCPCB do the assembly. Ended up having to redo the entire layout. Switched to the SCSI-2 connector, which is a smaller variant of the 50 pin connector. These connectors and adapters seem to be available, so let's hope it's good.

Updated layout and schematic attached.

Going to generate the gerbers and send them off to JLCPCB to get started. Will update this thread once I've done that :)

Edit: had to change a few components again because they were out of stock. Sadly the op amps and the reluctance ICs are Out of stock so I'll have to install those myself, but everything else is being assembled.

5 boards, with all passives and a few ICs assembled for $44 SHIPPED lol. This is dumb cheap. Now to order the other components that I'm missing. The maxim ICs are expensive, like $4/ea and there's 4 per board.
Attachments
rev2-layout.png
rev2-layout.png (70.63 KiB) Viewed 3157 times
Rev2.png
Rev2.png (585.55 KiB) Viewed 3157 times
PiHat.pdf
(216.29 KiB) Downloaded 155 times
User avatar
Holden202T
Posts: 10311
Joined: Sat Feb 28, 2009 9:05 pm
Location: Tenambit, NSW
Contact:

Re: ABS Hacking

Post by Holden202T »

looks good, certainly cheap enough!
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've started on the software for this finally.

Using PiGPIO library, I get surprisingly accurate results (with some modification to the example code).

They have a daemon that seems to pretty accurately sample inputs at a time interval you request (surprising). very little jitter from what I can tell. They had some example code to count input frequency which does basic edge counting over a known time. The advantage: simple. The disadvantage: the faster you want the sample rate, the less accurate it becomes.

I scrapped all that and use a time delta between each rising edge added to a circular buffer to store a certain amount of samples (i'm playing with this, but 5-10 samples seems to be good). It averages the samples in the circular buffer and rounds. I find this gives really stable results on the measured input frequency for slow-changing frequencies (IE a wheel sensor). It effectively only looks at the last 5-10 pulses and averages the measured frequency across them. The nice thing about the approach used by the pigpio library is the GPIOs are read in banks, so reading 1 GPIO vs reading an entire bank (32 IOs) doesn't really affect speed, other than extra processing I'd have to do on the IOs, but for a 1.5 GHz CPU, that's not a concern. Currently it uses 5% of my CPU, with pretty inefficient code.

Also seem to have it accurately measuring input pulse width as well (torque request and torque delivered signals are PWM).

I'm using C, though, which might help. I don't know if python would be fast enough. I'm from the embedded world, so I'm a bit more comfortable in C, anyway. I need to decide how I want to actually write the data to a datalog. I imagine a CSV file with 100 hz resolution on all signals should be enough, i'd think. Haven't actually done this before, though. I imagine you simply keep some block size of data in memory as it comes in and then write to a file in large chunks since disk writes are slowwwww. I'll likely dump the VPW comms into another .csv file with time stamps.

Here's what I plan to log, and in what units. I'm open to thoughts/input:

1) Delivered Torque: PWM Duty Cycle %, PWM Frequency (128 Hz nominal, measured. This can only change ~9x/sec, so there will be redundant data here).
2) Requested Torque: PWM Duty Cycle %, PWM Frequency (same notes as above)
3) Lateral Accelerometer: Input Voltage
4) Yaw Accelermoter: Input Voltage
5) 4x Wheel speed: period between pulses, updated 100x/sec
6) Brake Pedal Switch: Binary on/off
7 & 8) Steering wheel pos A and B: Input Voltage
9) Brake Pressure Sensor: Input Voltage
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 »

And they are here! Now to finish assembling the through hole components and the components they did not have in stock.

Just finished assembling one board. Now to start the programming for real.

I was at Circuit of the Americas last weekend and had a blast. I was able to avoid ice mode from activating but COTA is apparently extremely hard on brakes.

GPS data shows I was doing 158 mph down the back straight and would slam on brakes to get to 35 mph for the turn. I managed to get down to metal on metal for the brakes in 1 day. They had half of their pad material left when I installed them and had done 6 track weekends prior. Pretty crazy. Managed to get some brakes installed and went at it again on Sunday but ended up cracking a rear rotor. So the Vette goes back into the garage today (still on the trailer) and I'll experiment with checking the input from the wheel sensors.
Attachments
20200727_160251.jpg
20200727_151124.jpg
20200727_134507.jpg
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 »

Alright, now I've been writing software for the last few hours.

So far I've got
1) Frequency counters on the wheel speed inputs, measures time between pulses and does a rolling average to determine frequency
2) SPI communication with ADC and reading all 5 analog channels and then converting them to a voltage value (reports voltage on all 5 channels).

Time to sample all 5 channels is ~7 us, I can drop it if I increase SPI speed, but I don't want risk noise causing issues.

Now I need to build some code to handle actually pulling these inputs together and dump it to a file.

Also wrote in python a quick "record 30 seconds at 100 hz and dump to file" program to throw it into a log viewer and see if it works. Looks decent. There's some noise on one of the supplies (I have it monitoring the 3.3V rail), I suspect is due to the RPi switching between different CPU speeds, putting load on the 3.3V rail. Perhaps I shouldn't have used the RPi on board supply. I'll try fixing the frequency of the pi and maybe that'll clean this up. The noise is pretty minor. It's ~50 mV of noise on a 5V supply, but you can see it.
User avatar
antus
Site Admin
Posts: 8238
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 »

Cool, good progress!
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 »

Software updates:

I've just written stuff in python since it's easiest to quickly write. I was doing C, but the calls to multiple libraries was getting messy. Easier just to do it in python. Turns out it doesn't really affect performance or accuracy since the IO daemon runs and the python merely calls on that API. The IO daemon time stamps everything so it doesn't matter too much. There might be a few ms of latency on some of it, but I don't believe it'll matter.

Anyway, I was using a PWM waveform generator connected to the wheel speed sensor analog front end and tested datalogging the wheel speed sensor input. It logs the frequency of the wheel speed sensor (or period in microseconds). If you remember, I mentioned I used a rolling average filter to help with some of the noise. I was testing the response to step functions, particularly how long it takes for locked up wheels to show up, since this is most critical. I had a depth of 10 samples, which turns out to be way too long. 5 samples might be too long as well, taking about 300 ms to show when the wheel gets down to about 0.2 rev/sec. However, since I can only update the frequency based on when I get input, and the input becomes much farther and fewer in between at low speeds. So wheel lock ups get delayed. I need to play with this.

I am able to successfully detect frequency and duty cycle of all input digital waveforms, and will grab what I need. I need to come up with a method to start and stop a datalog via my phone or a button. Also i need to combine some of my scratch/test code into some program to do everything at the same time. Next up will be logging OBDII calls.

Anyway, here's some pictures of the logs of the ADC (done via SPI) and me playing with the frequency detector. The ADC channel output is raw voltage. all channels but the green one are floating. Green was connected to the RPi's 3.3V supply, and there appears to be a ~80 mv offset at midrail. I might calibrate this out in software. Need to determine where this is coming from.
Attachments
adc.png
adc.png (20.8 KiB) Viewed 2917 times
step function up.png
step function up.png (1.08 KiB) Viewed 2917 times
step function delay.png
step function delay.png (5.76 KiB) Viewed 2917 times
overview.png
overview.png (25.36 KiB) Viewed 2917 times
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 am disheartened to discover after sinking many hours into cleaning up my python classes for reading the ADC and digital inputs, that when I try to put them together, I get terrible results that are quite inconsistent for timing.

There's a chance I might need to look at moving to C++ for this software. In python if I ran the ADC code at maximum throughput, I achieved ~4200 Hz of sampling, which is way overkill. 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.

FRUSTRATING
Post Reply