making bike speedometer

Go To Last Post
27 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi

two monthes ago i started learning about avr. i decided to make bike speedometer a little while ago. i am using mega16 @ 8mhz with 3410 nokia lcd. reed relay for reading "did the wheel do the whole circle". this was a first problem. when i read the state of relay with ICP pin a got a several impulses more then i should (i guess because it is switch after all). so i did this but i dont know if there is other method to solve this:

ISR(TIMER1_CAPT_vect) 
{
      if(prvi_impuls) // flag to catch just one impulse
	{
		impuls++; 						
		p_impuls = FALSE;
	}
} 

ISR(TIMER1_OVF_vect)
{
	TCNT1 = 64535;
	mili_sek++; // ono milisecond passed for counting time and date
	time++;     // ono milisecond passed for counting time on wheel
}

.
.
.

// in main()

TCCR1B =  (1 << CS11) | (1 << ICNC1);  // prescaler 8, input caputre noise canceler
TIMSK = (1 << TICIE1) | (1 << TOIE1);  // interrupt
TCNT1 = 64535; 

MCUCR = (1 << ISC11) | (1 << ISC01); // falling edge
GICR = (1 << INT1) | (1 << INT0);

while(1)
{
          if(!p_impuls) 
		{
			speed = op / time; // mm/ms = m/s
			speed *= 3.6; // in km/h
			

			p_impuls = TRUE;
			time = 0; //reset time to 0, the wheel did the whole circle
		}
.
.
.

when i make a quick pass with magnet it counts one puls, but if it is a slow it counts 2.
i dont know if that is the good way i am doing things so if i can get some feedback i would be grateful

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

well,

you could use a timer to add a delay after the first read. There is a large(relative) time that the switch should not be activated after an activation.
Also debouncing might help here....

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am sure that there must have been a lot of speedometer projects. I just use a regular commercial unit.

I guess that the MCU will spend most of its time fast asleep, and even when running it probably clocks fairly slowly.
After all a 207cm circumference wheel does not go that fast. 50kph is 14m/s or 7 revolutions a second.

So your reed switch is going to fire every 140ms - 2000ms. I have never pedalled at 50kph!

Your AVR only has to wake up to record the pulse. My bike computer only calculates average speed every minute or so. It does not even need to calculate current speed more than every few seconds.

The LCD does not need much power either.

Returning to your reed switch bounce. You can safely assume that any pulse < 100ms is suspect. I would guess that a reed switch bounce will be in small milliseconds anyway. So you can either use regular software debounce or just ignore anything after the first 'make'.

It depends on how keen you are on battery life.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

thank you for replies. i dont know if i will implement it on my bike but it is, as it turns out, a great project to start learning things

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The reed switch has a certain amount of inerita and will require a minimum amount of magnetic flux intergrated over a period of time to close. So at slow speeds you get a solid close while at high speeds you barely get it to close, and with some bounce. You might need a stronger magnet, or to reduce the distance between the switch and the magnet to get good operation at high speed. You also might consider the use of a hall effect sensor (which has no moving parts).

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
You also might consider the use of a hall effect sensor (which has no moving parts).

Hall effect sensors require constant current source for excitation. I do not recommend this for battery powered devices.

Why do you actually need a debouncing on ICP1? If you expect speeds from 1.5m/s to 15 m/s (periods from 1.3s to 0.13s), log the first edge only.

Quote:
when i read the state of relay with ICP pin

Do not read the state of the reed switch(hope you meant that) at all! Simply read one chapter of ATMega16, titled "16-bit timer counter, input capture".

- set pullup on ICP1 pin
- set T1 prescaller to 256
- enable TICIE1
- enable falling edge of ICR
- sei.

Each time your reed closes, content of TCNT1 is latched in ICR1 register.

#define DISTANCE_UM 2000000UL
ISR(TIMER1_CAPT_vect)
{
 static uint16_t ticks_since_previous_capture=0;
if(ticks_since_previous_capture<1000)
{
 //I am pedalling 270km/h or contacts bounce?
 //No, I guess contacts bounce.
 //I will wait for next ICP then.
}
else
{
//So there was a longer pause between captures..
ticks_since_previous_capture=ICR1-ticks_since_previous_capture;
 uint16_t current_velocity;
current_velocity=DISTANCE_UM/ticks_since_previous_capture; //velocity scaled in um/T1_ticks.
Update_LCD(current_velocity);
}
}

Mind this is a simple sketch of an ISR, so it does not calculate velocity correctly when you are not moving, going deadly slow or pedalling 300km/h.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Brutte wrote:
Why do you actually need a debouncing on ICP1? If you expect speeds from 1.5m/s to 15 m/s (periods from 1.3s to 0.13s), log the first edge only.
At high speeds the switch will bounce since the magnetic flux isn't strong enough to overcome all of the reed switch's inerita. He may see two edges for a single pass of the magnet, so some form of debounce may be required. Using the switch to drive a counter is a nice idea, the input should be disabled after each count for a long enough period to avoid seeing extra bounce closures, but not long enough to miss a second true pulse. As was stated before pulses won't come faster than once every 100ms at speeds that a bicycle can move it.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
He may see two edges for a single pass of the magnet

I get it, but still does it matter if at some speed he gets N edges? Since he is only interested in a period of the signal.. He can measure the time from first to first, or from last to last. Will it change anything with debounce in case of 1.5m/s to 15m/s speed?
Quote:
the input should be disabled after each count for a long enough period to avoid seeing extra bounce closures

Step by step, bit by bit. I guess the most difficult part of speedometer is division and scaling.

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

He needs to measure the number of pulses per second. He can use an interrupt or a counter to accumulate pulses, and a timer to end the counting window. OR he can use the period of time that the switch is not closed to gate a counter and determine the period or rotation throwing away readings that are too small (a bounce would only be in the low ms range). Then convert the period of rotation speed.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Why not use an optical rotary encoder? Overkill? Maybe. But no bouncing!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hectorheadgear wrote:
Why not use an optical rotary encoder? Overkill? Maybe. But no bouncing!
It's mechanicaly simplier to mount a magnet on a wheel spoke and a reed switch to the front forks than trying to couple an optical encoder shaft to the wheel rotation. I guess you could try and mount an IR led and photo diode on the fork and an interrupter blade on the wheel but the alignment would be tricky, especially if the wheel didn't run true. You'd also have to realign the thing every time you changed the tire. Also note the constant current consumption of the LED.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
but the alignment would be tricky

I used to have a bike with a little generator on it. It was mounted on a bracket attached to the bike frame, and a rubber wheel on the end of the shaft that ran along the side of the wheel rim. There were never any alignment issues. An encoder could be mounted in a similar fashion, but this solution would require more code work. That same bike actually had a magnetic reed switch speedometer on it, so that is probably the best solution. :)

