As I wrote in the previous article, the barebones design has been through some basic testing - 500km mixed environment driving - and has been mostly successful so far.
I had a suspicion that the output impedance of the circuit must somehow match a known impedance, but was not sure which. The clue was that the RaceChip unit raised city consumption by 5-15% even though it had no effect during the bench testing.
Here's a datasheet for a similar Bosch pressure sensor:
http://rb-aa.bosch.com/boaasocs/index.jsp;jsessionid=A20738712FCFB9E51CA919DD7D2F9E91.sundoro2?ccat_id=275&prod_id=516
For testing they are using a pull-up resistor, so on the input side of the ADC the same circuit must be simulated in order to drive the sensor. I used a 10k resistor, but perhaps even the internal pull-up could work.
At the DAC/PWM output I found out that a 1.5k resistor was too large and could not sink the ECU input line low enough. With a 10ohm resistor it seemed to work fine, perhaps 47ohm would also be ok. I don't have a definitive value yet as I want to implement it in another way.
The initial barebones circuit used an Arduino Nano (v2?) without RTS/CTS lines on the serial port. This means that on startup, the bootloader takes around 2 seconds until it jumps to the main loop. The car does a basic check and reports the sensor as faulty. The solution: turn the ignition off and immediately back on, before starting the engine. This is because there is a 30s delay from ignition off until the systems are powered down, at least on my car. It's also a nice anti-theft measure, the thief can only drive with reduced power, I think around 20%.
Idle consumption with my unit is now at 0.5l/h when warm, compared to 0.8-0.9L/h stock, 0.9-1.1L/h with RaceChip. So >30% fuel savings while idle.
The idle is a little shaky if unloaded, runs smooth if some load is added (A/C or in drive gear). Incidentally, with the unit disabled but in-circuit, the behavior is almost the same (0.6L/h) which means the input/output impedance is mismatched.
Highway consumption yielded a 5.7L/100km average on one trip, and then 6.3l for the return trip, so I would say a 6L/100km is achievable. Stock was around 8L, with RaceChip around 7L. I think that's pretty impressive, 25% highway mileage increase - see updates at the end of the post.
Here are the settings used during the test drive:
Torque is lower, but still adequate for day-to-day driving. I measured a stock 0-100km/h time of 8s, I would guesstimate now it's 10-12s. The car had no issues reaching 170km/h so there was no reason to do more tests, for now. My goal is improved mileage, a target of 1300km with one tank.
As I wrote above, the input/output impedance is really sensitive and there is no way to get a precise setting for each car. So my next step would be to design another simplified circuit with a relay. The relay would initially pass the sensor line to the ECU while de-energized, and use the Arduino 'passthrough' if energized.
During the calibration phase the Arduino would sample the input at the relay while it's off. When turning on, it will check if the input is the same through it's own circuit; if not, it will calibrate the input. It will then measure its own output and compare it to the input, when no modifications are applied. It will then save the output calibration constant.
Either way, there should be at least two trimmer pots or perhaps digital pots, 1-15k for the input pull-up and 10-100ohms for the output. Of course the RC constant of the output filter is also affected by this.
There was an error in the Arduino playground EEPROM snippet, it reads a byte (0-255) and compares it with a char (-128 to 127) which fails the verification on values larger than 127.
I found the need of storing several curves inside the EEPROM, perhaps number 1 should be the default and have another 5 or so for testing (focused on power, consumption, city, highway etc).
The curve size of 10 points is a bit too coarse, perhaps I will increase it to 20 points.
Source code still at: https://github.com/ligius-/DieselTuningBox
I've used a plastic food container to house the circuit. The plug was molded with hot glue as I cannot find any DB25 in my parts bin and still cannot source the original connectors. Bluetooth reception from inside the car is ok.
The small circuit board provides the input pullup, RC output filter and a way to probe and connect signals. I had to change its layout and components many times, which is why it looks like it has survived a war.
In September I've had some problems with the DPF which caused me to initially suspect the custom module. However it turned out to be just a bad sensor that had to be replaced.
At that time I also took careful measurements of the consumption and found out that the OBC display was erroneous - the actual consumption was higher than reported.
I was worried that the increased consumption could flood the DPF causing costly repairs with seemingly no added benefit. However, I took the car to a dealer to have the real DPF soot measured and it was within nominal parameters (i.e. <6 grams).
I've since removed the module from the car but haven't done a lot of driving so without a definitive consumption baseline it's hard to tout any benefits. So far, stock, I'm getting 9L/100km in mixed driving and 12-15L in heavy traffic. I will need to do more precise measurements when refueling to see if that is a real value. If that is indeed a real value then the saving of the module is probably not 25% but still could be above 10%.
I need to see if I can access some real fuel flow data through OBD instead of the one derived by the OBC (which probably uses the rail pressure in addition to the flow meter).
TL;DR: the OBC display is way off sometimes and I cannot confirm any measurements. No negative side-effects have been observed.
I had a suspicion that the output impedance of the circuit must somehow match a known impedance, but was not sure which. The clue was that the RaceChip unit raised city consumption by 5-15% even though it had no effect during the bench testing.
Here's a datasheet for a similar Bosch pressure sensor:
http://rb-aa.bosch.com/boaasocs/index.jsp;jsessionid=A20738712FCFB9E51CA919DD7D2F9E91.sundoro2?ccat_id=275&prod_id=516
For testing they are using a pull-up resistor, so on the input side of the ADC the same circuit must be simulated in order to drive the sensor. I used a 10k resistor, but perhaps even the internal pull-up could work.
At the DAC/PWM output I found out that a 1.5k resistor was too large and could not sink the ECU input line low enough. With a 10ohm resistor it seemed to work fine, perhaps 47ohm would also be ok. I don't have a definitive value yet as I want to implement it in another way.
The initial barebones circuit used an Arduino Nano (v2?) without RTS/CTS lines on the serial port. This means that on startup, the bootloader takes around 2 seconds until it jumps to the main loop. The car does a basic check and reports the sensor as faulty. The solution: turn the ignition off and immediately back on, before starting the engine. This is because there is a 30s delay from ignition off until the systems are powered down, at least on my car. It's also a nice anti-theft measure, the thief can only drive with reduced power, I think around 20%.
Consumption
The idle is a little shaky if unloaded, runs smooth if some load is added (A/C or in drive gear). Incidentally, with the unit disabled but in-circuit, the behavior is almost the same (0.6L/h) which means the input/output impedance is mismatched.
Highway consumption yielded a 5.7L/100km average on one trip, and then 6.3l for the return trip, so I would say a 6L/100km is achievable. Stock was around 8L, with RaceChip around 7L. I think that's pretty impressive, 25% highway mileage increase - see updates at the end of the post.
Here are the settings used during the test drive:
Power
Torque is lower, but still adequate for day-to-day driving. I measured a stock 0-100km/h time of 8s, I would guesstimate now it's 10-12s. The car had no issues reaching 170km/h so there was no reason to do more tests, for now. My goal is improved mileage, a target of 1300km with one tank.
Findings and improvements
During the calibration phase the Arduino would sample the input at the relay while it's off. When turning on, it will check if the input is the same through it's own circuit; if not, it will calibrate the input. It will then measure its own output and compare it to the input, when no modifications are applied. It will then save the output calibration constant.
Either way, there should be at least two trimmer pots or perhaps digital pots, 1-15k for the input pull-up and 10-100ohms for the output. Of course the RC constant of the output filter is also affected by this.
Firmware
There was an error in the Arduino playground EEPROM snippet, it reads a byte (0-255) and compares it with a char (-128 to 127) which fails the verification on values larger than 127.
I found the need of storing several curves inside the EEPROM, perhaps number 1 should be the default and have another 5 or so for testing (focused on power, consumption, city, highway etc).
The curve size of 10 points is a bit too coarse, perhaps I will increase it to 20 points.
Source code still at: https://github.com/ligius-/DieselTuningBox
'Packaging'
I've used a plastic food container to house the circuit. The plug was molded with hot glue as I cannot find any DB25 in my parts bin and still cannot source the original connectors. Bluetooth reception from inside the car is ok.
The small circuit board provides the input pullup, RC output filter and a way to probe and connect signals. I had to change its layout and components many times, which is why it looks like it has survived a war.
Update December 2016
In September I've had some problems with the DPF which caused me to initially suspect the custom module. However it turned out to be just a bad sensor that had to be replaced.
At that time I also took careful measurements of the consumption and found out that the OBC display was erroneous - the actual consumption was higher than reported.
I was worried that the increased consumption could flood the DPF causing costly repairs with seemingly no added benefit. However, I took the car to a dealer to have the real DPF soot measured and it was within nominal parameters (i.e. <6 grams).
I've since removed the module from the car but haven't done a lot of driving so without a definitive consumption baseline it's hard to tout any benefits. So far, stock, I'm getting 9L/100km in mixed driving and 12-15L in heavy traffic. I will need to do more precise measurements when refueling to see if that is a real value. If that is indeed a real value then the saving of the module is probably not 25% but still could be above 10%.
I need to see if I can access some real fuel flow data through OBD instead of the one derived by the OBC (which probably uses the rail pressure in addition to the flow meter).
TL;DR: the OBC display is way off sometimes and I cannot confirm any measurements. No negative side-effects have been observed.
This is nice as experiment, but basically fine tuning of curves is everything.
ReplyDeleteIdea to tweak rail pressure in constant regimes (i.e. below some 2-2.5V) is really bad for many reasons.
In idle you are slightly overreporting rail pressure value to ECU which has a consequence of slightly lower idle consumption (which btw. is almost irrelevant even for cars without start/stop functionality) but also jiggly engine work due to lack of power and broken ECU control loop which can hurt many engine components.
In high-way driving you underreport rail pressure i.e. ECU boosts it which I really don't understand how it can make lower fuel consumption except that fuel consumption of your car is actually calculated by the reported boost pressure times injection interval and not by fuel pump flow (so please check real fuel consumption not reported one by the board computer).
Even overreporting rail pressure to the ECU would not necessarily reduce fuel consumption (but would for sure make the car sluggish) since fuel consumption curves are optimized for constant driving and rail pressure in range from 1.5-2.5V (for higher range they are limited to minimize exhaust gases). Remember ECU works in a closed loop, so basically when you inject less fuel for the given load you slow down unless you step-up more on the gas pedal to maintain constant speed and then you actually end up spending more gasoline.
That is basically the reason why any descent tuning chip works only in higher rail pressure range (when car accelerates). On the other hand this is the only range where you could effectively (and safely) save some fuel. Problem is to significantly save fuel there you would have to make your car really sluggish.
Fastest rail pressure sensors have time constants above 1ms so speed of CPU/ADC/PWM should not play much of a role. The only place where the existing chip tuning boxes could be improved is to not have a static curve but calculate gradient of rail pressure and based on that info change a starting point of the tuning curve.
You obviously are involved in automotive R&D (as was I) but as you know the cars today are so complex is hard for one person to grasp everything. The short answer is: I don't know why it works, I can only speculate.
DeleteIdle consumption is very relevant in my case as city driving means basically stop&go traffic and my car does not feature start/stop. You are probably right about broken closed loop, the PID parameters for holding idle are tuned with some specific values in mind. I would especially be worried about instability in driver for the high pressure pump inducing some self-reinforcing mechanical oscillations.
The highway underreporting of rail pressure - I'm not exactly sure that's what it does since I don't have a clear picture on what the original signal should be, I intend to fix that in the next iteration so I that before/after can be precisely compared. My theory: the emissions and consumption peaks (vs. rpm) don't exactly overlap so this moves closer to the best consumption peak and away from the best emissions peak.
Also, rail pressure is just a parameter from the map, interacting with 10 others, so probably this is some lucky coincidence. However, my goal is to allow some reversible non-destructive fine-tunning, so if it's able to alter the engine working conditions then I would call it successful.
"so basically when you inject less fuel for the given load you slow down" - that's not 100% true. You should think closer to rich vs. lean analogy not gas pedal analogy.
You are right about response time, I wrote in a previous article, the sensors I've looked at are at ~2ms. I'm not sure how fast the ECU samples (I guess it depends on the manufacturer/developers) and how the low-pass filter is implemented on its input. It does make a difference when implementing the RC PWM filter which is dependent on the R of the output impedance.
"Problem is to significantly save fuel there you would have to make your car really sluggish" - that's not an issue to me, everyone has a different requirement. I just want to be able to make a 1200km trip with one tank, which was originally not possible.
Thank you for the comment, I always look forward to knowledgeable people explaining stuff.
"The only place where the existing chip tuning boxes could be improved is to not have a static curve but calculate gradient of rail pressure and based on that info change a starting point of the tuning curve." - which is exactly what the design above does. It's still missing important bits like input and power protection and fail-safe, but I did not want to invest more time if the prototype was unsuccessful.
DeleteAs mentioned by previous poster, you cannot use the cars trip computer to calculate fuel savings. This is becuse it assumes correct fuel pressure. You must do full tank to full tank (ideally using same fillig station pump) and actual mileage to get an accurate comparison. For an accurate figure you also need to calibrate the odometer (using GPS) for an absolute consumption value.
ReplyDeleteThat's what I assumed as well but it seems the consumption is tracked correctly on my car. Probably depends on OEM supplier and manufacturer requirements. After >200L of fuel I could see no significant deviation.
DeleteRegarding odometer - AFAIK it tracks the mileage correctly, only the speedometer reading has false corrections built-in. That's true for most modern cars that I know of, especially ones that have a factory GPS unit.