[neilh20]

@nick I just tried – and it worked for me with 4 sensors. https://monitormywatershed.org/sites/nh_test230803/

Perhaps you could try starting from the beginning. Nothing bad should happen creating sites.

[neilh20]

I saw this as well. Though it turns out the site was created  .

https://github.com/ODM2/ODM2DataSharingPortal/issues/663

I hoped the issue had gone away, so  I closed it after a few weeks..

I’ll re-open it with a reference to this conversation. I guess its a benefit in tracking bugs. If/when the project gets a burst of energy/focus (or $) then they all get examined.

[neilh20]

@nick IHMO there are few maintenance and ease of use concepts  built into   github.com/EnviroDIY/ModularSensors    & MMW.

To  make it easier, it takes what Computer Science people call “Use Cases” for how equipment is used in the field. There are international standards for managing equipment maintenance states – however they  take more software infrastructure work!

I haven’t found any way of being able to set a MWM node to a “test state”, show the test data separately until its determined that its ready for real data gathering. But maybe it will happen some day.

What you can do is test the parts separately with out POSTs to the “Production” MMW site – that is test with a “dummy test” UUIDs to a test MMW site, and then switch the UUIDs in some form – possibly as a compile option in a ms_cfg.h file. If it compiles and you have eyeballed the data flow, it probably will work.

I’m a great fan of ModularSensors, and its great strength is interfacing to sensors.  I have extended the software for real world equipment management.

I put the UUIDs on the uSD as an .ini file and they are read at initialization. I also build a set of .hex programs for my release, and then I can program all the Mayflys with the same features from this one .hex – and the uSD customizes each hardware unit. Data driven design. I discuss it here. https://www.envirodiy.org/geographical-scaling-modularsensors/

For my replacement board, I test with a “dummy test” of UUIds on the uSD to verify that the board works to MMW.  However it doesn’t upload to the “production” MMW.

In the field they will disconnect the solar panel, battery, and RS485 shield from the Mayfly. Unscrew/remove the Mayfly from the enclosure. Then they will take out the uSD, which has the personalization UUIDs on it, and plug it in the new Mayfly. Then put the board back together – since this is often in the humid riparian zone, take care to keep sweet out your eyes, off the board – and make sure all the pins of these small devices locate properly!!!  Be interested to hear how you make it work!

 

[neilh20]

Thanks for the hint for running at 56K – that has been working.

[neilh20]

@braedon-dority it seems to me you have “bridged” or wirelessly connected one S3B/Mayfly1 to another S3B(XCTU or Mayfly2) and proved the data connection.

A vehicle represents a number of parts  that hang together ~ ModularSensors represents a number of Classes that hang together – the value of open source is you can modify the programs/Classes.

However that implies you’ve launched off on your own – so phrasing your question right,   becomes something you are trying to refine?.

Based on your previous application environment, It seems like you might be asking, “how do I receive the data on Mayfly2 and push it to the .csv file?”

 

[neilh20]

@braedon-dority I would add that the Digi range of modems is extensive- with many functions. They have good “Data Sheets” on their capabilities.

What it sounds like you are asking is can two S3Bs be setup like a “wire” – a link for two S3Bs – a peer-two-peer (P2P) link.
That is “print”  an ASCII serial string to an S3B over the UART and have it come out another S3B uart.

I am afraid its looking at the manual to see if this can be done for the particular model, and follow the examples they give in the manual.

Like a vehicle – for exact technical capabilities dig into the manual

I know some of the 900Mhz models I looked at could do it. However, as its wireless also look at under what conditions it might loose parts the string Good luck.

[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

[Author]

Posts