rusefi.com

My 1993 Volvo 240 has a v8. That v8 now runs on rusEfi!



That video was shot with no sensors hooked up (other than crank position...), so I had it locked to sensible-ish idle settings of 3.5ms fuel, and 20 degrees ignition timing. It was also only running on 6 cylinders in that video, since the pins for injectors 3 and 4 were shorted together on the pcb. That's since been fixed, and it now purrs on all 8 cylinders!

Welcome to https://github.com/rusefi/rusefi/wiki/List_of_engines_running_rusEfi

Car has now been for a ~half hour drive. No issues to report! Spent some time up above 4k rpm without any sync issues.

Also of note is that AFR was logged using an AEM X-Series wideband controller, connected over CAN bus!

Attached is the log from the drive.

mck1117 wrote: ↑

Mon Dec 16, 2019 5:59 am

connected over CAN bus!

Please PR this part?

aren't there delays introduced by using can bus instead of direct ADC?

puff wrote: ↑

Mon Dec 16, 2019 7:38 am

aren't there delays introduced by using can bus instead of direct ADC?

Short answer: No.

Long answer: Yes, but no.

Longer answer:
ADC: We sample the ADC at 200hz. That's a period of 5ms, so the average amount of time we have to wait from any arbitrary point in time until we get a new o2 measurement is 2.5ms (note: this used to run at 20hz, so it used to be 25ms)

CAN: A CAN message can't be longer than ~150 bits, and transmits at 500kbit/s, which means a full frame can transmit in 300 microseconds (0.3ms). The interrupt overhead and processing on the ECU side adds at most another 100us (0.1ms) (since this is relatively low priority compared to other threads/interrupts). TunerStudio is only polling at ~100hz (10ms period), so this is much much faster than anything can consume it. This particular controller sends CAN messages at 100hz, but that's totally fine since the sensor is slow enough that there isn't any content at higher frequencies than that.

Result: Advantage CAN.

In reality, the CAN-based solution is actually MUCH faster than those numbers would suggest. This isn't because the transport is faster (which it is), it's because the actual wideband controller I'm using (AEM X-Series inline) is SO much faster than their older stuff.

Have a look at this snip from the attached datalog:

You can see this happen, in order:
1. TPS starts opening
2. AFR goes lean (transient)
3. air mass starts increasing (MAP sensor indicates pressure change)

Compare that to this log from my other car, where the AFR lags behind the TPS change (using an older AEM 30-4110 wideband gauge/controller):



So even if the actual transport was slower (which it isn't), the faster sensor interface makes up for it.

Interesting pictures, thank you!

Would be interesting to compare these two images to rusEfi basic cj125 implementation.

russian wrote: ↑

Mon Dec 16, 2019 11:59 pm

Would be interesting to compare these two images to rusEfi basic cj125 implementation.

Back when I had a cj125 (internal) and the AEM 30-4110 (external) hooked up to the same ECU with dual sensors next to each other in the pipe, they were essentially identical. The internal controller was maybe slightly faster, but not significantly like the X-Series is.

Also of note is that the X-Series also has a normal linear analog output, which probably provides the same speed benefit without CAN. However, with CAN, you don't have to worry about DC offsets between the wideband and the ECU.

Updates, updates!

This car now has an electronic throttle. I've installed a Hitachi ETB0024, which is intended for a later (gen4, 2005-2013 ish) GM truck, along with an adapter plate to adapt to my 3 bolt intake.

Went for a short drive tonight (with many safety features not enabled...), and didn't die! Yes, my "pedal sensor" was my original cable throttle dangled off to the side. No, you should not try this at home.

Anyway, a datalog of the drive is attached. The throttle tuning isn't perfect (nor is the engine tuning), but it's decent enough!

I wonder how many 1993 Volvo 240 on this planet have DBW

Here's a nice log and the corresponding tune in the name of https://github.com/rusefi/rusefi_documentation/issues/66

The content of the log is roughly:

• Cold (~21 degrees C) start
• Local driving to get Chinese takeout
• Hot restart (~89 degrees C) after acquiring food
• Highway driving, including a few nice wide-open pulls
• A bit of city driving at the end before shutdown

mck1117 wrote: ↑

Thu Jun 04, 2020 4:02 am

Here's a nice log and the corresponding tune

Can you please record a new one? My main interest is how many warnings would you get.

I've just looked at a random log (of the car driving nicely) from a few days ago, and seen this:

https://github.com/rusefi/rusefi/blob/master/firmware/controllers/algo/obd_error_codes.h says Hi

CUSTOM_ERR_2ND_WATCHDOG = 6103
CUSTOM_ERR_VVT_OUT_OF_RANGE = 6726
CUSTOM_OBD_SKIPPED_SPARK = 9009
CUSTOM_OUT_OF_ORDER_COIL = 9012

how did you get CUSTOM_ERR_VVT_OUT_OF_RANGE wow?

My cam is configured as "single tooth cam", because that's what it is. One tooth, falling edge at #1 TDC, rising edge at #6 TDC (360 degrees later). So /technically/ I think I have VVT sensing, but no control of it.

https://github.com/rusefi/rusefi/issues/2921 let's see if we can configure this warning out by specifying vvt offset or if that would be a code change to disable it in your case.

I don't understand where these values are coming from. It's bouncing between ~1309 and ~0.3.

~0 I understand: the rising/falling edge is just about exactly at TDC on my engine, modulo timing chain slop (no tensioner, pushrod engine).
Where did ~1309 come from? 1309 modulo 360 is 229. Nothing about my engine is 229 degrees. Where did that number come from?