catching switch closure, help needed

Franklin

I am building a weather station using the propeller and need some input. The rain gauge and anemometer both have magnets that close a reed switch as they pass and I need a way to count these closures to update data. The rain gauge switches from once a second to once every two months and just needs to be accumulated for a 24 hour period. The anemometer can pulse up to 50 time a second and needs to be accumulated for 2.5 seconds. I've done this with ctra and hardware but was wondering if this could be done in software. Looking at the objects in the OBEX they seem to be more for querying a pin to see if it is pressed but with the other things the prop will be doing I'm not sure I would catch all the pulses that way. Does anyone have any insite on this problem?

Thanks,

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Mike Green

It's way too easy to do the counting using the counters (CTRA and CTRB). You'd need a cog routine in Spin to handle the timing. Set them both up for edge triggered mode with FRQA/FRQB set to 1 and PHSA/PHSB initialized to zero. The Spin code would initialize the counters and then drop into a timing routine that would use WAITCNT to do the 2.5 second timing, read the accumulated anemometer count and reset it and keep a count of the number of 2.5 second intervals. 34560 of those would be 24 hours and you'd read the accumulated rain gauge count, reset it, and reset the number of 2.5 second intervals. You probably should use an RC filter to smooth out any contact bounce from the switch closures although with reed switches that would be minimal.

Yes, you could do this all with software and not use the counters, but you'd need a cog anyway to handle it and that already comes with two counters.

Franklin

Thanks Mike. That is how I was doing it but without hardware debounce it was giving me bogus numbers. You'd be supprised how much noise there is on a reed switch to an 80mhz micro!!

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

JonnyMac

I agree with Mike's comments and, just for fun, I wrote software-based version just to see if it works (I still think you should have a [noparse][[/noparse]very] small RC filter on the input).· The attached anemometer object is written in PASM.· You would pass it a pin number and the address of the·variable that you want to use as your accumulator; the object runs from there, updating the variable every 2.5s.· To use it you might do something like this:

anemometer.init(0, @WindRaw)

Where P0 is your input and WindRaw is your [noparse][[/noparse]long] variable.

The software debouncing works on the theory that your input (bouncing) will last no longer than 1/4 of the 50Hz sample window.· When the input goes high the pulse count is updated, a short delay is inserted, and then the code checks to see if you've reached the end of the 2.5s accumulation window.· If that happens, the pulse count is written to your variable and the process starts over.

This is just an idea whipped up over coffee -- if you try it and it works (or doesn't), please let me know.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA

Franklin

Thanks Jon, I'll take a look at it tomorrow and let you know. I got a kick from the " << + >> " code, only geeks think like that [noparse];)[/noparse]

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

Franklin

OK, with no hardware debounce I get these numbers:

0
0
0
0
0
0
0
88
76
107
58
131
0
181
0
0
0
0
0
0
0

I'll hook up the debounce and see what I get then.

Thanks for the help, any direction is better than random...

Very simple test program attached, there is no substance so don't bother running it.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
- Stephen

JonnyMac

On of the [noparse][[/noparse]many] fun things about the Propeller is that we can sometimes write code for another cog that simulates an input.· Case in point: your anemometer project.· For grins I wrote a test program that launches a simulator cog; the "on" output of the simulator is very noisy; the off time is clean.· You can run this on any Propeller board and see that, despite the noisy input, it still reports correctly (125 pulses every 2.5s at 50Hz)

Note that I changed the delay-from-detected-high timing inside the anemometer object to 10ms (one half of your 50Hz max input).· I suggest you connect a 'scope to the circuit just to see what the actual duty-cycle from that switch is; you may need to adjust the code.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Jon McPhalen
Hollywood, CA