Well, I have been using COUNT 300 as an alternative which appears to be 100% accurate to the RPM code Bean had posted but much slower. Bean's code used up way too much space so I had to find an alternative. By adding 10 to the 300, it makes the displayed RPM match the Tach.
Ok, so lets see if I have this right....
There appears to be 2 pulses per rpm since using COUNT 300 instead of 600 is accurate.
I am trying to use Bytes as the variable returned from the PULSIN statements to preserve space so I am not sure how accurate it will be in a wide range of RPM's.
PULSIN high and PULSIN low @ 30 microseconds added together and then divided into 100 and would give me a pretty accurate RPM? It is dark outside so I cannot test anything right now [noparse]:([/noparse]
You really should put a 'scope on your tach signal to see what it looks like at idle and near red-line RPMs -- knowing that will allow you to design the code appropriately.
Comments
Ok, so lets see if I have this right....
There appears to be 2 pulses per rpm since using COUNT 300 instead of 600 is accurate.
I am trying to use Bytes as the variable returned from the PULSIN statements to preserve space so I am not sure how accurate it will be in a wide range of RPM's.
PULSIN high and PULSIN low @ 30 microseconds added together and then divided into 100 and would give me a pretty accurate RPM? It is dark outside so I cannot test anything right now [noparse]:([/noparse]