Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of WikiWatershed, an initiative of Stroud Water Research Center designed to help people advance knowledge and stewardship of fresh water.
New to EnviroDIY? Start here

Sara Damiano

Forum Replies Created

Viewing 10 posts - 171 through 180 (of 465 total)
  • Author
    Posts
  • in reply to: XBee – R410M – Can’t connect #14217
    Sara Damiano
    Moderator

      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.

      in reply to: Editing Variable UUIDs #14163
      Sara Damiano
      Moderator

        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?

        in reply to: Editing Variable UUIDs #14117
        Sara Damiano
        Moderator

          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.

          Sara Damiano
          Moderator

            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.

            in reply to: Editing Variable UUIDs #14105
            Sara Damiano
            Moderator

              I’m so sorry.  I haven’t tested it yet.

              in reply to: Double_logger example modification #14078
              Sara Damiano
              Moderator

                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.

                in reply to: Editing Variable UUIDs #14077
                Sara Damiano
                Moderator

                  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.

                  in reply to: Editing Variable UUIDs #14076
                  Sara Damiano
                  Moderator

                    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.

                    in reply to: Editing Variable UUIDs #14074
                    Sara Damiano
                    Moderator

                      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.

                      in reply to: Double_logger example modification #14058
                      Sara Damiano
                      Moderator

                        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?

                      Viewing 10 posts - 171 through 180 (of 465 total)