Sara Damiano

I was feeling cocky after the LTC1480 worked and pulled out the Max485 and level shifters. Zero success with communication, but I didn’t have any problems with the program crashing.

Ok, I broke out the 3.3V RS485 chip I have (an LTC1480) from the “someday I’ll test this” box. I’d bought the chip ages ago to try out in place of the (5V) MAX485 that I couldn’t ever get to work. But since the automatic flow control always worked nicely, I threw the LT1480 onto a shelf unopened.

Anyway, it worked for me. I made some very…[Read more]

Also, I’m really surprised you couldn’t find an adapter with automatic flow control. Where were you looking? There are a bunch on Amazon. This is one brand I’ve bought: https://www.amazon.com/SMAKN%C2%AE-Adapter-Serial-Converter-Module/dp/B010723BCE

I have never gotten the communication to work correctly using manual flow control, but it should not be causing your board to restart. I’ll look into it.

When using manual flow control, you have to set the direction pin high or low to change directions. The library does this, but I think there is a timing issue or something because my attempts at…[Read more]

Well, actually, I forgot about the internal data filter. Leaving the sensor always powered will give time for that to come into play. I don’t know if it will help any, though.

Some thing else I thought about in your code: Even though you’re delaying for a second between calls to the SonarRead() function, you were actually parsing and keeping…[Read more]

I put your code into a “code snippet” to make it easier to read.

You’re listening to the sonar via SoftwareSerial. SoftwareSerial works by means of pin change interrupts. Pin change interrupts wake the board up. While the sonar is powered, it will continuously send out data. So if your sonar is continuously powered and continuously sending…[Read more]

Can you post your code? I can’t help much with the sleeping issue without seeing your code.

The issue with getting those 300mm values back from the sonar is an issue with the sensor/installation itself not the code. The sonar will report its blanking distance (300 or 500 depending on the model) anytime something is too close to it to get a real…[Read more]

Oops, I was just looking over again the code I gave you and realized there’s a mistake in line 41. The levelStatus should be the inverse of the modbus result since 0 is good. (bool levelStatus = !modbus.uint16FromRegister(0x03, 40042)) I corrected it above.

You should be able to copy that chunk of code and apply it to any variable you’re interested in. You can even grab multiple variables in the same query. In the example I typed up I grabbed all six registers for the date/time at once (with the getRegisters call) and then used the uint16FromFrame function to separate them into the component parts.…[Read more]

Correct.

The sequence of variables (and the order of the plots) is fixed.

When you delete a variable result, it’s gone forever. Any data you attempt to add to that result time series will disappear into the ether. Creating a new variable result generates a new UUID; you would have to reprogram your Mayfly to know about the change.

You can…[Read more]

It looks like you’re using the Arduino IDE. Managing multiple libraries for the Arduino IDE is NOT easy – it is quite a hassle. Have you installed all the libraries following the instructions here: https://github.com/EnviroDIY/Libraries#installing-libraries-in-the-arduinocc-ide? Have installed them more than one time? When you open your…[Read more]

Okay, this should get you pretty far.

#include <Arduino.h>
#include <AltSoftSerial.h>
#include <SensorModbusMaster.h>


// Create the stream instance
AltSoftSerial modbusSerial;
// OR, if AltSoftSerial isn't working consistently enough
// HardwareSerial modbusSerial = Serial1;

// Create the modbus instance
modbusMaster modbus;

// Setup…

[Read more]

I’ve only ever used a much older ISCO automated sampler and that only using its internal programming. This is something new to me; I’m skimming your manual. The Signature itself is obviously more powerful than the Mayfly. Are you just looking to use the Mayfly to report live data in order to avoid buying the ISCO supplied modem? Doing that…[Read more]

I’m sorryfor the confusion. The unit selected on MonitorMW should be the unit you are sending data in. The MonitorMW data portal never does any calcu lation of any type on the posted data, including unit conversions. If you select different units from those units sent in your post request, the website will simply be wrong. If you modify an…[Read more]

I don’t think you should have to be messing with eTree if you’re using ulmo. There’s a get_values function that returns a simple python dictionary: https://ulmo.readthedocs.io/en/latest/api.html#ulmo.cuahsi.wof.get_values The WSDL URL is https://monitormywatershed.org/wofpy/soap/cuahsi_1_1/.wsdl.

Have you found the ulmo library: https://github.com/ulmo-dev/ulmo It can parse the WaterML.

I believe it’s what Model My Watersehd and other tools we have are using. I haven’t actually used it myself, so I can’t help with it more than giving you the link.

There are some bugs with WOFpy right now; I think some had been fixed, but I don’t remember the current state. I know that even when it is working large data queries tend to crash browsers.

https://github.com/ODM2/ODM2DataSharingPortal/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+wofpy

Just a note on sending to ThingSpeak: there’s no free tier for anything but “personal use.” If you set your MathWorks/MatLab/ThingSpeak account up as anything else (even non-profit/educational) you only get 30 days free and have to pay beyond that, no matter how low your usage is.

If a new csv is being created, it’s almost certainly because the logger is restarting. It could be some irregularity in the power that’s causing the board to restart directly or it’s the watchdog. If you’re not specifically setting the file name, whenever the board attempts to talk to the SD card, it puts together the logger ID and the date and…[Read more]