Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of Home › Forums › Mayfly Data Logger › Mayfly clock and battery
Tagged: monitor my watershed
- This topic has 15 replies, 4 voices, and was last updated 2020-01-15 at 6:29 PM by
Sara Damiano.
-
AuthorPosts
-
-
2020-01-14 at 6:09 PM #13622I would like to better understand the Mayfly dependency on having its clock set correctly prior to deployment. If you remove the coin-cell battery for many days, then reinstall it, will the Mayfly losI would like to better understand the Mayfly dependency on having its clock set correctly prior to deployment. If you remove the coin-cell battery for many days, then reinstall it, will the Mayfly lose its time setting? Assuming so, would that cause it to be unable to upload data to MMW? If the battery is completely absent, will that prevent uploading data?
Our scenario is this: I programmed a Mayfly in Idaho, removed its battery, and shipped it to Michigan, where Jake deployed it in the field, initially with a missing coin-cell battery. It didn’t upload any data, so we’re wondering whether a missing battery or an incorrect clock setting could be the cause.
Thanks,
Matt -
2020-01-14 at 6:21 PM #13623If you remove both the coin battery and the mayfly loses power, even for an instant, the clock will reset to Jan 1, 2000 0:00:00.
The coin battery isn’t necessary if there’s another power
If you remove both the coin battery and the mayfly loses power, even for an instant, the clock will reset to Jan 1, 2000 0:00:00.The coin battery isn’t necessary if there’s another power supply, but it’s very convenient to power the clock with its own battery so that you don’t have to reset the clock every time you turn the Mayfly off. The clock battery should last for a few years. If you’re running modular sensors and have internet connection, the first thing it attempts to do on boot-up is set the clock and it will continue to attempt to connect to NIST and set the clock on every cycle until the clock passes a “sanity” check (ie, between 2019 and 2025). If there’s no internet connection, though, it will spit out lots of warnings about the incorrect time but should proceed to sample on every 5 minute interval. Once you download the SD card you’ll have to use your installation notes to estimate when you turned it on and adjust everything accordingly.
I don’t remember if there’s a “sanity” check on MMW or not – I thought not. Look for data that’s labeled as 20 years old. (Man that makes me feel old..)
-
2020-01-14 at 6:41 PM #13624There’s no reason to remove the CR1220 coin cell battery before shipping the board. You’re not able to ship loose batteries, or larger multi-cell batteries, but it’s okay to ship oThere’s no reason to remove the CR1220 coin cell battery before shipping the board. You’re not able to ship loose batteries, or larger multi-cell batteries, but it’s okay to ship one watch battery if it’s installed in equipment, such as being inserted into the Mayfly’s battery holder. Don’t ship more than one at a time, and protect the Mayfly from rattling around, and protect it from short-circuiting on anything else inside the package. If you follow those steps, you are allowed to ship it via any US carrier without any certification or warning sticker requirements.
And as Sara said, the latest sketches we use (as found in the current ModularSensors examples) synchronizes the clock every time the board is restarted (assuming you’ve got a wifi or cellular connection), so manual setting of the RTC isn’t necessary. Or you can just load a DS3231 adjustment sketch, set your clock, then load your logging sketch. The CR1220 should last 4-5 years under ideal conditions.
-
2020-01-14 at 7:08 PM #13625Thanks for your quick responses! The shipping constraints are good to know; going forward I won’t remove the battery after setting the clock.
I was able to confirm, using PCSync, that my develo
Thanks for your quick responses! The shipping constraints are good to know; going forward I won’t remove the battery after setting the clock.I was able to confirm, using PCSync, that my development mayfly does lose its clock setting with power and coin cell disconnected. No surprise there. And then I disconnected USB power again, then reconnected and uploaded my MMW testing sketch, still with no coin cell installed. The Mayfly connected to NIST via 4G successfully, set its clock, and uploaded data properly to MMW. So, it seems that the clock/battery question is not the cause of Jake’s board not uploading data. Not sure what is though. The UUIDs are all set properly as far as I can see. The Mayfly’s modem (and SIM) were transferred from an operational Mayfly into this newly-programmed board.
Thanks,
Matt
-
2020-01-14 at 10:14 PM #13627
Was anything recorded on the SD card?
-
2020-01-15 at 9:15 AM #13629
Yes
-
2020-01-15 at 9:34 AM #13630
I’ll attach the code here. Thanks, Matt
Attachments:
-
2020-01-15 at 2:54 PM #13640
I didn’t try running it, but there’s nothing that jumps out at me in a very quick glance through the code. Did the SD card have data on it?
-
2020-01-15 at 3:53 PM #13645The SD card did have data. I left the SD card in long enough to complete one measurement. Attached. I then removed the SD card and took it home to look at the data, but left the station running withThe SD card did have data. I left the SD card in long enough to complete one measurement. Attached. I then removed the SD card and took it home to look at the data, but left the station running without an SD card because I didn’t have a backup on me at the time.
Attachments:
-
2020-01-15 at 3:58 PM #13647That’s good to hear. Yep, all looked as expected in the data file on the SD card. It was named with 2000-01-01, so apparently never connected and synced to NIST. I’ll zip and attach the csThat’s good to hear. Yep, all looked as expected in the data file on the SD card. It was named with 2000-01-01, so apparently never connected and synced to NIST. I’ll zip and attach the csv file, in case that illuminates anything. I am noticing that the Mayfly temp has a bad value (-17966.2), which is odd.
-
2020-01-15 at 4:30 PM #13649Oh. Oops.
The data was probably rejected because of the timestamp. The clock resets itself to 2000-01-01T00:00:00 – but then ModularSensors applied a negative offset to it assuming you want
Oh. Oops.The data was probably rejected because of the timestamp. The clock resets itself to 2000-01-01T00:00:00 – but then ModularSensors applied a negative offset to it assuming you wanted the file to be in UTC-6 with an RTC set in UTC. That caused a weird rollover (roll-under?) giving you a timestamp of 2000-01-01 252:211:00. MonitorMW would have rejected that time purely based on syntax (hours and minutes must be two digits). Obviously, the developer of ModularSensors did not do sufficient testing for this scenario. I’m sorry.
-
2020-01-15 at 4:42 PM #13650
I made an issue for myself to fix this: https://github.com/EnviroDIY/ModularSensors/issues/304 Unfortunately, that doesn’t give you back lost data.
-
2020-01-15 at 5:34 PM #13651No problem.
So, to make sure I’m understanding: the funky date issue aside, had the Mayfly connected to the internet successfully, we believe it would have set its clock from NIST and would hav
No problem.So, to make sure I’m understanding: the funky date issue aside, had the Mayfly connected to the internet successfully, we believe it would have set its clock from NIST and would have begun uploading successfully to MMW, right? Testing at my desk, I’m able to take a new, out of the box Mayfly, drop in an XBee3 (with previously registered SIM) on an LTEBee adapter, and no coin cell, and it connects and uploads data.
-
2020-01-15 at 5:37 PM #13652Yes, that’s what it should have done. I don’t see any obvious reason why it wouldn’t have, other than that it clearly didn’t. The single battery measurement was on the lowYes, that’s what it should have done. I don’t see any obvious reason why it wouldn’t have, other than that it clearly didn’t. The single battery measurement was on the low side (only 3.6) so it is possible that your battery just died.
-
2020-01-15 at 6:22 PM #13653Here’s our platformio.ini, which I didn’t post earlier. It’s identical to what works from my desk, so don’t suspect there’s a problem here.1Here’s our platformio.ini, which I didn’t post earlier. It’s identical to what works from my desk, so don’t suspect there’s a problem here.12345678910111213141516171819202122232425262728293031323334353637383940414243444546;PlatformIO Project Configuration File;; Build options: build flags, source filter; Upload options: custom upload port, speed and extra flags; Library options: dependencies, extra library storages; Advanced options: extra scripting;; Please visit documentation for the other options and examples; https://docs.platformio.org/page/projectconf.html[env:mayfly]monitor_speed = 115200board = mayflyplatform = atmelavrframework = arduinolib_ldf_mode = deep+lib_ignore = RTCZerobuild_flags =-DSDI12_EXTERNAL_PCINT-DNEOSWSERIAL_EXTERNAL_PCINT-DMQTT_MAX_PACKET_SIZE=240-DTINY_GSM_RX_BUFFER=64-DTINY_GSM_YIELD_MS=2; additional build_flags for modem debugging:; -DTINY_GSM_DEBUG=Serial; -DMS_LOGGERMODEM_DEBUG; -DMS_LOGGERMODEM_DEBUG_DEEP; -DMS_DIGIXBEE_DEBUG; -DMS_DIGIXBEECELLULARTRANSPARENT_DEBUG; -DMS_DIGIXBEECELLULARTRANSPARENT_DEBUG_DEEP; -DMS_DIGIXBEELTEBYPASS_DEBUG; -DMS_DIGIXBEELTEBYPASS_DEBUG_DEEPlib_deps =EnviroDIY_ModularSensors@0.23.16; ^^ Use this when working from an official release of the library; https://github.com/EnviroDIY/ModularSensors.git#develop; ^^ Use this when if you want to pull from the develop branchStreamDebugger;; The following monitor_flags setting is needed becasue in transparent mode the XBee3; uses CR line endings instead of the more typical CR+LF. This setting enables you; to see all back and forth communication.; (https://www.envirodiy.org/topic/connecting-xbee3-lte-to-the-internet/#post-13312);monitor_flags =; --eol; CR
I guess the next step is to test it while connected to a laptop so that we can capture debug info.
Thanks for your help.
-
2020-01-15 at 6:29 PM #13654
That configuration looks good to me. Let me know if you see any bugs I can smash.
-
-
AuthorPosts
- You must be logged in to reply to this topic.
