[fisherba]

What’s your enclosure? Is there a chance it’s blocking signal? There are probably apps for checking cell signal strength and direction.

The Maximus just connect straight to our Bee radios and sits inside a plastic enclosure (Pelican and Polycase).

[fisherba]

We’ve had great improvement with the Maximus FXUB66.

https://www.digikey.com/product-detail/en/taoglas-limited/FXUB66.07.0150C/931-1202-ND/3724559

[fisherba]

@srgdamiano, does this mean that
https://github.com/vshymanskyy/StreamDebugger.git
is no longer needed in the lib_deps?
(In other words, is Stream Debugger now in Modular Sensors?)

[fisherba]

Are your UUIDs all correct? If you are not sending a parameter, such as modem status, it still needs to have a full string in the “shape” of a UUID.

…first guess without more information…

[fisherba]

For each supported sensor in the Modular Library there’s an extensive wiki. I haven’t used that sensor, but the OBS3+ wiki (https://github.com/EnviroDIY/ModularSensors/wiki/Campbell-OBS3) says that it’s an analog communication and here are the wire color details:
“The power supply is connected to the red wire, low range output comes from the blue wire, high range output comes from the white wire, and the black, green, and silver/unshielded wires should all be connected to ground.”

So this basically means that the low range goes to one analog pin and the high goes to to another analog pin, such as AA0 and AA1 on the Mayfly. I assume there’s a place in your sketch to define which pin is low and which is high. Then red is voltage and the other three all connect to the ground. You could do this through a Grove port (with a 4-screw terminal), or the analog header rail.

[fisherba]

Hi Cesar,

We (mostly me and @aufdenkampe, I think) have been purchasing them directly from Yosemitech because they are so darn cost-effective without compromising quality. Currently they are subject to the new 25% “Trump Tariff,” but they are still proving to be cost effective. Note that to use these sensors, the Mayfly needs a “wing” to boost power and translate modbus communication. The most current documentation is here: https://github.com/EnviroDIY/SensorModbusMaster/tree/master/hardware/Modbus-Mayfly_WingShield (with a little extra background and links here: https://github.com/EnviroDIY/SensorModbusMaster/tree/master/hardware).

Yosemitech is a small company and has been good to work with. They make sensors when you order/pay, so the turn-around time, with shipping and the inevitable hang up in US customs, takes ~2 months to receive sensors. We are trying to work with them on how they declare and describe the sensors to smooth the ride through customs. The purchasing process is a little tricky because they don’t take credit cards (we usually wire transfer). They also have a warranty/maintenance situation that we basically cannot maintain by purchasing them for use in the US (last I checked).

The process is involved, so I’m all ears for alternatives, and will be watching this thread.

Beth

[fisherba]

Sounds like Modular Sensors Library? The original versions had 2 minute readings scheduled at the beginning of logging to make it quick/easy to see if a station was logging upon deployment. I think @srgdamiano recently removed this from the new version of the Modular code.

[fisherba]

Neil, for the develop branch I would point to a specific commit. The current commit in develop tonight is located here:
https://github.com/EnviroDIY/ModularSensors/commit/8f1d8b58c2b9813484feed77a6074f215ecbc3e3

For my platformio.ini file’s lib deps, I would point to with the syntax:
https://github.com/EnviroDIY/ModularSensors.git#8f1d8b58c2b9813484feed77a6074f215ecbc3e3

The latest release that PlatformIO can recognize is v0.12.2, which refers to the Master branch. I see that your 0.15.3 is the current Develop branch, but that won’t be recognizable by PlatformIO until it is merged to Master.

[fisherba]

My 2-cents on which branch to use is that the *model* structure is that end users work from the master branch. @neilh20 might be overqualified as an end user, so if future readers show up on this thread for help, they may be mislead by the notion that develop is the better branch.

But the Modular branches have been so very active in development lately (woot!) that I (very end user) have deployed nearly everything from development branches. What I think @srgdamiano means by the develop branch being *better* is that it has new features. I’m outside of Sara’s building and have been one of the someones actively requesting and testing new features. But buyer beware, that if the features haven’t been merged to master, they may not be fully tested.

So the bottom line regarding which commit to use: use the github commit that matches wherever you pulled the example file. If your Git is pointing to master, use the master branch commit to compile(build) your sketch. If your Git is pointing to develop, use that branch. When Sara does her development work, she is very good about making sure the examples match the current features, and this means that compiling from other branches may not work.

[fisherba]

Hi Neil,

You renamed the .ino file to a .cpp?

Sorry I didn’t have time to explain what all of the things meant. 4 hours of glazed reading sounds painfully familiar.

My platformio.ini file is in the root directory for my PlatformIO “project”. It has to be moved from the sketch folder to the root directory. Sara puts an example ini file in the sketch folder so we don’t have to guess which dependencies are needed for the sketch (which I really appreciate, but it seems to be a source of confusion for new users).

Here’s where my sketch is located:
/~/Documents/Arduino/EnviroDIY_deployments/deploy-BAF/logging_to_EnviroDIY/logging_to_EnviroDIY.ino

And for that sketch, my ini file is located here:
/~/Documents/Arduino/EnviroDIY_deployments/platformio.ini

To “build” (aka “compile” and I sill think of it as compile, as does your terminal monitor!) the sketch, PlatformIO will use the instructions I give it in the ini file. When the build occurs, PlatformIO will fetch and write your libraries and write them to a hidden directory (at least as Atom renders PlatformIO). To see the hidden files, I go into Settings>Packages>tree-view and I uncheck the “Hide Ignored Names” default. This will reveal several folders in your root directory that were built based on your instructions in the ini file, including .git, .pioenvs, and .piolibdeps.

My ini file looks something like this (and I’ll break it down below):

; PlatformIO Project Configuration File
;
; Build options: build flags, source filter
; Upload options: custom upload port, speed and extra flags
; Library options: dependencies, extra library storages
; Advanced options: extra scripting
;
; Please visit documentation for the other options and examples
; https://docs.platformio.org/page/projectconf.html

[platformio]
;src_dir = deploy-Limno/MeteoTsu-1
;src_dir = deploy-BAF/UST/Bixby4c
;src_dir = deploy-BAF/testsketches/Yosemitech_utilities/ChangeSlaveID
;src_dir = deploy-BAF/testsketches/Yosemitech_utilities/GetSlaveID
;src_dir = deploy-BAF/YosiConductivity
src_dir = deploy-BAF/WSP01
;src_dir = deploy-BAF/testsketches/onewiresearch
;src_dir = deploy-BAF/baro_rho_correction

[env:mayfly]
platform = atmelavr
framework = arduino
board = mayfly
lib_ldf_mode = deep
lib_ignore = RTCZero
lib_deps =
; Using ModularSensors *master* branch as of May 18, 2018: v0.11.7
; EnviroDIY_ModularSensors@=0.11.6
https://github.com/PaulStoffregen/AltSoftSerial.git
https://github.com/EnviroDIY/SoftwareSerial_ExternalInts.git
;Using ModularSensors *PaleoTerraRedox* branch as of Sept 18, after hardware I2C with variable base correction
https://github.com/EnviroDIY/ModularSensors.git#5928eca124aa76d6a3bd818c295df652422975fc

In this syntax, the semicolon is the comment out character and it *must* be at the beginning of the line with no spaces in front if it or you will think your computer is blowing up.

Here’s how you tell your instructions to PlatformIO:

[platformio]: Tells PlatformIO where to find your sketch (your .ino file). Don’t point to a file name, point to the directory. Remember how the Arduino IDE required you to have your sketch in an enclosing folder of the same name? Still true in PlatformIO. Notice that I like to keep several directories handy here, but I can build only one directory (the rest are commented out).

[env:mayfly]: This is your virtual environment. PlatformIO knows the Mayfly board (and something like 500 other boards). There are several things to specify in the environment:

platform = this is the type of microcontroller you are using. The Mayfly (and probably most Arduinos?) are AVR, which is a family of microcontrollers developed by Atmel.

framework = arduino. This one makes sense, but apparently you can use multiple frameworks.

board = mayfly

lib_def_mode = This is how you want PlatformIO to search for library dependencies. The mode options are listed here. I’ve been directed to use “deep” and that seems to include everything we need.

lib_ignore = Exclude this library.

lib_deps = This is where we point to the URLs of GitHub repositories. We can tell PlatformIO to use the most recent version of the library (syntax matters), such as anything greater than or equal to version 0.12.2:
EnviroDIY_ModularSensors@>=0.12.2

Or you can point to a specific commit on GitHub, which allows you to point to development branches. My recent deployment used some new work that hadn’t been merged into the Master branch, so I directed it to the development branch. When I do this, I make a note about the date and any memorable aspects of that commit, so I don’t have to go back and read the commits on GitHub to remember why I selected that. I also keep track of which commits I used when I deploy a station (in a readme.md file in my deployment repository) so I can replicate it if needed:
;Using ModularSensors *PaleoTerraRedox* branch as of Sept 18, after hardware I2C with variable base correction
https://github.com/EnviroDIY/ModularSensors.git#5928eca124aa76d6a3bd818c295df652422975fc

Not sure why they must be listed separately, but currently the Modular Sensors library requires these libraries:
https://github.com/PaulStoffregen/AltSoftSerial.git
https://github.com/EnviroDIY/SoftwareSerial_ExternalInts.git

[Author]

Posts