[Anthony Aufdenkampe]

@james-dareboprc-govt-nz, those power issues you came across on GitHub (regarding getting the brush to spin and wondering about setting the spin rate) were quite old (2017?) when we first started using YosemiTech sensors and early in my knowledge of DIY electronics. The short-story is that once we figured out that we needed to add a capacitor (i.e. powering a device wasn’t just about voltage), then we had no problems.

I strongly urge you to get the Y511 turbidity sensor with the auto-brush/wiper. Otherwise you will be seeing sensor drift within a week or so (depending on the season) and will need to manually clean your sensor. The extra US$150 is definitely worth it. More details here: https://www.envirodiy.org/topic/problems-with-obs3/#post-15556

I like your solution for testing the RS-485 adapter boards from China before soldering them onto a Mayfly-Modbus-Wing.

By the way, when I have found a RS-485 adapter board that doesn’t work, I have solved the issue 14 out of 15 times by soldering on a 120 ohm resistor (1/4 W) directly to the A+ and B- terminals on the RS-485 adapter, as I showed and described here: https://github.com/EnviroDIY/SensorModbusMaster/issues/14#issuecomment-678554101

 

[Anthony Aufdenkampe]

James, I’m glad to see that you’re using our DIY Mayfly-Modbus-Wing. Yes, soldering the DIY windshield is required. I had thought you were discussing soldering an RS485 adapter directly to the Mayfly. My bad for misunderstanding!

From my perspective, there is not “problem” with the YosemiTech Y511 turbidity brush running every time the sensor wakes up to take a measurement. You might have read of some issues back in 2017, but since we massively improved power management shortly after that (via ModularSensors improvements), we have had no power problems.

[Anthony Aufdenkampe]

James, I really like all the YosemiTech sensors I’ve used, and I’ve facilitated the purchase of approximately ~150 or more for various organizations. The Y511 turbidity sensor with wiper is the most common we use, and everyone is very satisfied with it.

I’ve been working with a water utility, and after doing a careful comparison with their other commercial sensors, they decided to purchase an additional 60 sensors for YosemiTech.

To answer your specific questions:

