Using My Speedometer Project

Hi(hope that I’m in right section), I want use “My Speedometer Project” from user ElectricWater,8790.0.html
I set everything alright, turn on the board and the project is working! yay! But after few miles everything freezes… Input don’t work, button to change screen dont work, whole board is dead.
I tought restart will help, but no. So I uploaded another sketch to my board and everything is fine, works like charm. I uploaded back Speedometer project, and nothing, sketch is still dead. I took another arduino, uploaded sketch, it works(yay), few miles and dead. Could the sketch did something to the boards? Or there is a problem in that skech?

Can you explain what you mean, please?

Now, I edited it.
And here is the sketch, same like from ElectricWater

Speedometer / Odometer Arduino Sketch
by ElectricWater

dfowler / for Timer2 code
MPGuino for Large Font inspiration
whosawhatsis / Arduino forum for Large Font code

This sketch detects a square wave input using external interrupt 0.
The signal's frequency is proportional to the vehicle's speed.
The sketch also detects internal Timer2's overflow.
The two are used to calculate the vehicle's speed, and the square wave count is also
used to report the distance travelled.

Interrupt 0 (Digital pin 2) is connected to the vehicle's speed sensor.
An interrupt service routine triggered by a rising edge on Interrupt 0 increments
a counter (SensorCount).

Timer2 in the AVR is reconfigured to run at 125 KHz.
An interrupt service routine triggered by Timer2's overflow increments a counter
(TimerCount) by 8 and tests to see if the counter has reached a predetermined constant
value (CalValue - used for calibration). If so, 3 things happen:
 - The value of SensorCount is copied intothe variable "Freq" for use in the main loop
 - The "Trigger" flag gets set
 - SensorCount and TimerCount get reset
TimerCount reaches CalValue at a very consistent rate, which is used to calculate the vehicle speed.
When CalValue is properly calibrated the value of Freq is equal to the actual speed in Miles per Hour.

The Timer2 ISR aslo causes digital pin 4 to toggle between high and low for testing purposes.

Note: The reason for incrementing TimerCount by 8 is that the sketch when first written
originally configured Timer2 to run at 2 MHz, which is 8 times faster than its current 250 KHz.
Slowing down Timer2 to 1/8 its original speed and having the ISR add 8 instead of 1
allows the AVR to spend less time servicing interrupts. This change resulted in no
noticeable degradation in speedometer function.

The main loop tests to see if the Trigger flag is set. If so, several things happen:
 - The variable "Speed" is set to the average of the 3 most recent cycles of "Freq"
 - Speed then gets printed on the LCD in large 2-line block font.
 - Freq is used to update the odometer
 - Odometer information is printed to the long as we're not in a menu
The main odometer uses the variables TotalClicks, TotalTenths, and TotalMiles.
The trip odometer uses the variables DistanceClicks, DistanceTenths, and DistanceMiles.

TotalClicks is increased by the value of Freq each time Trigger is set, which means that it is
a running total of the speed sensor's pulses. CalDist is a calibration value that when adjusted
correctly is equal to the number of sensor pulses per 1/10 mile. Therefore, when TotalClicks
reaches CalDist the vehicle has travelled 1/10 mile, so TotalTenths is incremented and CalDist
is subtracted from TotalClicks. When TotalTenths reaches 10, TotalMiles is incremented and
TotalTenths is reset to zero. When TotalMiles reaches 100000 it gets rolled over back to zero.

The trip odometer then goes through the same process, except that DistanceMiles rolls over at 1000.

A trip odometer reset button is provided via a pushbutton switch connected to digital pin 6 (Button1).
Digital pin 6 has its internal pull-up resistor turned on and the pushbutton drives the pin low when pressed.
When a low is detected it resets DistanceClicks, DistanceTenths, and DistanceMiles to zero.

Interrupt 1 (Digital pin 3) is connected to a power-fail signal that goes low when the unregulated DC voltage
drops below ~10 volts. When ISR1 is called it copies all of the odometer data into EEPROM for use the next
time the circuit is powered up. Upon power-up the EEPROM is read back into the odometer variables.

