[Sara Damiano]

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 out data and you don’t explicitly stop listening and turn off those interrupts, your board will be immediately woken up by the sonar. I’m sorry. If I’d just thought a little harder I could have figured that out without seeing any code. Anyway, if you want to use your code mostly as-is and keep the sonar on all the time, remove the sonarSerial.begin(9600); from your setup and make it the first line of your readSonar() function. Then add sonarSerial.end(); just before the return of that same function. Doing that should prevent the interrupts from keeping the board awake any time except within that function.

I don’t think leaving the sonar continuously powered like that will help it to stay fog-free unless it actually is a “self-cleaning” module. The 7389 isn’t. Have you actually seen it make any difference? I don’t think we’ve ever even tried.

You’re not using ModularSensors, but for anyone who might be and notices the keep-awake issue with a MaxBotix, I created an issue for it here: https://github.com/EnviroDIY/ModularSensors/issues/303

[Sara Damiano]

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 reading. Usually the thing too close to the sonar is condensation on the sonar itself. You’re probably seeing it a lot more in the winter because of the difference in temperature between the sonar/Mayfly box and the outside air. Having the sonar in a pipe over the water might make it even worse. It’s also possible that the sensor is just dirty, but if it’s alternating between blanking distance and good values, it’s probably condensation. In most of our newer code I re-read the sonar up to 25 times if it’s reporting 300/500, but if there’s really too much condensation on the sensor there’s nothing any code can do to change it. I’m pretty sure the “self-cleaning” feature available on some of the MaxBotix models is a heater to prevent condensation.

I also strongly recommend switching from the Arduino IDE to PlatformIO. Library management is much easier in PlatformIO – you can keep set up different groups of libraries for each program and not worry about an old sketch breaking because you updated the libraries to use in a different sketch. I know VSCode and PlatformIO can seem a lot scarier up-front, but I promise it’s easier to use in the long run!

[Sara Damiano]

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.

[Sara Damiano]

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. You could just as easily grab the level value in the same call as the date and time or get the sec/min/hr/etc each in individual calls. It takes less time (the actually communication time between the Mayfly and the ISCO) to make one request for many registers than to make multiple calls for single registers, but the code might be easier (for a person) to follow if you request each result separately. The maximum number of registers you can get in a single call is 125.

You could hack the variables from the Signature into ModularSensors by calling them “calculated” variables where the “calculation” is actually to interrogate the Signature for current values. You’d have to make sure that “calculation” includes the code to power up your RS485 adapter if you’re powering it from the Mayfly because the calculations are all run after all normal sensors are finished and put to sleep.

If you want to really treat the Signature properly as a sensor, you should create a new sensor within ModularSensors. You might want to base it on either one of the Keller or Yosemitech sensors – they also use modbus. If you want to go that way, I can look it over and give some pointers and review, but I probably won’t be able to write it up for you anytime soon.

[Sara Damiano]

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 modify the metadata tied to a variable result without changing the UUID.

[Sara Damiano]

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 Arduino library folder (likely documents/Arduino/libraries), do you see only one folder for each library. If you see multiple folders with the same names, (ie, EnableInterrupt and EnableInterrupt (2) ) then you do have multiple copies of libraries and must remove the extras. If you have not done any modification of you libraries and you haven’t programmed other boards in a way that you need to be able to reproduce exactly, I would start fresh by deleting everything in your Arduino/libraries folder and reinstalling them all following the directions I linked above. If you’ve modified any other library or you have other programs depending on the exact versions of your installed libraries, you’re going to have to manually go through them and delete the conflicting versions and install anything missing. All of the dependencies for ModularSensors are listed here: https://github.com/EnviroDIY/ModularSensors/wiki/Library-Dependencies (and of course ModularSensors itself is required).

This difficult in managing libraries is the primary reason I would never recommend the Arduino IDE. PlatformIO makes this management much easier, even though it might seem scarier to beginners at the start.

[Sara Damiano]

Okay, this should get you pretty far.

C++

#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 function // This is in addition to any other setup you need for a timer, sleep, // and modem communication or anything else you might be doing. setup() { // Start the stream modbusSerial.begin(baudRate); // start the modbus instance // modbusSlaveID = Signature's device address as programmed in Modbus Output Setup (2.6.4) modbus.begin(modbusSlaveID, modbusSerial); // If you want the Signature to automatically update its readings every 5 minutes, // you could do something like this: // 40025 = TakeReadingFlag - Set to 1 to update readings, 2 for automatic update (SRGD: 0 for no update?) modbus.uint16ToRegister(40025, 2); // 40026 = UpdateIntervalWordSeconds - The reading update interval in seconds // 300 seconds = 5 minutes modbus.uint16ToRegister(40026, 300); } // loop function // again, this is in addtion to other timing, sleep, and communication you need loop() { // Get current level status // The manual doesn't actually specify clearly, but I'm assuming the map is to holding registers (0x03) // 40042 = Levelstatus - The level status - non-zero is an error // Since anything non-zero is error, we'll just man-handle this into a boolean bool levelStatus = !modbus.uint16FromRegister(0x03, 40042) // Should we bother getting values if there's an error? if (levelStatus) { // Ask what time the last level reading was from: // we'll get all the registers at once // 40043 - 48 = Leveltime - The last level reading time,sec-min-hour-day-month-year bool gotDateTime = modbus.getRegisters(0x03, 40043, 6) if (gotDateTime) { uint16_t sec = modbus.uint16FromFrame(0); uint16_t min = modbus.uint16FromFrame(2); uint16_t hour = modbus.uint16FromFrame(4); uint16_t day = modbus.uint16FromFrame(6); uint16_t month = modbus.uint16FromFrame(8); uint16_t year = modbus.uint16FromFrame(10); } // Ask for the value // Note: we could get this in the same call as the time if we canted // 40040 - 40041 = Level float level = modbus.float32FromRegister(0x03, 40040); } // wait 5 mintues for the next reading }

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