1. Yes, YosemiTech sensors have equivalent  data quality to the major brands of commercial water quality sensors.
2. Get the sensor with the wiper, always for long-term deployment. I would only get the one without a wiper if I were building “hand meter” sensor system for spot checking.
3. The Modular Sensors code on the Mayfly turn off power to sensors between measurement intervals (to save power). The YosemiTech sensors with wipers all spin the wiper each time it is powered on, and I suspect the YSI does the same. You can reconfigure the wiring and the code to do this differently if you want. Brushes definitely require more power, but it is very important to do regularly. That said, I have no problem deploying a YosemiTech turbidity sensor with a 2 W solar panel and a 4400 mAh battery and taking measurements every 15 minutes.
4. The DIY Modbus-Mayfly_WingShield costs about US$ 35 in parts and ~1 hour to solder together. The new manufacturable version by @neilh20 costs a bit more than that but no labor (see https://www.envirodiy.org/topic/testing-ttl-rs485-adapters/#post-15553).

[Anthony Aufdenkampe]

James, by the way, I would suggest that you NOT solder anything to the wing headers. Our two options just plug into them and can be removed anytime, just like an Arduino shield.

[Anthony Aufdenkampe]

James, we’ve been playing with hardware designed for this for quite some time (as a subfolder in our SensorModbusMaster repo), and just recently spun our commits/designs into it’s own Mayfly-Modbus-Wing repo. Have you seen this?

Our solder-your own DIY version is described here: https://github.com/EnviroDIY/Mayfly-Modbus-Wing/tree/master/Modbus-Mayfly_WingShield

Meanwhile, @neilh20 designed a much improved manufacturable variant that we’re getting made now. It’s shown below and described here:
https://github.com/EnviroDIY/Mayfly-Modbus-Wing/tree/master/knh002-MayflyWingShield.

We have some work to do on improving documentation, but hopefully this will all be helpful.

Attachments:

1. 

   KNH002rev7picTopcrop.jpg
   

[Anthony Aufdenkampe]

Hi All,

Good news! We completed the fix to issue #3 “Sparkline” plots and CSV downloads not functioning.

As expected, most of the data that looked to be missing is now showing up in the “Sparkline” plots, in the data table views, and in the CSV downloads.

One disappointing discovery is that the #2 Networking (Domain Name System) issues lasted longer than we had thought. It looks like hours-long chunks of of data were lost from May 5 to May 12. You can see these gaps as straight lines here: https://monitormywatershed.org/tsa/?sitecode=WCC019&variablecode=Decagon_CTD-10_Depth&view=visualization&plot=true (zoom into May 3-15 to see).

If you really need this data, remember that it should be stored in CSV files on your device’s SD card. If you retrieve that data,  you can upload it to the Monitor My Watershed web portal to fill in the blanks.

[Anthony Aufdenkampe]

@mbarney & @neilh20, the CSV downloads are not an effective way of accessing data gaps, because that mechanism relies on the same corrupted catalog crosswalk that underlies the problem with the sparkline plots.

There are really only two ways for you to assess data gaps:

• Keep a record of server response codes from RESTful POST requests, from your device or from a program/script that uses a correctly formatted JSON payload with all the correct tokens.
• Fetch the data using WOFpy REST service (https://monitormywatershed.org/wofpy/), which currently only responds with one value, so you need a script that will integrate through all time intervals.

[Anthony Aufdenkampe]

Hi All,

Our apologies for the several sets of bugs on the Monitor My Watershed / EnviroDIY / ODM2DataSharingPortal.

The short story is we have had 3 sets of issues in the last two weeks:

1.  Browse window not mapping sites or populating filter pane #496
   • Fixed! No loss of data.
2. Networking (Domain Name System) issues
   • Fixed!
   • Hours of data were unfortunately lost May 5-7, unfortunately.
3. “Sparkline” plots and CSV downloads not functioning
   • Ongoing
   • No data are being lost. All data will “come back” when we fix it.
   • The cause was related to #1 and maybe #2
   • Issue is caused by a corrupted catalog crosswalk (similar to what happened previously with Data isn’t appearing in sparklines or TSA – but only for some parameters #436)
     1. We know how to do the short term bandaid fix, and it takes a good bit of processing resources/time and needs to be monitored. Unfortunately, we didn’t find a window this week to do it. We will prioritize it for early next week.
     2. The long term fix requires a big architectural overhaul, which we have mapped out but are seeking funding before we start. For an idea of what is required, see our Release 0.12 – Tech Debt updates and  and Release 0.13 – Refactor code for performance & scalability Milestones.

Thank you for your patience with these issues. We’re very excited to overhaul the system and are getting closer to pulling together sufficient funds.

[Anthony Aufdenkampe]

Shannon, thanks for those additional details!!!

Matt, from what I read in Shannon’s description, keeping the address set to ‘0’ might result in you only taking 1 measurement for averaging, even if you asked for 6.

[Anthony Aufdenkampe]

Matt, my understanding is that the warning to not use address “0” came from a Meter/Decagon integration manual and from real-world experience. If I’m not mistaken, some sensor manufacturers reserve the “0” address for all sensors to use all the time, even when their address has been changed. This allows for a back-door to poll a line for all the connected sensors to find out the status of what’s connected. When manufacturers do this, they often disable sending data from that address. This is also the case for some Modbus implementations.

I think Meter has implemented this convention for some but not all of their sensors. I can’t remember which. Also, since Meter has purchased Decagon, we’ve seen them slowly modify their SDI-12 protocols with firmware updates, sometimes silently.

Sara & Shannon can likely provide more detail. Alternately, you could call Decagon/Meter. They are a small company and would likely connect you to an engineer relatively quickly.

[Author]

Posts