StromTrooper banner

Speed sensor output specifics

5K views 9 replies 4 participants last post by  BigMan73 
#1 ·
Has anyone looked at the output of the DL650 speed sensor in detail? I assume it's a hall effect device an it looks like there are maybe 4 pulses per revolution?

The schematic isn't a lot of help. There are three wires. One is grounded and the other two connect into the speedometer. The manual show how to test the sensor using a battery, resistor and multimeter, but doesn't give any data on what the voltage levels should be when it's in operation.

I'd assume that one of the lines goes from zero volts to the supply voltage as each of the 4 magnets pass the sensor? I'd also like to know how long the pulses are for a given wheel speed.

I suspect I'm going to have to measure them myself, but if someone has already done it I'd be interested in what they found. The tough part of the measurement "in situ" is spinning the front wheel fast enough and smoothly enough to represent typical operation of the bike travelling at a constant speed.
 
#2 ·
The output is a 5V square wave.

I use the speed sensor output to calculate miles per hour for my automatic turn signal cancelling circuit. When I first made the unit the speeds were double what they should have been. My math seemed right so I looked at the sensor output with a scope. I was surprised to find that there were eight pulses per rotation, not four as the picture of the sensor would suggest.

For my purpose, in determining miles per hour it was only necessary to measure the full period as opposed to the shorter pulse. With the tires I am currently using, the time of one period at 60 mph is 0.009967108541812 seconds.

Ron :mrgreen:
 
#3 ·
Thanks Ron! That's very useful information. My time resolution is 10us, so 60mph would give me a 996 count, which should be just fine for my purposes. I assume you calculated the period rather than measured it with femtosecond resolution!

I've been building a microcontroller system for the bike. Currently it displays information on gear selection and battery voltage (charging system) and I've just added a deceleration function using a sensor from an old bicycle speedometer strapped to the fork and a magnet on the disk rotor. It lights up an auxilliary brake light if I'm decelerating at more than 0.2G (e.g. using engine braking) or if my speed is in the 0-1mph range. The intent is to keep cars off my tail without me having to manually flash my brake lights when I'm slowing down or stopped. If I can use the bike's wheel rotation sensor it cleans up the system a bit, plus with 8 pulses per revolution rather than 1 I could get a faster system response.

I'm also looking at a distance and velocity sensor for approaching traffic, though that's very much in the bench development stage right now. Might not be practical and might not be worth the cost if it gets too complex.

It would be great if someone finally hacked the SDS protocol so that info could be read directly from the OBD system, but as far as I can tell there's no published method to do that in a useful way. There are some hardware hacks for the interface and people have mangaged to pull some data, but nothing very useful as yet. Obviously it can be done since Healtech have done it. This thread is probably the best source of info on that - SDS protocol - ECU hacking
 
#4 ·
I measured it with the stop watch in my cell phone. Just kidding! :biggrinjester:

I calculated it prior to writing the program. I needed to do that so that I could tell if the program was working right or not. The micro-controller (PIC) does the measuring in the cancel unit. Once it gets the period time the program then calculate miles per hour. I use mph for all the comparison stuff because for me it's a lot more intuitive than using time periods or clock ticks.

I like the your idea of deceleration monitoring for brake light flashing. I'm doing something similar with my turn signal cancel unit but am not flashing brake lights. My cancel unit keeps the signals on when slowing or stopped. When above a minimum speed and accelerating it allows them to cancel.

Have you looked at any of the new accelerometers on a chip? I think one might be ideal for determining rate of decelaration. I was thinking of using one for my turn signal project, but in the end decided to use the speed sensor.

Thanks for that link. I'll check it out.

Ron :mrgreen:
 
#5 ·
I tried one of the 3 axis accelerometers (only using one axis) and it works fine but since acceleration and gravity have the same effect, going down a hill is the same as slowing down - and slowing down going up a hill can be the same as moving at a constant speed as far as the accelerometer is concerned! You also need a significant degree of filtering and signal averaging to remove all the high frequency jitter caused by bike vibration. Another negative is that you can't tell the difference between not moving and moving at a constant speed with an accelerometer.

So in the end I think a speed sensor is a far better way to do it. Once you have the speed you could do all sorts of fancy stuff. You could have multiple trip meters and a crude mpg estimate (once the gas level sensor has dropped below maximum. It takes about a gallon to move it off the upper stop). You could also have a maximum and average speed readout. However I'm trying to keep displays that have to be read down to a minimum to avoid distraction. I really don't want an LCD display with 4 lines of data. I have an LED display of gear and that's all I really need. I can use warning and status lights for most of the other functions.
 
#7 ·
snip...
It takes about a gallon to move it off the upper stop.
Interesting about the accelerometer. I hadn't thought of that.

On my bike it takes about 1 1/2 gallons before the float starts moving. The reason I know this is that I did lots of testing with the sender and fuel levels when I made my "fuel gauge corrector". With it, each bar now equates to one gallon (except the top bar).

Ron
 
#9 ·
Pulse width should be one of the parameters you would be able to read if you could crack the SDS protocol and access the OBD. The pulse width should give you instantaneous mpg but obviously you'd have to integrate it over time and store the data in non-volatile memory to get an average mpg. You'd also have to record every injection pulse.

On the other hand, mpg isn't something I really need to know in real time, so it's not something I'm likely to work on. I'm happy with calculating it when I fill the tank! A simpler system than measuring pulse width would be to detect when the fuel level sensor wasn't hard against the stop, then measure how the average level was changing with mileage. Should be pretty simple to do as long as you have the number of wheel rotations counted.

However the only real time parameters that I need right now (in addition to the stock instrumentation) are what gear I'm in and if the charging system is working correctly. The fewer readouts and distraction I have, the more I can concentrate on the road.
 
This is an older thread, you may not receive a response, and could be reviving an old thread. Please consider creating a new thread.
Top