#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 function // This is in addition to any other setup you need for a timer, sleep, // and modem communication or anything else you might be doing. setup() {     // Start the stream     modbusSerial.begin(baudRate);       // start the modbus instance     // modbusSlaveID = Signature's device address as programmed in Modbus Output Setup (2.6.4)     modbus.begin(modbusSlaveID, modbusSerial);       // If you want the Signature to automatically update its readings every 5 minutes,     // you could do something like this:     // 40025 = TakeReadingFlag - Set to 1 to update readings, 2 for automatic update (SRGD: 0 for no update?)     modbus.uint16ToRegister(40025, 2);     // 40026 = UpdateIntervalWordSeconds - The reading update interval in seconds     // 300 seconds = 5 minutes     modbus.uint16ToRegister(40026, 300); }   // loop function // again, this is in addtion to other timing, sleep, and communication you need loop() {     // Get current level status     // The manual doesn't actually specify clearly, but I'm assuming the map is to holding registers (0x03)     // 40042 = Levelstatus - The level status - non-zero is an error     // Since anything non-zero is error, we'll just man-handle this into a boolean     bool levelStatus = !modbus.uint16FromRegister(0x03, 40042)       // Should we bother getting values if there's an error?     if (levelStatus) {         // Ask what time the last level reading was from:         // we'll get all the registers at once         // 40043 - 48 = Leveltime - The last level reading time,sec-min-hour-day-month-year         bool gotDateTime = modbus.getRegisters(0x03, 40043, 6)         if (gotDateTime) {             uint16_t sec = modbus.uint16FromFrame(0);             uint16_t min = modbus.uint16FromFrame(2);             uint16_t hour = modbus.uint16FromFrame(4);             uint16_t day = modbus.uint16FromFrame(6);             uint16_t month = modbus.uint16FromFrame(8);             uint16_t year = modbus.uint16FromFrame(10);         }         // Ask for the value         // Note: we could get this in the same call as the time if we canted         // 40040 - 40041 = Level         float level = modbus.float32FromRegister(0x03, 40040);     }       // wait 5 mintues for the next reading }

[Sara Damiano]

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 looks like it would be relatively straightforward.

Based on my read of the manual, here’s what I’d do:

Don’t bother with the wing thing. It’s really nice if you’re going to power the your RS485 sensor through the Mayfly and connect to multiple RS485 devices, but since the Signature needs way more power than the Mayfly can provide and you haven’t mentioned any other RS485 gadgets, you’re not getting anything out of using it. The wing board also limits you to AltSoftSerial which may or may not work. Just use an RS485 adapter by itself. Do get one that uses 3.3V logic with automatic flow control.

You need to set up the Signature to use Modbus output following 2.6.4 in the manual. Pick any device ID, just be sure to make note of it. Pick ‘RTU’ protocol type; 2400 bps (Mayfly is too slow to use 115200); 8 data bits; ‘none’ parity; 1 stop bit. Power cycle the Signature to make sure the settings take effect.

Connect the Signature’s DO- to A-; DO+ to B+; and ground to ground on the RS485 adapter.

Connect the RS485 adapter to power and ground on the Mayfly. Also connect data out of the RS485 adapter to Mayfly pin 6 and data in to pin 5. I’ve gotten adapters with Tx and Rx labeled differently so if you get no communication, try flipping them.

Program your Mayfly using AltSoftSerial (https://www.pjrc.com/teensy/td_libs_AltSoftSerial.html) and SensorModbusMaster (https://github.com/EnviroDIY/SensorModbusMaster). AltSoftSerial says that it can be used stably at 2400 baud, but I’ve never tested it at that low a speed on the Mayfly. Be prepared to test and switch to using HardwareSerial if communication isn’t stable enough and values get garbled. If you need to use HardwareSerial to talk to the Signature and you still want to use the XBee slot to for external communication you can cut both sides of SJ8 and SJ9 on the Mayfly to disconnect the XBee slot from Serial1 and run jumper wire on the back of the Mayfly to connect pin 6 to pin 2 of the XBee slot and pin 5 to pin 3.

I’ll upload a code snippet for you in a bit. I’d had something all typed out and then clicked away and it disappeared on me.

[Sara Damiano]

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 existing variable on MonitorMW to select different units, the label will change but the values will not. By “calculated variable” MonitorMW means “someone else calculated this and posted the results” not “this was calculated by MonitorMW.”

You *can* create a calculated variable in ModularSensors where you give the equation that will convert C to F or mm to inches and then report that calculated value to MonitorMW. In that case, when you’re creating the variable on MonitorMW you would select your sensor make/model in the same way you normally would, but then select the alternate units (ie, F or inches, which I will add shortly).

[Sara Damiano]

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.

I hate having to use the eTree library. I find trying to navigate through layers of XML to be approximately 0% fun.

[Author]

Posts