cellular turn off upon location wait.

[shlomots]

I want to fix the problem of insufficient time windows when I search for a fix. 
I know that the recommended way is to use priority mode + EDX + PSM, but I tried to just turn the cellular capabilities while searching for a fix and it worked fine. 
The only thing I don't understand is why this isn't recommended at least as an option in the case it fits my use case. am I missing something?

https://academy.nordicsemi.com/courses/cellular-iot-fundamentals/lessons/lesson-6-cellular-fundamentals/?version=v3.3.0

I saw the recommendations in this chapter of the cellular course.

Thanks in advance,

Shlomo.

[Øyvind]

Hello, 

Here is an answer from out chat bot:

Great question! You're not missing anything fundamental — turning off the cellular modem while searching for a GNSS fix is actually a valid approach and is even mentioned in the course material.

From the exercise content:

"In an actual application, you wouldn't completely deactivate LTE but rather configure PSM or eDRX so that the GNSS and LTE can be used rather often without having to completely activate and deactivate the modes." [Exercise 1]

This hints at the key trade-off: the reason it's not the primary recommendation is about usability and connectivity, not correctness. Here's what you'd be giving up:

• No real-time data transmission: While searching for a fix, your device is completely offline. You can't send or receive data until you re-enable LTE. This is a significant limitation for many IoT use cases (e.g., asset tracking where you want to send location data as soon as it's acquired).
• Re-attach overhead: Depending on your network configuration, deactivating and reactivating the modem may require going through a power-consuming attach/registration procedure again, negating some of the power savings.
• Latency: If your application needs to respond to downlink messages (e.g., commands from a server) while also getting a fix, this approach makes that impossible.

PSM and eDRX are recommended because they allow both GNSS and LTE to coexist — the modem stays registered with the network while giving GNSS sufficient time windows during sleep periods. [Exercise 2]

If your use case allows for the device to be fully offline during GNSS acquisition (e.g., you only need to send location data periodically and don't need to receive anything in between), then deactivating LTE during the fix search is a perfectly reasonable and simpler solution. The course just doesn't highlight it as the primary path because it doesn't generalize well to most IoT applications.

Let me know how that works for you.

Kind regards,
Øyvind

[shlomots]

sounds fair enough, but I am trying to use this approach together with the cellular location fallback, and I am having a problem with the PDN.

[00:03:35.936,523] <dbg> location: scan_cellular_execute: GCI history search (NCELLMEAS=3,5)
[00:03:36.394,256] <dbg> location: scan_cellular_lte_ind_handler: Cell measurements results received: ncells_count=0, gci_cells_count=3, current_cell.id=0xFFFFFFFF
[00:03:36.394,256] <dbg> location: scan_cellular_lte_ind_handler: No neighbor cell information from modem
[00:03:36.399,719] <wrn> location: Default PDN context is NOT active, cannot retrieve a location
[00:03:36.399,749] <err> location: Location acquisition failed and fallbacks are also done
[00:03:36.399,749] <dbg> location: location_utils_event_dispatch: Dispatching event: type=3
[00:03:36.399,780] <dbg> location: location_utils_event_dispatch: - handler=0x0001F749
[00:03:36.399,902] <inf> slm_gps: SAT: tracked=2 using=2 weak=0 unhealthy=0 fix

This happens because the PDN is assigned after the lte network reconnects. 

What is the recommended fix for that?