Is it possible to use 15 digital pins as same time pulse counters. I want to use 15 x rain gauges ...freq max 1Hz.
Ah, no, you don't get away that easily!
Yes, at 1 Hz, there is no problem polling 15 sensors. Please do not get so muddled you start talking about interrupts however!
The thing is, if you seriously want to do this, you need to know what these sensors are? Are they tipping buckets? Do they use reed switches? 1 Hz would be two tips per second. Even with reed switches, you need a de-bounce routine and 15 inputs at 1 Hz is easily de-bounced - always in software, of course. Don't even think about hardware. :astonished:
reed switches, tiping bucket yes.
then this can handle 15 pulse counting simultaneously?
That's how you post a link on the forum, please read the sticky post before you post again.
But, yes, that is the kind of thing Paul__B is talking about. Personally, I would not buy that particular design because it's not very breaboard friendly. But if you already have an Uno you want to use, I guess it will be quite convenient.
Now a question for you. 15 rainfall sensors. Why?!?
Why 15 inputs need a port expander? Why not to use HW debouncing? Why not to use interrupts?
Well, the OP did not say what kind of Arduino they have, which usually means they have an Uno and may not even know that other types of Arduino exist. 15 pins would use up most of what an Uno has available, and the OP did not mention what else pins might be needed for. So a port expander seems like a reasonable suggestion. The OP seemed to be interested in the idea, so maybe they are concerned about running out of pins. This is all conjecture on our part, of course, having so little detail to go on.
I would say that using interrupts often gets beginners into trouble. And in this case is completely unnecessary, as the events will come 15 per second at most. If that were 15,000 per second, I would agree that interrupts would be a good idea.
Hardware debouncing would mean 15 X sundry components, more soldering, more PCB space. Software debouncing moves that complexity into the code, which is what microcontrollers are all about.
Thank you PaulRB. :grinning:
Now I have not researched exactly how typical tipping bucket devices are configured, but it is somewhat easier if the reed switch is on for one position and off for the other. If the magnet just "flashes" past the reed switch on the way from one side to the other, the timing would be a little more critical.
Any attempt at hardware de-bouncing would involve more than one component per input, so more like "45 X sundry components".
With my rain sensor, the reed switch is activated momentarily by a magnet on the bucket/see-saw as it passes. I seem to remember the reed is typically closed for around 8~9ms when the bucket tips. I use a tiny85 to monitor it (plus anemometer & windvane).
The tiny runs at 1MHz and spends most of its time in sleep mode to conserve the battery and wakes every 1ms to check the sensors. When the reed is closed but was open on the last check, a count is incremented.
This seems to reliably avoid bouncing and never misses a tip. I tested it extensively, tipping it by hand many times, and it has been in operation for a couple of years now without any problems.
So I think that even via a port expander, it should be no problem for a 16MHz Arduino to monitor 15 sensors. An input pin could be used to poll the INT pin on the pcf chip to know when to read the data from the chip.
Yes, I thought that might be the case.
The idea of a port expander - the PCF8575 would be a trifle more practical than the PCF8574 - sounds excellent in this context with the INT pin polled.
My normal preference for debouncing is a routine that tests the input for a consistent new state on every poll over an interval of say 5 to 10 ms, resetting the count whenever any one poll reverts to the old state. This is the most appropriate for a manual pushbutton whose expected behaviour is to be pressed for at least 100 ms. If on the other hand, the expected behaviour of this reed switch is as you say, then it would be sufficient to check for a consistent change over a three millisecond interval - which is to say as many polls as occur while millis() advances by two - and also check for a "stuck" switch which stays on for more than a second.
That certainly should be quite straightforward to code.
@PaulRB: Interrupts are not a toy to burn time of professional programmers. It is one of the most important features MCUs have. Many tasks are very difficult or even impossible without them. For example your project already uses interrupts to wake up every 1ms. If you used them properly to wake up only at pin change you likely would reduce your current consumption by order(s) of magnitude. I agree it is not the first thing for beginners to learn but it is worth to learn soon. Such project may be a good starting point. I don't want to say interrupts MUST be used but it is a viable option.
@Paul__B: 3 components for debouncing? AFAIK usually a low pass filter (resistor and a cap) is used. Maybe internal pull-up and external cap may be used for only one component per input. Again I don't want to say SW debouncing is bad. But HW may be easier, especially for 15 inputs. At least OP may practise soldering on plenty of cheap, easy to solder components ;-)
15 rain gauges for measuring dispersion of rain about 50x50m area... for school project.
i found cheap rf rain gauge , what you think is it possible to get data out from display unit and arduino to collect that data ?
Possibly, yes. But a vastly more difficult project for a beginner. An Arduino expert armed with lots of experience in RF signals, oscilloscopes and RF signal analysers would not find it easy. Also the rf signals from 15 of these units would almost certainly interfere with each other. So my advice would be to stick to the simple reed-switch based sensors.