Timing Advance reading too high and neighbouring cells unable to be parsed.

Hi there,

I am using an nRF9160DK and looking to get accurate Timing Advance numbers from it and also information on neighbouring cells.  I believe in order to get an accurate figure for TA from the serving cell, I need my RCC Mode to be 'connected', then to get information about neighbouring cells RCC Mode needs to be 'Idle'.  This seems to almost give me the right results with two issues (as detailed below).  The sequence of setting things up in the code is:

nrf_modem_lib_init();
lte_lc_connect_async(lte_handler);
lte_lc_connect();
Which shows me connected in RCC Mode whislt I send a few text messages and do my first "AT%NCELLMEAS"
The result of that is:
%NCELLMEAS: 0,"00165701","53001","A320",160,9485,220,50,18,3949,3947
Cell ID, MCC, MNC etc. are correct but I am only about 600m from the tower, yet a TA of 160 puts me at 160*78m = 12.5km.  Am I calculating the TA wrong or is there any additional mode's I need to turn on (for example I remember with 2G TA could only be measured whilst in a phone call)?
Second question.
After I do the abouve, I wait till I see 'RCC Mode: Idle' from the handler then do a "AT%NCELLMEAS=3,2" , and get:
%NCELLMEAS: 0,"00165701","53001","A320",160,14267,9485,220,56,21,19043,1,0,"0004A605","53001","A320",65535,0,9485,479,43,8,19043,0,0
[00:00:20.319,580] <err> lte_lc: Parsing of neighbor cells failed, err: -95
Again, the neighbouring cell is in the general area (according to OpenCellID), so that is good, but I am not sure what the error -95 means?  My responce buffer is set up as char response[200]; so the 132 character reply fits in it ok. 
Any guidance would be great!
Thanks
Parents
  • Hello, 
    Could you please provide what version of the modem FW you are running on your device? What are you trying to achieve? 

    but I am not sure what the error -95 means

    From nrfxlib\nrf_modem\include\nrf_errno.h - 

    #define NRF_EOPNOTSUPP 95       /**< Operation not supported on socket */
    I am using an nRF9160DK and looking to get accurate Timing Advance numbers from it and also information on neighbouring cells. 

    The AT%NCELLMEAS is documented here

    .  Am I calculating the TA wrong

    Where do you have this calculation from? I'm not aware of how to calculate this, and could not find this in the referenced 3GPP documentation. 

    Kind regards,
    Øyvind

  • Hey there,

    Thanks for the reply.  I am trying to get an accurate timing advance number and neighbouring cell ID's for location purposes. I'm running firmware mfw_nrf9160_1.3.7

    The timing advance usually calculated out to be 78m (or so) per unit.  See here:The LTE Timing Advance – WirelessMoves and 4G LTE Timing Advance Distance Calculator | 5G-Tools.com

    Therefore a TA of 160 should equal a distance of around 12.5km, which is reading from the device about 12km farther than it should be.  I have since done a walk to the cell tower and the TA numbers did decrease and eventually went to '0' when I was right by the tower.  So it seem like it is some form of TA value, but I am not sure what the scale is (it's calculating out to about 3m per unit at present).

    For the error, my probelm is that I am doing nothing but running the following command (once RRC is showing as 'Idle'):

    err = nrf_modem_at_cmd(response, sizeof(response), "AT%NCELLMEAS=5,3");
    and then in my handle I have this code as a place holder:
    static void cellMeasHandle(const char *notif)
    {
        printk("cell measurement complete");
    }
    but get the  "<err> lte_lc: Parsing of neighbor cells failed, err: -95" come up in the console.  This does not happen when I run the following:
    err = nrf_modem_at_cmd(response, sizeof(response), "AT%NCELLMEAS");
    So I am just wondering why this error occurs for the NCELLMEAS command when I give it a 5,3 argument vs. no argument.  The only other difference is I deliberately run the no argument command when RRC is 'Connected' and the 5,3 version when the RRC is 'Idle' (which I have to do to get the neighbouring cell data).
    After a little more investigation, this does not occur in the Serial Terminal run from nRF Desktop (as expected as there is no parsing), and only seems to be an issue the first time the AT%NCELLMEAS=5,3 is called.  Subesequent calls seem to work ok.  So I think there may be an issue in the parser somewhere?  I'll try and look into it a bit more when I get the chance from my end.
  • As for the error from your parsing code, I still have to look into that more, but have to move house in between. Any indication on how to avoid the error coming up would be helpful. 

  • Hello, thanks for your patience.

    The problem is most likely that you are directly calling %NCELLMEAS and not calling lte_lc_neighbor_cell_measurement() to trigger the measurement. LTE LC needs to know the measurement parameters to be able to parse the notification correctly

  • Hey there, 

    oh, I didn’t even know that function existed. Are the parameters detailed anywhere?  I’m struggling to find the information. 

  • No, that's is an issue that our developers will fix. They do see that the information is lacking. 

    That said, if you are using LTE LC, you should be using i.e. lte_lc_neighbor_cell_measurement()

  • OK, I’ll see if I can work out how to use lte_lc_neighbor_cell_measurement() myself but if I struggle I’ll just use have to live with the parsing errors till the function has a little more documentation. Thanks for bringing it to the attention of your developers. 

  • Reply Children
    Related