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.

Viewing 15 reply threads

Author

Posts

2020-01-14 at 6:09 PM #13622
Matt Barney
Participant
I 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 #13623
Sara Damiano
Moderator
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 #13624
Shannon Hicks
Moderator
There’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 #13625
Matt Barney
Participant
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
Sara Damiano
Moderator
Was anything recorded on the SD card?
2020-01-15 at 9:15 AM #13629
Matt Barney
Participant
Yes
2020-01-15 at 9:34 AM #13630
Matt Barney
Participant
I’ll attach the code here. Thanks, Matt
Attachments:
1. BearCT.zip
2020-01-15 at 2:54 PM #13640
Sara Damiano
Moderator
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 #13645
Jake Lemon
Participant
The 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:
1. BearCT_2000-01-01.csv
2020-01-15 at 3:58 PM #13647
Matt Barney
Participant
That’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 #13649
Sara Damiano
Moderator
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
Sara Damiano
Moderator
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 #13651
Matt Barney
Participant
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 #13652
Sara Damiano
Moderator
Yes, 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 #13653

Matt Barney

Participant

Here’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.

;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 = 115200
board = mayfly
platform = atmelavr
framework = arduino
lib_ldf_mode = deep+
lib_ignore = RTCZero
build_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_DEEP
lib_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 branch
    StreamDebugger
;
;  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

;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 = 115200

board = mayfly

platform = atmelavr

framework = arduino

lib_ldf_mode = deep+

lib_ignore = RTCZero

build_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_DEEP

lib_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 branch

StreamDebugger

;

; 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
Sara Damiano
Moderator
That configuration looks good to me. Let me know if you see any bugs I can smash.

Author

Posts

Viewing 15 reply threads

You must be logged in to reply to this topic.

Attachments:

Attachments: