[Sara Damiano]

No active bootloader is… bad.  Are you trying to talk to the XBee3 by way of the Mayfly or do you have a separate adapter board (like the Digi development board or a UartSBee or something similar)?  It’s not impossible to use the Mayfly as a carrier board to connect your XBee3 to XCTU, but it won’t work that way “out of the box.”  The LTE adapter board does something different.

If you’re using the LTE adapter board you shouldn’t need SJ13.   That power jumper between the adapter board and the Mayfly doesn’t the same thing.

I don’t think the RSSI light is “on” by default.  It’s one of the “options” for pin 6; the ModularSensors code should tell the XBee3 that that’s the option it wants.  But even when selected I’ve never seen the RSSI light up until *after* you’ve joined the network (and the assoc has gone from solid to “standard single blink.”

[Sara Damiano]

I’m sorry I haven’t been responding.

Right now the ModularSensors library doesn’t directly support LoRa or any other “radio” type communications – it’s designed around a board which has its own internet connection.  You could make it work with an ethernet/radio bridge, but it would take some more work.  So far we haven’t had enough sites where there were enough stations close enough together to push us to develop the radio support.  We have the stations right around our lab communicating by radio, but their operation is more of a first draft that we’ve not had a chance to upgrade than something I’d recommend you copy exactly.

As for ThingSpeak: it should work.  Yes, apn is the access point name and you need it to be correct before any cellular modem can send data on the network.  I guess that’s confusing in the ThingSpeak example because that example uses a wifi modem and wifi needs an network ID/pw instead of an APN.  In your code, either add a line const char* apn="hologram" above the modem definition or just replace the “dangling”  apn with "hologram".

[Sara Damiano]

Posting here is really the best way.  You can attach the output as a text file.

[Sara Damiano]

@aufdenkampe – any thoughts?

Postman automatically tacks on more standard http headers than I include in the post from ModularSensors.  I wonder if one of them is making a difference. In PostMan after making a request you can click the “Headers” tab and you’ll see 8 or 9 “temporary” headers that it used in addition to your token header.  ModularSensors only includes host, content-type, and content-length (and, of course, token).  If you open the EnviroDIYPublisher.cpp you can find and re-activate lines to add the cache control and connection headers (a few places needed: lines 24-25, 163-164, and 229-233).  Maybe one of them will make a difference.  If neither of those, I suppose it could be one of the accept headers, which I’ve never added.

[Sara Damiano]

I think the Hydros 21 takes half a second or so to warm up and take a sample, so it’s probably fine.  It’s turbidity sensors, sondes, and anything Yosemitech that are really the slow-pokes.

If you’re not worried about the small amount of extra data consumed on your cellular plan by those few extra characters, you could also just include the extra variable and send it with the empty UUID just like you’re doing now.  If you’re right at the edge of a price change on your cell plan, it might make a difference, but it’s not going to be huge.  [~10ish characters * 1 byte/character * 288 posts/day (5min intervals) * 30 days = 0.0864MB/month per junk variable]   A lot of the cellular data consumed is in overhead as the unit opens the connection to the server, does the TCP three-way-handshake, and repeats any packets that don’t get acknowledged by the server.

[Sara Damiano]

Huh.  I’m not aware of any particular reason today would be worse than any other day.  There was an update to MonitorMW released on Thursday (1/23), but it mostly dealt with Leaf Pack data and shouldn’t be affecting anything today.

[Sara Damiano]

The loop that requests values from sensors only queries sensors that have an associated variable in the variable list.  So if you don’t put the ds3231Temp in your variable list, the program will never actually ask the DS32321 for the temperature.  In that case, the value returned by ds3231Temp->getValue() in your calculation equation will just be whatever junk was in that memory slot when the board booted up.  You’re actually kind-of lucky the program ran instead of just crashing or locking up.

You can force a sensor update from within the calculated variable by calling getValue(true) – that is set the “updateValue” flag to true instead of letting it default to false.  This will give you a brand new value to do the calculation from, but you lose all of the timing optimizations that can happen when the getValue() is called from within the array instead of from within the calculation equation.  For something like the temperature from DS3231 (which is actually the real-time-clock) the process of getting a new value from the sensor takes a trivial amount of time, so you can just add the word true to your calculation equation, deleted the variable you don’t care about and call it done.  That’s what I recommend you do.

If you wanted to do it “right” and have the sensors all update in the array but only output the calculated result to MonitorMW you should do something like in the “data saving” example where you put the raw value in the full array but only the calculated value in the “to go” array.  That is what I would recommend if you wanted were using multiple sensors and wanted to do a calculation based on the results of a “slow” sensor like turbidity.  Doing it that way you would allow the VariableArray to attempt to optimize the order in which it gets values from sensors and then your calculation equation would use the value saved in memory when all the sensor are finished.  But what you’re gaining in speed of update and possibly long battery life is at the expense of having to understand and write out a large portion of the logging routine yourself.  Which is why, since you’re only talking about the DS3231, I would not recommend you bother.

[Sara Damiano]

Fix pushed.

[Sara Damiano]

@lemon – most of them were deployed in the field working and stopped for no apparent reason.  I didn’t realize we’d had so many failures until Shannon dumped them on my desk the other day.

@mbarney – we’ve gone back and forth over and over about the transparent-vs-bypass issue.  My experience has generally been that the modem connects more quickly and more consistently and is more frequently successful in sending data when in bypass mode.  Despite that, there is some bug that I have not been able to track down and only seems to happen with an XBee3 in bypass that causes the whole system to occasionally completely lock up until the watchdog finally forces a reset.  So we’ve been deploying with transparent.  The watchdog reset does work meaning you should only lose 15-20 minutes of data when the board freezes, so if you’re ok with that it should be fine to deploy in bypass mode.

As for the logs, I’m not sure about that one error.  It’s still working, so it’s probably not a big deal, but it should be fixed.  The permissions error in installing or compiling sometimes happens when somehow the computer thinks a file is stuck open.  Whenever you install a library or ‘build’ anything the PlatformIO and the compiler create and modify a whole bunch of files in the hidden .pio directory.  If it thinks one of those files is open by another process it can’t do its thing and give that error.  Usually completely closing all open copies of VSCode or Atom will ‘free’ whatever file got locked and you can re-open and it will be fine.  Sometimes you have to reboot.

I’m sorry about the issue with the “modemLast” branch.  Bleeding edge .. I changed something and was sloppy and didn’t make it backwards compatible.  I’ll push a fix.

[Sara Damiano]

@shicks came over to my office yesterday with a pile of LTE XBee3’s that will no longer connect to the internet.  We’re going to buy some alternative types of modems to see if any of them are any better.

[Author]

Posts