On the other hand, if you're going to take the time to build something that already exists, why not go overboard? ;)

In fact, overcome the power supply issue by combining a generator to supply the uC and rotary encoder in the same housing, mounted by bracket as above. Add a light flasher and small stereo, and now we're talking! Ed Begley would be proud.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I meant that the alignment to get an interrurpter blade between an LED and Diode would be tricky. I've seen those old generators. If there is any slippage the reading would be off with the optical encoder. Also the shaft speed on the encoder might be too high with that method.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

GPS

No RSTDISBL, no fun!

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
GPS

I love that creative stuff.
As said above, the OP has the right idea just needs to flesh out the details.
I realize I have been zero help, but I get off on looking at a problem from 30 different angles. Especially where hobby stuff is concerned and creeping elegance creates a monster.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

i can se an explosion of ideas... but i am not building traction control system so the system can take control if the tire slips.

as the third post said. avr would most of the time be idle. does the frequeny need to be lower? if uC is asleep what mode is suited for it if i want it to count time as well or it does not matter cause it has to be awake every second

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

can anyone answer on question pls so i dont have to open new topic

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Since bicycle speedometers are inexpensive and standardized it doesn't seem a good idea to me to design and make a new one. You couldn't make one that is as good as a $30 one that you could get eBay, but you could spend $100 and 100 hours trying. One of the skills that make a successful electronics designer is knowing when to just buy something that someone else has already made.

