Help caculating RPM using a PICAXE-8M

[newelltech]

picaxe rpm code

Here's what I think is going on. Sorry for cheesy table, lost patience with trying to get HTML turned off.

Line______PulseIn___Pulse_____Expected__My Code__32 Bit____Corrected
_________Polarity___Width_____Reading____________Bit Code__32 Bit Code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Tach______0________14________RPM/2____RPM/2____RPM______RPM/2
Tach______1_________0.7______RPMx10___RPMx2____RPM______RPM/2
PIP_______0_________7________RPM______RPM______RPMx2____RPM
PIP_______1_________7________RPM______RPM______RPMx2____RPM


1. The Tach line has a narrow pulse. When the polarity is 1 we're measuring it and in the pics it is about 0.7 msec. This will give us a very low count and cause register overflow with unpredictable results. Mathematically it should read 20,000 RPM. Neither code version checks for this. I tried to add a branch but it never got called. So the first step is to check the count for too low a reading and peg the RPM at some number.

2. I don't have time to review the 32-bit code but believe there is a factor of 2 error. If we reduce the reading by 1/2 (see last col) it produces the correct results (except for tach 1 of course)

3. With the 32 bit code corrected, both code versions give the same results. The suspicious thing is that they both produce RPMx2 with Tach 1. So either they have the same overflow consequence or something else is going on. Regardless, the code should never allow the condition and I wouldn't worry about it.

Regards,
Dennis

 

[rexlan]

how to pic picaxe input counter

Here's what I think is going on. Sorry for cheesy table, lost patience with trying to get HTML turned off.

Line______PulseIn___Pulse_____Expected__My Code__32 Bit____Corrected
_________Polarity___Width_____Reading____________Bit Code__32 Bit Code
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
Tach______0________14________RPM/2____RPM/2____RPM______RPM/2
Tach______1_________0.7______RPMx10___RPMx2____RPM______RPM/2
PIP_______0_________7________RPM______RPM______RPMx2____RPM
PIP_______1_________7________RPM______RPM______RPMx2____RPM


1. The Tach line has a narrow pulse. When the polarity is 1 we're measuring it and in the pics it is about 0.7 msec. This will give us a very low count and cause register overflow with unpredictable results. Mathematically it should read 20,000 RPM. Neither code version checks for this. I tried to add a branch but it never got called. So the first step is to check the count for too low a reading and peg the RPM at some number.

2. I don't have time to review the 32-bit code but believe there is a factor of 2 error. If we reduce the reading by 1/2 (see last col) it produces the correct results (except for tach 1 of course)

3. With the 32 bit code corrected, both code versions give the same results. The suspicious thing is that they both produce RPMx2 with Tach 1. So either they have the same overflow consequence or something else is going on. Regardless, the code should never allow the condition and I wouldn't worry about it.

Regards,
Dennis

Dennis I think you are correct on all fronts here. I got hold of tech in UK today and now I think I know what is going on.

This PULSIN command looks at a change of state from 0-1 or 1-0 and that is the time measurement. The manual is pretty misleading on this as I thought it was the time from two rising or falling edges, not the case.

So this accounts for the discrepancy. I think your code is perfect.

Hippy suggested using a divide-by-2 flip-flop as the input so it will give a pulse on every rising edge. I think this is the only way to do this now.

I will appreciate your schematic for this as I haven't a clue now! Will also be nice if we can just directly input the 12v source signal.

Thanks Dennis,
Rex

 

[newelltech]

hippy picaxe lcd code

Noooooo!!!!! Don't put in a divide-by-2!!!!!!!!!!
It just degrades the system and adds more parts.
Fix the math - it should be easy!!!!!!!!
All my calcs were done assuming the pulse width (not period) was measured, but I remember reading the description several times before I came to a conclusion.
It's clean, don't hack it now.

 

[rexlan]

picaxe event counter

Noooooo!!!!! Don't put in a divide-by-2!!!!!!!!!!
It just degrades the system and adds more parts.
Fix the math - it should be easy!!!!!!!!
All my calcs were done assuming the pulse width (not period) was measured, but I remember reading the description several times before I came to a conclusion.
It's clean, don't h(at)ck it now.

Humm ..... Your math is spot on perfect so nothing to fix there. The 32 bit math is very, very close also but it DOES NOT WORK unless I divide by 2 because of this PIP signal. Easy to fix for this one car type but not too good otherwise.

Here is the problem though. I also have a T1 Corvette and another car I race and I want to have this (when it is all said and done) for all of them. They do not have this PIP line. They too are electronic but will likely have a similar signal to the Tach_Out line like the SRF does.

So what we need to do is make one unit that can work on 4-6-8 cylinders and trigger the pulse on the leading edge of the signal.

Next is to add these features: You are in charge of design, hardware and code We will use the 18X version. I am still trying to find a suitable display but no luck so far.

1. Speed
2. Oil pressure/temp (maybe just flash lights at X value?)
2. Water temp
3. Shift light at X RPM