Home › Forums › Infrastructure and Equipment › esp32-bee-wifi-bluetooth
- This topic has 5 replies, 3 voices, and was last updated 2023-07-10 at 2:52 PM by neilh20.
-
AuthorPosts
-
-
2023-06-28 at 10:17 AM #17952
For the device https://www.envirodiy.org/product/envirodiy-esp32-bee-wifi-bluetooth-pack-of-5/
Is their a Circuit Diagram available
thanks -
2023-06-29 at 11:54 AM #17955
There’s a link to the schematic on the item page along with a link to an example sketch on Github.
-
2023-06-29 at 2:23 PM #17956Thanks for the update with cct – (at least sorry if I didn’t see it the first pass).
Thanks for the reference to the sketch. I tried running the sketch, and I just couldn’t get it toThanks for the update with cct – (at least sorry if I didn’t see it the first pass).
Thanks for the reference to the sketch. I tried running the sketch, and I just couldn’t get it to compile – 3hrs trying – sometime I just admit defeat and move on. So I used it as an example with another sketch that I have running and got it working.So super exciting to be able to think of running it at 115Kbaud –
Just wondering, have you tested it for 115K baud – no problem if you haven’t just checking.
I seem to have problems initializing it to work here is the output with the flags
-DMS_ESPRESSIFESP8266_DEBUG
-DMS_ESPRESSIFESP8266_DEBUG_DEEPC1234567891011121314151617181920SerialStd.print(" ModemESP32 init default ");SerialStd.println(modemBaud);modemSerial.begin(modemBaud);for (int8_t ntries = 5; ntries; ntries--) {// This will also verify communication and set up the modemif (modemPhy.modemWake()) break;SerialStd.print(" ModemESP32 init 9600 pass ");SerialStd.println(ntries);// if that didn't work, try changing baud ratemodemSerial.begin(115200);modemPhy.gsmModem.sendAT(GF("+UART_DEF=9600,8,1,0,0"));modemPhy.gsmModem.waitResponse();modemSerial.end();modemSerial.begin(9600);}// Synchronize the RTC with NIST// This will also set up the modemSerialStd.println(F("Synchronize the RTC with NIST"));dataLogger.syncRTC();[2023-06-26 19:30:19.865] —Boot() Sw Build: a\src\logging_to_MMW.cpp Jun 26 2023 19:29:02 b’neilh20′
[2023-06-26 19:30:19.880] Modem WiFi ESP32 TinyGSM Library version 0.11.5
[2023-06-26 19:30:19.880] Using ModularSensors Library version 0.34.1-baa[2023-06-26 19:30:19.880] ModemESP32 init default 115200
[2023-06-26 19:30:21.133] Powering unspecified modem with pin 18 <–LoggerModem
[2023-06-26 19:30:21.149] Initializing pin 0 for modem status LED with starting value 0 <–LoggerModem
[2023-06-26 19:30:21.149] AT
[2023-06-26 19:30:21.306] AT
[2023-06-26 19:30:21.447] AT
[2023-06-26 19:30:22.636] AT
[2023-06-26 19:30:22.639] AT
[2023-06-26 19:30:22.639] Tested AT command and got no response meaning unspecified modem is probably asleep <–EspressifESP8266
[2023-06-26 19:30:22.639] Running wake function for unspecified modem <–EspressifESP8266
[2023-06-26 19:30:22.639] modemWakeFxn1 18 -1 <–EspressifESP8266
[2023-06-26 19:30:22.639] Waiting for boot-up message from ESP8266 <–EspressifESP8266
[2023-06-26 19:30:22.639]
[2023-06-26 19:30:22.639] Waiting up to 700 ms for unspecified modem to respond to AT commands…
[2023-06-26 19:30:22.639] AT
[2023-06-26 19:30:22.639] AT
[2023-06-26 19:30:22.854] AT
[2023-06-26 19:30:23.152] AT
[2023-06-26 19:30:23.470] No response to AT commands!
[2023-06-26 19:30:23.470] Attempting a hard reset on the modem! 1
[2023-06-26 19:30:23.470] No pin has been provided to reset the modem! <–LoggerModem
[2023-06-26 19:30:23.482] modemHardReset failed!
[2023-06-26 19:30:23.482] Setting up the modem … <–LoggerModem
[2023-06-26 19:30:23.482] AT
[2023-06-26 19:30:23.623] AT
[2023-06-26 19:30:23.782] AT
[2023-06-26 19:30:23.938] AT
[2023-06-26 19:30:24.080] AT
[2023-06-26 19:30:24.237] Tested AT command and got no response meaning unspecified modem is probably asleep <–EspressifESP8266
[2023-06-26 19:30:24.252] Waking up the modem for setup … <–LoggerModem
[2023-06-26 19:30:24.252] AT
[2023-06-26 19:30:24.394] AT
[2023-06-26 19:30:24.550] AT
[2023-06-26 19:30:24.708] AT
[2023-06-26 19:30:24.864] AT
[2023-06-26 19:30:25.022] Tested AT command and got no response meaning unspecified modem is probably asleep <–EspressifESP8266
[2023-06-26 19:30:25.022] Running wake function for unspecified modem <–EspressifESP8266
[2023-06-26 19:30:25.037] modemWakeFxn1 18 -1 <–EspressifESP8266
[2023-06-26 19:30:25.037] Waiting for boot-up message from ESP8266 <–EspressifESP8266
[2023-06-26 19:30:26.230] Wake function for unspecified modem did not run as expected! <–EspressifESP8266
[2023-06-26 19:30:26.246]
[2023-06-26 19:30:26.246] Waiting up to 700 ms for unspecified modem to respond to AT commands…
[2023-06-26 19:30:26.246] AT
[2023-06-26 19:30:26.544] AT
[2023-06-26 19:30:26.858] AT
[2023-06-26 19:30:27.156] AT
[2023-06-26 19:30:27.470] No response to AT commands!
[2023-06-26 19:30:27.470] Attempting a hard reset on the modem! 1
[2023-06-26 19:30:27.479] No pin has been provided to reset the modem! <–LoggerModem
[2023-06-26 19:30:27.479] modemHardReset failed!
[2023-06-26 19:30:27.479] AT
[2023-06-26 19:30:27.779] AT
[2023-06-26 19:30:28.082] AT
[2023-06-26 19:30:28.381] AT
[2023-06-26 19:30:28.695] AT
[2023-06-26 19:30:28.992] AT
[2023-06-26 19:30:29.291] AT
[2023-06-26 19:30:29.479] WATCHDOG ISR barksUntilReset 51 <–WatchDogAVR
[2023-06-26 19:30:29.604] AT
[2023-06-26 19:30:29.903] AT
[2023-06-26 19:30:30.201] AT
[2023-06-26 19:30:30.515] AT
[2023-06-26 19:30:30.813] AT
[2023-06-26 19:30:31.127] AT
[2023-06-26 19:30:31.425] AT
[2023-06-26 19:30:31.738] AT
[2023-06-26 19:30:32.031] AT
[2023-06-26 19:30:32.345] AT
[2023-06-26 19:30:32.643] AT
[2023-06-26 19:30:32.942] AT
[2023-06-26 19:30:33.256] AT
[2023-06-26 19:30:33.555] AT
[2023-06-26 19:30:33.868] AT
[2023-06-26 19:30:34.166] AT
[2023-06-26 19:30:34.465] AT
[2023-06-26 19:30:34.778] AT
[2023-06-26 19:30:35.077] AT
[2023-06-26 19:30:35.375] AT
[2023-06-26 19:30:35.689] AT
[2023-06-26 19:30:35.999] AT
[2023-06-26 19:30:36.301] AT
[2023-06-26 19:30:36.602] AT
[2023-06-26 19:30:36.901] AT
[2023-06-26 19:30:37.214] AT
[2023-06-26 19:30:37.512] unspecified modem failed to wake!
[2023-06-26 19:30:37.512] … unspecified modem did not wake up and cannot be set up! <–LoggerModem
[2023-06-26 19:30:37.528] unspecified modem warms up in 0 ms, indicates status in 350 ms, is responsive to AT commands in less than 700 ms, and takes up to 500 ms to close connections and shut down. <–LoggerModem
[2023-06-26 19:30:37.544] Because the modem was asleep prior to setup, putting it back to sleep now. <–LoggerModem
[2023-06-26 19:30:37.559] Putting unspecified modem to sleep. <–LoggerModem
[2023-06-26 19:30:37.559] AT
[2023-06-26 19:30:37.703] AT
[2023-06-26 19:30:37.842] WATCHDOG ISR barksUntilReset 50 <–WatchDogAVR
[2023-06-26 19:30:37.858] AT
[2023-06-26 19:30:38.015] AT
[2023-06-26 19:30:38.156] AT
[2023-06-26 19:30:38.313] Tested AT command and got no response meaning unspecified modem is probably asleep <–EspressifESP8266
[2023-06-26 19:30:38.344] unspecified modem is already off! Will not run sleep function. <–LoggerModem
[2023-06-26 19:30:38.344] unspecified modem failed to wake!
[2023-06-26 19:30:38.344] ModemESP32 init 9600 pass 5
[2023-06-26 19:30:38.344] AT+UART_DEF=9600,8,1,0,0
[2023-06-26 19:30:39.349] AT
[2023-06-26 19:30:39.364] AT
[2023-06-26 19:30:39.364]
[2023-06-26 19:30:39.380] ERROR
[2023-06-26 19:30:39.443] AT
[2023-06-26 19:30:39.458] AT
[2023-06-26 19:30:39.474]
[2023-06-26 19:30:39.474] OK
[2023-06-26 19:30:39.474] Tested AT command and got OK meaning unspecified modem must be awake <–EspressifESP8266
[2023-06-26 19:30:39.490] unspecified modem was already on! Will not run wake function. <–EspressifESP8266
[2023-06-26 19:30:39.490]
[2023-06-26 19:30:39.490] Waiting up to 700 ms for unspecified modem to respond to AT commands…
[2023-06-26 19:30:39.508] AT
[2023-06-26 19:30:39.508] AT
[2023-06-26 19:30:39.521]
[2023-06-26 19:30:39.521] OK
[2023-06-26 19:30:39.537] … AT OK after 45 milliseconds! <–EspressifESP8266
[2023-06-26 19:30:39.537] AT
[2023-06-26 19:30:39.553] AT
[2023-06-26 19:30:39.568]
[2023-06-26 19:30:39.568] OK
[2023-06-26 19:30:39.568] ATE0
[2023-06-26 19:30:39.599] ATE0
[2023-06-26 19:30:39.616]
[2023-06-26 19:30:39.616] OK
[2023-06-26 19:30:39.616] AT+CIPMUX=1
[2023-06-26 19:30:39.647]
[2023-06-26 19:30:39.662] OK
[2023-06-26 19:30:39.662] AT+CWMODE=1
[2023-06-26 19:30:39.710]
[2023-06-26 19:30:39.710] OK
[2023-06-26 19:30:39.725] unspecified modem should be awake and ready to go. <–EspressifESP8266
[2023-06-26 19:30:39.725] Setting up sensors…
[2023-06-26 19:30:40.730] Synchronize the RTC with NIST
[2023-06-26 19:30:40.730] Attempting to connect to the internet and synchronize RTC with NIST
[2023-06-26 19:30:40.730] This may take up to two minutes!
[2023-06-26 19:30:40.746] AT
[2023-06-26 19:30:40.746] WIFI CONNECTED
[2023-06-26 19:30:40.777] WIFI GOT IP
[2023-06-26 19:30:40.811]
[2023-06-26 19:30:40.811] OK
[2023-06-26 19:30:40.824] Tested AT command and got OK meaning unspecified modem must be awake <–EspressifESP8266
[2023-06-26 19:30:40.824] unspecified modem was already on! Will not run wake function. <–EspressifESP8266
[2023-06-26 19:30:40.840]
[2023-06-26 19:30:40.840] Waiting up to 700 ms for unspecified modem to respond to AT commands…
[2023-06-26 19:30:40.840] AT
[2023-06-26 19:30:40.856]
[2023-06-26 19:30:40.856] OK
[2023-06-26 19:30:40.871] … AT OK after 37 milliseconds! <–EspressifESP8266
[2023-06-26 19:30:40.871] AT
[2023-06-26 19:30:40.887]
[2023-06-26 19:30:40.887] OK
[2023-06-26 19:30:40.902] ATE0
[2023-06-26 19:30:40.918]
[2023-06-26 19:30:40.918] OK
[2023-06-26 19:30:40.934] AT+CIPMUX=1
[2023-06-26 19:30:40.965]
[2023-06-26 19:30:40.965] OK
[2023-06-26 19:30:40.981] AT+CWMODE=1
[2023-06-26 19:30:40.997]
[2023-06-26 19:30:41.013] OK
[2023-06-26 19:30:41.013] unspecified modem should be awake and ready to go. <–EspressifESP8266
[2023-06-26 19:30:41.028] … Watchdog low barksUntilReset 50 expected 52
[2023-06-26 19:30:41.028] AT
[2023-06-26 19:30:41.044]
[2023-06-26 19:30:41.044] OK
[2023-06-26 19:30:41.060] Tested AT command and got OK meaning unspecified modem must be awake <–EspressifESP8266
[2023-06-26 19:30:41.060] Modem was already awake and should be ready. <–EspressifESP8266
[2023-06-26 19:30:41.060]
[2023-06-26 19:30:41.060] Attempting to connect to WiFi network… <–EspressifESP8266
[2023-06-26 19:30:41.075] AT+CIPSTATUS
[2023-06-26 19:30:41.091] STATUS:2
[2023-06-26 19:30:41.122]
[2023-06-26 19:30:41.122] OK
[2023-06-26 19:30:41.138] … WiFi connected after 75 milliseconds! <–EspressifESP8266
[2023-06-26 19:30:41.138] Connected to internet for RTC sync with NIST
[2023-06-26 19:30:41.138] PLO postLog file DBG2306.log res len 13 <–LoggerBase
[2023-06-26 19:30:41.154] logPLO err opening DBG2306.log
[2023-06-26 19:30:41.154] postLogLine can’t open file
[2023-06-26 19:30:41.154] AT+CIPSTATUS
[2023-06-26 19:30:41.185] STATUS:2
[2023-06-26 19:30:41.212]
[2023-06-26 19:30:41.217] OK
[2023-06-26 19:30:41.217]
[2023-06-26 19:30:41.217] Connecting to NIST daytime Server <–EspressifESP8266
[2023-06-26 19:30:41.217] AT+CIPCLOSE=0
[2023-06-26 19:30:41.248]
[2023-06-26 19:30:41.264] ERROR
[2023-06-26 19:30:41.279] AT+CIPSTART=0,”TCP”,”time.nist.gov”,37,120
[2023-06-26 19:30:44.638] 0,CONNECT
[2023-06-26 19:30:44.670]
[2023-06-26 19:30:44.670] OK
[2023-06-26 19:30:44.779] AT+CIPSTATUS
[2023-06-26 19:30:44.811] STATUS:3
[2023-06-26 19:30:44.842] +CIPSTATUS:0,”TCP”,”132.163.97.1″,37,59547,0
[2023-06-26 19:30:44.858]
[2023-06-26 19:30:44.874] OK
[2023-06-26 19:30:44.983]
[2023-06-26 19:30:44.983] +IPD,0,4:èDÈU
[2023-06-26 19:30:44.999] 0,CLOSED
[2023-06-26 19:30:49.221] AT+CIPSTATUS
[2023-06-26 19:30:49.253] STATUS:4
[2023-06-26 19:30:49.268]
[2023-06-26 19:30:49.284] OK
[2023-06-26 19:30:49.284] NIST Time server did not respond! <–EspressifESP8266
[2023-06-26 19:30:49.284] AT+CIPSTATUS
[2023-06-26 19:30:49.315] STATUS:4
[2023-06-26 19:30:49.347]
[2023-06-26 19:30:49.347] OK
[2023-06-26 19:30:49.362]
[2023-06-26 19:30:49.362] Connecting to NIST daytime Server <–EspressifESP8266
[2023-06-26 19:30:49.362] AT+CIPCLOSE=0
[2023-06-26 19:30:49.394]
[2023-06-26 19:30:49.394] ERROR
[2023-06-26 19:30:49.409] AT+CIPSTART=0,”TCP”,”time.nist.gov”,37,120
[2023-06-26 19:30:49.519] WATCHDOG ISR barksUntilReset 51 <–WatchDogAVR
[2023-06-26 19:30:49.535] 0,CONNECT
[2023-06-26 19:30:49.567]
[2023-06-26 19:30:49.567] OK
[2023-06-26 19:30:49.598]
[2023-06-26 19:30:49.598] +IPD,0,4:èDÈZ
[2023-06-26 19:30:49.613] 0,CLOSED
[2023-06-26 19:30:49.692] NIST responded after 107 ms <–EspressifESP8266
[2023-06-26 19:30:49.692] AT+CIPSTATUS
[2023-06-26 19:30:49.723] STATUS:4
[2023-06-26 19:30:49.755]
[2023-06-26 19:30:49.755] OK
[2023-06-26 19:30:49.771] NIST Response <–LoggerModem
[2023-06-26 19:30:49.771] Response Byte 0 : è = 232 = 11101000 <–LoggerModem
[2023-06-26 19:30:49.771] Response Byte 1 : D = 68 = 1000100 <–LoggerModem
[2023-06-26 19:30:49.771] Response Byte 2 : È = 200 = 11001000 <–LoggerModem
[2023-06-26 19:30:49.771] Response Byte 3 : Z = 90 = 1011010 <–LoggerModem
[2023-06-26 19:30:49.786] Seconds from Jan 1, 1900 returned by NIST (UTC): 3896821850 = 11101000010001001100100001011010 <–LoggerModem
[2023-06-26 19:30:49.802] Unix Timestamp returned by NIST (UTC): 1687833050 <–LoggerModem [2023-06-26 19:30:49.802] Time for Logger supplied by NIST: 1687804250 -> 2023-06-26T18:30:50-08:00 <–LoggerBase [2023-06-26 19:30:49.802] Current Time on RTC: 1687804249 -> 2023-06-26T18:30:49-08:00 <–LoggerBase
[2023-06-26 19:30:49.817] Offset between NIST and RTC: 1 <–LoggerBase
[2023-06-26 19:30:49.817] Internal Clock within 5 seconds of NIST. -
2023-06-29 at 4:28 PM #17957The processor on the Mayfly isn’t clocked fast enough for reliable two-way communication at 115200. It’s pretty reliable at talking at that speed (ie, to the serial monitor), but when listThe processor on the Mayfly isn’t clocked fast enough for reliable two-way communication at 115200. It’s pretty reliable at talking at that speed (ie, to the serial monitor), but when listening at that speed, it drops and garbles too many characters to be usable.
I don’t know why you had problems compiling the sketch. It compiles and runs for me with both debugging definitions.
The reason initialization is failing is the baud rate. I wrote that example for someone with a new ESP32 bee. In the example, the baud for the modem is first set at 115200, which is what an ESP32 will use at factory defaults. The modem is woken, and the communication is tested at the set baud; if (when) that fails, it tries to reset the baud rate to 9600 and then saves that baud to the ESP32’s flash. Because the slow baud is saved to flash, the initial communication will fail after running the script the first time because the Mayfly is still trying at 115200, but the ESP’s already down to 9600. You can fix it by setting the modemBaud to 9600 in the first place, but remember that that won’t work with a new ESP32 bee. Even if you don’t change the baud, the two should sync after the first attempt at initialization when the Mayfly retries at the slower baud.
-
2023-06-29 at 6:38 PM #17958Thanks for the explanation – I do so appreciate that the code at 9600 baud works, and there is a lot of hard work gone into configuring it – as you say to work both first off and subsequThanks for the explanation – I do so appreciate that the code at 9600 baud works, and there is a lot of hard work gone into configuring it – as you say to work both first off and subsequent power ups.
Coming from a real time programming background I keep forgetting about the simplicity of Arduino. So I keep tripping over issues like this – it will be burnt into my brain someday – it would have been so nice for that explanation to be in place in the code where it goes through gyrations.
I would suggest its actually the architecture that is the real issue, not the lack of cycles which consume power just polling . I’ve used mega2560 with 115200 fast processing in the past.
https://forum.arduino.cc/t/serial-input-basics/278284
and from TinyGsmClientESP8266.h
12345while (stream.available() > 0) {TINY_GSM_YIELD();int8_t a = stream.read();if (a <= 0) continue; // Skip 0x00 bytes, just in casedata += static_cast<char>(a);it needs to receive <NL> before processing the buffer.
My take is the issue is that the buffer handling/parsing is being processed at too high level – and not closer to the hardware. There is a lot of value in reducing power consumption in being able to process the serial stream to/from the MMW faster – so I believe its worth understanding. However I haven’t gone through the layers with TinGSM to understand it.
Some years ago while chatting with a Standford CSU Professor at a TinyOS conference, he said it was so hard to teach people real-time processing, and of course event based processing and finite state machines . Their solution, Berkley/Standford nesC (network embedded systems C) was harder to understand than the problem they where solving.
-
2023-07-10 at 2:52 PM #17971
Thanks for the hint for running at 56K – that has been working.
-
-
AuthorPosts
- You must be logged in to reply to this topic.