Monday, May 23, 2016

Designing a better diesel tuning box - part 3 - simplified design results

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

Consumption


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:



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


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.


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.

Thursday, May 5, 2016

Designing a better diesel tuning box - part 2 - simplified design

There are many variables needed to get a reliable product, so while taking a break from the ISO automotive requirements I thought of playing with a barebones design - just an Arduino, an HC-05 module and perhaps a few passives.

Concept - this is similar to what the boxes on the market do - read the value on ADC, output the modified value with PWM. I'm using an Arduino Nano for this, took about half a day including the 'preview' spreadsheet.

Nano pinout:

  • Vcc to sensor supply (5V), from ECU
  • GND to sensor ground
  • A0 the output from the sensor
  • Pin 9 goes to ECU (former sensor data)
  • TX goes to RX of HC05
  • RX goes to TX of HC05
Notes:
A0 should probably be pulled up to Vcc through a 1k resistor, I haven't tested this yet. Perhaps the Arduino weak pull-up would work.
Pin 9 (PWM output) should go through a resistor and capacitor connected to ground, 1k with 0.3u looks good in my tests.




The first two pictures show the Android phone connected to the HC05 for sending commands and receiving telemetry. The third one is the Arduino terminal on the computer running at the same time. While HC05 is serial data can be sent to the computer but not from the computer.

The user settings can be stored in the internal EEPROM.

After proving that the concept works and is fairly reliable (in a non-automotive environment) I took the time to make an Excel sheet (actually, OpenOffice) to chart the input versus output and compose the serial configuration string.


Regarding serial, the arduino sends each second a status with raw input and raw output. This incidentally also blinks the white LED (on pin 13) so you should see a bright flash if everything is running fine.

A tighter loop - every 10ms - reads the analog input and adjusts the PWM output. By default the output is sent unmodified (i.e. module is inactive), to get it to enable you need to send 'e' via the terminal. Conversely, send 'd' to disable it. While enabled, the LED will light up with a low duty cycle.

Terminal commands:
  • e - enable offset ('boost' car)
  • d - disable offset (do nothing)
  • rm - reads the minimum value from which the module starts working
  • rM - reads the maximum range
  • rc - outputs the entire configuration (version, min, max, curve points)
  • sm - sets the minimum range. Example: input sm300 - press enter
  • sM - sets the maximum range. Example: sM800
  • sC - sets a point on the curve. E.g. sC5117 sets point five to value 117. This means that during that specific range the output will be offset above by 17%
  • sX - sets the entire configuration in a single string. Can be generated by the spreadsheet
  • S - saves the config to EEPROM
  • L - loads the config from EEPROM, overwriting the current one
I won't provide a detailed explanation on how this works, just play with the green numbers in the spreadsheet to see how the output (blue) changes and whats the 'gain' (red) compared to original.

There is no error checking, no failed user input protection, no electrical protection, no watchdog protection and absolutely no warranty.

Other things: the PWM output is running at 60kHz, I think since the original sensor has a 2ms response time this could go unfiltered to the ECU. I assume they are filtering it there. The bootloader adds a startup time, ~5s, that could cause the ECU to trigger an error if it expects something during that time. I don't think it does.

To get you started, the minimum signal (while powered) should be 0.5V, the absolute maximum should be 4.5V, the car idle voltage should be around 1.2-1.5V. In my example above, the idle voltage is increased (to lower fuel consumption while idle) while during the other active ranges the voltage is decreased (adding power).

Power consumption is 25-50mA.

Edit: initial live tests

I got the engine light on (blinking coil) but the engine did start. The values I was expecting were a bit different than the real ones. Got an ADC value of 243 (1.18V) for engine idle (~780 rpm) and 256 (1.25V) for 1000 rpm.
It seems that the bootloader startup delay might be interfering with the ECU expectations (see above) or a pull-up resistor is required somewhere. Will have to do some measurements to determine the exact cause.

Monday, May 2, 2016

Designing a better diesel tuning box - part 1 - I/O board

As seen from my previous post and the sources enumerated in it there are several competing designs on the market that basically achieve the same thing - apply a negative offset to the rail sensor voltage.

Since none of them offer a desirable amount of control (for the price) I'm open sourcing an own design.

Goals:

  • full programmability - curves, upper and lower threshold limits
  • telemetry
  • reasonably fail-safe
  • MCU agnostic - as far as possible
  • preserve the original waveform signal
  • easy to make - should not require exotic or expensive components

The overall architecture is simple: read sensor data into the microcontroller, process the signal, send an analog (PWM) signal out.

Disclaimer: this is probably not road-legal in many countries (missing certifications) and it might break the car subject. I am not responsible if anything bad happens, do it at your own risk.

However, it's not all dark, as I've already written there should be no damage as the unit still functions within factory settings and I will try to make everything as safe as possible.


In this first part I will focus on the driver electronics: concept, simulation, schematic and (perhaps) PCB. Since this is just a prototype I'm currently omitting protection circuitry.

Simulation


The improved concept I came up with is applying the negative offset through an opamp subtractor. This way, if the microcontroller ceases to function the unmodified signal will be sent back to the car ECU.



The simulation above provides proof of concept: the yellow trace is the output from the pressure sensor, the blue trace is our modified signal that gets sent to the ECU.