 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Tachometer Code..?
| Author | Message | ||||
Zonker Guru  Joined: 18/08/2012 Location: United StatesPosts: 767 |
I was tring my luck at creating a decient tach display and was not sure the best way to do it. I currently already have a 1/10 second timer routine going to collect data from temp IC's. the routine takes 10 samples per channel and stores the data in an array. after 10 samples, we average the results and check if the new data is different from the "old" reading. If so, it signals the main loop to update the guage objects. Is it best to also sample the incoming PIN at regular times ? Should I also render an average like I do for the incoming temp data ? I have tried various combanations using both the "frequency" and "period" methods with mostly good results. At the moment I am not averaging the results, and sometimes I get a wildly inacurate answer back. Currently I am using a AWG to generate a narrow pulse (2% duty cycle) into the PIN. I would be creating an input circuit that monitors the "spark" timing coming off the engine. Now, on some 2-cycle engines, you get a spark event 2 times per revolution. Some others, it's 1 to 1, ect.. The 2 for 1 motor would produce 12000 pulses per minute at 6000 rpm (near top speed). Using the frequency method, I should get 2000 cycles pre second at the PIN. (12000/60) This same motor also has an idle speed of 500 rpm, so would be puting out 1000 pulses per minute. This figures out to just 16 cycles per second. Now, for the 1 to 1 motor, the idle would be just 8 cycles per second. Humm.. answers come in a bit on the low side of the scale and I'm wondering if the MM code can produce accurate data at these low frequencies. Now, having said that, I do seem to be getting mostly good results. Still, just, being a "nubbie" at the MM codeing stuff, I was wondering what the best way is to apply the proper code to get the best results. Has anyone else tried doing this type of thing...? Any advice would be welcome and thanks in advance TBS.!! |
||||
| JohnS Guru Joined: 18/11/2011 Location: United KingdomPosts: 4038 |
12000/60 is 200 not 2000 If you sample, remember Nyquist... John |
||||
TassyJim Guru Joined: 07/08/2011 Location: AustraliaPosts: 6270 |
I use the counting option. The maximum frequency for frequency input is 200kHz so I assume that the same limit applies for counting. You use settick to interrupt every second and read the count then reset to counter or don't reset, just take the difference each time. (The counter will eventually overflow but that is easily taken care of.) For my water flow meters and wind speed, I read every 3 or 30 seconds depending on requirements. Jim VK7JH MMedit |
||||
| Zonker Guru Joined: 18/08/2012 Location: United StatesPosts: 767 |
Thanks for all the advice Gents... I guess I was just wondering how the code inside provides the answers coming out of, let say the frequency option. The data is available whenever you check the pin. However, is it wise to sample the pin along with my other gathered data every 1/10th sec and average every second..? Or, does this happen automaticly inside, and all i do then is check every 1sec and see if the data is different..? I'm just trying to figure out the "correct" way the write the code... I was hopeing to use the period option to get faster data updates for the guage, but again, I'm not sure if the MMcode works inside. Does it get a new answer every time the pulse train goes through a transition..? If so, then should I do some sampling and averaging with it, or just get the "current" data and the guage update rate I want..? I'll try pooking around the code samples for any other examples.. Thanks TBS for the time spent reading this babble..!!  |
||||
BobD Guru Joined: 07/12/2011 Location: AustraliaPosts: 935 |
On something with fast changing data like a tacho, shorter samples will show more peaks and troughs. Longer samples will average out these peaks and troughs. You might have to try it out and see what suits you best. I would be using the input pin as a COUNTing input. You seem to be producing a clean pulse on every spark. COUNT reads an input on every rising pulse. As for using the MM to average counts over 1 second compared to getting 10 samples per second and then averaging them I would suspect there would be little difference. The 10 samples per second would make the MM work harder. If you want to see an example of what happens with varying the sampling periods you can run the Windows PC Task Manager on the Performance tab. In the View menu you can set the sampling rate to High, Normal or Low. Low will tend to flatten the peaks by averaging over a longer time whereas High will show more detail about the peaks. Run something like Explorer copying a folder to see what happens. |
||||
| Snags Newbie  Joined: 26/02/2016 Location: AustraliaPosts: 2 |
I am currently working on an engine governor project and part of that involves a tachometer. The Ideal way I found to measure "slow" speeds (3000RPM = 50Hz) is not to measure the frequency of the shaft speed but to measure the period and then convert that to frequency (f = 1/T). There was a suggested way to do this in Silicon Chip a few years back (for the Maximite) and I have based my design on this. Basically, it uses the 200KHz output available on the (old) Micromite (500KHz in the "170's") and counts that as it is turned on and off by a sensor on the motor (ignition, optical pickup etc.). I have got all this part of the circuit working - only need to get a stable pickup on the engine and fine tune the program for the speed control. VK3UCB |
||||
MicroBlocks Guru Joined: 12/05/2012 Location: ThailandPosts: 2209 |
Would the rate of sampling not be determined by how fast you want the gauges to update. I would think 1 second is a pretty large lag time. Sampling 10x per second would not be a heavy load as the counting pulses part is done in a hardware peripheral and does not cost any cpu power. I would even go for 20 or 40 samples per second. Microblocks. Build with logic. |
||||
| Snags Newbie Joined: 26/02/2016 Location: AustraliaPosts: 2 |
The good thing about measuring "period" that it gives an update usually once every two shaft revolutions. Even at an idle speed of 600RPM this equates to five times per second which I consider pretty quick. VK3UCB |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
