In my application I need to configure the APN and the PDP context before the system can connect. The APN and the context depend on the customer setup and network (e.g. Verizon, AT&T, Kore, Rogers). What I would like to do is the same thing we do with other wireless modems, such as MultiTech: provision the modem at the factory such that a pristine setup in the field would be able to connect automatically, without having to involve service personnel. This is possible with MultiTech because it persists the relevant configuration command, e.g. AT+CGDCONT=1,“IP”,“ltemobile.apn”,0,0 across a power cycle. Unfortunately, SW AL GL7500 does not. Is there a way to work around it, and, for example, store the desired PDP context and APN during factory provisioning time in some persistent storage in the modem itself, and later retrieve it programmatically by the application for use in the above, sadly, non-persistent command?
Hi sslobodov,
The parameters of the +CGDCONT command are saved in non-volatile memory over module reboot in GL7500.
Which firmware version are you using? Are you using Verizon firmware or AT&T firmware? If you are not in the latest firmware, please download the latest one and retry.
You can get it here AirPrime HL7588 Firmware
Hi Donald,
I did not explain it right. What I meant is that the modem seems to require the command like AT+KCNXCFG=1,“GPRS”,“lteinternet.apn” each time after a restart, where the right PDP context and the APN have to be inferred or stored in the host. For a Verizon modem it seems to be always context 3 and its associated APN returned in the AT+CGDCONT? command. For an AT&T modem with a Rogers SIM, it’s context 1 and the APN returned in the same command. For the AT&T version with a KORE SIM the list returned by AT+CGDCONT? is empty after a restart. Other network access providers have their own APNs that cannot be easily inferred from the output of AT+CGDCONT?, if any. Our application relies on the APN being stored in the modem itself, so that a fully provisioned modem could be connected to any of our systems in the field that support it. This does not seem possible with GL7500, from what I understand. Having to redesign our application presents a significant hurdle for adopting GL7500 for our IoT needs and is holding up purchasing decisions. Any help with figuring out whether we could persistently store the APN and the PDP context in the modem during its factory provisioning step, and use it in the field conditions would be greatly appreciated.
Hi sslobodov,
The +KCNXCFG command is used to configure the bearer to be used for future IP services.
The parameters of the + KCNXCFG command are not saved in non-volatile memory over module reboot in GL7500. The GL7500 does not support the persistent storage of PDP contexts and APN names.
The HL7800 supports restoring the session on boot. You can purchase the HL7800 module.
Help to tick " Solutions" if your question is answered.
Hmm, HL7800 looks like a module to solder on the board, not a standalone modem, so not currently in scope. Is there any general purpose NVRAM storage on GL7500 we could use to store and retrieve the APN name, with an AT command? Only need a few dozen bytes.
Hi sslobodov,
No, there isn’t.
Persisting the state of AT+CGDCONT= appears to be sufficient for our purposes.