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 - 1 through 10 (of 479 total)
  • Author
    Posts
  • in reply to: Unable to Compile Error Message #19665
    Sara Damiano
    Moderator

      From your error messages, it looked like you have mismatched versions of libraries.  I’m not sure how permissions are set up on your PC, but typically the Arduino libraries would be stored in a personal user folder that you could change at will.

      https://support.arduino.cc/hc/en-us/articles/4415103213714-Find-sketches-libraries-board-cores-and-other-files-on-your-computer

      in reply to: Unable to Compile Error Message #19634
      Sara Damiano
      Moderator

        How and when did you download all of your libraries?

        in reply to: DigiXBeeWifi class mqtt codeflow example #19623
        Sara Damiano
        Moderator

          Are you using anything else from the Modular Sensors library? Post your entire sketch as code (use the <> button to post as code)?  Are you setting the host and port for the mqttClient? (mqttClient.setServer(ip, port)) Use your local IP there.  If you do that, I don’t see why you’re not getting a connection even with the bad DL setting in the extraModemSetup function. The correct DL should be set by PubSubClient when it connects because it will call client.connect(ip, port) on the client created by modemXBWF.createClient(); That client is a TinyGSM object which should properly set DL using XBee command mode.

          If you don’t need the power on/power off via pins that are in the DigiXBeeWifi class, use a TinyGSMModem/TinyGSMClient object directly.  There’s no need for that fake client thing. TinyGSM does all the work of converting the xBee into a client and provides you with the functions to connect to the network and a host so you don’t need XCTU.

          The reason the extraModemSetup forces DL to 0.0.0.0 is to force the Bee to grab a new IP address each time. Doing that means that you *can’t* use XCTU – which is the “bug.” But the reason that’s done is that the WiFi bee tends to get stuck thinking it has an open socket to an IP address if it has one in memory – even if the module isn’t connected to the internet.  Sorry, it took me a bit of thinking to remember why that was done.  This is not a bug that should be fixed.

          If you’re going to leave your Mayfly and XBee fully powered the whole time you program is running and you’re confident that your never going to lose the internet or socket connection and you’re comfortable with XCTU, then you may be fine with your faked client.

          in reply to: DigiXBeeWifi class mqtt codeflow example #19621
          Sara Damiano
          Moderator

            Ooooh.. yup, there’s a bug in DigiXBeeWifi.cpp.  I’ll look into it.

            Exactly which version of the library are you using (release, master branch, develop branch)?

            For now, you may be able to get it working by commenting out lines ~303-310 in src/modems/DigiXBeeWifi.cpp, the section starting with “set the destination IP to 0”

            in reply to: Wifi Bee AT Firmware and Baud Rates #19618
            Sara Damiano
            Moderator

              If that doesn’t compile for you, update your TinyGSM library or just delete lines 87-92 to remove the forceModemBaud command, which needs the version of TinyGSM within the last few weeks.

              It it’s working for you, comment out the section that resets the modem to defaults (lines 107-126) and run it one more time to get the modem to 9600. It should stay at that baud through power cycling.

              in reply to: Wifi Bee AT Firmware and Baud Rates #19617
              Sara Damiano
              Moderator

                Use 3.3V to power the WiFi bee and make sure that you’re adapter uses 3.3V logic.  The 0.5A most USB ports can provide should be enough for the WiFi bee without browning out.  You are seeing the lights on the bee go on, right?

                This script worked for me to force the baud rate on three different WiFi Bee’s.  The script forces the baud rate and then factory resets the board and then forces the baud rate again – over and over, just to show it works.  Don’t run it long; you could wear out the bee’s flash if you let it run forever.

                 

                in reply to: Wifi Bee AT Firmware and Baud Rates #19612
                Sara Damiano
                Moderator

                  Once you’ve successfully changed the WiFi bee’s baud rate, it will stay at the slower baud. You should only have to reset the baud rate if you factory reset the bee or update it’s firmware – neither of which you can do by accident.

                  in reply to: Wifi Bee AT Firmware and Baud Rates #19611
                  Sara Damiano
                  Moderator

                    The WiFi bee should have the AT firmware on it. The problem probably is the baud rate. The default baud rate for the ESP32 (the brain on the WiFi bee) is 115200. That’s too fast for stable communication with the 8MHz Mayfly.  The Mayfly can usually *talk* fairly accurately at 115200, but it can’t listen that fast.  The auto-baud function depends on the Mayfly hearing an ‘OK’ to detect the baud rate so it’s iffy at best.

                    Assuming you’re using the Monitoring Kit sketch as it is currently on the master branch of the repo, try replacing the auto-baud section with a fire-and-forget attempt to change the baud rate.

                    That is, replace lines 485-505  with something like this:

                    The WiFi bee does not have a built-in FTDI or other TTL-to-USB converter on it, so to flash it or talk to it directly, you have to use a separate adapter of some kind.  If you do have an adapter, it’s easy to change the baud rate from your PC.  Connect the bee’s TX, RX, power (3.3V!), and ground to your adapter and that to your PC. Set your terminal to 115200, check that you can get an “ok” back from an “AT” and then send the command AT+UART_DEF=9600,8,1,0,0.  After you get an ‘OK’ back from that, stop your terminal, restart it at 9600 and make sure you can get an ‘OK’ after an ‘AT’ at that baud rate.

                    If you can’t get the modem to respond to anything, it’s possible there is something wrong with your firmware.  The easiest way to flash is using espressif’s Flash Download Tool and the ESP32-WROOM-32 AT firmware binary. The programming UART uses bee pins 18/17 as TX/RX and you need to hold bee pin 9 (ESP32 IO0) low as you apply power to get the ESP into ‘download’ mode where it can accept new firmware . You can’t flash the bee through the Mayfly, you need a direct connection to your computer.

                    in reply to: Requirements for making a sensor compatible #19489
                    Sara Damiano
                    Moderator

                      Using ModularSensors doesn’t necessarily require the sensors to be directly connected to the Mayfly.  They could be, but they don’t have to be. In the case of a lot of inexpensive sensors sold as breakout boards, the Mayfly connects and talks directly to the sensor, but most of the not-bare-circuit sensors have black-box layers between the raw sensors and the Mayfly that do some internal processing before passing the number along.  If you wanted to make your sensors SDI-12 slave, you’d need to create those layers, whether on your 328p or some other in-between board.  Most commercial environmental sensors can do some on-board averaging, bad-value management, temperature correction, power management, and communication translation. Then “sensor” as the Mayfly sees it is the combination of the bare circuit sensor and the processing layers.  The Mayfly doesn’t need to know anything about what the lowest level sensing, just how get a “final” measured value.

                      in reply to: Requirements for making a sensor compatible #19487
                      Sara Damiano
                      Moderator

                        I spent some time skimming your GitHub code for your device.  If your logger is using a simple serial protocol to communicate with your GUI controller, it should also be able to communicate with the Mayfly (with or without Modular Sensors) in the same way if you expose the Serial (or AltSoftSerial) pins.

                        ModularSensors already supports the MS5803 and the Mayfly has a QWIIC connection.  The Mayfly has a built-in ADS1115 for analog sensors. The VCNL4010 is not implemented in ModularSensors, but it looks like an I2C sensor with an Adafruit library, so it would be easy to implement and submit a PR for using the example of the MS5803.  Keep in mind if you’re developing anything with I2C communication that the I2C protocol is designed for short distance communication so you need an alternative if you want more than a few feet of cable.

                      Viewing 10 posts - 1 through 10 (of 479 total)