Posts made by aezero

@felmue Thanks, Felix! You're the best!

Hi all,

I have a number of COM.LTE modems running successfully with CoreBasic units. I was just going through some of my code to make a list of which pins are available for use when I noticed a reference to pin 2 during the modem initialization.

I see it show up in almost every sample config and forum post like this:

SerialAT.begin(115200, SERIAL_8N1, 5, 13); 
pinMode(2, OUTPUT);
digitalWrite(2, 0);
delay(3000);
digitalWrite(2, 1);

What is the purpose of pin 2 here? Many of the examples will have a comment along the lines of "set pin 2 high for using the modem (simulates a power button press)".

My code doesn't have the two digitalWrite lines, but a single modem.restart() and it has been working fine. As an experiment, I tried removing the pinMode(2, OUTPUT) line in my code and reassigning it as an input connected to a toggle switch, and everything still seems to be fine.

Thanks!

aezero

I just made another discovery. If you power it up with the factory demo software, go the home screen, and then tap on "CORES3" six times, it puts you into a factory test mode

And on further examination, there's the dark grey PB_IN and PB_OUT pins, at G8 and G9. The splash screen when you power it on shows G8 and G9 are on Port B (there's a typo, saying "Port.C" but it's in the position of the black Port B connector).

Looking at the pinout diagrams with some refreshed eyes and I see it now... "PA" is short for "Port A" and "PC" is short for "Port C". And PA has a red background, like the red Port A connector, and PC is in the same light blue as Port C's connector.

@felmue
Hi Felix! Good to hear from you again!

Thanks for the clarification! The second serial connection is the blue connector, right?

Hi all!

I just got my first CoreS3 yesterday. I've been using the original Core with COM.LTE modules for a product/project I've been working on. I'd really like to start using the CoreS3 instead, as it has so many more features that are perfect for my project. But it looks like the M-BUS connector has a slightly different pinout. Am I able to use the COM.LTE with the CoreS3?

By default, the COM.LTE uses pins 5 and 13, which are listed as the GPIO and IIS_WS pins, respectively. On the CoreS3, those same pins are PA_SCL G1 and GPIO G7. Is the PA_SCL pin the SCL on the external red I2C connector? I do need that for some sensors.

I could use the DIP switches to change from using pin 5 to using 15 or 16. 15 was formerly IIS_OUT but is now I2S_DOUT, which I'm assuming is for the speaker, which I need. 16 was formerly RXD2 but is now PC_RX G18. Not sure what that pin is for.

Thanks! I'm so excited to get this new unit going!

aezero

Hi all,

