2020-10-28 at 10:29 AM #14723BrianJastramParticipant
I’ve got 5 solar powered Mayflys deployed with ProTrinket tip counters connected to heated and non heated rain gauges reporting their data to MMW via Digi XBee3 – RF TXRX Cell 4G LTE AT&T Verison – XB3-C-A2-UT-001 modems. These deployments range in length from 2-14 months. Within the past few months two of these setups have started reporting tips when there is no precipitation or melting snow. I’ve tried re-terminating the rain gauge wires on the ProTrinket screw terminal but that didn’t fix the problem. There doesn’t seem to be more than one tip per recording period (5 min.) and I can’t see a pattern in the frequency of bad tip data. I’ve attached a photo of a graph showing all the rain gauges in my network. The two in question are represented by the thick blue line and the white line. Let me know if you have any troubleshooting ideas.
2020-10-30 at 10:33 PM #14761neilhParticipant
Hi Brian, You may want to describe the type of tipping bucket and the electrical interface for counting . Some types of relay contacts can oxidize and require a minimum wetting current at some point. Do you have a link for the ProTrinket.? regards
2020-11-02 at 11:20 AM #14767Sara DamianoModerator
I’m guessing you’ve made one of these: https://github.com/EnviroDIY/TippingBucketRainCounter
I’ve edited the code that makes it work with ModularSensors, but I haven’t ever built one. Sorry.
2020-11-02 at 4:51 PM #14776
@brianjastram, I think my colleagues in Washington DC have experienced a similar problem to yours, and after a bunch of troubleshooting, we figured out that it was due to electromagnetic interference in the analog signal line from the tipping bucket to the counting device. They had used unshielded cable and also had some unshielded connectors on the outside of the box. We solved the problem only after shielding the entire length of cable, and grounding one end (and only one end) to the battery negative.
I had never seen that my other installations, and those same stations worked fine our Ann Arbor office but started showing those tips at odd times of day in busy urban Environment at our DC office. Our clue was that two tipping buckets sitting next to each other on a desk were showing those random tips at the same time.
Let us know if this might make sense for your situation.
2020-11-02 at 9:49 PM #14777
Is there a benefit to using a Trinket for counting the tips instead of using the Mayfly? I’ve built a bunch of tipping bucket recorders using only Mayfly boards by just connecting the bucket’s reed switch to the Mayfly pin D10 and using code to look for an interrupt to wake the Mayfly, increment the count, and go back to sleep. It records and transmits (via 900mhz Xbee) the count every 5 minutes, and resets the daily total at midnight. I’m guessing the Trinket is there so that you don’t miss counting a tip that comes in while the Mayfly is busy doing an uninterruptible time-consuming function, like transmitting the data via cell?
What kind of heater power are you using (AC or DC?), and what circuitry is controlling the heater on-off functionality? Are the ones recording the bad tips equipped with heaters or not? I’d remove the rain gauge reed switch wires from the Trinket so there’s no input at all to the Trinket, and then see if it continues recording phantom tips or not. If it is still recording bad tips, then your problem is with the Trinket. If the bad tips stop, then your problem is likely in the wires going to the gauge (a short somewhere, corrosion, or RFI or other signal interference) or with the reed switch failing (which I’ve seen before).
2020-11-03 at 9:19 AM #14781
@shicks, that’s great to hear that you have a bunch of tipping buckets connected directly to the Mayfly. Could you share that code with us? Is it integrated with ModularSensors? It would be very valuable to do that.
I can’t remember all the reasons for developing the TippingBucketRainCounter device application for the Pro Trinket. I do remember exploring lots of options and getting lots of opinions back in the winter of 2018, and my memory was that there were good reasons for not using the Mayfly directly. I’ll see if I can dig up my notes on that.
2020-11-03 at 9:49 AM #14783
Below is the code I wrote several years ago that is still running on all our local tipping buckets. This was way before all the ModularSensors libraries and MMW portal, so things could be written differently now, but it can give you and idea on how the Mayfly handles the interrupt signal from the tipping bucket. There’s a 1-second delay after a tip is sensed to filter out any switch bouncing that sometimes occurs when a tip happens.
First you need to enable the pullup resistor on pin D10, which is already built in to the Mayfly board, you just have to close jumper SJ12 on the back of the Mayfly. Then this snippet of the code shows how to set up your sketch to look for a low trigger from the tipping bucket switch:Arduino1234//enable the D10 pullup jumper on Mayfly solder jumper SJ12 in order for the next 2 lines to workpinMode(10, INPUT); //sets pin 10 as an inputattachInterrupt(2, pin10interrupt, LOW); //sets up an interrupt looking for a LOW trigger//connect one terminal of tipping bucket to Mayfly pin D10, connect other side of bucket switch to Mayfly ground
2020-11-04 at 11:26 AM #14785
After thinking about this old code yesterday, I was curious about what actually happens if a tip occurs during a long delay period, like the 2-second delay on line 123 and and 2.5-second delay on line 125 (which are delays to give the Xbee 900mhz radio module time to successfully wake up and then finish its routine before sleeping). I programmed a test board with the sketch from above, but increased the delay time to 10 seconds for each of those lines, to give me enough time to experiment. What I found was that if a simulated bucket tip on pin D10 happens anytime during a 10-second delay, the delay instantly ends and the interrupt routine successfully gets executed (meaning a tip gets counted) and then the sketch moves on with the next line of code (either line 124 or 126, depending on which delay the tip happened in). So this shows that no tips will get missed by the Mayfly, but the delay period gets instantly cut short. If you’ve got a radio or cell module that needs multiple seconds of uninterrupted wait times before doing the next step, then care should be taken about how you handle interrupts from D10 during that time. You could unattach the D10 interrupt during those important delay times, and then reattach it when you’re done, or find another way to handle either the interrupt or the telemetry delays.
2020-11-09 at 9:24 AM #14802BrianJastramParticipant
Shannon, great job moving the science forward. It seems like your line of experimentation could lead to a simpler way to count rain gauge tips and transmit the data to MMW possibly without using a ProTrinket. Maybe if a tip happens while a cellular transmission is happening the transmission could be interrupted, the tip could be counted, and then during the next send interval the data could then be sent to MMW. I am looking for a way to reliably count every tip and send all tip data to MMW even if a send interval is missed here or there.
Using @aufdenkampe ‘s advice as a clue I replaced the 25′ of extra, coiled, shielded analogue signal cable from the original installation between the rain gauge and the ProTrinked with a 3’ length of shielded analogue signal cable on 11/6/2020 and haven’t had any false tips since.
Thank you everyone for the input.
2020-11-09 at 11:27 AM #14804
- You must be logged in to reply to this topic.