Forum Replies Created
-
AuthorPosts
-
If XCTU doesn’t recognize the XBee3, that’s a pretty bad sign. How are you attaching your XBee to the computer? Do you have the USB-C XBee3 carrier? https://www.digi.com/products/models/xbib-cu-th That development board should make sure the bee is awake and work flawlessly with XCTU. Are you plugged into the USB-C port, not the side microUSB? Is the other end of the USB-C that’s attached to your computer attached to a USB-3 power delivery port?
If you’re using another carrier/development board (ie, not a Digi one) it’s possible that the bee is asleep or not sufficiently powered and that’s why it’s not talking to your computer. Make sure whatever carrier board you’re using has pin 9 on the bee socket held at ground to keep the bee awake for communication and provides up to 1 amp power. A “standard” USB port will only provide 500mA power, which is NOT sufficient for the LTE XBee3 and may cause it to brown out. An unmodified Mayfly will NOT work as a carrier board for your bee to talk to the computer
The u-blox M-Center program is not likely to recognize the chip on the XBee unless you have both programmed the XBee to be in USB direct mode and connected the USB direct pins to your computer. I don’t think there’s anything you can do with the m-center program that you can’t do with XCTU, so I wouldn’t bother with it if you don’t need to.
I just added another fix for the XBee wifi and the modem-measured battery voltage. Have you been able to get it to work for you?
I’m sorry. I finally fixed pushed what I think should be the changes needed to the develop branch, but I still haven’t programmed an actual board to test it. You should be able to test it yourself by listing the develop branch from git in your dependencies. (In the platformio.ini replace “ModularSensors” with https://github.com/EnviroDIY/ModularSensors.git#develop)
This everyone being home all the time situation is brutal. Anyone doing well with it is clearly a lot more disciplined and organized than I am.
I’m just seconding what Shannon said about using the hardware UART – always use hardware UART unless you definitely cannot. In your case where you’ll be parsing long NMEA sentences, I’d recommend actually re-wiring your Bee/modem to give your GPS the better connection if you’re trying to use both. In your code, you just use “Serial1” to communicate over the RX1/TX1 exactly like you would use “Serial” when writing to the computer. AltSoftSerial is the next best alternative – on the Mayfly with AltSS Rx will be on pin 6 and Tx on pin 5 (and only those pins). Like Shannon said, you can use any pin that allows pin-change interrupts for SoftwareSerial (which is nearly any digital pin on the Mayfly) but you are more likely to have misread data using it.
I’m so sorry. I haven’t tested it yet.
No problem! The wonder of git is that I actually could track back pretty quickly how long it had been since any changes were made and what those were.
I’ve pushed what I think should fix the testing mode to the develop branch of the ModularSensors library, but I haven’t actually tested it myself yet.
I’ll see if I can get it tested tomorrow and then pushed to the master branch.
Working on it right now for you. It will be a library update. The lack of modem update in sensor testing mode was an oversight; I want it to be there automatically.
You didn’t manage to connect to the internet for the clock sync. I’m not sure why that happened.
The modem values won’t update in sensor testing mode and they’re always updated at the *prior* internet connection. Since you didn’t connect successfully for the clock sync, they didn’t update.
I waded back through my “git blame” and I don’t see any changes I’ve made to the request more recent than 8 months ago, where I removed one single space – from a double space in one of the headers. The next most recent change was 15 months ago. Is it possible your libraries were that old?
-
AuthorPosts