@ensign
Active 1 months, 3 weeks agoForum Replies Created
-
AuthorPosts
-
2023-12-01 at 12:19 PM in reply to: Changes coming January 1, 2024 for Monitor My Watershed users #18202
@w3asa – Thanks for sharing your thoughts on our subscription plan pricing structure. We arrived at this pricing structure after exploring all the options for most equitably distributing costs across the diverse community of users and organizations. We hope users appreciate the extra value that Monitor My Watershed provides in comparison to other for-profit commercial services. We value your participation in growing one of the largest environmental datasets in the world collected and shared using open source hardware and software!
2023-12-01 at 12:00 PM in reply to: Changes coming January 1, 2024 for Monitor My Watershed users #18201@juleschultz – We certainly understand how valuable it is for Monitor My Watershed users to share their data on their own websites. While there isn’t a direct way to share Monitor My Watershed webpages, there are several ways to automate the data download process for reprocessing and posting your data in a separate service. First, you can retrieve a csv file of all of a parameter’s data by copying the url from that sensor’s observations page. Look for the cloud download button; the url will look like this (with a different result_id):
https://monitormywatershed.org/api/csv-values/?result_id=5081
There are more sophisticated methods for retrieving data using Monitor my Watershed’s Time Series Analyst endpoint. If you use Python, check out Sara Damiano’s GitHub Gist notebook for instructions.
To share a link on your website to all of your organization’s sites use this link:
https://monitormywatershed.org/browse/?organizations=Spokane%20Riverkeeper
Modify this link for other use with other organizations using the release notes on GitHub.
2023-04-13 at 11:21 AM in reply to: MMW last-reported observation not updating after site update #17732@millerlp: are you seeing current data now? We are aware of the issue but it should be resolved now. If you are still seeing issues can you report them to help@monitormywatershed.org?
On a Mayfly V1.0 Rev A3, is power to the 2X10 analog header controlled by pin 22 or is the header constantly powered? I’m trying to utilize power from the 2X10 analog header while the grove ports are not powered (pin 22 is low) if this is possible.
@wcb_data: you can access csv formatted data for a parameter at a site by specifying the parameter ID. For example, I can retrieve all of the specific conductivity data for site https://monitormywatershed.org/sites/CR_UTFZ/ with this url: https://monitormywatershed.org/api/csv-values/?result_id=5081
You can grab this url for any parameter at a given site by right clicking the download button (see attached screenshot).
Alternatively, you can access all data for a given site; here’s an example for the site used earlier:
https://monitormywatershed.org/api/csv-values/?result_ids=5081,5082,5084,5085,5088,5089,5091,5093
The url is available by right clicking the “Download Sensor Data” button at the top of the “Sensor Observations at this Site” section (see attached screenshot).
Attachments:
Given the popularity, complexity, and expense of turbidity sensors, the team here at the Stroud Center has compiled a snapshot of some commercially-available options that may help people decide on the best option. This table likely excludes many vendors and models, and it only summarizes sensors that we have recently used or investigated. In addition to these commercially-available options, you might consider do-it-yourself options like OpenOBS, a well-document project on Github with a peer-reviewed background. Another open-source DIY turbidity sensor is described by Droujko and Molnar 2022 in Nature, Scientific Reports.
- Campbell Scientific Clari-Vue (recently replaced the OBS3)
- no wiper
- pre-calibrated
- SDI-12 at 5V
- 9.6-18V (nominally 12V)
- compatible with Mayfly version 1.1 (or any Mayfly version with an interface board with separate 12V supply)
- compatible with Modular Sensors
- $$ on a scale of $ (<$1000), $$ ($1000 – $2000), and $$$ (>$2000)
- Yosemitech Y511-A
- includes wiper (the Yosemitech Y510-B does not include a wiper)
- pre-calibrated
- Modbus over RS485
- 5-12V (nominally 12V)
- compatible with Mayfly version 1.1 with EnviroDIY RS485 adapter (or any Mayfly with both separate 12V power supply and RS485 adapter)
- compatible with Modular Sensors library
- $
- Turner Designs Turbidity Plus
- available with and without wiper
- not pre-calibrated
- analog voltage communication
- 3-15V
- compatible with Mayfly version 1.1 with multi-purpose 6 pin screw terminal grove adapter (or any Mayfly with a voltage divider with separate 12V power supply)
- not compatible with Modular Sensors library
- $$
- Turner Designs Cyclops 7
- no wiper, but has an optional cap to protect the sensor window
- not pre-calibrated
- analog voltage communication
- 3-15V
- compatible with any Mayfly version with multi-purpose 6 pin screw terminal grove adapter
- compatible with Modular Sensors library
- $$
- Analite NEP-5000
- includes wiper
- pre-calibrated
- SDI-12 or Modbus over RS485 or analog communication
- 8-30V
- compatible with Mayfly version 1.1 (additional adapters required depending on communication protocol used)
- not compatible with Modular Sensors library
- $$$
Thanks to everyone that contributed to our Survey regarding Monitor My Watershed. We are summarizing the results to inform our future efforts.
Jake, I deleted a “test” site of mine last week in MMW and it worked as expected (no error).
Problem solved. As Sara has noted before, the AltSoftSerial can only use pin 6 on the Mayfly for receiving and pin 5 for transmitting. So, while the sketch worked with Software Serial as shown above (and would have worked by defining pin 6 for transmitting and pin 5 for receiving), my pairing of the sensor rx and tx wires to the Grove jack was wrong. See lines 17 and 18 above; I swapped the wiring from the sensor to the Grove jack and now get data from the sensor. This is what the portion of the sketch in question should look like to work with AltSoftSerial:
12345678* white wire from RGB sensor to yellow Grove wire to D5 on Mayfly Grove connection* green wire from RGB sensor to white Grove wire to D6 on Mayfly Grove connection* ======================================================================= *///#include <SoftwareSerial.h> //include the SoftwareSerial library#include <AltSoftSerial.h> //this is the alternative to SoftwareSerial#define rx 6 //define Mayfly pin 6 as the receive pin#define tx 5 //define Mayfly pin 5 as the transmit pinI’m struggling to use AltSoftSerial in place of Software Serial to connect an Atlas-Scientific Color sensor to a Mayfly. The script below successfully communicates and reports sensor data as expected with Software Serial (with lines 21 and 26 active instead of lines 22 and 27 as shown below). As shown below I don’t get any data from the sensor. Any advice?
1234567891011121314151617181920212223242526272829303132333435363738394041424344454647484950515253545556575859606162636465/** =========================================================================* RGBsensorAutoMode.ino* Example of using the Atlas Scientific RGB sensor modified from* code provided by Atlas Scientific:* https://atlas-scientific.com/probes/ezo-rgb-embedded-color-sensor/** author: Scott Ensign <ensign@stroudcenter.org>* Build Environment: Arduino IDE* Hardware Platform: EnviroDIY Mayfly Arduino Datalogger V0.5** DISCLAIMER:* THIS CODE IS PROVIDED "AS IS" - NO WARRANTY IS GIVEN.** The wiring from the RGB sensor was spliced to a Grove cable as follows:* black wire from RGB sensor to black Grove wire to grd on Mayfly Grove connection* red wire from RGB sensor to red Grove wire to V on Mayfly Grove connection* white wire from RGB sensor to white Grove wire to D6 on Mayfly Grove connection* green wire from RGB sensor to yellow Grove wire to D5 on Mayfly Grove connection* ======================================================================= *///#include <SoftwareSerial.h> //include the SoftwareSerial library#include <AltSoftSerial.h> //this is the alternative to SoftwareSerial#define rx 5 //define Mayfly pin 5 as the receive pin#define tx 6 //define Mayfly pin 6 as the transmit pin//SoftwareSerial RGBserial(rx, tx); //define how the software serial port is going to workAltSoftSerial RGBserial(rx, tx); //this is the alternative to SoftwareSerialvoid setup() { //set up the hardwareSerial.begin(9600); //set baud rate for the hardware serial port_0 to 9600RGBserial.begin(9600); //set baud rate for the software serial port to 9600pinMode(22, OUTPUT); //On the Mayfly Data Logger, pin 22 supplies power to the Grove portsdigitalWrite(22, LOW);}void loop() { //digitalWrite(22, HIGH); //turn on power to the Mayfly's Grove portsdelay(500); //wait 500 millisecondsRGBserial.readStringUntil("\r"); //holds for 1 second; this and the subsequent two commands remove the introductory returns from the RGB sensorRGBserial.readStringUntil("\r"); //holds for 1 secondRGBserial.readStringUntil("\r"); //holds for 1 secondRGBserial.print('R'); //send that string to the Atlas Scientific productRGBserial.print('\r'); //add a <CR> to the end of the stringdelay(500); //wait 500 millisecondsint red = RGBserial.parseInt(); //myserial.parseFloat is an alternative, but unnecessary hereint green = RGBserial.parseInt();int blue = RGBserial.parseInt();int lux = RGBserial.parseInt();while (RGBserial.available() > 0) { // this gets ride of the "*OK" or anything else trailing at the endRGBserial.read();}Serial.print("Red: "); // print "Red: " to the serial monitorSerial.println(red); // print the red value from the sensorSerial.print("Green: "); // ...Serial.println(green);Serial.print("Blue: ");Serial.println(blue);Serial.print("Lux: ");Serial.println(lux);delay(1000); // wait ___ milliseconds; adjust this value to set the sampling interval for the sensor} -
AuthorPosts