math after using pulsin

ellizard

HI everybody

I'm trying to do a rev counter, and i used the count command on the exit of a IR sensor, but i am facing the lack of accuracy that this sistem involves, i tried any number of segments up to 16, and it's still poor in accuracy.
I would investigate the use of the command Pulsin, but my mathemathics is not so strong, so here the question:

in my project the Pulsin command give me back a number that is varying from 32609 to 4167 units of 2 usec.
How can I achieve the formula revs min = 1/(pulsinresult * 2 * 0,000002usec)
i need to multiply for 2 because the pulsin only get the duration of half turn of the crankwheel, and also i'm very poor in pbasic mathemathics involving numbers with many decimals.

i read some of the·Tracy Allen·docs, at EMESYS site but could'nt take out the spider from the hole,

thanks for the aid
Stefano·

Post Edited (ellizard) : 6/5/2005 6:10:47 PM GMT

Newzed

You say you get a pulsin variable of 32719.

32719 x 2 = 65438 microseconds = 65438/1000 = 65 ms'

If I understand you correctly the pulse occurs twice for every rev, so
65/2 = 32·ms per rev.· Then 1000/32 = 31 revs per second or 60*31
= 1860 revs per minute.· Remember, the Stamp can not handle decimals so you will note that I dropped the decimal in each case above.

Does this help?



▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Need a bezel for your LCD?

Newzed@aol.com
·

ellizard

HI Newzed

Tanks for replay,

I got the pulsin to measure half of the diameter of the crankwheel so the time of the duration measured by pulsin is half of the time for one revolution,

the numbers are

32609 units of 2 usecs for 460 revs/min and on the high end 4167 units for 3600 revs/min

But the real problem is this: You· Say:

32609*2=65218 msecs, 65218/1000=65 msecs, 65*2=130 msecs the real duration of one entire revolution, 1000/130=7, 7*60=420 i.e. 10% less

but at a faster revs, let say 3600 revs per minute, with your method gives me a result of·:

4167*2=8334, 8334/1000=8, 8*2=16, 1000/16=62, 62*60=3720 i.e. 3% more

with these tolerances it is far more better a mechanical revs counter, i was supposed that using micros i could achieve a tolerance of about 1% or less, I'm I wrong?

Anyway i'll deep more into the long division word, because it is true that Basic Stamp cannot work decimals, but it is true also that neither computer can basically do that,·even the most up to date supercomputer at NASA.

