OK I'm just starting trying to help solving the issue about the jumping values:
Tim do I understand right that you changed the voltage-divider from
rpm-signal
>----10kOhm
x
>
Prop-IO-Pin
at "x" there is a resistor 100 kOhm connected down to Ground
and changed it to
rpm-signal
>----10kOhm
x
>
Prop-IO-Pin
at "x" there is a resistor 10 kOhm connected down to Ground
Is this correct?
The 10kOhm-resistor between rpm-signal and Prop-IO-pin limits the current
into the prop-IO-Pin down to
1V / 10000 Ohm = 0,1mA = 100 µA. The voltage reaching the Prop-IO-pin is still 5V.
So an "over"-voltage of 5V-4V = 1V must be "driven away" through the internal clamping-diodes inside the propeller-chip.
They can stand a current of 500 µA. So this is a working circuit.
Me personally I would prefer a voltage-divider like this:
rpm-signal
>
12 kOhm
X
20 kOhm
ground
At "x" the prop-IO-pin is connected directly or maybe through a 150 Ohms resistor
In this circuit the maximum voltage going into the prop-io-pin is
5V / 32 kOhm) * 20 kOhm = 3,125V which is surely detected as "HIGH" but inside the limit of 3.3V.
Now the jumping value come from noise on the rpm-signal.
In the rsing phase of the signal the voltage jumps - for a short time - around 1.65V.
1.6 up to 1.7 down to 1.59 up to 1.75 down to 1.61 etc.
so the counter is detecting multiple lows and highs through the noise before the signal becomes stable at 4.5V.
And this noise is causing the jumping values.
Now this noise can be filtered out in two ways:
using an rc-filter. (I don't have a circuit and values handy)
or by using a schmitt-trigger like JonnyMac suggested.
The chip JonnyMac suggest suits very good because it is 5V tolerant at the input
even if you supply it only with 3.3V to stay within the rated limits of the propeller-chip
This schmitt-trigger filters out the noise because
- let's start at a signal-voltage-level of 0V
supplied with 3V the output stays low until the voltage raises over 1,75V. Then the output switches to HIGH
and the output WILL stay high until the input-voltages stays over 1,00V.
This means as long as the noise in your signal is smaller than (1,75V - 1,00V = 0,75V) the propeller-chip "sees" only ONE
pulse even if the noise would make your signal jumping up and down a thousand times between 1,1V and 1,7V)
Now as you have bought a 4-channel digital storage-oscilloscope (DSO) you are well equipped to analyse your rpm-signal
and any kind of filter-circuit to get proper readings from the propeller-chip.
Tim If you have any questions please post them here or send me a PM for more assistance and supporting.
I appreciate you taking the time to help me understand this part of my project. In a previous post, I read something about using an OP amp to help clean up the signal so I found some that I had purchases from RadioShack a long time ago and have been reading Wikipedia on how they work. I am not sure if the ones that I have will work since they do not Schmitt trigger op amps. The part number is 741 according the the package.
the 741 is a very classical OPAmp.
I prefer LM358 because the LM358 has internal offset-compensation and a much higher input-impedance.
I have no practical experience with the 741. But as it is an OpAmp it should work.
The behaviour of an OpAmp depends on the external ciruitry around the OPAmp. Schmitt-trigger is one of these behaviours.
Scroll down the page until you find schmitt-trigger. There is also a some explanation
The other filter-circuit is to use an rc-low-pass. The noise has a high frequency and the low-pass-filter will "let through" only low frequencies.
In real high frequencies are "lowered down". For using this we need to know what is the maximum frequency that the rpm-signal comes in with.
As you have a DSO know you can test the circuit excellently. If you connect one probe to the rpm-signal directly and the second probe to the output of the
OP-Amp. This is nescessary for testing as the 741 the maximum-output voltage is lower than 5V. The datasheet says at supply-voltage +-20V maximum output-voltage
is 16V. (voltage-drop) You have to check with your DSO if the output-voltage is still above 1.7V so the propeller-chip can surely detect a HIGH-signal.
More modern OPAmps like LM324 or LM358 have a lower voltage-drop (around 1.5V) and there are also rail-to-rail OPAmps with almost no voltage-drop at all.
(rail-to-rail = Output-voltage can swing from Ground-rail to supply-rail)
It would help to know more about your circuity. What kind of sensor is feeding the Propeller? Also, when the speed changes, what do you see on your scope? Do the ~10ms wide pulses you highlighted in a graphic get narrower, or does the spacing between them change, or both?
As has been pointed out, the electrical environment of an automobile is VERY noisy. A simple RC circuit can help filter that noise, the Schmitt trigger after than provides a clean transition into the Propeller. The simple circuit suggested and I've attached may just be the ticket to keeping your code very simple. I used the TinyLogic Schmitt in the circuit but that's easily replaced by the more readily-available opamp circuit Stephan suggested.
When viewing it on my O-scope while driving, the pulse width and pulse spacing changes as I change the speed. My question is, why would not simply using INA[speedsensor] work? If the prop pin has a threshold of around 1.4V, would the "on pulse" signal be more than enough to trigger this? In my previous posts a few pages back, I posted code that I wrote that calculates time between the ON state of a pin to the next ON state. Maybe I am trying to make this too complex, just throwing out ideas to make it work easier for me
The sensor that is feeding the PROP is referred to as a Reed Switch in the manual. I have not taken my dash out to look at it, but I would figure a reed switch would have serious "bounce" issues at higher speeds. It may be a reed switch or it could be a hall-effect sensor as well. Too much work to pull the dash to find out....
When my wife gets home from church, I can go get some more screen shots which could help out a bit more. I am watching my kids right now I will also see if I can get a better view of each peak to see what kind of noise I am working with.
After reading over the OpAmp schmitt circuit, I noticed it is using a 5V source and expecting around a 3.3V input. Would a 3.3V source input work? I could use the voltage divider I already am using to convert the VSS input to ~2V which would make the new threshold voltage ~1V correct?
EDIT: the value of the lower and upper threshold-voltage depends on the values of the resistors.
On this website you can let calculate the resistor-values for any threshold-voltages you like http://sim.okawa-denshi.jp/en/rercal.php
If I understood right you are using some kind of voltage-divider but with not optimised values or not optimised connection to the prop.
Can you please make a hand-drawn schematic how you have the rpm-sensor connected to the prop and upload the picture to a posting?
The bouncing or other kind of noise causes the rpm-signal to go up and down several times below and above the threshold-voltages of 1.65V.
The internal circuitry of the propeller-switch is very fast. You can feed in a 1MHz-pulsetrain and the counter will still count every single pulse.
So as long as the rpm-signal goes up and down below and above the threshold-voltage of 1.65V even if it is only for micro-seconds the counter will count too much pulses.
Now you could try using software-debouncing. For this you have to analyse what is the shortest period the pulses can have. The software-debouncing will only work as long as the noise
is not overlapping the time-window of the debouncing-algorithm. If your device is used in other vehicles there will be other kind of noise. So noise-reduction and noise-filtering is the better way.
Do these vehicles have a EMU anyway? (electronic motor control unit) most of them provide a rpm-signal.
If these vehicles are custom-made anyway I hink it would be a good investment in reliability to mount a magnet and a hall-sensor somewhere in the motor.
Most of the vehicles the other version has been used on all have stock ECM's that are chipped and tuned. Others use AEM or Ostrich which also have a RPM signal output. I have the RPM function working properly and accurately though
The feature I am working with is for the vehicle speed sensor to either automatically upshift to the next gear or to block a user from downshifting into a lower gear when traveling too fast for the previous gear. This feature can be turned off by the user if they desire to or if they do not have the equipment to run this feature. It is just an added protection that could also double for "lazy" shifting for cruising around town. I have the stock shift map for my vehicle and most is calculated from vehicle speed along with RPM.
sorry my fault. I did'nt had in mind that all is about the speed-sensor. Is tire-burn-out a usual praxis for this kind of vehicle?
Are you already using an extra-speed-sensor or did you connect the propeller to the official tachometer?
Would using a sensor from high-quality bicycle-tachometer which uses a hall sensor an option?
Most users don't do burn-outs since most are all wheel drive. Some do though, which is something I am working on too. I have a "Gear Lock" setup for those who need to burn-out. It simply holds the vehicle in first gear while they do it. I would have to say that 95% of the vehicles this would ever be used in will have the VSS still in tact and working so I would prefer to stick with using the original speedometer.
Hopefully the wife will be home soon so I can begin testing again. I am really interested in trying an RC filter and / or the OpAmp to see if I can get this working.
even if all things speak for noise. At first please do a analysis if there is really noise by using the dso and "zooming in" the signal like described above.
You should decrease the time-base until only the rising part of one pulse can be seen. and then increasing voltage-sensivity until the curve almost fills the screen.
Then you will see most of the details.
As it is a DSO it might be even possible to move 0V down out of the screen increasing the voltage-sensivity again to see just the upper part of the rising edge.
And to decrease the time-base to lower values to see the start of the pulse and then increase a delay when recordning the signal should start to record the middle
and the rightest part of one pulse with a high time-resolution.
My wife just got home and I am about to see if I can get some good screenshots of the signal. I will try what you said to get a bigger picture of each pulse.
Yeah, I have a back road drive that I take to go different speeds for each screen shot. I would let my wife drive, but someone has to stay with the kids My friend who was supposed to help me on the project can never seem to find time to come by and help, so I am stuck doing this on my own I can easily pause the screen, then take a screenshot when it is safe for me to do so. That is what I did on the last few I did.
I would figure a reed switch would have serious "bounce" issues
Yep -- big time.
Maybe I am trying to make this too complex,
Actually, you're hoping the problem is simpler than it is; that said, the solution is not difficult.
Again, the car electrical system is noisy and an RC filter will help clean that up -- it will eliminate spikes that are too short for you to see on your scope but do get counted by the Propeller in edge mode. The Schmitt trigger takes a slow-rising signal and causes it to quickly snap one way or the other (it uses two thresholds instead of one). This is important because you don't want a signal hovering around an io pin threshold and causing false positives.
The RC circuit I showed above has a time constant of 0.1ms -- as long as your high-going pulse is at least 0.3ms or wider, it should be fine.
you will have to bear with me for a bit till i figure out the settings on the O-scope. The instructions are in slightly broken english and most items I have never worked with before. Right now, I am trying to understand the Threshold (THR), Top Limit of visible trigger level (V1), Bottom limit of trigger level (V2), any Horizontal Level of each channel (Y). These are all settings on the right side menu. The instructions don't explain much of what they do other than the short description. Any help on these?
I think I have a few things set incorrectly on mine which I am about to change. He did not have the same firmware as I do, but he explained what each part did. I also have a 555 timer I wired up to mimic the RPM output of my vehicle which I can use as a signal for testing my new O-Scope skills
Here is my first go at reading the 555 tach generator I built. This is a device I use to bench test RPM signal calculations. I think I did a little better with this one
Did anyone try the method I suggested in message 3 where a low frequency is combined with the tach input through an XOR gate.
After the reading is taken the bias frequency is subtracted and resulting in the the true tach frequency.
The advantage here is the counter code will not hang even though the tach input is 0.
Another advantage is it updates the tach readings faster.
I did not try that as the RPM signal is working properly for my project. The frequency that is from the vehicle speed sensor could range from 1 pulse per 500 ms to 400 pulses per 500 ms. I am not advanced enough to setup an additional frequency generator to be calculated into the speed sensor input to the prop.
It's definitely the noise. Got my PASM pulse timing code rewritten so it now deals with the problems that were pointed out by kuroneko (and fixed my 1 msec timer which had the same embarrassing mistake). Just want to make sure the code is totally working before I post it.
What I did find, however, is that the Prop is far more noise sensitive than I had expected. My test program was looking for input on Pin5 and, out of curiousity, I touched Pin5 and got a huge number of pulses in the range of 2-10 microseconds wide. If I were just injecting 60 Hz noise into the pin, I'd expect to be finding pulses at either 60 Hz, or some harmonic of 60 Hz. Guess it's time to look at the Propeller electrical specs again as I'm used to touching TTL circuitry while it's operating without it noticing. Looks like might have to start putting a pulldown resistor on the input pin as well as a low value capacitor (the Prop is behaving more like an analog circuit than a digital one).
I will see about getting some better screen shots of the speed sensor pulses on my way to work tomorrow. If I can clean up the signal with a simple RC filter, that would be awesome!
What I did find, however, is that the Prop is far more noise sensitive than I had expected. My test program was looking for input on Pin5 and, out of curiousity, I touched Pin5 and got a huge number of pulses in the range of 2-10 microseconds wide. If I were just injecting 60 Hz noise into the pin, I'd expect to be finding pulses at either 60 Hz, or some harmonic of 60 Hz.
.. but touching a pin, is not "just injecting 60 Hz noise" - it is injecting a broad spectrum with a skew to the higher frequencies.
The Prop pins are tuned to allow Quasi-Sigma-Delta ADC operation, where they operate at the Pin threshold.
That means no hysteresis, and so a few mV swing is enough to fire H-L-H-L-H-L signal sense.
External Hysteresis is certainly a good idea, as is a RC filter (mentioned above) to limit the highest count rate, and this buys some RF immunity.
Some designs use something like a H11L1 (Digital Optocoupler), which gives both optical isolation and Schmitt action.
I have looked at getting the NC7SZ14M5X TinyLogic component JonnyMac was talking about. The only problem I have at the moment is if this is the correct chip for my application. I would like to go surface mount as it uses much less room, and it appears to handle the voltage range of what I am working with. Is there anywhere I could get a sample of this chip, or do I have to order a reel of them to test it out?
If you have a pin and a cog left over on the Prop, then with a couple of resistors and a very short software loop, you can create a software Schmidt effect.
Comments
Tim do I understand right that you changed the voltage-divider from
rpm-signal
>----10kOhm
x
>
Prop-IO-Pin
at "x" there is a resistor 100 kOhm connected down to Ground
and changed it to
rpm-signal
>----10kOhm
x
>
Prop-IO-Pin
at "x" there is a resistor 10 kOhm connected down to Ground
Is this correct?
The 10kOhm-resistor between rpm-signal and Prop-IO-pin limits the current
into the prop-IO-Pin down to
1V / 10000 Ohm = 0,1mA = 100 µA. The voltage reaching the Prop-IO-pin is still 5V.
So an "over"-voltage of 5V-4V = 1V must be "driven away" through the internal clamping-diodes inside the propeller-chip.
They can stand a current of 500 µA. So this is a working circuit.
Me personally I would prefer a voltage-divider like this:
rpm-signal
>
12 kOhm
X
20 kOhm
ground
At "x" the prop-IO-pin is connected directly or maybe through a 150 Ohms resistor
In this circuit the maximum voltage going into the prop-io-pin is
5V / 32 kOhm) * 20 kOhm = 3,125V which is surely detected as "HIGH" but inside the limit of 3.3V.
Now the jumping value come from noise on the rpm-signal.
In the rsing phase of the signal the voltage jumps - for a short time - around 1.65V.
1.6 up to 1.7 down to 1.59 up to 1.75 down to 1.61 etc.
so the counter is detecting multiple lows and highs through the noise before the signal becomes stable at 4.5V.
And this noise is causing the jumping values.
Now this noise can be filtered out in two ways:
using an rc-filter. (I don't have a circuit and values handy)
or by using a schmitt-trigger like JonnyMac suggested.
The chip JonnyMac suggest suits very good because it is 5V tolerant at the input
even if you supply it only with 3.3V to stay within the rated limits of the propeller-chip
This schmitt-trigger filters out the noise because
- let's start at a signal-voltage-level of 0V
supplied with 3V the output stays low until the voltage raises over 1,75V. Then the output switches to HIGH
and the output WILL stay high until the input-voltages stays over 1,00V.
This means as long as the noise in your signal is smaller than (1,75V - 1,00V = 0,75V) the propeller-chip "sees" only ONE
pulse even if the noise would make your signal jumping up and down a thousand times between 1,1V and 1,7V)
Now as you have bought a 4-channel digital storage-oscilloscope (DSO) you are well equipped to analyse your rpm-signal
and any kind of filter-circuit to get proper readings from the propeller-chip.
Tim If you have any questions please post them here or send me a PM for more assistance and supporting.
friendly greetings, kind regards
Stefan
the 741 is a very classical OPAmp.
I prefer LM358 because the LM358 has internal offset-compensation and a much higher input-impedance.
I have no practical experience with the 741. But as it is an OpAmp it should work.
The behaviour of an OpAmp depends on the external ciruitry around the OPAmp. Schmitt-trigger is one of these behaviours.
Here is a schematic using the 741 as a schmitt-trigger.
http://talkingelectronics.com/projects/OP-AMP/OP-AMP-2.html
Scroll down the page until you find schmitt-trigger. There is also a some explanation
The other filter-circuit is to use an rc-low-pass. The noise has a high frequency and the low-pass-filter will "let through" only low frequencies.
In real high frequencies are "lowered down". For using this we need to know what is the maximum frequency that the rpm-signal comes in with.
As you have a DSO know you can test the circuit excellently. If you connect one probe to the rpm-signal directly and the second probe to the output of the
OP-Amp. This is nescessary for testing as the 741 the maximum-output voltage is lower than 5V. The datasheet says at supply-voltage +-20V maximum output-voltage
is 16V. (voltage-drop) You have to check with your DSO if the output-voltage is still above 1.7V so the propeller-chip can surely detect a HIGH-signal.
More modern OPAmps like LM324 or LM358 have a lower voltage-drop (around 1.5V) and there are also rail-to-rail OPAmps with almost no voltage-drop at all.
(rail-to-rail = Output-voltage can swing from Ground-rail to supply-rail)
best regards
Stefan
As has been pointed out, the electrical environment of an automobile is VERY noisy. A simple RC circuit can help filter that noise, the Schmitt trigger after than provides a clean transition into the Propeller. The simple circuit suggested and I've attached may just be the ticket to keeping your code very simple. I used the TinyLogic Schmitt in the circuit but that's easily replaced by the more readily-available opamp circuit Stephan suggested.
The sensor that is feeding the PROP is referred to as a Reed Switch in the manual. I have not taken my dash out to look at it, but I would figure a reed switch would have serious "bounce" issues at higher speeds. It may be a reed switch or it could be a hall-effect sensor as well. Too much work to pull the dash to find out....
After reading over the OpAmp schmitt circuit, I noticed it is using a 5V source and expecting around a 3.3V input. Would a 3.3V source input work? I could use the voltage divider I already am using to convert the VSS input to ~2V which would make the new threshold voltage ~1V correct?
EDIT: the value of the lower and upper threshold-voltage depends on the values of the resistors.
On this website you can let calculate the resistor-values for any threshold-voltages you like
http://sim.okawa-denshi.jp/en/rercal.php
If I understood right you are using some kind of voltage-divider but with not optimised values or not optimised connection to the prop.
Can you please make a hand-drawn schematic how you have the rpm-sensor connected to the prop and upload the picture to a posting?
The bouncing or other kind of noise causes the rpm-signal to go up and down several times below and above the threshold-voltages of 1.65V.
The internal circuitry of the propeller-switch is very fast. You can feed in a 1MHz-pulsetrain and the counter will still count every single pulse.
So as long as the rpm-signal goes up and down below and above the threshold-voltage of 1.65V even if it is only for micro-seconds the counter will count too much pulses.
Now you could try using software-debouncing. For this you have to analyse what is the shortest period the pulses can have. The software-debouncing will only work as long as the noise
is not overlapping the time-window of the debouncing-algorithm. If your device is used in other vehicles there will be other kind of noise. So noise-reduction and noise-filtering is the better way.
Do these vehicles have a EMU anyway? (electronic motor control unit) most of them provide a rpm-signal.
If these vehicles are custom-made anyway I hink it would be a good investment in reliability to mount a magnet and a hall-sensor somewhere in the motor.
best regards
Stefan
The feature I am working with is for the vehicle speed sensor to either automatically upshift to the next gear or to block a user from downshifting into a lower gear when traveling too fast for the previous gear. This feature can be turned off by the user if they desire to or if they do not have the equipment to run this feature. It is just an added protection that could also double for "lazy" shifting for cruising around town. I have the stock shift map for my vehicle and most is calculated from vehicle speed along with RPM.
sorry my fault. I did'nt had in mind that all is about the speed-sensor. Is tire-burn-out a usual praxis for this kind of vehicle?
Are you already using an extra-speed-sensor or did you connect the propeller to the official tachometer?
Would using a sensor from high-quality bicycle-tachometer which uses a hall sensor an option?
best regards
Stefan
Hopefully the wife will be home soon so I can begin testing again. I am really interested in trying an RC filter and / or the OpAmp to see if I can get this working.
even if all things speak for noise. At first please do a analysis if there is really noise by using the dso and "zooming in" the signal like described above.
You should decrease the time-base until only the rising part of one pulse can be seen. and then increasing voltage-sensivity until the curve almost fills the screen.
Then you will see most of the details.
As it is a DSO it might be even possible to move 0V down out of the screen increasing the voltage-sensivity again to see just the upper part of the rising edge.
And to decrease the time-base to lower values to see the start of the pulse and then increase a delay when recordning the signal should start to record the middle
and the rightest part of one pulse with a high time-resolution.
best regards
Stefan
do I understand right that you have to drive to get the screen-shots?
So I recomend driving with an assistant you drive and the assistant is O-scoping or vice versa. don't scope and drive!
best regards
Stefan
Yep -- big time.
Actually, you're hoping the problem is simpler than it is; that said, the solution is not difficult.
Again, the car electrical system is noisy and an RC filter will help clean that up -- it will eliminate spikes that are too short for you to see on your scope but do get counted by the Propeller in edge mode. The Schmitt trigger takes a slow-rising signal and causes it to quickly snap one way or the other (it uses two thresholds instead of one). This is important because you don't want a signal hovering around an io pin threshold and causing false positives.
The RC circuit I showed above has a time constant of 0.1ms -- as long as your high-going pulse is at least 0.3ms or wider, it should be fine.
http://eeshop.unl.edu/pdf/OscilloscopeTutorial--Beginner.pdf
http://www.williamson-labs.com/scope-main.htm
http://www.hobbyprojects.com/oscilloscope_tutorial.html
http://www.youtube.com/watch?v=G1_YS1yyYiI
I think I have a few things set incorrectly on mine which I am about to change. He did not have the same firmware as I do, but he explained what each part did. I also have a 555 timer I wired up to mimic the RPM output of my vehicle which I can use as a signal for testing my new O-Scope skills
After the reading is taken the bias frequency is subtracted and resulting in the the true tach frequency.
The advantage here is the counter code will not hang even though the tach input is 0.
Another advantage is it updates the tach readings faster.
Duane J
Duane J
What I did find, however, is that the Prop is far more noise sensitive than I had expected. My test program was looking for input on Pin5 and, out of curiousity, I touched Pin5 and got a huge number of pulses in the range of 2-10 microseconds wide. If I were just injecting 60 Hz noise into the pin, I'd expect to be finding pulses at either 60 Hz, or some harmonic of 60 Hz. Guess it's time to look at the Propeller electrical specs again as I'm used to touching TTL circuitry while it's operating without it noticing. Looks like might have to start putting a pulldown resistor on the input pin as well as a low value capacitor (the Prop is behaving more like an analog circuit than a digital one).
.. but touching a pin, is not "just injecting 60 Hz noise" - it is injecting a broad spectrum with a skew to the higher frequencies.
The Prop pins are tuned to allow Quasi-Sigma-Delta ADC operation, where they operate at the Pin threshold.
That means no hysteresis, and so a few mV swing is enough to fire H-L-H-L-H-L signal sense.
External Hysteresis is certainly a good idea, as is a RC filter (mentioned above) to limit the highest count rate, and this buys some RF immunity.
Some designs use something like a H11L1 (Digital Optocoupler), which gives both optical isolation and Schmitt action.
You will need some hystersis as well; if you already know and use the '555, then you can use one of those as a Schmitt-like buffer.
See
http://www.555-timer-circuits.com/schmitt-trigger.html
use a CMOS 555 for lower supplies.
Cheers,
Peter (pjv)