Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@srgdamiano
Active 1 months, 1 weeks agoForum Replies Created
-
AuthorPosts
-
Up to you whether you want to work with the develop or master branch. They are currently **not** compatible with each-other though, so if you’re flipping back and forth, you’ll need to adjust your code each time to match up. I think all the changes are in the modem structure.
I don’t know if the May code is compatible with the current master or not. It’s definitely not with the current develop.
The code in the develop branch is **theoretically** better than what’s up on master, but it’s never been run by anyone except me and never on a sensor outside of my building. I don’t want to push it to master and release it until someone (or hopefully several someones) can verify its functionality a bit.
It looks like you mis-typed the last GUID’s; you put a space on the end of it. The parser doesn’t expect a space inside of the GUID, so it fails. The error is at character 333, which is the guilty space.
Update! I got the Digi LTE-M XBee to work on Hologram!
It turns out I needed a brand new sim; one that had never been registered with another device. As soon as I put that in, it worked.
That all looks right.
Two notes:
All Sodaq uBee’s (U201 (3G), R410M (LTE-M), and N211 (LTE NB-IoT)) should work with the Mayfly with no soldering required, but I personally have only tested the U201. I do not know what, if any, SIM cards the LTE uBee’s will work with.
The Sodaq uBee’s do NOT fit in the plastic case provided in the Mayfly starter kit from Amazon. The Digi ones do.Your setup put the Bee to go into deep sleep, but you didn’t assign a pin to be the wake-up pin. So the Bee isn’t waking up anymore. You need to either set the modem to be always on (ModemSleepMode = modem_always_on) or put a pin in for modemSleepRqPin (probably 23 if you’re using a Mayfly). If you want the modem to not sleep, you will have to use XCTU or manually send the commands to the Bee to turn off sleep mode.
NOTE: The next version of this library coming out soon will change this set-up.
In our live installations, we still have the 2G Bees. That being said, what do you mean by “supported?” The Mayfly should work very with any of the digi cellular Xbees. You do need the solder jumper to get enough power for the 3G and cat 1 bees. The cat m might be able to go without it, but I haven’t tested enough. As far as library and code to communicate with the network through the Bees, TinyGSM (which I maintain a fork of) supports the digi bees. I’ve wrapped TinyGSM into the giant Modular sensors library and think it works rather nicely.
The problem we’re having with using the digi XBee’s is the communication with the Hologram.io cellular provider we’ve been using. For reasons not yet understood by me, I have not been at all successful in getting the LTE (cat 1 or m) to be allowed registration with a hologram sim. I have heard from both digi and hologram that they know of customers using them together, but I haven’t had any success. I had no problem registering and using the 3G XBee with a hologram sim or the LTE XBee’s with an AT&T sim.
So, if you’re not using hologram’s network, I’d go with the digi LTE-M xbee. It’s carrier certified, not horrifically expensive and it readily available.
If you are using hologram and can do one solder jumper, get the digi 3G xbee.
If you want hologram and don’t mind buying from the Netherlands or can’t solder, I’ve tested the Sodaq uBee with the U201 and it works nicely. The other versions of the uBee might work, but they aren’t carrier certified and I really don’t know if they’d be accepted into the network. They assist won’t fit in the boxes we like to use.
The Mayfly does not implement enough on in the xcee footprint to use any purge cellular xb I’ve found.
Oh, and a warning on the Digi LTE-M XBee: I can’t get mine to work on the Hologram network that we’ve been using with 2G. Other people say they have, but I can’t seem to get mine to work.
The modbus power up and down *can’t* include the begin or the pin settings because the modbus functionality is built around any Arduino stream type object. You can use a modbus sensor connected to anything that you can communicate with as an Arduino stream – that means HardwareSerial, SoftwareSerial, Client, etc. If you’re not using Serial1 for a modem, I’d actually strongly recommend you use it and not AltSoftSerial. Stream is a pure virtual class and it doesn’t actually have a begin function. The begin() functions are implemented by specific streams. And unless you are using the AltSoftSerial stream instance on a Mayfly or Mbili board, that digital write low won’t work.
The powerUp and powerDown functions themselves are implemented in SensorBase. Though, actually, in the newest branch I’ve moved the modbus ones (Yosemitech/Keller) into their direct parents to allow for separate power to the sensor and an RS485 adapter. I’m about to submit a pull request with that and some other updates.
@neilh – Thank you!
You can connect and send data at a different rate than you log it by essentially creating two different logger objects and setting them to different intervals. The “data_saving” and “double_logger” examples each do slight variants on this right now. You just can’t use the easy “log” function like in the data_to_envirodiy example.
Right now, there isn’t any fall back for sending missed data. Data gets sent right after it’s created or never. It is all logged to a SD card though! I’ve thought about trying to create a buffer of un-sent data, but I haven’t come up with a decent way of doing it and it hasn’t been a high priority for me. If you have ideas, though, let me know!
Please, do send in a pull request! I really deeply appreciate other people taking the time to look through my code and giving any suggestions they might have.
You should be able to use the build flag “build_flags = -D DEBUGGING_SERIAL_OUTPUT=Serial” but that might give you way, way more than you want to see. There is a LOT of debugging output possible in the library. I’d suggest you open the header (*.h) file for whatever you’re trying to debug and un-comment the define in that header only. The Keller Parent also has a “deep debugging” output which will spit out the raw modbus commands.
-
AuthorPosts