thanks for the help you get me (i didn't think of making the calculation this way, my way was far more complicated than yours)

regards

Stefano

Tracy Allen

Ahh, a nice math problem! Here is one way to do this:

' reciprocal calculation
' explanation at http://www.emesystems.com/BS2math2.htm#Shortcut3
 wx VAR Word  ' result from PULSIN, works for wx=256 to wx=65535
 wy VAR Word   ' calculate 5000000/wx, effectively 10000000 / (2*wx)
 nj VAR Nib
 
 wx = 4167   ' this is the result from PULSIN 
 GOSUB reciprocal   ' prints 1199  1/(2*4167)=0.00011999
 wx = 32609
 GOSUB reciprocal   ' print 153    1/(2*32609) = 0.000015333
 END

reciprocal:
  nj = NCD wx - 8
  wy = 65535 / wx << 8 + (65535 // wx + 1  << (8 - nj) + (wx >> nj))
  wy = wy ** 50000 */ 100   ' effectively 5000000/wx
  DEBUG DEC wx, " per second", CR 
  RETURN

Now you further said that that a reading of wx=4167 corresponds to 3600 rpm, and wx=32609 is 460 rpm. Observe...
4167 * 3600 = 15001200
and
32607 * 460 = 15000140.
That is no accident, the formula to convert the PULSIN reading directly to RPM would be...
rpm = 15000900 / wx
I used an average value for the constant in the numerator. The slight difference in the constant is a non-linearity that probably has to do with the response time of your photodetector.


So, if you want the answer come out directly in rpm, change the final step in the reciprocal subroutine, to this...
wy = wy ** 50003 */ 300
There is no need to calculate the reciprocal per se when you can go directly from the PULSIN value to rpm.

I think that wil work. Let me know if not. (note that 50003 * 300 = 15000900).

There is explanation of this method on my web site at,
www.emesystems.com/BS2math2.htm#Shortcut3

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

ellizard

HI Tracy

Glad to receive an answer by you, it is a couple of year that i currently visit your site, i tried to solve by myself, but this kind of math is too high for me, i read of your method but there are two factors that limit my understanding, first of all my poor knoledge of high math, i can just a little more than the four basic operations and also the scientific english language is sometimes (quite often) tooo hard to me
anyway, i'll let you know the results of my (your) work

tanks
Stefano

P.S. wich method do you think it is better for counting revs, the count or the pulsin approach?

Post Edited (ellizard) : 6/5/2005 6:23:22 PM GMT

ellizard

HI Tracy,
Sorry to disturb you again, but ...... may be there is a mistyping of the code you write, because on the debug screen your subroutine gives me the following answer:

4167 per second
32609 per second

there are the values from wich i started!!!!!!!!
please let me know

Tracy Allen

Oh, sorry about that. In the DEBUG statement, it should be wy, not wx. That is, the result of the computation, not the starting value.

You asked which would be better, COUNT or PULSIN.

I think you already found out that you have to COUNT for a long time in order to get good resolution. With only one pulse per revolution, you have to COUNT for one whole minute to get to 3600 on a BS2. The more segments you have around the wheel the better. With 100 segments per revolution, then you only have to COUNT for 0.6 second to get to 3600.

PULSIN is nice, because you are getting your reading in about 0.06 second or less. The disadvantage of that is, maybe, the result would not be so stable from time to time or as the components age or shift around or vibrate. But it might be good enough.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

ellizard

I got the lesson now i have to work for putting all this together in a real program
tank for all the time you deserved to me
Stefano

Tracy Allen

Stefano,

prego.

I loaded the program into a Stamp and tried it, and made a bug fix and a couple of changes. This is direct cut and paste, so I know it works...

' reciprocal calculation
' explanation at http://www.emesystems.com/BS2math2.htm#Shortcut3
 wx VAR WORD  ' result from PULSIN, works for wx=256 to wx=65535
 wy VAR WORD   ' calculate 5000000/wx, effectively 10000000 / (2*wx)
' also example of rpm calculation
 nj VAR NIB
 
  wx = 4167   ' this is the result from PULSIN 
  GOSUB reciprocal
  DEBUG DEC wx, TAB, DEC wy, " /sec", TAB ' 1/(2*4167)=0.00011999
  GOSUB rpm
  DEBUG DEC wy, " rpm",CR
 
  wx = 32609  ' the slow end of the range
  GOSUB reciprocal
  DEBUG DEC wx, TAB, DEC wy, " /sec", TAB    '1/(2*32609) = 0.000015333
  GOSUB rpm
  DEBUG DEC wy, " rpm",CR
 END

reciprocal:
  nj = NCD wx - 8
  wy = 65535 / wx << 8 + (65535 // wx + 1  << (8 - nj) / (wx >> nj))
  wy = wy ** 50000 */ 100   ' effectively 5000000/wx
  RETURN


rpm:    ' direct to rpm calculation, empirical
  nj = NCD wx - 8
  wy = 65535 / wx << 8 + (65535 // wx + 1  << (8 - nj) / (wx >> nj))
  wy = wy ** 50003 */3001 +5/10 ' with rounding for empirical accuracy.
  RETURN

The bug was a "+" where there should have been a "/". Big difference!

This has one subroutine for reciprocal, and one for going directly from the PULSIN result to rpm, based on your empirical result. In the rpm routine, I put in an extra significant figure and then rounded off, to have the result come out at exactly 3600 rpm and 460 rpm at the ends of the range of PULSIN values, per your observation. Note that the reciprocal and the rpm routines are identical, except for the constants with ** and */.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Newzed

I have been thinking about this rev counter problem, and I would like to present the following approach for consideration.· Tracy, correct me if I'm wrong.

Let's assume you have a 3" wheel.· You drill a .125 hole EXACTLY 1" from the center.· This puts the hole on the rim a a 2" circle.· The circumference of a 2" diamter wheel is 6.28 inches.· The .125 represents 6.28/.125 = one 50.24th of the wheel diameter.· Now let's assume you have a detector - IR, photo resistor, etc.· At a certain speed you detect a pulse width of .001 - 1 ms.· The wheel must traverse 6.28-.125 = 6.155 inches before it detects another pulse.· This is equivalent to 49.24ms.· Remember, there are 50.24
.125 spaces in the circumference, which leaves 49.24 spaces.· If you get a pulse every 49.24ms, this is equivalent to 1000/49.24 =· 20.308 revs per second or 60*20.308 = 1218.52 revs per minute.·

Make sense?· The point is, at speed X, the further from the center of the wheel your aperture is, the shorter the duration of your pulse.· So....., you have to know exactly where your aperture is and its relationship to the total diameter at that point.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Sid Weaver
Need a bezel for your LCD?

Newzed@aol.com
·

Tracy Allen

Hi Sid,

You're right about the observation that the pulse width will depend on the distance from the center. It will also depend on things like vibration, aging, the optics, etc. And maybe in your example, the shape of the hole, circular versus solid arc for example. The calibration will have to be somewhat empirical to get the best accuracy.

As to the math, you had a 2" diameter circle, 6.2832 circumferance. There are three ways you could measure pulse width, and I think you are focussing on #1 and 2...
1 -- the time the the light shines through the hole, one millisecond in your example. That time will be very sensitive to the shape of the hole, alignment of the optics, vibration, etc.
2 -- the time the light does not shine through the hole. The distance travelled is 6.2832 - 0.125 = 6.1582 inches (if we can be that exact!), and the time is 6.1582 / 0.125 = 49.2655 millisecond. Note that the sum of #1 and #2 is 50.2655 millisecond. The rps is 1/0.0502655, not 1/0.0492655.
3 -- the time it takes from one leading edge light pulse to the next. Imagine that the light pulse toggles a flip flop that is high for one rev and low for the next. If this signal (from the toggle flip flop) is one second high, and one second low, that means that the wheel is rotating at one rps. Or in your example, if that signal is 50.2655 ms high and 50.2655 milliseconds low, then the rps is 1/0.0502655 = 19.89 rps = 1194 rpm.

Observe that while #1 and #2 depend on the diameter where the hole is drilled and the drill size, #3 does not. #3 works at any diameter (because one revolution is one revolution), and at any hole size (because it keys in on the rising edge of the signal). Does that make sense? #3 time is the sum of #1 + #2.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

Newzed

I never thought about using a flip-flop, Tracy.· That would be the way to go since the hysterisis is practically zero.· All you have to do is measure the duration of the HIGH - or of the LOW - and you've got one rev.· Neat!

Sid

ellizard

HI Tracy and Newzed,

I'm happy to have raised a very deep debate for the best technik to solve a so not obvious problem,

for what relates to the sensor i used, it consist of a " Parallax Qti" ·infrared sensor that as to be mounted over a large flywheel of the diesel engine of a boat (36 cm diam a little more than 14 inches), beeing made of hard iron, obviously i cannot drill a hole trough it, and there are also balancing considerations to take in account that suggests not to attach anything to it.

So I experimented various sets of black painted sectors over the circumference, till 64, to be used with the command count, the result was jittering, because due to several causes it happened that some of the black sectors where not decoded, giving an unpleasant walzer of figures on the display though the fly wheel is running at a very stable ritm, so i thinked of using only one sector with an amplitude of exactly half of the circumference, to be used with the pulsin·command, this would certainly lead to less jitterish reading of the angular speed of the flywheel, and here we are,

Specifically to Tracy, you beated me by hours, yesterday i tryed your subroutine and could not resemble sense with the figures it gave me in response.

anyway i'll let you know the results of my work.
A bit more information of the whole of the project: it should be an RPM counter that when the control panel is switched on but the engine is not yet running, should display the hours that engine has runned, this is achieved with the aid of a DS1603 (time elapsed counter from Maxim-Dallas), in the future i'm planning to use one i-button identification real time counter as key (i.e. not allowing to start the engine and also to keep trace of the hours elapsed).

When it will be finished i'll post it in the project forum
for this time my "Divine Comedy" is at a pause.

warmest regards
Stefano

Newzed

Tracy, just for fun I thought I'd build up a rev counter using a flip flop.· However, I'm a bit rusty on flip flops.· So.................

I was looking at a 74HC73 JK flip flop:

If I tie the J input high, then apply a series of pulses to CP the Q output of J would toggle on the negative-going edge of the pulse.· I would look for a High, then a LOW on Q

or

If I tie both J and K high, then the Q outputs of each latch would toggle.· Then I could look for a HIGH on first one Q output, then look for a high on the other Q.

Am I even close?

Sid

Tracy Allen

It's been a while since I've had to think about flip flop logic! Tie both J and K high, and both Q and Q\ will toggle with each active clock edge. With a D flip flop, you make it toggle by tying Q\ back around to the D input. Or just get a counter chip and use the /2 output. On any of these things, be sure the clock edge is clean, or else it will toggle erratically.

With the Stamp, you can measure the high time using one PULSIN, and then the low time using another PULSIN. Then add them up to get the total time for one period. The two times are measured in different cycles, and it is important to have good transitions,. But that can eliminate having to use an external part or or having to fuss with calibration when the proportion of the cycle high or low is not well fixed.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Tracy Allen
www.emesystems.com

ellizard

HI everybody interested on this thread

All of the program is working fine, i'm adding the last small tricks for refining the display ease of readability,

and other minor functions,

Tank to you all

i'll post soon ....(bread first) the project.

Stefano

ellizard

HI Tracy

I'm back on this tread to discuss the behaviour of the time elapsed-RPM counter i designed and programmed, after near a month of observation, i noticed a strange or not wanted effect on the display of the numbers when in RPM mode:

if the figure is below 1000 then any 10-20 seconds there is a flash in the last digit (the thousands one) of the number 5 displayed instead of a blanck, this does not happen when the figure is 1000 or more:

Doubts:

it could be the 7219 not operated correctly, I know i'm·very very far from beying·the smart programmer, or a somewhat interval that the continuos PULSEIN command needs to take to accomplish hidden task?

I acclude the program, thinking you could be interested in knowing reported·behaviours of the Stamp.

Warmest Regards

Stefano




Post Edited (ellizard) : 7/2/2005 5:03:44 PM GMT