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
-
I just want to be really clear that the very slow connection speed and non-response is A PROBLEM WITH THE XBEE ITSELF, NOT THE CODE.
The messages like “no response received” are merely letting you know that the Bee is not responding.
There is nothing I’ve done in the code recently that changed it from “not working” to “working” with the LTE-M XBee3. I’ve done a lot more testing and tweaks to make it work better, that’s all. The basic code has been working as long as the module has been available.
The XBee’s are all 3.3V logic levels.
I used pin A4.
Shannon soldered a jumper on a board for me to connect the reset pin to a data pin on the Mayfly’s mcu so I could try it with the XBee.
Unfortunately, it won’t work if you’re powering the XBee off of the battery (ie, w/ solder jumper 13).Erm… or rather, unfortunately, the board I had her put the jumper on seems to have gone very flakey. It works on a different board.I’ve made some tweaks to try to make the LTE XBee work better. Code wise, it should have already been working, though. The problem was more about slowness/inability to make a connection to the internet and periodic non-responsiveness. That problem is somewhat upstream of ModularSensors.
I’ve spent a lot more time playing with the LTE-M XBee3 so I think I can help a bit better now.
I cannot get it to connect without the solder jumper – it just needs the extra uumph. And the antenna is also definitely not optional.
No matter what I do, it sometimes stops responding. I’m seeing this whether I have it powered off the mayfly or if I have it on a separate Skywire development board, so I don’t think’s a capacitance or brown-out problem. Putting it to sleep and waking it again seems to magically resolve it.
Setting the network technology (“N#) to 2 (LTE-M only) seems to speed the connection up dramatically for me. On waking from sleep it will connect in comfortably under a minute.
And, acting against the manual, I’ve found I can connect even faster and it flakes out less if I put the thing in bypass mode and tell TinyGSM it’s a u-blox (which it is). Go figure.
To put it into bypass mode you set AP5, WR (write changes) and then FR for a force reset. It doesn’t enter bypass until after that.
Ugh. I’m sorry you’re having so much trouble understanding what’s going on in ModularSensors. It’s a very heavy-weight library.
While you’re deep debugging your modem connection, though, sticking to TinyGSM and a basic sketch, or even just XCTU, is probably the way to go.
Neil’s right about the symbol – it’s a reset-not pin – pull it low to reset.
But… it’s not connected to anything else on the board, so you can’t pull it in any direction without some hacking. You could use the pin stubs on the back of the board to solder on a wire to connect the bee reset pin to some processor pin. The Digi documentation recommends putting a capacitor near the reset pin to prevent any resets from noise.
No, the gerbers are not available.
Assuming you’re using the modular sensors library, the 2 minute reading on the start-up was a feature that was supposed to help with debugging. The idea was that right after deploying a station you’d want to make sure it was working so you’d want frequent measurements. I took it out in the most recent release because nearly everyone was confused by it and thought there must be a bug.
Between versions ~0.6.6 and ~0.11.5 I’d additionally mistakenly set the internal sample count to an 8-bit instead of 16 bit integer, which was causing the sample count to roll over at 256 samples and re-enter the start-up interval.
So, I think updating your library should make it work the way you expect. Please let me know if it doesn’t!
The default settings allow up to 10 seconds before it times out and drops you out of command mode and has a 1 second “guard” time around the +’s to get back in. TinyGSM cuts the guard down to 100ms.
-
AuthorPosts
