Telelogger Setup Issue - Config file fault mishandling

[ryanww]

I have been pulling my hair out and finally found a pretty bad bug.

I had storage configured in the config.h to use a different APN provider. In monitoring the device, it would show APN as being correct in the console. I also realized I had storage set as SD, but didn't have a SD card in there.

Within the setup function, there is this block of code:
ESP_ERROR_CHECK( err ); err = nvs_open("storage", NVS_READWRITE, &nvs); if (err == ESP_OK) { loadConfig(); }

Since the SD card was not in the unit, this function was not returning an ESP_OK state, and thus, would not call loadConfig(). Within that function, it is copying CELL_APN over to the apn variable, and actually setting the cell modem's APN.

The issue is that everything looks completely normal from the console. APN shows correct, unit acts like its reporting up and so forth. But really, this shouldn't be in a run state, since the loadConfig() was never called. There really needs to either be some feedback or just hold the whole routine and report an error.

[stanleyhuangyc]

The block of code you quoted has nothing to do with SD card. Also config data are stored in ESP32's flash memory no matter which storage option you set which is in regard to telemetry log data.

[ryanww]

Well what I can say is that as soon as I commented the #define STORAGE out, everything loaded properly. Uncommenting this caused err variable to be something other then ESP_OK, and thus not running loadConfig() and in turn, not setting the APN, no bluetooth, no wifi.. In any event, the console still reported "APN:xxx" as set in the config.h file, but the cell chip was trying to join the hologram APN that is incorrect. So that was really throwing me for a loop.

`/**************************************

• Data storage configurations
  **************************************/
  #ifndef STORAGE
  // change the following line to change storage type
  // #define STORAGE STORAGE_SD
  #endif
  `

[stanleyhuangyc]

loadConfig has nothing to do with STORAGE if you look at the code. It simply loads APN setting from NVS (onboard flash).
More likely cause of your issue is that you set the APN via the App over BLE and it is stored in NVS. You then changed APN in config.h but it is not used as the setting in the NVS (loaded by loadConfig) is always used.

[ryanww]

The only file edited is config.h. Setting the APN on 92: #define CELL_APN "data00.telnyx"

Doing this on line 144, the unit fully boots and runs with the correct APN, Bluetooth works, etc...:
// #define STORAGE STORAGE_SD

Doing this, the unit DOES NOT run properly, incorrect APN on cell modem (though the console shows the correct one), no bluetooth.
#define STORAGE STORAGE_SD

Regardless, I can say that is the one change that is causing the framework to start up and assigned the right APN, or not. Feel free to give it a try based on the current repo. As I mention above, there is something not right with the boot up routine.

[stanleyhuangyc]

Have you ever changed APN via App (BLE)?

[stanleyhuangyc]

Actually I test devices without SD card every day (before shipping) and never encounter any issue.

[ryanww]

Negative. I've never had Bluetooth function until I commented this line out today. After I realized it, I was able to connect via Bluetooth, but the app never loaded the parameters, and I didn't try setting it either. I've only pushed this library and the cell test library. Neither worked from the beginning and only the telematics library works with that commented.

[ryanww]

I bought 3, and all 3 act the same way. After failing to connect to Telnyx, I bought a Hologram card, and that worked. When I reached out to Telnyx, they let me know it was trying to connect to their network using their sim and an APN of hologram, even though the console was saying APN:data.telnyx. After I went digging today, I tried commenting that line out, and that is what allowed 2 of the 3 (haven't gotten back to the last one) worked right off the bat and connected to telnyx.

[stanleyhuangyc]

That is really weird as the APN printed in serial output and used should be the same.

[ryanww]

I completely agree! I didn't have enough time to really dive in, but I was at least able to get it to run by that one line being commented out. So there's certainly a bug in this somewhere.. And based on some of the other peoples posts in the forums, I have a feeling this is contributing to those issues.