[Shannon Hicks]

Sensors with heaters are another big challenge, especially if they run continuously.  Are the heaters powered all the time, or only when taking a sample?   Do they require 12v to operate, or was that spec just listing the power draw at 12v?

You can do some basic battery life calculations on this handy website: https://oregonembedded.com/batterycalc.htm

[Shannon Hicks]

Standard practice is that when the Mayfly board goes to sleep in between measurements, it turns off all power supplied to the sensors and radio module.  So the power consumed when sleeping is just the bare minimum to keep the Mayfly in sleep mode, which is usually a little less than 1 milliamp.  There are ways to make it use even less in sleep mode, but it’s usually not necessary since the overwhelming majority of the power used is during the sensor sampling and radio transmitting time.  Power-hungry sensors with motorized wipers or large current draw, and radios that need long connection times are the most challenging peripherals to use, but 3 soil moisture sensors and an unltrasonic sensor will use very little power when sampling, so they won’t stress a 4400mAh battery at all when matched with a decent solar panel like the 3.5w or 5w panels we usually recommend.  I don’t know what Xbee module you’re using since they make wifi, cellular, and RF modules, but your transmit time and duty cycle will determine the overall power usage.

[Shannon Hicks]

It appears that the Hologram service interruption has been fixed and almost all of the cellular stations on Monitor My Watershed have returned to normal operation.  If any stations don’t rejoin the network by later today, it might require a field visit to cycle the power or possibly replace the battery.

[Shannon Hicks]

I’m not sure what the Mayfly Data Logger Pro is.  Do you mean the program (or sketch) used to configure the board?  If you’re using one of the provided sketches we publish on Github, there’s a couple lines in each sketch that looks like this:

// Logger ID, also becomes the prefix for the name of the data file on SD card const char* LoggerID = "XXXXX";

1 2	// Logger ID, also becomes the prefix for the name of the data file on SD card const char* LoggerID = "XXXXX";

The Logger ID is just an alphanumeric designator that you can use to name your station to help with record-keeping and organization, because the logger ID becomes the prefix for the data file that is written to the Mayfly’s microSD card.   All Mayfly data card files are named using the Logger ID and the date the file was started.  So a Mayfly with the logger ID of “BLUE” would have a file named “BLUE_2023-07-20” if the logger was started today.

If you look through the EnviroDIY Monitoring Station Manual, you’ll see examples and further descriptions of the file operations of the Mayfly.  The manual was originally written for our partners in the DRWI monitoring program, and those stations were all built and programmed by me, and we used an internally-generated logger ID system starting with the letters SL.  Other users are free to choose any name or number they want.

In general, it’s good to put the stream name or some other helpful info in your logger ID (while still keeping it short, and using underscores instead of spaces) because it will make the names of your resulting microSD card datafiles more descriptive.  For example, i might call one “Upstream_JonesCreek”, that way all my data files will begin with that string, because there might be a “Downstream_JonesCreek” station too.  A new data file is created anytime the Mayfly station is rebooted, so if both stations are out collecting data and both get visited today and have their data cards swapped with new blank cards, they will both start recording to data files with today’s date in the filename.  It’s the Logger ID that will make the filenames unique so that when you later copy both of those data files to your PC, they’ll be uniquely named and there won’t be any confusion about where they came from.

Another note, the Logger ID as written in the Arduino sketch of the Mayfly board is not the same as the Site ID of a station on Monitor My Watershed.  That’s a different type of naming convention that is independent of the Mayfly programming.  The string entered for Mayfly Logger ID in your sketch is only used for generating the microSD card filename on the logger.

[Shannon Hicks]

There’s a link to the schematic on the item page along with a link to an example sketch on Github.

[Shannon Hicks]

