I'm curious about the approach taken in the nRF Connect SDK's location library for cell neighbor scans (https://github.com/nrfconnect/sdk-nrf/blob/main/lib/location/scan_cellular.c#L164-L264).
If, as in the asset tracker example's default configuration, a client of this library is performing a cell neighbor scan where cell_count == 3, this implementation would:
- Do a non-GCI extended light neighbor search
- Do a GCI history neighbor search
- (if not enough cells are found) Do a GCI extended light neighbor search
My questions are:
- Since the requested cell count is 3, we know that the function won't exit after the non-GCI neighbor search. Why is this search still performed?
- My best guess is that this is a fallback in case RCC does not become idle within the timeout?
- If RRC is not idle, this is returning cached results from the last scan performed during RRC idle (at best), so it still doesn't seem super valuable?
- Since the GCI extended light search (NCELLMEAS=4,X) will start by doing a history search per the AT command doc (https://docs.nordicsemi.com/bundle/ref_at_commands_nrf91x1/page/REF/at_commands/mob_termination_ctrl_status/ncellmeas_set.html) then extend the search if not enough cells are found, why is the separate GCI history neighbor search done beforehand?
- My best guess is that there's an opportunity the history search can exceed the requested cell_count if there happens to be enough neighbors based on the history, without consuming a whole lot of excess power?
I'm trying to implement neighbor cell scans in my own application and figure out the most power efficient strategy based on my requirements, hence why I'm trying to understand the approach taken in the nRF Connect SDK (I figure if anyone knows what they're doing here, its Nordic's own software developers).
Any insights would be greatly appreciated!