From what I've read, there isn't a way to monitor the battery level on a Basic Core ESP32 using the Arduino IDE. Is there at least a way to monitor if the battery is present (ie that it hasn't failed)? There's M5.Power.isCharging(), but that will show as true even with the battery removed.

Thanks!

@flypeek It definitely compiles smaller! I got it down to around 250KB with the SerialMon disabled. The only issue I have is that it doesn't light up the backlight on the screen. I can see the text is there if I hold up a flashlight to it. Any idea how to light it up? I've been doing some searching, and it doesn't look like it's a simple HIGH/LOW sent to pin 32. The M5Stack.Lcd library says it's PWM controlled.

Thanks!

That helps! Thank you!

I'm going to drop the SerialMon stuff too. I only added it just in case I had a unit with a faulty screen, but then I realized that if the screen were faulty, no one would see the message to bring it back to me. And why would I want a unit with a faulty screen? LOL!

Hi all,

I'm going to be deploying a bunch of M5Stack core units with LTE modems. I have been writing a small firmware that I can push to them OTA in case a unit gets lost or stolen. This way, the original firmware if replaced with a "if found, return to..." message. It's very simple but still compiles to 346KB, which does not OTA very quickly (Carrier problem. I have another thread that explains why.). I'd really like to get this to a smaller size, if I can. Is there a way to either optimize the compiler to shed code that it doesn't use (ie. wifi, etc), or can I manually trim down the M5stack library?

Thanks!!

#define SerialMon Serial

void debug(String msg) {
    SerialMon.print(msg);
    M5.Lcd.print(msg);
}

void debugln(String msg) {
    SerialMon.println(msg);
    M5.Lcd.println(msg);
}

void setup() {
    M5.begin();
    SerialMon.begin(115200);
    M5.Lcd.clear(TFT_BLACK);
    M5.Lcd.setTextSize(3);
    M5.Lcd.setTextColor(TFT_WHITE, TFT_BLACK);
    debugln(F("If found, call"));
    debugln(F("xxxxxxxx"));
    debugln(F("xxxxxxxxxxxxx"));
    debugln(F(""));
    debugln(F("or return to"));
    debugln(F("xxxxxxxxxx"));
    debugln(F("xxxxxxxx"));
    debugln(F("xxxxxxxxxxxx"));
    debugln(F("xxxxxxxxxxxx"));
    }

void loop() {
}

Hi all!

I figured I'd update this thread with my findings. I've been running a unit in my non-insulated plastic shed for two months of Canadian winter with no problems whatsoever. The screen turned on immediately and is perfectly fine. No unexplained lockups, reboots, or other glitches.

It has been a relatively warm winter (unfortunate for my testing). Inside the shed, it got down to -15C one weekend, but for the rest of the time, it has been between 0C and -6C. Humidity has been an average of 78% with a peak at 97%.

Hi all,

I'm planning on rolling out a few hundred M5 Basics for a project, and I'm hoping to be able to offload as much of the grunt work as possible to the junior techs (lol). If I export my code as a .bin file, what's the easiest way to get them to flash it onto brand new units? I was thinking I could just make them a little bundle with the .bin, esptool, and a batch file for them to run. I don't want to have them install the Arduino IDE and give them the source, just in case someone accidentally entered some characters, or there was a library that changed.

If they could flash multiple simultaneously, that would be even better.

Thanks in advance!

@ajb2k3 Good to know! The Core ESP32 bundle is pretty cheap. The COM.LTE is the most expensive part.

@teastain Thanks for the reply!

I'm actually not too worried about the LCD failing, unless it fails in such a way that it takes down the whole unit. I'm only going to have the LCD enabled for the initial setup, then it will be off. I know Expressif lists the ESP32 operating range as -40C to +125C.

I'm also running a COM.LTE in it. The SIM7600 lists -40C to +85C.

I guess I'll need to stick one out in the back yard next month and see what happens :)

Hi all,

Has anyone had any luck running a Core ESP32 in non-temperature-controlled environments? I'm in an area of Canada where we'll get winters down in the -25C area and summers up to 40C. The Cores would be in utility boxes, to monitor the gear inside. They'd get a little warmth from the gear in winter, but would still be subzero. In the summer, they'd have the outdoor temperature, plus the warmth off the gear (no air conditioning or fans in the utlity boxes), so it'd likely be 50C.

Thanks!

Hi @felmue!

Good news! I got this working using the most ridiculous solution. My 220KiB test firmware would write in about 105 seconds, so approximately 2KiB/sec. I enabled mod_ratelimit on Apache and gave a 2KiB/sec rate limit to my firmware directory.

<IfModule ratelimit_module>
SetOutputFilter RATE_LIMIT
SetEnv rate-limit 2
</IfModule>

Now the firmware gets written at roughly the same rate at which it downloads, keeping the TCP session active the whole time, instead of the "burst then die while idle" connection behavior from before.

Thank you for all your help!

Hi Felix,

That's correct, it fails every time. When tinkering with it yesterday, I had a couple runs that actually got past the 60 second timeout, but I couldn't pin it down to a specific reason. I started digging around online about TinyGSM. They even have this in their main Github page:

"If you are able to open a TCP connection but have the connection close before receiving data, try adding a keep-alive header to your request. Some modules (ie, the SIM7000 in SSL mode) will immediately throw away any un-read data when the remote server closes the connection - sometimes without even giving a notification that data arrived in the first place. When using MQTT, to keep a continuous connection you may need to reduce your keep-alive interval (PINGREQ/PINGRESP)."

That does somewhat align with what I'm seeing. I added a .htaccess file onto the server to enable keep-alive with a pretty long interval, but it doesn't seem to have helped.

Regarding tasks, I do have it doing a few things, which I had completely working before I started on this OTA endeavour. It is an M5Stack Core with a display, an ENV III sensor, and a battery

• In setup():
• • After powering on, it checks if it is running on battery (to alert me about power outages)
• • Intialize the ENV III sensor
• • Initialize the screen
• • Initialize the modem
• In loop()
• • Update the screen
• • Get temperure/humidity readings
• • It calls a function to submit the results to my server via HTTP
• • Handle any error that the server returns, which includes it needing a firmware update. It then calls a function that has your code.
• • Then there is a while loop that runs for five minutes to watch for the buttons to be pressed.

In regards to power, the same failure occurs if it running on the internal battery or an external charger.

I think my priority here is to find a way to make the connection stay up through the 60 second barrier that seems to be imposed by the CGNAT. I am planning on deploying a number of these units, and many of the locations are rural with very poor cellular coverage, so I am expecting slow transfers. I just picked up a SIM from other carrier, which I am going to test to see if their CGNAT behaves differently.

Thanks for all your guidance!

UPDATE: Different carrier didn't have an issue with their CGNAT. I'm thinking it's because that one is a consumer service, and the one that's giving me problems is M2M specifically.

@felmue
Hi Felix!

My setup differs from yours in that I initialize the modem, do a post of data from the onboard sensors which includes the version number, then the server returns a message to it to indicate that it needs to download a firmware update. That's where I have your code run within a function instead of the main loop. So the modem already has been initialized and has working data connectivity.

I've tried a number of things over the weekend to no avail, including:

• Changing TINY_GSM_RX_BUFFER to very low values
• Reinitializing the modem within my updateFirmware function (including this step makes it almost your code verbatim)
• Removing the lte.connected() and lte.available() from the while loops

I forgot to mention, I'm downloading the same replacement firmware when I use your code and mine (it just says "It worked!" on the console), so won't contibute any differences.

@felmue Thank you so much!!! I wish I had gotten some kind of notification when you posted this! Otherwise I wouldn't have burned an entire working week of failing to get other people's libraries to work!

I loaded up your sketch and tweaked it to my modem (SIM7600) and it flawlessly downloaded a bin file and flashed it. Curiously, when I merged it into my sketch, I get the output below when trying to download the same bin file. I wonder if maybe my sketch takes up too much memory and it can't store it or something.

UPDATE 1: I did a packet capture on the web server. I can see the server transmitting the entire file, and I can see the ESP32 acknowledging the entire transmission. It's not disconnecting while downloading, so it must be something from when it goes from memory into flash. The "actually read" value does fluctuate, but is always in the range of 120000-160000.

UPDATE 2: I just noticed the duration value is always 59s +/- 0.5. With your original version, it is always 35s.

UPDATE 3: This 59s thing caught my attention. I tried switching the SIM over to another APN. The original APN uses Carrier-Grade NAT and the new one gives the modem a real public IP without any NAT. Now the new firmware downloads successfully (after around 105s). I'm guessing the 59s is actually the CGNAT timeout. That being said, I need this thing to work behind CGNAT for a few reasons. So I guess this now boils down to two questions:

• Why is my sketch taking so much longer? It's basically your script pasted into mine almost verbatim. It's exactly three times longer, curiously...
• Is there any way to decouple the flashing process from the LTE connection? I could see in my packet capture that the download completed in under one second. I'm assuming that data is stored in some sort of buffer on the modem itself. Is there a way to do something like disconnecting from the LTE but keeping the data in the buffer and letting the flash happen at its own pace? Or how do I keep the NAT translation on the LTE connection alive?

Any ideas?

Content-length: 233040
Update begin ok
Reading response data

0.00% 7.69% 15.38% 23.08% 30.77% 38.46% 46.15% 53.85% 55.73%
Error Occurred. Error #: 12

Content-Length: 233040
Actually read: 129867
Duration: 58.87s