Read variable frequency from UV detector board

Erlend · 2013-10-27 03:26

One part of my (eternal...) project is to measure flame intensity. I've settled on using a UVtron tube, and the i/f bundled with it gives out a variable pulses/sec signal (handful of Hertz) propotional to the UV intensity - but in a Geiger kind of way I believe, meaning pulse spacing is not regular. I do not need high accuracy, but Propeller IO is tight now. Options are: 1) using one analog input channel (MCP3208) to measure the result through some RC filter, 2) using a digital input pin on the Prop together with som pulse count code, or 3) use some other brilliant other idea. For some reason I believe I havent cracked it yet.
Ideas?

Erlend

JonnyMac · 2013-10-27 08:31

It would be very easy to write a little PASM object that could measure the edge-to-edge timing of your signal and report it to the hub. Your program could treat this hub value as a regular variable and respond to it.

kwinn · 2013-10-27 16:07

If you mean less than 100Hz by a hand full of Hz you could use one of the MCP input channels as a digital input as long as you are taking readings often enough (2x max pulse rate). Probably more accurate and certainly faster response than using an RC filter.

kwinn · 2013-10-27 16:13

Another option would be to share the input pin the MCP uses by using the chip select signal to choose between them.

Tracy Allen · 2013-10-27 16:42

This might be a candidate for a cog counter, provided your main loop can come around at regular intervals to read the accumulation.

[SIZE=1][FONT=courier new]
PUB  PulseCounter(pin) | ticks
 ctra := % 01010 << 26 + pin      ' POSEDGE mode
 frqa := 1                          ' one count per edge
 ticks := cnt
 repeat
   waitcnt(ticks+=clkfreq)       ' synchronized wait one second
   showResult.Dec(phsa~)    ' capture accumulation and post-zero
   ' do other program stuff here, shy of one second[/FONT][/SIZE]

Erlend · 2013-10-28 04:05

Let me be a bit more accurate:
The signal is 5v pulses at varying intensity, but not in an orderly fashion; something like this: | | | || || | || | | | | || | ||||| |||| ||| | |||||| - which would convert to (averaged) intensity something like this: 2 .. 3 .. 3 .. 1 .. 1 .. 3 .. 5 .. 4 .. 5.
The pulse intevals range from infinite to approx 0.05mS (20Hz). Some averaging is probably needed.
I like the idea of trying out the cog counter, but then I'll need to understand how it works - an that is hard.

@kwinn
Can you explain the 'using ADC as digital input' a bit further?

Erlend

Tracy Allen · 2013-10-28 09:22

Disillusion yourself of the notion that cog counter is hard to understand!

In the posedge (negedge) mode it simply detects rising (falling) edges, and for each one it adds the frqa value (frqa:=1) to the accumulator, phsa. That's all there is to it. It does its thing while your program is off doing other tasks. To get a count over time, you have to have some means in place to read the content of phsa and reset it to zero at regular intervals.

Erlend · 2013-10-29 08:20

I will dillusion myself and go ahead with the cog counter

.

Erlend

Erlend · 2013-10-29 12:59

But counting pulses at megahertz speed maybe does not make much sense when all I'll ever count here are 1 - 20 pulses every second?

kwinn · 2013-10-29 16:14

Erlend wrote: »

Let me be a bit more accurate:
The signal is 5v pulses at varying intensity, but not in an orderly fashion; something like this: | | | || || | || | | | | || | ||||| |||| ||| | |||||| - which would convert to (averaged) intensity something like this: 2 .. 3 .. 3 .. 1 .. 1 .. 3 .. 5 .. 4 .. 5.
The pulse intevals range from infinite to approx 0.05mS (20Hz). Some averaging is probably needed.
I like the idea of trying out the cog counter, but then I'll need to understand how it works - an that is hard.

@kwinn
Can you explain the 'using ADC as digital input' a bit further?

Erlend

I hope that the 0.05mS (20Hz) is a typo and you really meant 0.05Seconds (20Hz). What I am posting is based on 0.05Seconds. The pulses are very short duration so you would need to stretch them out with a diode and RC circuit so the pulse duration is about 5mS. Then you need to read the ADC channel at least 40 times a second so no pulses are missed. Each reading is compared to the previous reading, and if it is higher than the one before a pulse has occurred. If the reading is lower or the same as before then there has not been a pulse. Of course you will need to have some minimum increase of the voltage to count it as a pulse or you will be counting fluctuations due to noise.

On the whole I think Tracy's suggestion of using the counter is the best way to go if you have a pin to spare, but using the adc will also work

Tracy Allen · 2013-10-29 20:49

Erlend wrote: »

But counting pulses at megahertz speed maybe does not make much sense when all I'll ever count here are 1 - 20 pulses every second?

The cog counter is just a specialized module that sits there sampling the input far, far faster than it needs to, but it only reacts and advances the count when the input changes. Is it a waste? Well, most programs spend a lot of time sitting in a loop, waiting. If you have concerns about power consumption, the cog counter could keep up with the UV-tron even with the prop running on a 5MHz clock, or maybe even RCslow if you have an external time reference.

Input signal edges from the UV detector would have to be clean, noise-free. The counter modules sample so fast when clkfreq is high, that noise on the input signal edges can lead to multiple counts per edge. If that turns out to be a problem, then one of the other suggested techniques might work better.

Erlend · 2013-10-30 01:14

@kwinn
You are right, the 'milli' was a typo. The ADC object runs in a cog by itself, so it should come around fast enough, but I can see this solution will need some circuitry , which I'd like to avoid, so even if I have to spend another pin, I think I will go for the cog counter idea. Actually I have ideas for how that pin can be shared with an other input signal.

@Tracy
The pulse signal will be coming directly from a logic gate output, so it should be clean. And it is just me being irrational about it (hardware-emotional?) to worry that such a powerful counter has do do such a menial task. Power consuption is not a worry in this application.

jmg · 2013-10-31 12:50

Erlend wrote: »

The pulse signal will be coming directly from a logic gate output, so it should be clean. And it is just me being irrational about it (hardware-emotional?) to worry that such a powerful counter has do do such a menial task.

You've paid for 16 counters, feel free to use them

If the Logic gate is a schmitt with some form of low pass before it, you should be ok.
If you want a rate, you will need to chose some timebase, and use maths or a table (guessing this is non-linear )

With the Prop's 32 bit counters avoiding any overflow issues, you can use multiple timebase - eg display a 10 second rate, and also display a 100 or 1000 second background rate, if you want longer averages, or more precision.

kwinn · 2013-11-01 19:45

Erlend wrote: »

The pulse signal will be coming directly from a logic gate output, so it should be clean. And it is just me being irrational about it (hardware-emotional?) to worry that such a powerful counter has do do such a menial task. Power consuption is not a worry in this application.

I know what you mean. It seems like a trivial function for such a powerful bit of hardware but jmg is right, better to use it for something simple than leave it unused.

Read variable frequency from UV detector board

Comments