So, I have started on a job for a person on these boards. He wants a tacho, it seems. Read some pulses coming in on a digital in, drive a servo on 4 digital outs (unipolar servo, I assume).
Step 1 is done - I have hooked up a stepper motor as an indicator dial. Of course, my stepper is 48 position, rather than the 600 that these instrument steppers are. But, the code should translate across ok.
Next step, hook up a 555 timer and a pot to give a square wave with a frequency between zero and 2050 Hz.
I'll post updates here as I go. Or at least, I intend to. Hopefully we get a picture of what doing one of these jobs involves.
For generating a square wave in that frequency range, you could also look at the Arduino tone function, if you haven't already done so. There are other alternatives as well with built in timers, unless you have to use external hardware like the 555 for other reasons.
I have just completed a job to do exactly the same thing. Try looking at the SwitecX25 libraries, they will give you just about everything you need to make this work. The only bit you will need is a way to count frequencies. For that you could use pulseIn() and a bit of maths.
The only issue with pulseIn() is that it is a blocking function and if the there is no incoming frequency then it will wait for the default timeout period (or one you select) before returning. This means that if you have it monitoring more than one pin it will block all the gauges for the timeout period in the event of there being no change of state on that pin.
The other option is to use pin change interrupts to increment a counter and use a timer interrupt to give you a count window. This will then give you frequency on all the pins without blocking.
I would suggest that you get the client's permission before you post anything though. Even though you may be doing something that is trivial from an engineering perspective, a lot of people posting for help here are running businesses and having your work linked to their business (not hard to figure out if you've posted publically to them) can have negative consequences for them.
Just a friendly thought to keep in mind. Think about your customer first!
Nothing I have posted has compromised my client confidentiality
The libraries are publicly available.
The problem with pulsIn is well known and
The method of smoothing out reading to get a low pass filtering effect is basic stuff.
When a customer asks me to build them something I use my knowledge to create a product. The customer has no right to my knowledge or experience Providing that I do not disclose anything that may compromise my clients position I fail to understand the problem.
In the demo video, I am using a 555 timer to generate a square-ish wave with a frequency from low up to about 2k, which is about where the top of his tacho range is. Of course, this will need to be tuned at the client's site to account for inaccuracies in the arduino resonator.
An arduino nano takes this input on pin 2, and drives a stepper motor on pins 3-6 via a darlington array chip and an external power supply (a couple of lantern batteries), as the stepper that I have is a 48-pole 12v thing from Jaycar.
Perhaps the main thing is that I am not using the switech library. I didn't manage to get it going for my stepper motor, almost certainly because the switech steppers can be driven much faster than my stepper. My stepper code is pretty basic and doesn't have the soft accelerate and decelerate that the switech library seems to have. But, assuming that the instrument steppers are just ordinary old unipolar five-wire steppers, the code I have written should be fine.
(to tell you the truth, the switech library looks weird to me: the activation pattern has six steps for four coils, and in some of the steps opposing coils are activated at the same time. Weird as hell. )
Client would prefer to drive two gauges off the one arduino, but a second nano is twenty bucks, and it will be more accurate without the two input pulses having to argue with one another.
Added code to make use of the intermediate steps of the stepper. Instead of A-B-~A-~B, it is now A-AB-B-~AB-~A-~A~B-~B-~BA . This means there are twice as many positions around the dial, but I can reduce the microseconds between ticks to less than half what it was before. The dial moves more smoothly and faster.
The switech library includes acceleration and deceleration code. If may be the case that with the needle moving this fast that that code becomes necessary. As before - I just can't know for sure without the hardware.
Further alterations available at github. Two things perhaps of general interest
implemented a ring buffer for timings
We were finding that the needle was a little "grainy" at high frequencies. This may very well be because at high frequencies, the difference in microseconds between the pulse lengths is such a large proportion of the total that when you take the reciprocal to get the frequency, they differ by more than 1 needle position.
To fix, my code now works over 4 samples, as well as having a low-pass filter (which may no longer be necessary at all, come to think of it).
altered the sketch so that it can drive multiple guages off multiple sensors. To do this, the various constants in the sketch were moved into a class, and those constants are initialized with a constructor. With cooperative multitasking, it should all just work.
worked great right out of the box. reset my stepper counts, works really good. I think you got it.Both motors work togeather off the same signal with no problems.will try tonight with 2 separate signal generators. needles zero great when there is no input signal. is it possible, if not no big deal can you get both needles to zero out at the same time. the way it is now stepper 1 zeros and then stepper 2 zeros. can we get them to zero at the same time?? I may want to add one more thing once we get all the bugs out. an RPM activated window switch on the speedometer. to operate at in a specific freguency. but it must pass a threshold and then turn on if the frequency in the window is met. for instance the switch would be active between the speeds of 90 to 100. MPH but you would need to exceed 100 mph to activate the switch. and then the switch would activate only between 90 to 100 mph if the input frequency is decreasing. now that you are totally confused ask and I can clarify it for you.
Dougsauto:
I may want to add one more thing once we get all the bugs out. an RPM activated window switch on the speedometer. to operate at in a specific freguency. but it must pass a threshold and then turn on if the frequency in the window is met.
Ok, so a 'window' with hysteresis. The way I do this is to make an object that takes the bounds, a pin number, and a reference to a signal detector. You the just wire it in with a constructor.
Actually, the way I do all my work is sorta described here. Your tacho job totally fits into that pattern of how I am approaching everything on arduino. But I hadn't worked with interrupts before, so cool stuff.
In any case: tonight is D&D night, and tomorrow I will be shopping all day and partying all night. So, probs Sunday (Australian time).
Never mind sunday - did it just now. Should be ok. Dials should zero together, and the on-board LED on pin 13 should come on when the frequency of the pin 9-12 input is 1000Hz and go off when its < 990.
Needles now zero both at the same time. How ever the rpm switch is working just not in my specific frequency window. I need pin 13 to activate ONLY when the frequency is between 160 to 165 HZ so off anything below 160 and off at anything above165 only on at 160 to 165 HZ. but here is the difficult part. when the frequency is rising, when it passes through 160 to 165 HZ pin 13 should not activate. it should only activate when the frequency is decreasing as it passes from 165 to160HZ below 160HZ it should be off.Since we have 1 pin left. leave in the RPM switch that is in there now. can it be switched to pin 4 and I can use that as a high speed warning.
Finished!!!! nice smooth needle movements and even 2 rpm activated switches. I figured we had 2 pins left might as well use them up. It was a bit of a struggle but a half dozen sketches later (including all my additions) everything works. once I can get it all set on a breadboard I will post a video
Dougsauto:
I am in need of some adjustment to the tacho code. Please let me know if you are available to make the needed code adjustments
I should have replied earlier.
I'm not really into doing ongoing maintenance of this project. The code is all open and unencumbered with IP, so someone else should be able to pick it up and go.
. I was half expecting this, anyway.