[Sara Damiano]

@stoltzfus-12osu-edu – that is very interesting to know.  Do you happen to know exactly what version of the library you’d had prior to updating?  If not, how long (at least roughly) would the long time since you updated be?  A month or two? A year?  The specification for the post format hasn’t changed at all since it was first developed, but if there could be something in my code that changed about the way I create the post request that I’ve somehow overlooked and decreased the success rate, I want to track it down.

[Sara Damiano]

It’s very, very intentional that ModularSensors uses that Atlas sensors only in I2C mode and I do not intend to change this.  When using Atlas sensors in UART mode, each sensor must have an individually dedicated UART port.  The Mayfly has exactly two hardware (processor implemented) UART’s – one dedicated to the computer/programming and the other dedicated to modem communication.  It is possible to replicate UART functionality with “bit banging” libraries like AltSoftwareSerial or SoftwareSerial, but both of these have serious limitations.  AltSoftwareSerial has acceptable quality communication but it is strictly limited to being used on pins 5 and 6 – which are spread on two different Grove ports on the Mayfly – and even then, monopolizes both of those pins.  SoftwareSerial has poor communication quality, conflicts with every other library using interrupts including those absolutely required to wake the logger from deep sleep, and besides requires two dedicated pins.  If the Atlas sensors are used as I2C devices, they can be connected to hardware already dedicated only to processor implemented I2C communication.  This gives them the best quality communication, allows up to 126 devices on the same connection, and does not waste other data pins on the Mayfly.  ModularSensors will continue to use I2C to support Atlas sensors.

[Sara Damiano]

It would be so much better if the website at least told you *why* and upload failed!  All you get is a “failed” which could mean anything – the format was bad, the file was too big, there was an internet blip, who knows.  The only way right now to even get an inking as to why it fails is to turn on “developer tools” (F12 in Firefox, I think also in Chrome) in your browser before posting the data and then searching through all the many tiny requests on the console for the right post request and hoping the error message is there and is interpret-able – and often it isn’t.

[Sara Damiano]

Also, just so you understand, ModularSensors isn’t powerful enough to “stash” recent data and save it for later.  So when you’re in production and only connecting once an hour, the data being sent on the hour will only be for that one point.  If for some reason there’s something wrong with the cellular connection in that moment it is supposed to send (thunderstorm, planetary alignment, the XBee being moody, etc), the data will not be sent.  The logger will not try to send out the back-log.  You’ll have to go fill in the gaps later from the SD card data.  It’s definitely on my list to get that working so we could send more data per connection and reduce the connection overhead to data ratio, but I haven’t figured it out yet.

[Sara Damiano]

@w3asa – I don’t have formal training in computer science or even in electrical engineering.   I have one bachelor’s level degree – in chemistry.

@stoltzfus-12osu-edu – two things with your code – and I completely understand why you did it the way you did – because the example did.  Blame the chemist.

1 – you’re creating each variable 3 times instead of creating it once and then referring it to that same one later.  Each time you use that “new” keyword it creates a new variable, but you can only assign one variable of each type to a sensor so the other two weren’t getting updated.  In the double logging example it worked fine to create the variables with “new” right in the variable array because there was no overlap between the two arrays.  But that definitely wansn’t made clear and is confusing.  Anyway, to fix that change your variable arrays so that instead of creating a new variable they use the same variable that you already created up in the sensor sections like so:

C++

// ========================================================================== // Creating the Variable Array[s] and Filling with Variable Objects // ========================================================================== // The variables to record at 1 minute intervals Variable *variableList_low[] = { ds3231Temp, new ProcessorStats_FreeRam(&mcuBoard, "xxxxx"), tbi2cDepth, modemRSSI, modemSignalPct, // ds18TempVar // if you're using this, you should create above extvoltV, }; // Count up the number of pointers in the 1-minute array int variableCountLow = sizeof(variableList_low) / sizeof(variableList_low[0]); // Create the 1-minute VariableArray object VariableArray arrayLow; // The variables to record at 5 minute intervals Variable *variableList_high[] = { new ProcessorStats_Battery(&mcuBoard), ds3231Temp, tbi2cDepth, modemRSSI, modemSignalPct, // ds18TempVar // if you're using this, you should create above extvoltV, }; // Count up the number of pointers in the 5-minute array int variableCountHigh = sizeof(variableList_high) / sizeof(variableList_high[0]); // Create the 5-minute VariableArray object VariableArray arrayHigh;

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

