Skip to main content

Posts

Showing posts with the label arduino

Designing a better diesel tuning box - part 5 - tweaks and updates

Living close to a densely populated area means that it's hard to do consistent testing without spending a lot of fuel, which is also expensive. Nevertheless, I took the pen&paper approach and started working my way from the basics. I studied all the Bosch sensors from this page , used a bit of common sense and figured out that my sensor is a Bosch 0281002691, or similar, with a 180 MPa (26000 psi) nominal rating. This might be wrong but It's a good place to start. I've already used Torque and my multimeter to get some data and it seems to fit with the sensor I've chosen. It might be wrong, but so far it clicks into place. Using the data I've gathered I've created a simple JS page that shows some logs and tries to simulate what my module (and sensor) does: https://jsbin.com/goyavabuju/edit?html,output (Note that this is the HTML/JS result after I did the interpolation.) So the basic function is: the ECU commands the pump, this delivers a pressure

Designing a better diesel tuning box - part 4 - improved design results

If you are following the project you might've seen that the new source code for the firmware and (Android) client application are up: Arduino firmware:  https://github.com/ligius-/DieselTuningBox Mobile UI:  https://github.com/ligius-/DieselBoosterClient With that out of the way, I've had about a month of testing with the new prototype and several months already with the old one. The definitive result is that there are significant fuel savings. Outside city limits I now get better than 6L/100km, at highway speeds (130 km/h) better than 6.5/%. I believe the highway consumption can be further improved but I haven't used the car so much lately to be able to fine-tune the settings. Previously I would get 7.6L/100km at best on country/county roads and 7.4/% on highways. So that would be a 12% mileage increase on highways and 21% on slower roads. Inside the city is where the story changes since that's where I did most of my driving and had time to tune the pa

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 47oh

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 th

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

Fail: controlling a buck converter with PWM

I wanted a second try on my bench power supply build, something that would allow me to programmatically control the output voltage via an 'Arduino'. The supply already has two buck converters inside the unit, both controlled by their feedback resistors, so it was only natural to try to create a programmable resistor. Resolution The feedback resistors are in the potentiometer with ranges a few kiloohms. Since I'd like the output voltage to vary within 0 and 30V with a 50mV precision the needed resolution is 30/0.05 = 600 steps. That means a way to vary the output with 10 bits (1024 steps). A cheap 8-bit DAC ( PCF8591 ) would provide a resolution of only ~120mV. We should not confuse resolution and precision, but I will break the rules for now. Why a DAC does not work Third, just a DAC is not sufficient as we need to have the feedback voltage adapt to the output voltage. We could feed the input through and ADC, sample it, calculate and output the correct DAC value

I2C, Energia, Stellaris Launchpad and HT21D

A friend asked me to help him connect the HT21D temperature and humidity sensor to a TI board. He's using the TM4C123 board while I'm using the older LM4F Launchpad. The first thing to know is that neither of the boards have pullups adequate for I2C. You need to add a 4.7k resistor from SDA to VCC and another one from SCK to VCC. I've tested it with 1k resistors and it works with those as well. The second thing is that the Stellaris boards have several I2C modules, so you need to select one. Even worse is the fact that the Energia library by default chooses the Boosterpack: if(i2cModule == NOT_ACTIVE) {   i2cModule = BOOST_PACK_WIRE; } So you first need to go into this folder "\hardware\lm4f\libraries\Adafruit_HTU21DF_Library-master\" and edit two files as explained below. Adafruit_HTU21DF.cpp From: boolean Adafruit_HTU21DF::begin(void) {   Wire. begin() ;   reset(); To: boolean Adafruit_HTU21DF::begin(int moduleNo) {   Wire. setModule(modu

Decoding wireless weather sensor data

Being on the hunt for the cheapest wireless temperature and humidity sensors led me to FreeTec  NC-7345-675 - sold by pearl.de at the fair price of 10E, though I might have paid even less for them. The requirements were: multi-channel, have at least 0.5C accuracy and provide humidity readout. Rolling your own can easily cost more than that. The sensors pair with this weather station . The goal is to store all the data on an SBC and provide a nice HTML frontend with long-term statistics and heating automation. EDIT: blogger removed without warning all the newlines from my code, I had to redo some of those Hardware The first step is to open up the sensors and see what we are dealing with. With the main board detached from the zebra display connector, we can see the coil antenna at the top and the wires for the humidity sensor running at the bottom right. Judging by the traces going from the SW-CH part directly into the chip it seems there is no way to force additional c

Power supply project - part 2

This is a follow-up to  http://hackcorrelation.blogspot.de/2013/07/power-supply-project-part-1.html  in which I was trying to fix a car battery charger but ended going down the 'feature creep' path. It still contains two power supplies, one is 0-17V, the other one 7-25V. Unfortunately the input voltage is limited to 19V, which means the maximum output is lower than that. I would probably dump the transformer and put a 24V/2A HP printer power supply instead. The additions are two sets of binding posts and a power switch, better noise handling (star ground) and a new firmware. The top LCD display shows the voltage and current for the first power supply, with a nice 'clock' graph for the voltage and a thick horizontal bar graph for the current. This is duplicated for the second supply. The microcontroller also has a graph mode that can display any value over time, auto-scaled. Since the button to access that is on the back of the board I don't use it very of

Senseo custom firmware - update

This project is taking longer than anticipated even though it was supposed to be something simple. I will publish a schematic of the complete circuit in the near future (this year) but in the meantime there is still the slow process of troubleshooting. Safety considerations: the complete circuit is not isolated from mains so testing is pretty critical. I have been feeding 3.6V to test the low-voltage part but in the end it will have to be hooked up to 220V the boiler / water heater can only take a limited amount of pressure. If the thermistor is not properly calibrated in software there is the risk of a scalding hot water explosion With that being said there is some small but steady progress being done. The MSP430 has a some strange power requirements that are not properly documented. The VCC supply  needs to rise with >1V/ms otherwise it gets into an undefined state. That undefined state might also mean that some GPIOs are high, causing catastrophical failure. Curre

Building a new firmware for the Senseo coffee machine

This is one of those projects that just takes forever to finish, I must've started this 6 months ago. This part will describe all the hardware and various techniques used to figure out which signal goes where. Why do this? It's an improvement on the original firmware and an exercise in consumer product design. My goals will be listed in the second part of this post.

Power supply project - part 1

I've had a car charger break down on me and haven't been able to fix it. It has a sturdy metallic case and the transformer is still fine. The idea is to use some existing PSU modules I have laying around and fit those into the case, providing a readout on the display. Since it has to have a microcontroller (overpowered if I might add) it can also do some basic logging, over-voltage and over-current protection. I really hate designing my own supplies since there are so many ready-made around which are much better than I could ever accomplish.