An options menu is beginning to be implemented. Menu navigation is controlled by the 4
pushbutton switches connected to digital pin 6 and analog pins 0-2 (digital pins 14-16).
The A0 button (Button2) is used to enter the menu mode, and also to exit menu mode.
A1 (Button3) and A2 (Button4) is used to flip through the menus.
D6 (Button1) is used to select a menu option.
Once inside a menu option, Button3 and Button4 is used to change the data.
Button1  is used as an "OK" or "Enter" button, while Button2 is used as an "Exit" or "Escape" button.

The first menu option is to adjust the calibration value (CalDist) for the speed sensor count. (CalValue
is calculated from CalDist). When the CalDist is changed and "OK-ed" it will be written into EEPROM,
which is read again on power-up.

The second menu option is to display a temporary distance meter that reads in feet.

MenuMode is an integer variable that will change depending on which menu the user is in.
MenuMode = 0, no menu
MenuMode = 1, calibrate speedometer
MenuMode = 2, foot distance display mode

-----The circuit connections-----

 Speed sensor input to Digital pin 2 (interrupt 0)
 Power fail input to Digital pin 3 (interrupt 1)
 Timer2 test output is on Digital pin 4

LCD hookups:
 * LCD Vss pin (pin 1) to ground
 * LCD Vcc pin (pin 2) to +5V
 * LCD VO pin (pin 3) to ground
 * LCD RS pin (pin 4) to Digital pin 7
 * LCD R/W pin (pin 5) to Digital pin 5
 * LCD Enable pin (pin 6) to Digital pin 8
 * LCD D4 pin (pin 11) to Digital pin 9
 * LCD D5 pin (pin 12) to Digital pin 10
 * LCD D6 pin (pin 13) to Digital pin 11
 * LCD D7 pin (pin 14) to Digital pin 12
 Pushbutton switches:
 Button1 to Digital pin 6
 Button2 to Analog pin 0 (Digital pin 14)
 Button3 to Analog pin 1 (Digital pin 15)
 Button4 to Analog pin 2 (Digital pin 16)
 Physical protoshield layout of the pushbuttons:
   ----  ----
   ----  ----


// include the EEPROM library code:
#include <EEPROM.h>

// include the library code:
#include <LiquidCrystal.h>

// initialize the library with the numbers of the interface pins
LiquidCrystal lcd(7, 5, 8, 9, 10, 11, 12);

