Examples for a RPM monitor
Crosswinds
Posts: 182
Hello!
For some reason i dont get any results when searching the forum for "rpm". There must be tons of threads out there
Anyway, im currently working on a hobby Project that i will need to monitor RPM using IR transistor.
Im looking for some codingexample on where to start?
Any inputs?
For some reason i dont get any results when searching the forum for "rpm". There must be tons of threads out there
Anyway, im currently working on a hobby Project that i will need to monitor RPM using IR transistor.
Im looking for some codingexample on where to start?
Any inputs?
Comments
This is what I did to find one of my old threads.
Jim
https://dl.dropboxusercontent.com/u/7676084/ForumSearch.html
Thanks Leon. I though I had that bookmarked, but I guess I lost it. It's a very valuable link.
Thanks guys for your replies..
I do remember that the search function worked better a couple of years ago?
Peter your example looks very good for what i need i think..
Im having some problem with the PASM though, but i may not need to alter it to much. My knowledge of assembly is very limited.
Am i right if i say that to get the RPM i need the PASM routine, in combination with this routine from the spin code:
rpm := rpmcon/(sample/5)
Im i right? Seems a bit to simple though
Different encoder types present different problems.
If there are lots of encoder transitions to count you can just count them over a set period. If there aren't many encoder transitions then you may be better off computing the speed based on the time between transitions.
Actually the device is spinning quite fast, above the minimum suggested in the assembly comments.
The sensor is a IR(?) transmitter and receiver that sense the reflections from the spinnig device.
So it pulls the prop´s pin high every revolution.
Hope that claryfies a bit!
I wouldn't think you would need to alter it at all, why? This is not rocket science, it just measures the time between edges so it doesn't matter if the pulse goes high or low, it is measuring cycle time. The PASM is the heart of it but what it does is very simple, it just has to be in real-time whereas Spin does all the high level calculations, scaling, and display etc. But that is fairly typical of most Propeller apps, let a cog run PASM for the real-time, let Spin do what it does best. The type of sensor is totally immaterial as all the PASM cog needs to see is this pulse train from it.
The synth object is fairly basic, it just sets up a counter in frequency mode so it can be used to test the unit. If you set it up for 100Hz then it should report 100 * 60 = 6000 RPM. By default all the scaling factors are just set to one but if you were picking pulses off some gear then you need to scale it which is why we have a multiplier/divider instead of a floating point operation and a variable to set the number of sensors which is usually one.
Really you should just be hooking this all up and testing it to find out more about how it works. If you somehow get stuck after trying to do what you want to do then that is what the forum is for, although it's a dry bar
As is often the case, there's more than one way to solve this problem.
Here's a link to some code I wrote to count pulses. It uses a Spin loop using counters and a PASM loop which polls the input pin. It didn't occur to me at the time to use a waitpxx command.
If I were to pick one technique as "best" in this particular application, I'd go with Peter's waitpeq/waitpne strategy.
These strategies (code) would need to be altered if you wanted to monitor multiple motors.
Thank you Peter for your help..
I did hook everything up and got the sensor working.
I did a fast "boildown" on your code just so i can get to the bare minimum, and better understand what goes in to the rpm calculation..
(Its not pretty though
I did get some result, but they are way of. Ive attached the code just so you can see..
This is a snapshot of the terminaloutput:
284613
60000000
287597
287769
219931
53333333
179640
181440
179977
179506
This is with constant voltage to the little motor. and it does not spin anywere near 179506 haha!
Again, sorry for the sloppy work i made of your code, but as i stated, needed to boil it down to understand what is going on..
BTW, could this be that the signal is not "Clean" enough? If i make a simple counter for the pin, and measure it over one minute, the result is about 810rpm, and that seems about right..
Thank you
The calculations are correct as you can work that out manually that 810 RPM = 13.5Hz which should result in an interval count of 80,000,000/13.5 = 5925926
So rpmcom = 12 *80,000,000 and rpmcon/(5925926/5) = 810. If it doesn't report 810 then your interval count is much higher, perhaps due to threshold jitter and noise.
Therefore the haha should be that you confirm you have a clean signal and even if you don't have a scope, all you need is in front of you. First off you could just output the state of the input pin continually on the terminal as a * or . for high and low and if you are doing this constantly then you have a good view of what the pin is seeing. If the input is clean at 810rpm then assuming your terminal wraps are at 80 columns then you should have around 11 lines of a low and high before it repeats (assuming full terminal throughput).
The other thing is to print out not just the rpm calculation but also the raw interval count itself and don't wait one second between updates, like No. 5 you need more input. There is nothing stopping you from doing any of these things and more, surely you would want to know what it's doing?
And thank you.
I have it somewhat functional now, with some temporary code fixes. Just so i can get on with the project!
The Signal is not very clean we have noticed, it is affected by flourescent lights for example. However 9 out of 10 readings is accurate, and when its not accurate, the reading is of by over 100.000rpms.
So what ive done is to discard all readings above 10.000 and then it play nice. That however is not a very nice fix. And the IR transistor needs some help with cleaning the signal.
What ive noticed is that when it get a real positive signal it outputs 3.3. And if something else disturbs it, it can float around 1.5v up to maybe 2..
Is there maybe someway around this with a circuit of some sort?
Are you saying that you are using a phototransistor rather than a photointerrupter? The latter is designed with a narrow slit and close proximity to the IR LED both of which help filter out incident light (your 2V reading) that would interfere with the signal. Also they can have an IR filter over the transistor too. If you are just using a phototransistor then you will need to effect something similar but a photointerrupter is easier. Then again a hall effect works well too if you can place a tiny magnet somewhere.
btw, because there is so much IR interference around that is why IR remotes must use a modulated carrier so they can filter out all the "DC" and low frequency stuff etc. So it is possible to use one of these sensors too but why bother?
One of these: https://www.spektrumrc.com/Products/Default.aspx?ProdID=SPM1452
One that emitts the IR on to a reflector, and when it bounce back the other one "opens" up..
Iam actually thinking of getting one of these: http://www.eagletreesystems.com/index.php?route=product/product&path=63_71&product_id=69
Do they generate a voltage depending on how fast it goes, or does it just "open" up on the magnetic passing by?
It is quite simple though.
It grounds the signalwire when the IR beam reflects back on the sensor.
Oh okey, so the hall-effect sensor seems quite simple then.. Will try the IR sensor at the application and see how it works out.Seems to work pretty well when mounted correctly..
There are several terms but probably the closest would be "IR Reflective Sensor"
Also found a reference where they were called "Reflex optics" but when Googled a vast majority of the hits involved rifle sights.
Hard to tell. The manufacturer does not have Data Sheets that I can find, but it looks likes retro reflective.
It would help with the actual application you are trying to use this in. Better solutions might be avaiable.