Forum Replies Created
-
AuthorPosts
-
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.
How and when did you download all of your libraries?
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 bymodemXBWF.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.
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”
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.
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.
Arduino123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132#include <Arduino.h>#define TINY_GSM_MODEM_ESP32// See all AT commands, if wanted// WARNING: At high baud rates, incoming data may be lost when dumping AT// commands#define DUMP_AT_COMMANDS// Define the serial console for debug prints, if needed#define TINY_GSM_DEBUG Serial// Range to attempt to autobaud// NOTE: DO NOT AUTOBAUD in production code. Once you've established// communication, set a fixed baud rate using modem.setBaud(#).#define GSM_AUTOBAUD_MIN 9600#define GSM_AUTOBAUD_MAX 921600#ifndef TARGET_BAUD#define TARGET_BAUD 9600#endif#include <TinyGsmClient.h>#ifdef DUMP_AT_COMMANDS#include <StreamDebugger.h>StreamDebugger debugger(Serial1, Serial);TinyGsm modem(debugger);#elseTinyGsm modem(SerialAT);#endifbool flip = true;void setup(){Serial.begin(115200);delay(100);Serial.println(F("Starting force baud test in 1s..."));digitalWrite(18, HIGH);digitalWrite(A5, HIGH);delay(1000);modem.streamClear(); // Clear any junk in the stream from startup}void loop(){// put your setup code here, to run once:uint32_t modemBaud = TARGET_BAUD;bool baudSet = false;Serial.println(F("\n\n\n=============================="));Serial.println(F("=============================="));if (flip){Serial.print(F("Attempting to switch baud rate to "));Serial.print(modemBaud);Serial.println(F(" using a fire-and-hope method..."));Serial.println(F("Assuming modem baud rate is 115200 (default)"));for (uint8_t i = 0; i < 10; i++){Serial1.begin(115200);delay(50);modem.sendAT(GF("+UART_DEF="), modemBaud, F(",8,1,0,0"));modem.waitResponse();Serial1.end();delay(50);Serial1.begin(modemBaud);delay(50);if (!modem.testAT(1500L)){Serial.print(F("Attempt "));Serial.print(i + 1);Serial.println(F(" failed to switch baud rate"));}else{Serial.print(F("Attempt "));Serial.print(i + 1);Serial.println(F(" successfully switched baud rate"));break;}}}else{Serial.println(F("Attempting to force baud rate using forceModemBaud..."));baudSet = modem.forceModemBaud(Serial1, TARGET_BAUD);baudSet &= modem.testAT();}if (baudSet){Serial.println(F("Getting modem info to confirm communication is working..."));modem.begin();String modemInfo = modem.getModemInfo();if (modemInfo.length() > 0){Serial.println(F("\n================"));Serial.println(modemInfo);Serial.println(F("================\n\n"));}}if (baudSet){Serial.println(F("Wait 5 seconds, then factory reset modem to restore default baud rate..."));delay(5000);bool resetSuccess = modem.factoryDefault();Serial1.begin(115200);delay(350);if (resetSuccess){Serial.println(F("Modem successfully reset to factory defaults."));Serial.println();Serial.println(F("Test AT commands to confirm modem is responding at default baud rate."));Serial.println(F("On a 8MHz processor, THIS WILL FAIL! When dumping AT commands, you can see the modem is responding but the response will be garbled."));modem.testAT(1500L);}else{Serial.println(F("Failed to reset modem to factory defaults."));}}Serial.println(F("Wait 5 seconds before repeating the test..."));delay(5000);flip = !flip;}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.
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:
C++12345678910111213141516171819202122#ifdef USE_WIFI_BEE/** Start [setup_esp] */PRINTOUT(F("Attempting to force the ESP32 to switch from 115200 to 9600 baud.."));modemBaud = 9600;for (uint8_t i = 0; i < 10; i++) {modemSerial.begin(115200);delay(50);modem.gsmModem.sendAT(GF("+UART_DEF="), modemBaud, F(",8,1,0,0"));modem.gsmModem.waitResponse();modemSerial.end();delay(50);modemSerial.begin(modemBaud);delay(50);if (!modem.gsmModem.testAT()) {PRINTOUT(F("Attempt"), i, F("failed to switch baud rate"));} else {PRINTOUT(F("Attempt"), i, F("successfully switched baud rate"));break;}}modem.modemWake(); // NOTE: This will also set up the modem/** End [setup_esp] */#endifThe 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.
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.
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.
-
AuthorPosts
Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of