// ========================================================================== //    Creating the Variable Array[s] and Filling with Variable Objects // ==========================================================================   // The variables to record at 1 minute intervals Variable *variableList_low[] = {     ds3231Temp,     new ProcessorStats_FreeRam(&mcuBoard, "xxxxx"),     tbi2cDepth,     modemRSSI,     modemSignalPct,     // ds18TempVar  // if you're using this, you should create above     extvoltV, }; // Count up the number of pointers in the 1-minute array int variableCountLow = sizeof(variableList_low) / sizeof(variableList_low[0]); // Create the 1-minute VariableArray object VariableArray arrayLow;   // The variables to record at 5 minute intervals Variable *variableList_high[] = {     new ProcessorStats_Battery(&mcuBoard),     ds3231Temp,     tbi2cDepth,     modemRSSI,     modemSignalPct,     // ds18TempVar  // if you're using this, you should create above     extvoltV, }; // Count up the number of pointers in the 5-minute array int variableCountHigh = sizeof(variableList_high) / sizeof(variableList_high[0]); // Create the 5-minute VariableArray object VariableArray arrayHigh;

Since you only use the free RAM in one of the two arrays and battery in the other and you didn’t create either at the top, it’s fine to create them “new” in the array. If you decide you do want them in both or the look of the code bothers you, you can create the free ram and battery variables with statements like Variable *yourVarName = new ProcessorStats_FreeRam(&mcuBoard, ...) up in the processor section or elsewhere above.

2 – Modems in ModularSensors are special; they don’t get updated like regular variables tied to a sensor.  The signal quality isn’t update until *after* you send out some data.  With each cycle, the signal strength saved to the csv and posted is actually the data from one cycle prior.  And if you never post data (you don’t) and explicitly update the modem metadata, the values don’t update.  You’d want to add publishing code like this in the “high” section right after turning off the SD card.

C++

// Connect to the network if (modem.modemWake()) { loggerLow.watchDogTimer.resetWatchDog(); if (modem.connectInternet()) { loggerLow.watchDogTimer.resetWatchDog(); // Publish data to remotes loggerHigh.publishDataToRemotes(); modem.updateModemMetadata(); loggerLow.watchDogTimer.resetWatchDog(); // Sync the clock at midnight // NOTE: All loggers have the same clock, pick one if (Logger::markedEpochTime != 0 && Logger::markedEpochTime % 86400 == 0) { Serial.println(F("Running a daily clock sync...")); loggerLow.setRTClock(modem.getNISTTime()); } // Disconnect from the network loggerLow.watchDogTimer.resetWatchDog(); modem.disconnectInternet(); } } // Turn the modem off loggerLow.watchDogTimer.resetWatchDog(); modem.modemSleepPowerDown();

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

// Connect to the network if (modem.modemWake()) {   loggerLow.watchDogTimer.resetWatchDog();   if (modem.connectInternet())   {     loggerLow.watchDogTimer.resetWatchDog();     // Publish data to remotes     loggerHigh.publishDataToRemotes();     modem.updateModemMetadata();       loggerLow.watchDogTimer.resetWatchDog();     // Sync the clock at midnight     // NOTE:  All loggers have the same clock, pick one     if (Logger::markedEpochTime != 0 &&         Logger::markedEpochTime % 86400 == 0)     {       Serial.println(F("Running a daily clock sync..."));       loggerLow.setRTClock(modem.getNISTTime());     }       // Disconnect from the network     loggerLow.watchDogTimer.resetWatchDog();     modem.disconnectInternet();   } } // Turn the modem off loggerLow.watchDogTimer.resetWatchDog(); modem.modemSleepPowerDown();

 

 

[Sara Damiano]

The csv uploading tools are very sensitive to an irregularities in the files.  We would very much like to improve them, but right now that’s pending time and, mostly, budget.

[Sara Damiano]

If your goal is to have everything on that one 4-port splitter – it won’t work.

