[neilh20]

Thanks 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

while (stream.available() > 0) { TINY_GSM_YIELD(); int8_t a = stream.read(); if (a <= 0) continue; // Skip 0x00 bytes, just in case data += static_cast<char>(a);

1 2 3 4 5

while (stream.available() > 0) {         TINY_GSM_YIELD();         int8_t a = stream.read();         if (a <= 0) continue;  // Skip 0x00 bytes, just in case         data += 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.

http://tinyos.stanford.edu/tinyos-wiki/index.php/Getting_Started_with_TinyOS#The_BlinkAppC.nc_Configuration

 

[neilh20]

Thanks 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_DEEP

C

SerialStd.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 modem if (modemPhy.modemWake()) break; SerialStd.print(" ModemESP32 init 9600 pass "); SerialStd.println(ntries); // if that didn't work, try changing baud rate modemSerial.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 modem SerialStd.println(F("Synchronize the RTC with NIST")); dataLogger.syncRTC();

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

SerialStd.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 modem         if (modemPhy.modemWake()) break;         SerialStd.print(" ModemESP32 init 9600 pass ");         SerialStd.println(ntries);         // if that didn't work, try changing baud rate         modemSerial.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 modem     SerialStd.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.

[neilh20]

Hello Dan, thanks for the info. I’m using RevX from Digikey “,”1998-251-ND”,”VERIZON SIM TRIPLE FF CAT-M” with XB3-CA-2/XB3M1

For the Enviro LTE Bee, RevX supports suggests ATT may be more flexible, so fairly low rish ~ 1998-1011-ND RevX Systems Corp. TRI SIM 2FF/3FF/4FF SIM AT&T
I’ve got a query out to Digikey about an M5Stack Variant of the SIM7080G for which networks it works on. https://forum.digikey.com/t/m5stack-u128-which-cellular-networks/31823/2
Seems like Digikey should have that as part of supplying the devices, though its not a XBee format.

I’d be interested in any perceptions/timeline on how long you found the XB3-C-A2 worked for you before failing. I’ve got a number that I’ve used, and doing some focused testing in Jan/Feb this year and some more I’m deploying. I have made some adaptions to TinyGSM to handle some issues in the way it connects, so I’ve got my fingers crossed.

[neilh20]

I think I found the answer by emailing support@rexV, since I got it from amazon.com Mar.2022 it wasn’t certified for Verizon.

This can be checked https://opendevelopment.verizonwireless.com/activation-troubleshooting

support@RexV said “RevX does not certify devices for use on M2M/IoT rate plans, rather the manufacturer registers the IMEI with the carrier for end certification”

I guess I can try the one I have on another network and see if it works.

@mbarney, I was wondering where did you get your latest ones that work with Verizon. Many thanks

 

I was wondering, @shicks do you have a date for when the current stock of EnviroDIY LTE Bee SIM7080G parts was placed on Amazon.

amazon.com/gp/product/B09W3N37LL/ref=ox_sc_act_title_1?smid=AUR1TC3X771V3&psc=1

many thanks

[neilh20]

Hello @mbarney,  or @dan-wachusett  I’m looking to try the LTE BEE – just wondering if you have used the RevX Verizon CAT-M sims.

I have been using it with the Dig XB3-C-A2 and have a few spare. Seems like it should work at this stage, but many ships have foundered on unseen shoals.!

[neilh20]

There is some onchip references, but maybe not useful. From the manual mega164A_PA-324A_PA-644A_PA-1284_P_Data-Sheet-40002070B.pdf   (applies to the mega1284)

Chp 23.2: “<span class=”fontstyle0″>Internal reference voltages of nominally 1.1V, 2.56V, or AV</span><span class=”fontstyle0″>CC </span><span class=”fontstyle0″>are provided On-chip. The voltage reference may be externally decoupled at the AREF pin by a capacitor for better noise performance. </span> ”

However the benefit of the 3.3V is that its +-1% – whereas the 1.1V and 2.56 are +/- ~10%

[neilh20]

Hey thanks for the overview. Welcome to the art of jumping in – and learning by doing (my philosophy though I’m an EE graduate) – though its beneficial to bring an engineering basis to analyzing the components, and then plug the components together.  The engineering basis can be thought of as a technical story – though for EE graduates we talk about engineering requirements.

I’d suggest looking at how to interface to the Campbell Scientific – that is can you inject some dimension less numbers in some fashion and have it come out the other side somewhere that can be used.  Maybe other people know more about it, than I do – but you may want the specific model numbers.  I looked at trying to work with a 20yr old CS recently, and concluded it really needed a whole new upgrade  – and actually finding the satellite channels for even an upgrade  was going to be one challenge.

At the simplest level, if you have some Analog inputs available on the Campbell scientific, then it could be case of “extending” those inputs remotely, and scaling the input voltage to your snow depth units.

So then on the snow depth sensor,  how does the sensor present its measurement   – from other posts on the board it seems you are trying to measure some voltages, so may be that is the snow depth measurement.  So then what is the range of the depth measurement. you want to make and what is the dynamic range and resolution on the sensor. That is the sensor might have a dynamic range of 3meter with an accuracy of +/10cm, but actually you are only interested in if there is 0-5cm increase of snow in a 1hour period.

Maybe some other people have better insights – but that would be my first guess at defining what you want to achieve

[neilh20]

Gosh Brandon, I successfully used the 900Mhz modules about 15years ago with the TinyOS framework.

Seems you are thinking of using it in a Peer-2-peer arrangement, possibly in a mesh configuration. A lot of options.

I wonder what your back ground is  – cause its sort of like jumping into the deep end, and you may wanna flesh out your plan – what your basic intent is.  Is there any reason XBee Pro S3B, and not a LoRa in a peer to peer? (Digi XBee LR).

From what I remember, for some of the Xbee’s you can configure in a point to point mode, and then it looks like you are sending data down a wire. The critical issue is that through the XCTU you configure two units to look like a wire  – start with XCTU and data sheet of the devices.  Of course if you are sending in JSON one end , then you need to have a JSON parser the other end. So that means you want to design your JSON packet. Of course JSON is bulky and thats where if you use the simplest binary numbers, it could fit in a LoRa packet, thats why I bring up the differences.

[neilh20]

Hi @dani68k, welcome to EnviroDIY.

I’ve not got any experience on the ATmega32u4, and as a small AVR processor I would think you would need to customize your development for it. SDI-12 bit banging is very sensitive (unrelaible) if the timing isn’t configured right. Possibly using the USART would be better for timeing, but configuring that is another story. Also needs compute the CRC in the allocated time.

 

My approach would be to separate the development in to two parts  divide the problem into smaller testable parts – one proving the SDI-12 protocol/ response and the other reading the sensor over I2C.

Say every time there is SDI12 request – after any response to the host, flash the led for a correctly decoded CRC and a different sequence for failed CRC  – that way you know if the basic request msg was received OK.

Then for successful request return an incrementing number, that way you can see that all the protocol is working, and the response CRC is being correctly calculated.

Then separately, set up program so that say every 10seconds it reads the PH sensor, computes the units correctly and displays it with print the basic format you want to send as well as human readable format.

Of course with realtime protocols like SDI12, and reading a sensor, prints do impact the real-time nature and may cause realtime bugs just using them. Having the USB interface does allow prints to come out, but also implies you need to understand how the queue is maintained inside the 32u4

Unfortunately, its easy for many things to go wrong, and sometimes it takes focused analysis on the data flow to see the way it might work, and then tweak the program to work that way.

When asking for help, you may want to be explicit as to  which library’s/systems  you are using, devices you are using and do all the work for any reader with links.

 

good luck with it

 

[neilh20]

Thanks to @ptomasula for fixing https://github.com/ODM2/ODM2DataSharingPortal/issues/658

If I understand it right, the internal redirection for  POST to MonitorMyWatershed.org/api/data-stream/ HTTP/1.1 got broken with the upgrade to v0.15.0, and a http response of 301 was returned, which ModularSensors doesn’t handle. Of course its not a good idea for ModularSensors to handle a redireciton, as its expensive in power.

Given the failure, and that my fork has built in reliability  https://github.com/neilh10/ModularSensors/wiki/1a-Feature-notes I’ve been monitoring the responses from 4 systems and characterizing the server after the upgrade.

I’m afraid the server seems to have degraded after this upgrade, I wonder if anybody else is seeing different results after the upgrade.?

I’ve put my results here https://github.com/ODM2/ODM2DataSharingPortal/issues/661

A previous reference is here https://github.com/ODM2/ODM2DataSharingPortal/issues/552

I’m happy to run this against a staging server if available.

[Author]

Posts