NRF9151 replaces NRF9160: LTE not working any more

[AraNRF91]

Greetings,

we developed a custom board with a NRF9160 last year to be used with NB-IoT (LTE-M as Fallback) to communicate over HTTPS with our Servers. Now this worked quite well and without any problems, every LTE Connection built up and established in under 10 seconds.

Now with the change from the NRF9160 to the NRF9151 we adjusted the Driver to what was written as changes in the new Documentation (new RX/TX length of modem, UICR, internal Clock, CFUN=1 after config,...). We are using the embassy-net-nrf91 Rust driver. But the NRF9151 does not get any connection to any LTE provider. We can clearly communicate fully with the modem and also get all information from the Sim-Card (no eSim) and do all AT-Commands with correct/possible Responses. The NRF9160-Board still works with the new firmware but not the NRF9151, and it takes now about 30 seconds to establish a connection. 

Now the question is: What has to be changed for the driver or hardware to get the new Board with the NRF9151 working as this is the only hardware changed in the whole process? Are there changes in the LTE-Provider-Call setup or similar?

You can take a look at the patched Rust driver at https://github.com/embassy-rs/embassy/pull/4098 (currently dirty PR, needs rebase cleaned). The driver is based on the nrf_modem_lib.c et.al.

Edit: working on Ubuntu Linux 24.04.2 LTS with VSCodium 192.2, rustup 1.28.1, rustc 1.85.1, embassy at 141c170d + Patch

[AraNRF91]

i created a full log from starting the lte test application with setting up IPC and configuring everything for the modem to the whole "wait for lte connection" until the timeout after 60secs; it also includes the modem trace, marked with "modem trace:" as well as the libraries modem traces.

As the log is too big for posting it here, i added it at lte_standalone_nRF9160_xxAA_1749196801820_channel0.txt

[Hakon]

Can you please provide a modem trace in the format .mtrace or .bin?

[AraNRF91]

i gathered the modem trace as mtrace and the regarding full log again here:

nrf9151_lte_example_nRF9160_xxAA_1750233445688_channel0.mtrace

nrf9151_lte_example_nRF9160_xxAA_1750233445688_channel0.txt

as i experimented further with the modem and AT commands i found, that using "AT+COPS=?" for searching operator cells nearby draws 6 times the usual current but while setting CFUN=1 and waiting for attach the modems power draw does not change in comparison to CFUN=0? Are there any other commands or functions to be activated to power on the modem for CFUN=1?

Also while working on a improved lib with extended tracing and capability to extend the AT usage, we found that only very few already have a NRF9151, which is why approving and verifying is certainly very hard. We will get a nrf9151-DK to test on it in the next weeks.

[Hakon]

AraNRF91 said:

i gathered the modem trace as mtrace and the regarding full log again here:

Thanks, what modem firmware is this captured with?

[AraNRF91]

so after a long try-and-error path, refactoring the modem lib and manual analysis of the traces  i got the NRF9151 working with LTE again:

Make sure any AT search commands are off as at starting the lib mine tried to search for nearby towers and then when you use "CFUN=1" for full-conn and try to connect, the search param strictly prohibit the modem to connect to any cell. Therefore by (forcefully) disabling any search and then trying a reconnect, i finally got to re-attach my network successfull, with repeated and verified checks. And with CFUN=1 the CGATT ist automatically started, do not try to do both AT commands as those could conflict on the modem too. So in short:

AT+CFUN=0       // Set functionality mode off to configure
AT+COPS=0       // Automatic operator selection
AT%XSYSTEMMODE=1,1,0,1      // Set system mode preferences
AT+CGDCONT <APN-Config>     // Set APN Config
AT+CGAUTH <username, password>      // if used pass auth data
AT+CPIN <pin>       // if used add SIM Pin
AT+CFUN=1       // activate the modem
loop {
  AT+CGATT        // loop this until connected and returns 1
  ...

To verify your modem is ready and antenna and other hardware are intact and functioning, i used the "AT+COPS=?" to get a full list of all surrounding cell towers. Try that before digging too deep into the code while the hardware could be bogged.

This was my "final frontier" for this problem. On the way i adjusted many more options and measurements which you can read through in this chat, in the problem description or the public Rust driver.