There is a mountain about 50 miles from Portland Oregon that has a six-mile-long well-paved road between the Timberline Lodge and the main highway. It is very steep for its entire length and has several long straightway passages. About 20 years ago, when I was young and stupid, I once rode down it as fast as I could on a bicycle and got up to 40 MPH in a couple of places, according to the bike speedometer. 40MPH in a Buick is boring, but on a bicycle it is most definitely not. I can't recommend doing anything like that now to anyone with half a brain, but all AVRfreaks are welcome to try it out.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it is not meant to be better then some speedometer on market rather to learn something from that project...

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

ljudiii wrote:
can anyone answer on question pls so i dont have to open new topic

Do not worry about the sleep / current consumption for the moment. Design your algorithms and get the speed, average speed, maximum speed, odometer etc displaying to your satisfaction on a regular 16x2 LCD.

Cycle computers have been around for 15..20 years. Just watch the way that they work. And yes, a magnet on a spoke with a reedswitch on the fork works just fine.

You can compare your device with a regular £8 computer.

Now you can start experimenting with slow clock speeds, long sleep periods etc. I would guess that you can match the commercial units for battery drain. However, the cost of a bespoke LCD is going to be expensive. Experimenting with refresh rates etc is another job.

Yes, it sounds fun to do. Unless you have some special functions that are not available on commercial computers, a home-made computer is not very practical. For a start you need to rain proof the device, and fit on your handlebars.

Good Luck.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess if you want 1% speed accuracy, you need to time the rotation period within about 1%. 40mph with a 26" wheel is 58 fps/ 6.8 ft/rev = 8.5 revs/sec = 177 ms/rev. Real Slow. Maybe use a 1 or 2ms tic. Now I guess we need to trigger a falling edge interrupt with the reed switch or hall switch. An C across the reed switch from a pullup R with a TC of 20ms would eat the bounce, but allow the cap to charge back up before the next rev. Inc a tic count in the tic handler. Inc a rev count in the edge handler, and read current tics. Calc delta tics (need to keep tics last pass). Do the period to speed calc in the loop, not the int handler.

Imagecraft compiler user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I missed this earlier.

I have a homemade bike computer with read switches for wheel and crank inputs. I basicaly run a 1024Hz timer in the interupt routine I increment 16 bit counters and sample the inputs. On the apropriate input transition if the count is < 50 I ignore it as bounce. On a valid input transition I increment a revolution counter as well as taking a copy of the apropriate 1024Hz counter and reseting it I set a flag for my main loop.

My main loop takes the latest recorded count to calculate speed and check for max speed. The revolution count increaces the trip and total milage etc. I don't know if I can miss a single revolution event but using the counter means my milage update will be good whether I miss the event or not.

The project has grown a bit over time I now have SD logging, a presure sensor for altitude, a gps. An ant tranciver for heart rate as well as wireless speed and cadence sensors. The ant also provides a wireless link to my homemade bike lights which the bike computer controlls. It's this feature that is not comercialy avalible that got me going on the project 2 years ago.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

hi,

just want to let you know how it looks...
there are 2 buttons like commercial seedometer, one reset and one to move to next function. on the first power on there is initialization. next step is putting it all on pcb






  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

This may not apply, but I made a speedometer with many functions for my electric assisted BMX...

I used the hall effect in the brushless hubmotor, which allowed the system to mess around with the limitations of the motor controller, allowing for a much higher top speed.

The hall effect system worked perfectly, and I used an AVR324p connected to a 128x64 LCD. I will see if any of the code is left over, but sadly I did not document it very well.

How about adding a strain gauge as well and then you can measure your output power. Add an HRM, and now you have a rolling fitness machine, able to train you in that sweet BPM zone!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good work getting things going. My first version used just buttons for controll but version 2 has moved to rotory encoder as well as two buttons which makes changing parameters a lot easier phisicaly and the coding is simpler as well. If I do another version I guess I will try a touch sensertive display.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Say, what is the resolution on your LCD? It has a nice square aspect ratio from the looks of it.

You did a great project there... cheers!

Brad

I Like to Build Stuff : http://www.AtomicZombie.com

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

it is nokia 3410 display. res 96x65