Need a Tach Converter...

Jeff Redington · 2007-05-21 23:55

Here is what I created before,

' {$STAMP BS2}
' {$PBASIC 2.5}

readfreq VAR Word
freq VAR Word
adjfreq VAR Word

Setup:
HIGH 0 ' make P0 high

Main:

COUNT 7, 50,readfreq 'read freq over 50 ms
freq = readfreq * 20 'reading * 20 would be pps
adjfreq = freq * 2 / 3 'adjusted freq for pulses out
FREQOUT 0, 950, adjfreq
GOTO Main

_____________________________________

This is close to what I want, but will not work, as the freqout disappears for 5ms out of every 1000.· As well there is no coding as to the duty cycle I need, 20% on and 80% off.... at the appropriate Freq.

_______________________________________________________________
I was adviced that the Propeller, with 8 processors, could do what I needed.· So here goes, it should be here tomorrow....

____________________________________

I want to get the readfreq (Read Frequency) with one cog of the Propeller.· On one input which is number 7.

Note: This Frequency is always 20% On and 80% Off.· The total cycle will always be 100%.
So at 800 RPM it is on for 5ms and off for 20ms.
At 7000 RPM it is on for .57ms and off for 2.29ms Which is still 20% 80%.· But much shorter.· This is the result of the distributer in cars engine.

I want another cog·to do the math.· readfreq * 2 / 3· This will give the proper spacing and conversion as needed.· Cannot just drop 1 out of three to get 2.· The timing and spacing are important, and must be correct.· And must be an evenly spaced pattern.

I want a third cog to handle the freqout (Frequency Out).·· And this freqout needs to have the added 20% duty cycle...· or the 20% on and 80% off in each pulse out.· Thus a true copy of the original signal.· freqout will maybe control a pulse out that has the built in Variable of the 20% duty cycle.

I hope the remainder of the cogs can handle whatever else this chip may need.

Thanks for your input.

- Jeff Redington

·

Capt. Quirk · 2007-05-22 06:55

Is this a simplified version of what your original wiring looked like? Just a Tach conected to the negative post of the ignition coil.

Tracy Allen · 2007-05-22 15:48

Hi again Jeff. I think you'll like the propeller to get that engine humming, and you'll find that it has many alternative ways to implement the tachometer 3:2 mapping. What you suggest about measuring the frequency with one cog and having that determine the frequency output produced by a second cog is certainly one way to go about it, including the requisite duty cycle. Another way, it seems to me, would be to measure the period on a cycle by cycle basis.

Like this: Measure the length of the input DW pulse (assuming it is a clean pulse and free enough from jitter). That gives all the information necessary to calculate the output pulses and spaces for the two output pulses. For example, if DW is found to be 5 milliseconds, that immediately implies a cycle of 25 milliseconds and a duration of 75 milliseconds for 3 cycles of input : two cycles of output. Calculate an output pulse width of 7.5 milliseconds, one starting at time offset zero and the next starting at time offset 37.5. The output pulse of proper width could be handed off to a cog counter, and the input pulse width and time offsets could be measured and synced to the system CNT register. The timing would be updated at least every three input cycles. I am saying that one cog could do all that. If the DW pulse is jittery, an alternative would be to measure a longer cycle on the input, or pass the pulse widths through a low pass filter, either of which would increase the i/o response lag.

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

Jeff Redington · 2007-05-22 20:12

Tracy Allen,

Thanks,

I think you are getting close to what I want.· All in all, when I am done, I want to understand what I have done...

The above PBasic program I wrote I understand.· And I want to in the Propeller work something I understand.· What you are proposing makes total sense to me.·

Of course I have never done a Propeller before.· But after reviewing what you have written, it seems doable to me.

I reviewed how they use different cogs to do different subrutines, and this makes sense as well.

__________________

Now what you are telling me, is the Propeller can do all these things and still put out the proper freq. without the 5ms delay that is in my basic program, and all with one cog...· How can it if it is only using the one cog?· Is much of its functioning and use of its cogs done automatic...?

Capt. Quirk · 2007-05-23 02:08

I know this isn't what you want, but it seems so simple to just hide a hall sensor under the engine and output 2 pulses per revolution to the tach

Tracy Allen · 2007-05-23 17:32

Hi Jeff,

I don't know much about engines, and I'm really just getting started with the Propeller, too, so take my pointers with a grain of fuzziness. I keep the manual on my desktop, and offten look back at the snippets and projects that people who are doing amazing things have posted here.

One way to measure the period of an input is by reading the system CNT register upon detecting edges on the input pin, as follows in Spin:

waitpeq(0, |< 7, 0)   ' initiallize, wait for a7 to be low
                  ' |< 7 is a trick way of writing %10000000, a mask for the input pin(s) to watch
waitpeq(|< 7, |< 7, 0)   ' wait for a7 to go high
cnt01 := cnt                  ' capture system counter
repeat
    waitpeq(0, |< 7, 0)     ' wait for a7 to go low
    cnt10 := cnt                 ' capture system counter
    period1 := cnt10 - cnt01    ' this is the time high in units of the system clock cycles
    if period1 > $7ffffffff ' caught the rollover of cnt register
        period1 := -period1  
    waitpeq(|< 7, |<7, 0)   ' wait for a7 to go high
    cnt01 := cnt                  ' capture system counter
    periiod0 := cnt01 - cnt 10   ' this is the time low in units of the system clock cycles
    if period0 > $7fffffff
        period0 := -period0
    period := (period0 + period)  ' total period in units of the system clock cycles, dimensionless
    perioduS := period / 80  ' in microseconds assuming clkfreq = 80mhz
    frequency := 1_000_000 / period  ' in Hertz

