Digital speedometer schematic available here (PDF, 34KB).
C source code available here under GPL (ZIP, 22KB).
I like knowing how fast my car is going, but the stock analog speedometer only goes up to 140kph. Plus, I suspect its accuracy isn’t all that great, it doesn’t register speeds below 15kph, and there’s no way to calibrate it. I looked at digital speedometers online, but most of them were backlit LCD displays (almost illegible in the sunlight atop my dashboard, and an eyestrain even when you can read them). The ones that weren’t were just too expensive for what should be a rather simple piece of electronics. I wanted a three digit 7-segment LED display, like my buddy Takahashi has in his Lancer EVO 6.
I looked at frequency counter chips, figuring I could use BCD decoder and a trio of 7 segment driver chips to display everything, but they were outdated and the amount of external timing circuitry I’d need was a bit ridiculous. I looked around at the local electronics supply store, and stumbled across some cheap programmable microchips. At first I thought it would be overkill, but considering a simple microcontroller is only $2 or $3 and reduces the number of parts significantly, it actually turns out to be the best option. Plus, you can add extra features like in-software calibration, 1/4 mile “drag strip” times, storing top speed, display in kph or mph, and whatever else you can think of. The drawback is the initial investment of a PIC programmer so that you can use your computer to burn your programs to the chip. You can now get an official PICKit 2 programmer for about $35 plus shipping, and it can be used on a variety of microchips all the way up through DSP microchips. If you’re into hobbyist electronics, there’s really no reason you shouldn’t get one. Cheap, easy to program, and powerful enough for most stuff.
The cheapest microcontroller I could find was the PIC16F648A, which is an 8 bit microcontroller with 16 input/output pins and 3 hardware timers, more than enough for this project. It has 256 bytes of RAM, 256 bytes of EEPROM permanent storage, and programming storage space for about four thousand instructions, and best of all, it doesn’t require any external oscillator hardware. PIC microcontrollers have a very minimal instruction set, meaning that any operation more complex than addition or subtraction requires a lot of instructions, but since this chip defaults to 1 million instructions per second that’s not usually a problem, assuming you have a compiler capable of generating those sequences. As well, almost every input and output is reprogrammable to different hardware functions such as voltage comparison, interrupt triggering, edge counting, timer capture, or even serial communication. It’s really quite a powerful little package, especially if you compare it to what was available just 5 years ago.
Your basic 7 segment LED has 10 pins. Two of those are the same, connected to either the anode or the cathode of all the LEDs, and the other 8 are the other end of each of the 8 LEDs. Since 24 LEDs is too many to control with 16 pins, I multiplexed them; that is, the 8 individual pins are all connected through resistors to 8 of the microcontroller pins, and I use 3 other pins to select which of the three displays to light up (via transistors since the PIC pins can’t source that much current). If you switch between the displays fast enough, the human eye can’t even tell they’re being switched on and off.
Obviously the whole thing runs off 5 volts, so to step down the 12-14 volts from a car battery you need a voltage regulator (I used an LM7805 because it was what I had on hand). A couple capacitors also help, as cars tend to have lots of voltage transients. If I wanted to be a bit safer I could have also used a zener diode for overvoltage protection, but the power supply area of the circuit board was already a bit tight for space and the LM7805 and associated components are cheap enough to replace if something bad happens.
Here’s a quick parts list of what I used:
1 – PIC16F648A microcontroller
1 – 18 pin socket (not needed if you’re just breadboarding it)
3 – 7-segment displays, common cathode
8 – LED resistors (I used 120 ohm, but you should design with the max LED current in mind.)
3 – NPN transistors, anything should work
3 – 1k resistors (to use with the base of each transistor)
1 – LM7805 5 volt voltage regulator
2 – 22uF 50V capacitors (maybe overkill, but if you have noisy wiring you will need to adjust this)
1 – button (for software control)
2 – 10nF capacitor (button debounce and speedo input filtering)
1 – 100k resistor (button pullup)
AND
a board to put it all on, and cables to string it together. You should be able to get all this stuff for under $20.
If you’re hooking this directly to a reed switch with no external driving circuitry (like a stock ECU), you will have to add another pullup resistor.
The easiest way would just be to hook up all the 8 LED leads to the same 8 bit port (PORTA or PORTB), but because we’re using some ports of A and some of B to do other things, we can’t be so lazy. So we’ll spread those out and use a software bitmask to determine which ports to light up. Thankfully, it doesn’t really matter that much what order they go in, because you can define it in software. The speedometer input has to be on a specific pin if we want to automatically log the timer when we get a pulse. And one of the pins cannot be used as an output, so we’ll set that one to be our button input (and when we’re putting our board together we’ll use it as a reset pin). Aside from that, we can stick the three selector bits wherever we want them, and still have the two serial port pins left for CAN interfacing if we want it, and another for supply voltage sensing (so we can determine whether the headlights are on or off and dim the display accordingly). The parts for these last two options aren’t included in the list above, because I haven’t added them yet.
Once the hardware is all set up, you need some software to run it, and that’s the tough part. The first order of business is reading the chip manuals thoroughly, and then finding yourself a C compiler, because programming in assembly is time consuming and rife with pitfalls. I started with cc5x but the free version only does up to 16 bit math, and it has a slew of other problems (“Can’t generate code” is the chief among them, requiring you to manually simplify your code and manually define intermediate variables for calculations). But I tried out SourceBoost and the free version has far fewer limitations. The code should first set up all the interrupts and config registers, define the BCD and seven segment driver code, set up the timers, and tell the main loop to show something useful. It’s best to stay simple; the first version of my code simply did a lamp test (all on, all off) and then displayed a rising sequence of numbers (which was actually just a spare timer I wasn’t using). This makes sure your lamps all work and your wiring is correct. Then you can start adding in code to test that the pulses are being received and triggering properly without bounce, probably using a counter.
Update 1:
It seems one of the LED 7-segment displays I bought has a bad lamp (D, the one on the bottom). Of course the test lamp feature caught this easily, but only after I soldered everything to a board. Note to self: in the future, use sockets instead of soldering 7 segment displays directly to a board.
Update 2:
It turned out the lamp wasn’t bad at all. It was just a short from overzealous soldering. Unfortunately I didn’t catch this until AFTER I had ripped out the display element, trashing it in the process. Oh well, there goes 200 yen. But the good news is that it works now, and I’ve worked out the software bugs I’ve been able to find.
Update 3:
I finally wired everything into the car. My wiring was fine, but I had lots of noise in the input signal, causing a small interrupt storm that sent the microcontroller into fits. A small capacitor (10nF) between the signal and ground wires at the speedometer fixed that problem. Driving around, the speedometer was just fine below 10kph, but above that there was a lot of jitter in the time between pulses. I’m tweaking the algorithm to average more and more pulses at higher speeds, but since memory is limited this is an interesting problem.
Update 4:
I’ve had a chance to run the speedometer in my car for several months, and it’s given me a chance to test it out. It works pretty well, is a lot more visible than my stock speedometer, and turns a few heads to boot. (“You built that YOURSELF??”)
Since several people have asked me to release the source, I will do so. The source is released under GPLv3. You are free to take the code and use it, modify it, and improve it. If you fix any bugs let me know so I can fix them on my speedometer too! Also if you build your own DIY speedometer and put it in a car or bike or whatever, I’d love to see it. Please ask me before using it in a commercial product; I’ll probably say OK but I would like to see the end result! The source does have known bugs which I haven’t gotten around to fixing; these are listed at the top of the source file in the comments. The biggest one is that quarter mile calibration still doesn’t work properly; with snow and ice on the ground I wasn’t too motivated to fix them. Now that spring has arrived, I can do so.
As the GPL works, if you redistribute assembled code including hardware with the code installed, you must distribute the source along with it. You got it for free, so you can’t complain.
The test modes included in my source code all let you test your wiring easily; simply set MODE_DEFAULT to MODE_TEST in the code, recompile and flash, and the tests will run when you apply power. The first test should display a constantly increasing number which wraps at 255. This makes sure your lamps are wired correctly and set up in software correctly. Press the button to go to the second test. The second test shows how long the button has been held down; a count of 30 is about one second. Use this to make sure your button works properly and isn’t bouncing. After about 15 seconds the pulse counter mode is activated. This will show how many speedometer input pulses have been received. This is handy to verify that noise isn’t triggering as pulses, and the pulses are registering properly. If all three of these tests work, then your wiring is correct and it should be possible to calibrate the speedometer (drive 50 and enter calibration mode) and display your speed.
Update 5
The schematic I’d posted before was using the wrong parts in the wrong configuration. I’m not sure how I screwed this up, but it’s fixed now. Thanks, Velson.
Since I’ve moved back from Japan and have changed cars, I don’t have a working testbed anymore. Feel free to submit patches to the code or modifications to the schematic, and of course if something doesn’t look right please let me know so I can fix it.
Not a problem! I’m glad it works.
First try running the calibration routine; it’s set up to calibrate at 50. Inflate your tires to proper pressure (because the reading is sensitive to wheel diameter). While driving 50 (miles per hour or km per hour), have a friend hold the speedometer button down until the menu appears, then tap the button to cycle through until it says CAL, and then hold the button down to enter calibration mode. Hold a constant speed of 50, and the speedometer should self-calibrate. When the speed reappears, the calibration is complete. You may have to try the calibration several times to get an accurate reading (use a GPS if you have one, stock speedometers are often off). If the displayed speed is not close to 50, you will have to modify the code to introduce a multiplication factor somewhere. I should be able to help with that.
I never did get around to setting up a kph/mph option, so just calibrate to 50mph if you want the speed in mph.
If you’re switching to common cathode, you may need to make some substantial modifications to the circuit (switch from NPN to PNP transistors) and possibly invert some outputs. If your 7 segment displays have a reverse output (forward bias green, reverse bias red) then use that, you’ll save yourself a lot of time.
Hey, Almost got it built on a board to mount in the vehicle. I think to make it accurate. I would take the amount of samples it uses, and divide this by 2? Would this not cause the outcome to be twice as fast?
Also. in comment 51. you say “if you’re switching to common cathode, you may need…….”
From what I could gather. The circuit is already built using common cathode. I wish to go to common anode. If this were the case, and you are correct with saying the schematic and programming uses common anode, then it would appear both types of LEDs will function.
Brian
Hey Jeff.. sorry to bother you.. I’ve almost got it working perfectly.. Just somewhere in code, I need to change it so the output is double. I’ve tried to calibrate while driving 50, and it goes back to 25.
Thanks
Brian
OK, about the doubling of the speed, the best way to do that is to cut the perceived pulse delta in half (the pulse delta is the distance between signal “spikes” from the speedo sensor). Scroll down in the code, there are two functions, one called make16 and the other called make16i. They have a block labeled “asm” inside each one, with 6 lines of assembly code. The assembly code here does a 3 byte barrel shift, twice. Add another one to each function by adding the following lines in again. The lines should be added inside the asm block.
rrf _bigtimer+2, 1rrf _bigtimer+1, 1
rrf _bigtimer, 1
So in the end, the make16 and make16i functions will have 9 lines inside the asm block instead of 6.
Hello again.I compiled it with Sorceboost and tried to simulate the schematics and the program in Proteus unfortunatly it didn’t work..:(.I’m considering making a test board before I build it completly.I want to ask you exactly what sensor did you use?I’m guesing a hall sensor, but I don’t know wich to order.And on the test board to simulate a sensor can I use a switch?
Thanks
@ #55, what are you going to be putting this into? I’ve got mine connected to the Vehicle Speed Sensor (which is a variable reluctance sensor). So i believe it can be connected to anything (that outputs pulses). As the schematic for it states.
Brian
for Brian
I have to present it to my teacher first and show that it works.On the final board I have to put a sensor,but to test it I think I have to put something else…I’m not very good at electronics…
If your lab has a waveform generator, use that to output a 0 to 5V square wave. Something around 10-20Hz connected in place of the sensor should work fine. As you increase the frequency, the number shown should go up. If you don’t have one of those, use a simple button or switch as shown within the dashed box on the schematic. For this case use the hardware test mode that counts the number of pulses.
Jeff
After putting in that code. All seems to be perfect!
Before you gave me that bit to add in, I tried something myself where I multiplied the equation of newspeed by 2. This did seem to make it accurate, but the speedometer would only increment by 2′s.
Now, it seems to work like it should, but when calibrating it… If I was driving around 50.. the calibrated speed would be significantly lower. So I tried it while on the highway, and it worked perfect at a higher speed.
Anyway. Thanks a lot for all your help! A working product will make the report flow much easier. Appreciate everything.
Brian
Hey, Jeff!
About the current through the LEDs, do you know with your 120ohm resistors what was it’s value? Should I rather go with 150ohms or greater? The brightness should remain sufficient I guess… Did you get 120ohm experimentally or with calculation?
That was a calculated value based on the voltage applied minus the saturation voltage of the LEDs (which I honestly can’t remember for my LEDs). This gives you the voltage across the resistor, and you can use Ohm’s law to calculate your desired current from there, and select an appropriate resistor value.
Your 7 segment display sheet should tell you what the saturation voltage and the max steady state current through the display should be. Since the current is PWM, you can fudge the numbers a bit and be OK, but typically 10mA is sufficient to get a bright display. Even if you go as high as 25 or 30mA it might be alright, but you’ll shorten the life of the display or possibly blow out the elements. When in doubt, read the datasheet.
OK, that’s clear to me but according to this calculation the current should be roughly 28mA which is a bit much. So, correct me if I’m wrong, a different type of calculation should apply, because of the duty cycle of the LEDs.
The saturation voltage for most of the LEDs is 1.6V. If the supply voltage is 5V then:
I[A]=(5V-1.6V)/120ohm which gives 0.028A. Taking the duty cycle in consideration this current should be lower but how lower?
Your calculations are correct.
I think I might have shot for 30mA at 1/3 duty cycle, and I can’t remember the specs; it might have been 10mA or 20mA max, but I probably overdrove it. The main concern is heat dissipation; if the current is too high for too long, the LEDs blow out from internal thermal stresses. But most LEDs can tolerate much higher currents at lower duty cycles.
Hi again ,sorry to disturb again but I read the code over and over again and I don’t undarstand how did you think the calibration.Especialy I don’t understand what foo is and why are u using it.I don’t understand what the roling sum does. And why did you calculate this :// 3600 sec/hr * 125000 smallticks/sec * 1.609km/mi * 1/4 mi => 181012500 smallticks * km / hr
In a word I don’t understand the principle of calculateing the speed and calibration,the rest I understand.
Could you be so kind and explain it to me via email at [redacted for safety],I would be very greatfull.
Hey Jeff. Speedometer works great. Pictures can be seen at http://www.fiero.nl/forum/Forum1/HTML/076039.html
Thanks for everything!
When driving, sometimes the speedometer will jump either really high, or really low, then count back to where the current speed is. I have to theories for this:
1. Maybe the pulses are the exact same for an extended period of time, causing it to think that it is reading zero.
2. Maybe for some reason, I am having something short, causing the PIC to maybe reset?
Have you ever ran into this situation while you had it in your vehicle for a few months?
Brian
Nicorici, I’ll try to respond to your question first. The “foo” being calculated in the MODE_CAL section is a very complicated way of determining about how many “smallticks” are necessary for 1 kph (or 1 mph if you’re using that). A “smalltick” occurs every 8 microseconds, if I remember properly, and it has to do with limitations on the hardware timer I’m using (which recycles about every 2 seconds). Obviously if we used smallticks as a measure of time between speedo input pulses, we’d overflow a 16-bit unsigned integer. But 32 bits is too many, especially when we must do division in software every time we calculate our speed. This would be prohibitively slow for dividing 32 bit by 32 bit. So we divide it out to minimize the number of bytes needed, which is where we get “bigticks”. A bigtick happens every 32 microseconds, and is a pretty good measure of time. This is because at 1 kph on the stock setup, the distance between two pulses doesn’t overflow 0xFFFF bigticks. So doing some rather nuts math, “calib_factor” is approximately the number of bigticks between each pulse at 1 kph. You’ll see the “make16″ function used in several places to shorten 3 bytes to 2, and also divide by 4 to change 24-bit smallticks to 16-bit bigticks (the asm code does two right shifts for a quick division). In Brian’s case, we set bigticks to be twice as long (64 microseconds), because at 1 mph the pulse length DID overflow.
Brian, I had the same issues with the weirdness. It’s related I think to a glitch in the software, but I was never able to pin it down. In my case everything would reset to 0 kph and then run up very quickly; it happened only occasionally, probably because of a missed timing event. There is a condition that resets the speed to zero in case no pulses are received for about 2 seconds; this might happen in real life if you slow down very quickly, and is intended to make sure the speedo reads 0 when you are really stopped. It’s possible this is being triggered. Alternatively there may be an error somewhere if division by zero occurs; the software divide cannot throw exceptions or a flag, and the result is undefined in such a case.
Also note that at 10, 20, 40, 80 etc the speedometer switches modes from averaging one to averaging more than one time measurement. This averaging is done because otherwise the jitter would overwhelm the measurements, but when switching back and forth the display will glitch out sometimes. There is a better way to calculate the speed (modifying calculate_speed, and perhaps the interrupt routine) such that there are fewer problems… since it’s installed in your car, I’ll leave it up to you! If you get it working better, let me know. I’d start by googling FIR filters. Remember that multiplication and division are REALLY expensive to do, but dividing or multiplying by multiples of 2 is cheap (using barrel shifts). If your calculations take too long, the speedometer will not update properly, and may glitch even more, so be careful.
Hi,
on the account of calibration, if I knew all the data I could avoid this step by simply putting the values in the software…
My wheel passes 1.695m per rev. and the magnet gives 7 pulses (does 1 3/4 turns and has 4 pulses per turn). When I do the math the time between two pulses at 1kph is just over 1 sec (1.12 roughly)
If a bigtick is 32us then the period is 35000 bigticks (0x88B8).
Where should I poke this value? I ask you this because I don’t have an accurate reference to calibrate to.
Anyway I should finish it soon and test it on a longer trip I’m taking this summer. I’ll post some photos after that. It’s not as fancy as Brian’s but it’s not bad I guess :)
#define CALIBRATION_SPEED_KPH 50
#define DEFAULT_CALIB_FACTOR 48094 <- replace this with 35000?
#define DEFAULT_PULSES_IN_QTRMILE 941
Yes, that will work. But calibration should work even better than manual entry, if you get it right. The problem with manually entering it is that the value you calculate won’t match exactly because of variations in tread wear, tire pressure, and such. Make sure your tires are inflated to recommended spec before calibrating the speed, and try running calibration a couple times until you get a satisfactory result. Then you can hook the PIC back up to a programmer and read those EEPROM values.
Hi again and thanks for the useful info.Sorry to bother you so much but I realy need to understand the pinciple of calculating the calib_factor.You say that “calib_factor” is approximately the number of bigticks between each pulse at 1 kph but in the program you count 256 pulses…To be honest I really don’t understand the math the thinking….and I reali need it to explain to my teacher.
If you could show me an example of teh math or something….I will be forever thankfull.
The pulse counting bit counts 256 pulses in an attempt to figure out how long a single pulse is. You could theoretically calibrate with just one pulse if you could get the wheel spinning just right, but just like in the laboratory it’s best to take many samples. So we start a timer (which counts in smallticks), count 256 pulses and then stop the timer. That gives us the length of 256 pulses at 50kph. So far so good?
Logically, the time taken for the same number of pulses at 1 kph is 50 times longer. So we multiply by CALIBRATION_SPEED_KPH. We then take that number and divide it by 256 (using shift operator) to get the time of a single pulse at 1kph, in smallticks. Divide that by 4 (foo >> 2) and you get the pulse length in bigticks, which ideally should fit into a 16 bit unsigned int.
The part in between for pulses_in_qtrmile is rather confusing, and never worked properly anyway. It’s supposed to calculate the number of pulses it takes to cover a 1/4 mile (or about 400m) for drag racing purposes. Obviously it won’t match dragstrip times if the sensor is on the driven wheel because of wheelspin, but the idea was to give you relative estimates of how much faster your car was after a mod. If you can get that working and figure it out, please let me know so I can fix it.
Hy again Jeff ,I just wan’t to thank you for this project and for the explications.Now I finaly understand the progam.
Hi Jeff
I have been trying to put together this speedometer but have run into trouble.
When I apply power nothing seems to happen. I have tested with a multimeter and between pin 4 and gnd I have +5V.
I have also tested the 7seg LEDs like described in comment 15 and they all seem to work properly.
It seems like the pic outputs too low voltage. Between 6, 12, 13 and gnd it only reads ca 0,5V. It’s even lower between the pins connected to an anode and gnd (0,1V).
It seems to me that the pic is operating in some kind of low voltage mode, but I am not very good with pic processors.
What should I do to correct this? Any help apreciated.
Hi Jeff,
I tried compiling the source with BoostC, but it seems the program is too long to compile with the free version, is there any way you can send me the compiled hex?
I would greatly appreciate it.
-Yon
Try removing some of the unneeded parts; you can comment out the entire quarter-mile section. Alternatively, you can unset _DEBUG and it will reduce the code size considerably, but you will lose access to the test modes.
To Erik,
While running, pins 6, 12, and 13 are duty cycling. If you attach them to a scope you should see each one pulsing about 1000Hz square wave, 0-5V. If you want to make sure the PIC is working properly, probe the voltage at pin 1 with your multimeter in DC voltage mode, and then apply power. The programmed lamp test should cause the voltage to go high for one second and then low for half a second before starting the duty cycle switching. This should be slow enough for your multimeter to register the voltages. If the circuit works properly, you should see 8.8.8. on the display briefly, then blank, then 0. If the LEDs seem dim, make sure you’ve selected resistors to run them at their rated max current.
Hi Jeff,
It turns out it wasn’t too long to compile it using the free version, I just wasn’t waiting long enough. Sorry about that!
-Yon
Hi,
made it, had trouble with it, then I got it to work. Strange thing, though, I only managed to calibrate it nearly perfectly when I was driving around 10kph give or take a few. When I was doing it at 50 after it had finished I got very low readouts, something like 1 or 2 at more than 60kph.
I added the same piece of code as you suggested to Brian and, as I said, calibrated it (in ultimate desperation) at very low speed. Now it reads OK, maybe 3-4kph off.
Now, as for the data, you wouldn’t by any chance now where in earth does the PIC save the calib_factor (lo and hi) values, would you? I suppose the first few bytes would be those, but I’m not really sure.
Lastly, when I’ve found it, should I increase or decrease the value to correct the readout? It should be showing 4kph more than it does now (reads 56 instead of 60 for example).
Anyway, great circuit, despite the fact that those above glitches are present in my speedo too. If I find a way around them, I’ll make sure to let you know.
Many thanks!
I am unable to find pic16F648A ,is it possible to program it to a pic 16F628A
Thanks
Should be possible. The two are pin compatible, and the only difference is that the 628A has less program storage space and a little bit less RAM. The latter won’t matter, but the former might cause problems. I can’t remember how big the compiled code is.
Because of this, you might have to cut some of the code out to make everything fit with the debugging version. The 1/4 mile timing mode would be a good place to start, since that doesn’t work anyway. You could also remove the calibration routine, though you’d have to be very good with your initial measurements and adjust it a couple times by hand.
Hi Jeff
Thanks for the info, i eventualy got hold of the 648a chip.I have been battling for a hole week now to get speedo to work, I was about to throw the hole project in the trash ,but i went through the older coments and found one from Velson Oct 2008.I’ve had the very same problem.
All is fixed now and it works great.You are one of the few guys that are willing to explain and help.As soon as the speedo is build into my car i will send same photos.
Many thanks again
Hi Jeff
great job! thanks :)
I added a taho too (4 digit distance and 6 digit mileage)
p.s.
there is a small bug in your code (hi instead of lo)
version: 0.2, 21 May 2008
line 471:
temp2 = eeprom_read(eeprom_pulses_in_qtrmile_hi);
Thanks Jeff!!
Hey there 0000 ………
can you please email me re: the 6 digit distance mod you added??? VERY interested in this part…. bennettsi@hotmail.com
I have been wanting to add an odometer function to store the KM/Miles travelled in either flash or eeprom and have it display on a seperate display…..
thankyou!!!
Wow. I can’t believe I missed that. It would explain why the quarter mile code never worked as I expected. Thanks, oooo! The latest version of the code should be fixed.
hi.I want to build this speedometer but without hex. i can’t do nothing.i’m beginer so can you send me the hex. file for microcontroller.THX (lewy)
Where is the best place to place the sensor?
In virtually all stock vehicles there’s an existing sensor on one of the non-driven wheels, and in auto-transmission cars you can tap off that signal at the transmission itself. In most cases there’s a way to grab the signal, whether it’s a VR sensor (in which case you’ll need an op-amp and something to handle the voltage spikes), a Hall Effect sensor (no extra hardware required if it’s 0-5V output), or a simple reed switch (which needs to be driven somehow). If the stock speedometer is working, there’s a sensor somewhere.
everything works great except i cant get it calibrate correctly. i am using a door contact(alarm door switch) for a sensor. i first connected it to a fan to check if its working and it calibrated to 50km/h. but after i installed it in my car it calibrates between 15 and 20. maybe its because the sensor is connected to the front shaft
Can someone please help me out with an odometer function?
Thank you
Jeff – Great job. I’ve been looking for something like this to clean up the dash on my Harley. Hopefully I can wrap my brain around it to add in an odometer function. Just a thought on the calibration that might be a safer method – calibrate to pulses per mile. It would be easy to mark off a known distance, start the calibration routine and then stop the routine when the mile has been reached (or kilometer as the situation might warrant). Not always feasible to have a second set of hands to assist. Good work.
hey jeff…. Can i use PIC 16F85 for this project…?
i cant find PIC 16f64 in my place as far as ive searched.. that program is specially designed for this Chip is it?? i dont have much knowledge about micro contollers..
so…. what changes ive to make in the program in order to use PIC 16f85 chip? this is also a 18 pin package.
thanks man….
Greg, that’s a great idea. If you want to modify the existing code to do that, you should be able to adapt the quarter-mile code, which does essentially the same thing. If you do mount on a motorcycle, waterproofing is going to be a big concern, even if you put it behind a windscreen. I’d like to see the final product when it’s done!
Winston, the project was designed on a 16F648a. Unfortunately the 16F85 only has one hardware timer, and this code uses all three timers on the 628a/648a series. While it might theoretically be possible to use a single timer, the 648a is common enough that you should be able to mail-order several for under AUD$15 plus shipping. In a pinch, 16F628a has only half the program storage but should also work with some tweaking and removal of unnecessary code.
can u gave me hex file
mahesh@brilliant.lk
mahesh_srilanka@yahoo.com
Hello, I’m trying to compile the C speedometer, but I’m getting an error message. My compiler is MikroC. Could you help me, stating that compiler use to create the HEX file;
I’m a beginner in C programming, and I have some doubts. So I am asking your help to complete the assembly of the speedometer. After all, what better learn by doing. I have read that many people set up and would be another in doing so. Thank you for your attention and I await a response.
I used SourceBoost to compile my original code. Unfortunately there’s not a “standard” compiler for PIC microcontrollers. The most common source of errors if you’re using a different compiler would be related to how your compiler names pins and registers. Could you post an example of the errors you’re getting?
hello, how you asked me, it happens the following error when I compile the file:
error: Can’t open include file “system.h”
#include
1 error in preprocessor.
LINE 0:0 – unknown pragma line ignored:
#pragma DATA_CONFIG, LVP_OFF,
&_BOREN_ON &_MCLRE_OFF,
&_PWRTE_ON &_WDT_OFF,
&_INTOSC_OSC_NOCLOCKOUT
LINE 83:0 – Syntax Error: Expected “)”, but ‘forceupdate’ found.
LINE 117:0 – ‘;’ expected but lastpulse_stale0 found.
LINE 117:0 – Specifier needed
LINE 117:0 – Internal error
If you can help me, I would be grateful.
Hey, could you provide the HEX code for download for me to test the Proteus operation, while we solve the problem with my compiler?
Jeff, How would one make your speedo read XXX.XX ?
I am building a fast pedal kart, and I want to be able to read the .XX so I can see if I get close to breaking the land speed records for pedal power.
Many Thanx
PeterT
Is it possible to set the calibration for a 20″ bicycle wheel?
What parameters would have to be changed so that the speedo will work off a bicycle type set up,
Current records for upright/upwrong bike is 75kph, Aero recumbent bike is 133.33kph, aero trike is 126.?? kph and aero tandem is 113kph, and I believe my bike will beat them all, but I cant really measure my speed accurately if I hit over the 200kph mark, as common bike computers heel over at 199.99kph
Many Thanx
PeterT
You could certainly add another digit at pin RA0. If you wanted 5 digits, you’d have to use some sort of multiplexer– you could get up to 8 digits that way. Adding a decimal is also certainly within the abilities of the code. But to be honest, the filtering isn’t set up for that level of accuracy, and changing it would require substantial modifications.
In your case, if you want high accuracy, why not use a GPS? Most can be coded to give you current and max speed, and work independently of wheel diameter. If you swap out your wheels for better gearing or make other mods, you’ll have to recalibrate a normal speedo anyway.