Imprecavo contro il nuovissimo ordinamento quando Nils ha detto :
I'm the one who pay for the board, the one that makes all the solderings ant the software guy :) ... oh yes, I'm also the customer!
-- Nuno on zx-6r '04 & CRe 250 '99 working in progress... La riforma della scuola è pronta dieci casse Marshall dentro ogni aula *** www.gladio.org ***
Imprecavo contro il nuovissimo ordinamento quando dalai lamah ha detto :
to
I've got a phonic wheel but it would not be "portable" to use such solution. I'd use instead the signal that goes to the ECU and an hall sensor. In this way I'd have to move just the sensor every time I change engine. Re-calibration would be done via software changing the number of cylinders and strokes of engine. Knowing the number of teeth of every phonic wheel is somehow harder.
-- Nuno on zx-6r '04 & CRe 250 '99 working in progress... La riforma della scuola è pronta dieci casse Marshall dentro ogni aula *** www.gladio.org ***
Increasing the number of cylinders doesn't make the shaft turn faster or slower. Neither does the presence or absence of a spark.
JS
Imprecavo contro il nuovissimo ordinamento quando JSprocket ha detto :
As I sayd to Dalai Lamah it's easier to count the sparks than the revolution of the crankshaft. from the sparks you can understand how many rpm is doing the crankshaft
-- Nuno on zx-6r '04 & CRe 250 '99 working in progress... La riforma della scuola è pronta dieci casse Marshall dentro ogni aula *** www.gladio.org ***
Now how would that timer loop count precise machine cycles?
-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
600ms wouldn't even be acceptable for a tachometer, it _certainly_ wouldn't be acceptable for a tachometer so cheesy it could only show increments of 100RPM, and it just plain wouldn't work at all for a governor application or an electronic ignition system.
Hence the suggestion that gives an answer with (hopefully) a usefully low delay.
-- Tim Wescott Wescott Design Services http://www.wescottdesign.com Do you need to implement control loops in software? "Applied Control Theory for Embedded Systems" gives you just what it says. See details at http://www.wescottdesign.com/actfes/actfes.html
You're going to couple to /all/ the spark plug wires?!? Inductive coupling to even one is going to be tricky.
Then do yourself one favor: Get a good consultant to check things out before deciding on a final circuitry. Maybe you can find one locally in Italy. I have seen similar designs where mistakes were made and it was too late.
For example the signal from the sensor needs to be pre-conditioned. Usually it's not enough to just digitize it using a comparator. Someone nearby keys the microphone on his radio and ... poof, it starts reading ghibberish. Ideally there should be lowpass, highpass, SW-adjustable gain and threshold, hysteresis (preferably also under SW control) and so on. Plus EMI filtering which is not an easy job at all in automotive.
-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
Maybe the engine uses a distributor and a single coil?
Use period to measure low speed RPM and frequency to measure high speed RPM. That way you will get response and accuracy that you will need.
Most of the current engine controllers now are measuring the engine speed from the crank sensor 60 -2 or 36 -1 (60 index markers with
2 gaps for synching)At low speeds the acceleration in an engine on firing can be impressive.
Regards,
-- Walter Banks Byte Craft Limited
Especially on motorcycles which the OP mentioned. Some of those can go from zero to 60mph or 100km/h in slightly over four seconds, revving the engine through several gears and up to 12000rpm peaks or higher. No idea how long an engine will last under that kind of stress but people do that.
-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
Actually, this is not correct. Let's assume that the sender (sensor) is the distributor high side, the number of firing pulses would be as you describe. However, the engine is still revolving between pulses, so the older tachometers take this into account as many have to be set up for number of cylinders.
On the other hand, if the sender (sensor) is the flywheel home pulse, then you will get a pulse each revolution.
Either way, 6000 RPM means the engine revolved 6000 times in 1 minute, or 100 times in a second. This is independent of firing pulses.
One of the best ways to create a tach. using a micro controller is to count 100 pulses, then see how long that took, then use a lookup table to determine the engine speed (MCHC11 for example -- used by many G.M. engine controllers up through 1998).
The number is actually an average because what is happening is a form of integration. If you are looking for min and max RPM, then count 1 pulse, get its time, etc.
Hope this helps.
Dave,
I don't follow your logic here. Why would a 100 RPM resolution imply that 0.6 sec update rate is not adequate? Who said anything about an electronic ignition or governor? Actually the OP said he wanted it for a data acquisition system in which case the requirements are very different. What is the update rate??? It may be that he is only storing data on 1 sec increments or longer.
All techniques have some lag to them, no measurement is instantaneous. Without a spec on the measurement time, there is no basis for saying that 0.6 sec is too long.
And what delay would that be???
Rick
That would be an exercise for the student! ;^)
Actually, are you serious that you don't know how to count machine cycles in an MCU? All of the small MCUs have deterministic timing. So your code can be measured to have a loop delay of Mn + B where M and B are constants and n is the repeat count for the loop. For sections of the code that have conditional branches, you can add fill code (NOPs) to make the timing of each branch equal. The loop checks the input to see if it has toggled and if so, increments a counter in memory or a register. When n iterations of the loop have completed the register is read to get the RPM, the value read is saved or transmitted, the register is cleared and the loop started again.
I'm not saying that this is something you would put in an MCU that is doing 10 things. But a $1 MCU with some 8 pins could be dedicated to this task and the code specifically designed for this. This is likely smaller, cheaper and lower power than many other solutions. Depending on the accuracy required, you might even be able to use an MCU with an internal RC oscillator or a very low power, low cost 32 kHz crystal.
Rick
Sure I know but it would be rather wasteful to block a MCU for pretty much any other task that way. Typically in an application like this your MCU needs to also calculate the RPM value, maybe do red range alerting, package it nicely in a format some display understands and then send it out via a link to an HD44780 chip. Or directly to glass.
Using a timer would be the smart thing to do.
-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
The OP mentioned motorcycles and he is in Italy. Have you ever seen a Ducati or Moto Guzzi revv through several gears and go from zero to freeway speed in just a few seconds? Some guys won't even stay in one gear for 0.6 seconds.
Desire (or command) to fetch the value versus actually receiving the value. On a motorcycle 0.6sec is an eternity.
-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
On a motorcycle 0.6sec is an eternity.
Especially when falling off at 80mph
martin
Ok, as an add-on, let me show you one reason. This is a Ducati accelerating pretty much at full bore, quite impressive:
Here is a clip of a Hayabusa where you can actually see the RPM gauge and how fast it has to be:
Now don't do this at home:
AFAIK the Hayabusa can get from zero to 100km/h in less than 3secs and it looks like the rider in the last video at times doesn't even spend those 0.6secs in one gear before shifting up. 0.6secs would not work at all for a machine like this.
[...]-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
(Actually, 2nd gear on that class of bike will get you illegal in almost every jurisdiction.) I don't recall ever watching the tach while twisting its nuts off, partly for the lag or just perceived possibility of lag, but mostly because the eyes and mind are already a hundred yards ahead of the bike.
If I were to build a tach for myself, I'm interested in 3 ranges of use. The first function is as you say. Timing between pulses and lighting a sequence of LEDs as it gets close to fuel shutoff is serves this need best. Minimum lag is required here. A little flicker between lights is OK, expected, and possibly useful of itself.
Near idle, I really do want good resolution, perhaps as fine as 10 or 25 rpm, to check the idle point, more out of idle curiousity while waiting for a light rather than any real need. Some smoothing to help readability is good, but it really should show the variability.
In a droning cruise, the case for almost all road miles, I want a dead smooth and readable response. Some lag is OK. 100 rpm resolution is sufficient. I use the tach rather than the speedometer to maintain speed. The speedometer has a built in 8.5% error and lags full seconds behind. The ears do a fine job of picking up small changes. The tach, substituting for the speedo, simply serves as a do-not-exceed reference point for that stretch of road. I might even like to toggle between the tach function and a digital pseudo speedo display calibrated for top gear only. (I doubt I would ever bother to toggle it to use it, though.)
It should be easy to build now. ;)
Out here I have the impression that biker don't give much of a hoot WRT jurisdiction. Especially the guys on the rice rockets. Surprisingly only one major crash so far but that one was really bad.
If you are a biker (I am not, but maybe some day ...) you might enjoy the tach in the video links I posted. The third one really gave me the chills, hoping the rider is still among the living.
-- Regards, Joerg http://www.analogconsultants.com/ "gmail" domain blocked because of excessive spam. Use another domain or send PM.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.