// build 2-line digit font data array
// Digits are 3 characters wide.
byte bignums[10][2][3] = {
// Define which characters to use for each number. 255 is a solid block; 254 is a space  
// The format is { {TopLeft, TopMiddle, TopRight}, {BottomLeft, BottomMiddle, BottomRight} }
 { {255, 0, 255}, {255, 1, 255} },        // data to display "0"
 { {0, 255, 254}, {1, 255, 1} },          // data to display "1"
 { {2, 2, 255}, {255, 1, 1} },            // data to display "2"
 { {0, 2, 255}, {1, 1, 255} },            // data to display "3"
 { {255, 1, 255}, {254, 254, 255} },      // data to display "4"
 { {255, 2, 2}, {1, 1, 255} },            // data to display "5"
 { {255, 2, 2}, {255, 1, 255} },          // data to display "6"
 { {0, 0, 255}, {254, 255, 254} },        // data to display "7"
 { {255, 2, 255}, {255, 1, 255} },        // data to display "8"
 { {255, 2, 255}, {254, 254, 255} }       // data to display "9"

int CalDist;                              // Calibration value for the odometer
                                          // Increase to increment slower, decrease to increment faster
                                          // Equal to the number of speed sensor pulses per 1/10 mile

int CalValue;                             // Calibration value for the speedometer
                                          // Gets calculated from CalDist
                                          // Increase to read faster, decrease to read slower
/*   ---Time and distance math---

  Timer2 runs at 250 KHz and counts from 0 to 255 before overflow.
  Each overflow triggers an interrupt adding +8 to TimerCount. This happens 976.5625 times per second.
  Therefore, TimerCount increases by an average of 7812.5 per second. We'll call these increases in value "counts".
  We'll call one pulse from the speed sensor 1 click.
  CalValue "counts" = 1 mile/hour 
  Formulas for relating CalValue to CalDist are as follows:
                                   7812.5 counts       1 click       1 hour   3600 sec      1 mile       2812500
  CalDist (clicks per 1/10 mile) = ------------- x --------------- x ------ x -------- x ------------ = --------
                                       1 sec       CalValue counts   1 mile    1 hour    10 1/10 mile   CalValue
                      7812.5 counts   3600 sec   1 hour      1 mile      1 1/10 mile    2812500
  CalValue (counts) = ------------- x -------- x ------ x ------------ x ----------- = ---------
                          1 sec        1 hour    1 mile   10 1/10 mile     CalDist      CalDist   

Let's see a schematic of your connections to the vehicle. You need to protect the inputs and the Vin from the car's electrical system.

I havent connected it to car yet, but I'm using Hall Sensor from VolksWagen

Jirka10: I havent connected it to car yet, but I'm using Hall Sensor from VolksWagen

How are you driving it "miles" to test it? I'd still like to see how you have the sensor connected.

Look at photo, and in the sketch there is output for testing. And the sensor is from gearbox…
btw. I have Mega1280 and Mini328

Ok, I can't see whats on the protoboard where the sensor plugs in. Can you point to a link that shows how this sensor is wired? Is it an open collector output, or is it magnetically generating pulses thru a coil? If it's the later, then that's what is smacking your boards. You need current and peak voltage protection on the input pin.

Sensor has three outputs. + - and rectangular signal whose frequency changes by the rpm in gearbox

Are you applying 12V to the + connection of the sensor? If so, then that's the problem. This came right out of the article you referenced:

"For power I'm running off the vehicle's battery, but I did take some protective measures. There's a dedicated line that connects very close to the battery itself, which from what I understand makes a pretty significant filter. I plan to use a key-on powered relay in the future, but for now I just plug in the PCB when I'm going to drive somewhere. I also have a simple overvoltage/overcurrent protection circuit that I constructed in the power cable:"

EDIT: I realize this is talking about the power connection, but the same applies to the input pin. If you have a 12V square wave coming out of the sensor, then it is quite likely that it is damaging your boards if you don't put anything in-line to limit the current and voltage.

Ahhhh, and what if im using test pin, from the sketch? And the sensor is powered with 5V from Arduino Mega and the sensor is givin 5V pulses

Jirka10: Ahhhh, and what if im using test pin, from the sketch? And the sensor is powered with 5V from Arduino Mega and the sensor is givin 5V pulses

I'd still be tempted to look at the signal and make sure no large spikes are present.

Ok, I will, but if I try another sketch boards looks pretty well, and if I write mileage manually to EEPROM it will show on the display.

Ok, I will, but if I try another sketch boards looks pretty well, and if I write mileage manually to EEPROM it will show on the display.

Have you verified that the actual I/O pin that is connected to the sensor is still working fully? You can “kill” portions of an individual pin. Fortunately, you would only have to replace the 328 chip (assuming you have the thru-hole part) for a few bucks to repair it.

Yes, I have. And when I use another sketch on same pin, everything works fine.

Well, either the pin is damaged or it isn’t. It’s not possible that it stopped working with your sketch, yet works with other sketches. Either your sketch has a bug that you don’t see, or the pin really is damaged in some fashion. Like I said, you can damage “part” of the functionality of a pin without killing everything that it can do.

If it is damaged, then it seems apparent that it’s the sensor causing the damage some how. Therefore, you need to examine the output of the sensor on a scope if you can, and you need to apply some kind of input pin protection. If you plan to install this in a car, then you will absolutely have to provide protection for the board. Don’t just connect it to a “convenient” 12V source, you will end up damaging a lot more than a pin. Without some kind of dampening, your board is likely to see 50V surges on the power or even reverse voltages are possible. Just do some research, there is a lot of good info out there.

Okay, I'll give it a try this weekend. :)

I was just saying. Would you please try this sketch? You don't need any sensor, you can use "test" pin(info in the sketch).

Jirka10: Ok, I will, but if I try another sketch boards looks pretty well, and if I write mileage manually to EEPROM it will show on the display.

Maybe a sketch that tests the operation of that Hall sensor would be good, right after a sketch that tests the pin it was connected to. If you don't troubleshoot those two and either one is bad then you'll just go in circles until you either do or quit.

I did both of this, but I'm trying to say, that there isn't problem in senser even in pin that I connected it to. I tought that there is a problem in the sketch, but it would do to another people using this sketch. I'm kinda confused.