The DS18 isn’t I2C – it’s OneWire.  If you really want to use it on that Grove port, you should be able to use it as either D16(SCL) or D17(SDA), but I strongly suspect that attempting to dual-use one of the I2C pins for OneWire would screw up communication with actual I2C devices (like the build in clock or ADC and your little display).  I’d be surprised if you could even get a sketch to run.  The I2C library (from Arduino core) has a bug (a while loop with no timeout) such that if either pin on the I2C bus is held low during any I2C communication the board will freeze in endless wait.  If you really have your heart set on that connection pattern, you can experiment with it, but I’d just just a different port if I were you.

[Sara Damiano]

If you need the SD library in your program, you need to include it in your platformio.ini file in the lib_dep section.  Add RTCTimer and Sodaq_DS3231 there while you’re at it since it looks like you use them.

Other answers:

• ModularSensors uses I2C, not Serial, for Atlas sensors.  Please read the documentation I linked earlier.  It has links to further Atlas documentation on how to set up I2C.
• A raw RTD like you’re using isn’t directly supported.  I would recommend attaching the RTD to the auxiliary ADC (TI ADS1115 – pins AA0-AA3 on the Mayfly) which is higher resolution anyway, and then using that:  https://github.com/EnviroDIY/ModularSensors/wiki/TI-ADS1115-Voltage
  • To calculate temperature and to correct conductivity for temperature you should use a calculated variable in ModularSensors.  I’m embarrassed that I actually don’t have documentation on that, just examples.
  • There’s a very generic example of a calculated variable in the menu a la carte example:  https://github.com/EnviroDIY/ModularSensors/blob/f607ff9ac5b22c87962802e5e5b348b3612d75a4/examples/menu_a_la_carte/menu_a_la_carte.ino#L1169.
  • There are several calculated variables in the barometric pressure correction examples:  https://github.com/EnviroDIY/ModularSensors/blob/f607ff9ac5b22c87962802e5e5b348b3612d75a4/examples/baro_rho_correction/baro_rho_correction.ino#L175
• Yes, the ModularSensors library should take care of all of the configuration for the GPRSBee
• Yes.  The values should be visible immediately, the plots may take up to an hour to update.

[Sara Damiano]

You need to include the Arduino library – add #include <Arduino.h> to the top of your program.  The Arduino IDE adds that automatically and does some other “massaging” of files when it converts an ino to a real cpp file that gcc then compiles; PlatformIO doesn’t.  Depending on how you’ve structured your program, that may cause a few more snags.  The two things your most likely to hit are:

• pre-processor defines within a file (ie #define) which the Arduino IDE applies as global build flags rather than single-compile-unit defines
  • the defines you have for pin numbers and headers are probably ok
• the basic cpp requirement that a function be declared or defined before it is used, which the Arduino IDE does some squirrlyness to get around.
  • If you have any functions in your program other than setup(){..} and loop(){...} make sure they’re above the setup and loop functions.  You may also have to re-order your functions depending on the order in which you’ve created/used them.

Like most things, PlatformIO has some documentation on this:  https://docs.platformio.org/en/latest/faq.html#convert-arduino-file-to-c-manually

I don’t know what all you’re doing in your program, but I’m it might be easier to start with the ModularSensors examples and use the already existing support for Atlas sensors.  And, of course, documentation for that:  https://github.com/EnviroDIY/ModularSensors/wiki/Atlas-Sensors

[Sara Damiano]

In episode 9, copy and paste from the folder that you already saved on your computer from when you cloned the whole library not from GitHub.

You should generally create a whole new project for each logger/program – just like in the Arduino IDE.  The platformio.ini file must be in the top level directory for the project – not in a sub-directory.  If you really want to have multiple loggers/programs in your project, each program must be in its own sub-folder and you must use the src_dir option within the platformio section of the platformio.ini file to specify which directory you wish to build from.  The structure of the ini file is well documented:  https://docs.platformio.org/en/latest/projectconf/section_platformio.html#src-dir

 

I was under the impression you already knew there was 2G available before buying the units.  I don’t think it’s worth writing up a separate program just to check signal strength unless you’re planning to make multiple trips to the site, one to check signal and another to actually deploy the Mayfly.  You’ll see within the first few minutes of running your logging program if you have signal based on the blink pattern of the modem and whether data appears online.  If you find out at the last minute that you don’t have signal, just yank the modem off and deploy without it.  Your logger board will be powered up ~5-10s extra every logging cycle trying to communicate with a modem that’s not there, but unless you’re in a really shady spot or not using solar, it’s not worth stressing over.

[Author]

Posts