The CTD sensor you have is a digital output sensor, meaning all of the measurement happens onboard the sensor and it outputs a string of 3 numbers, all the Mayfly logger board is doing is capturing those numbers and storing them.  If there was a problem with the Mayfly board, then you wouldn’t get the numbers at all, and there’s no calibration or conversion needed with those sensors, so the numbers being recorded on the Mayfly memory card are exactly the same numbers that are being sent directly from the sensor.  If the data from the sensor doesn’t match up to your QA/QC measurements, then the sensor is either fouled or broken.  There are a variety of ways those sensors can fail, sometimes it’s pretty obvious, and other times it’s more subtle and you need to look carefully at all the data and compare it to the real-world, hand-held measurements.

Do you have the continuous data file from the logger with all the data from the CTD sensor?  Your excel chart with weekly reading indicates that something started affecting the depth readings in early January, but if you can graph all 3 CTD parameters with the continuous data, you can probably find a specific event that caused the failure.  Being that time of year, it’s likely that either the sensor was subjected to freezing temperatures (which can cause catastrophic failure of one or more of the parameters) or the sensor cable jacket was damaged, which can affect the depth readings by interfering with the sensor’s atmospheric reference (essentially there’s a small air gap through the cable jacket that goes to the goretex vent on the cable end near the logger box that provides the atmospheric compensation).  Or it could be that the sensor is just fouled with something on the pressure disk and needs a thorough cleaning.  Have you removed it from the stream and examined it carefully and also examined the cable jack along the entire 30-foot length, looking for any nicks or cuts or holes?  What depth and conductivity reading do you get on the logger when the sensor is out of the water?

[Shannon Hicks]

Reminder quote from the first post of this thread:   If you’ve got a basic question such as what are the board’s features or how it differs from previous versions, this is the place to ask.  If you’ve got a more complicated question or issue, then it is probably best to start your own thread.  The goal of this thread is to be a great information resource for basic questions about the new v1.1 board that are common to all users.

I’d recommend taking these detailed technical questions to their own specific thread in order to keep this one short and easy for all users to read about the technical differences between the latest Mayfly version and previous ones.

[Shannon Hicks]

The analog reference voltage (AREF) pin of the ATmega1284P is broken out to the left-hand 2×10 header if you wanted to apply a voltage other than (and less than) 3.3v.  If you leave it floating and don’t specify the AREF in your code, then it’ll use the default 10-bit setting for any regular analog reading like you’ll find in most code examples.  If you apply a voltage other than 3.3v to AREF, you’ll need to add code to tell the sketch that you want to use AREF as the reference, plus take that into account for any ADC calculations you make.  So follow examples you might find online for other Arduino boards for using a custom analog reference.  I broke out the AREF to the header in the rare chance that someone would want to use it, but we found that most people are much happier with the increased resolution and sample rate and code flexibility of the aux ADC that I don’t know of anyone actually modifying AREF, but the capability is there on the Mayfly board if you want it.

[Shannon Hicks]

LTEbees should be back in stock later this week in the EnviroDIY shop and in a week or two on Amazon.  The big order we placed from our manufacturer back in March had some production delays but is supposed to be delivered this week.  The RS485 adapter is still not ready for release, the original design relied on the 12v boost circuitry of the Mayfly v1.1, but because there were some issues with the amperage that circuitry can provide to certain sensors, we’ve had to revert to a different design, but those parts are still unavailable from the chip manufacturers. Further extensive testing is needed using a variety of sensors to find the right combination of parts to create a stable and reliable circuit.

[Shannon Hicks]

The Bee socket of the Mayfly board isn’t powered continuously by default, so in your code examples above, it appears that you’re not turning them on.  If you study the schematic for whichever hardware version of the Mayfly you have, you’ll see that you either have to activate the power to the bee socket’s regulator by setting Mayfly pin D18 high in your code, or modify the Mayfly solder jumper SJ18 from the default D18 position to the 3.3v position for continuous power (there’s instructions for that on the Mayfly Jumper Settings page).

You can also close SJ16 so you’ll see a white LED on the Mayfly whenever the bee socket is powered, and you can close SJ17 to see a blue LED that indicates bee network status (if you’ve configured your xbee modules to show network status on the bee IO5).

[Author]

Posts