Project Logs

Collapse

• Input

  numero_trey • 09/24/2014 at 02:05 • 0 comments

  Sensors on a car are tricky. Most are single-wire variable resistors to ground of very low value. According to the service docs, the fuel level sensor reads from 110-2 ohms (I have not yet clamped a meter on the sensor and read the actual values). This makes designing the voltage dividers tricky. I don’t want to sink too much current through them, and I want to get a good range of values from the AD converter.

  
  

  The Math

  I started by sketching out some different values for the sense resistor on a spreadsheet. The sheet I used allowed me to enter voltage to the sensors (Vsen), sensor min/max resistance, sensor min/max measured range (eg. 0-120 psi), the sense resistor value, and the reference voltage (Aref). It calculates the min/max voltage output, the min/max AD readings, the reading delta, and the real units per AD step (eg. 0.34psi/step). This allowed me to try dozens of sensor configurations and find the best configuration for all of the sensors.

  To measure engine voltage, I went with a 10-turn 10k pot as a simple voltage divider with some simple filtering. I worked backwards from a desired 0.02v/step (~20v range over 10 bits) and calibrated the pot with a multimeter and a stable voltage source.

  I decided to feed the sensors with 5v and use the 2.56v internal Aref in order to make my voltage dividers simpler and to alleviate my fear of a sensor going open circuit and dumping 12v into my AVR input. I’m worried about noise at such low voltages, but I think I can filter enough to mitigate.

  Revolutions

  Reading the RPM of the engine is a tricky problem, especially when you don’t have a running engine to develop on. You are trying to measure a high-voltage, very noisy circuit that requires lots of protection and possibly analog filtering. I played around with low-pass filter designs and schmitt triggers in case I need them once I get ahold of a running engine. At the time I was trying to have the system working for our first race in Feb 2014, so I wanted to make sure I ordered everything I might need. This meant I had to sketch out lots of variations and order the parts to build them all (all on spreadsheets). I tried to vary as few components as possible to limit my order.

  Reading

  I had to design firmware for the AVR to read all of these values. The sensors were fairly straightforward. I found code online to read a value from the AD x times, throw away the highest and lowest y values, and average. At the moment, I am reading 20 values and discarding the top and bottom 5.

  The tach presented a trickier situation. All the code samples I found online were to count pulses over a fixed time. Since I am measuring 2 sparks/revolution, this would give terrible resolution on the low end with a slow refresh rate. With a measurement period of 500ms, I would only have a 60 RPM resolution. This is not enough resolution on either axis for our purposes.

  I decided to try interrupts and a counter to measure the time between pulses. This was fairly easy to get up and running, and I was able to test by simulating the tach signal with an Arduino. It is very accurate, measures down to 29 RPM with a 16-bit counter, and updates every time it gets a pulse. Utilizing the 16-bit timer for tach eliminates my need for

  I realized late while prototyping the hardware that I needed to measure the voltage I was feeding the sensors (Vsen) so I could compensate for fluctuations in my power supply. When I decided to use the AVR’s internal Aref regulator, the AD’s reference voltage no longer varied along with Vsen (+-0.1v variation on Vsen == +-4% skew in my readings). Another multi-turn pot voltage divider allowed me to read my 5v rail and a little math integrated this value to increase my accuracy.

  
  

  Protection

  Piping dirty voltages into a critical safety system is a little nerve racking. We must be able to handle a sensor input shorting to ground, going open, or getting hit with a big voltage spike.

  Handling shorts is a matter of picking a sense resistor large enough to prevent...

  Read more »

• Prologue: The car and the need

  numero_trey • 05/30/2014 at 14:26 • 0 comments

  Back in Oct. 2013, I joined a racing team for 24 Hours of LeMons and other junker leagues. The team had an ‘86 Honda Prelude 1.8L with an engine that blew 3 laps into practice at their first race. I decided that the first project I should take on would be a digital dashboard to replace the simple displays on the factory dash and try to prevent another disaster.

  
  

  Research

  I was lucky to find Honda service manuals online for the car, as well as a used Haynes manual on Amazon. These books, combined with info from preludepower.com and other forums, gave me a good view into the electrical systems of the car.

  I discovered the ECU was a simple analog state-machine, and had been practically disconnected from the engine by my team. The ECU mostly controlled the carbs, choke, and spark advance for emissions control, which is not needed in a race car. Deprecating the onboard electronics gave me full access to the sensors on the engine. Some more research and measurements of parts gave me the specs of all the factory sensors.

  
  

  The Data

  While I was learning about the operation of the engine, I started sketching out requirements for the data I would like to collect. I wound up with the following list.

  • Tach
  • Speed
  • Water Temp
  • Fuel Level
  • Volts
  • Oil pressure
  • Brake fluid low
  • Accelerometer
  • GPS

  
  

  The Work

  I also started sketching out the functionality I needed.

  • Data Collection
  • Logging
  • Dash display w/values, gauges, and alerts
  • Lap counter
  • Lap/split timing
  • Wireless link to pit
  • Multi-stage shift light

  
  The Hardware

  I needed a hardware target to aim at while I sketched, so I tentatively chose an AVR for data collection and a Raspberry Pi for the heavy lifting. I’m familiar with both and had the hardware on hand so it was an easy choice. I grabbed a cheap 7” LCD off Amazon to use as my dash display, along with a standalone tachometer in case our computer crashes.

View all 2 project logs