That gives the period of the input in system counts and also, for the record, in microseconds, and the frequency in Hertz.

That routine completely ties up the cog, waiting for the input edges. One way to add the output frequency is to pass that task off to the cog counter modules in the same cog.

You want an output frequency that is 2/3 of the input frequency, or a period * 3/2. It is most convenient to take the period in terms of clock cycles, which determines the value that needs to be entered in the frqa register:

'  add to the above code:
dira[noparse][[/noparse] 1 ]~~  ' make a1 an output
ctra :=  (%00100 << 26) + 1   ' sets counter A for NCO mode on pin a1
           ' setting the counter mode would only have to be initialized once
           ' a1 is low, but nothing else happens yet because frqa=0
  '...
  ' extend the repeat loop:
repeat
    ' ... code to determine input period
    ' ... got it ...
    period := period * 3 / 2  ' adjust for output period in system counts
    frqa :=     $ffffffff / period   ' phase to accumulate in phsa on each system tick

That would I think autonomously yield a symmetrical square wave of 2/3 the input frequency on pin a1, and the cog loop would update it once every time around the loop. Note that the calculation is based on the dimensionless period in counts. The actual system clkfreq does not enter the equation. However, the clkfreq would have to be high, like 80mhz, in order for the code to keep up. The machine language version would be much faster of course, and not much more involved.

You stated that the duty cycle of the output has to be 1/5, and this too can be accomplished by adding counter B into the mix. Both counters address pin a1, at the same frequency but with different phase, and with this arrangement any duty cycle from 50% to 100% can be acheived autonomously. The following would I think make the output pin low for 1/5 of the period and high for 4/5 of the period The logic in the propeller inclusive ORs together all sources that affect a given pin, so the pin is low only when all sources are low.

' initialize the counter NCO mode
dira[noparse][[/noparse] 1]~~  ' make a1 an output
ctra :=  (%00100 << 26) + 1   ' sets counter A for NCO mode on pin a1
ctrb :=  (%00100 << 26) + 1   ' sets counter B for NCO mode on pin a1
' a0 is low but nothing else happens yet on the output yet 
' because both frqa and frqb are zero

' extend the repeat loop...
repeat 
    ' ... code to determine input period
    ' ... got it  ...
    period := period * 3 / 2   ' output period in system clock cycles
    frqa := $ffffffff / period
    frqb := $ffffffff / period
    phsb := psha + (period * 4 / 5)   ' adjust phase B for 4/5 of a period advance

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

Post Edited (Tracy Allen) : 5/23/2007 7:31:34 PM GMT

Jeff Redington · 2007-05-23 18:50

Seems like the code above is on its way, where is the phsa and how do they tie to the cnta and cntb and on to the a1 output...

I don't quit see how they interface?· To cause the output to cycle...

Thanks,

- Jeff R.

Tracy Allen · 2007-05-23 19:28

Hi Jeff,

There is an application note AN001 for the cog counters, you can download from the Parallax web site.

The active register of a cog counter is its phase accumulator, a 32 bit register phsa or phsb. (Two counters, a and b per cog). Bit 31 of the phase accumulator is tied to an output pin when the counter is configured for NCO mode as in {ctra := %00100 << 26 + 1}. The value frqa is added to phsa on every clock cycle. Phase advances through one cycle that will bring phsa(31) and the output pin low for phsa<$80000000 and phsa(31) and the output pin high for phsa>=$80000000. One complete period, one pass through phsa takes period = 2^32/frqa where both period and frqa are expressed in dimensionless clock cycles. You measure period in clock cycles, and then calculate the corresponding frqx. The accumulation in the phsa and the hookup to the output pin happen automatically in the NCO mode. In the calculation, I substituted $ffffffff for 2^32. Close enough.

To make this quantitative.
-- Suppose the input frequency is 1000 hertz and the clkfreq of the Propeller is 80 megahertz.
-- Then during the one millisecond period of the input, the CNT register will advance 80000 counts.
-- Multiply that times 3/2 to get 120000, which is the dimensionless period in clock cycles you want .for your output.
-- Divide that into 2^32 (or into $ffffffff), which gives frqa = 35791.
-- Note that if you add 35791 to itself 120000 times, in the phsa register, that completes one cycle and phsa rolls back over to zero.
-- The output pin has been low 1/2 of the time and high 1/2 of the time.
-- The output frequency is 2/3 of the input frequency
-- phsa advances autonomously, without program intervention, you update frqa to track the input frequency.

Oops, I see I need to correct a couple of typos in my listing. I wrote cnta where it should be ctra.

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

Post Edited (Tracy Allen) : 5/23/2007 7:46:00 PM GMT

Jeff Redington · 2007-05-24 19:55

Tracy, and everyone who has helped.

On the Basic forum someone found a module for $79 bucks, that will do exactly what I need, it is already tested and ready to rock and roll, and was designed for this purpose.

I have learned here what might work, and now have the Propeller which I may play with, I may look into using it for another project.

Thank you for all your input.

- Jeff Redington

Need a Tach Converter...

Comments