Reading cell information using ADL

Hi,

I have some problem reading the cell information using the ADL library, specifically the MNC (Mobile Network Code). I subscribe to adl_L3infoSubscribe ( ADL_L3INFO_CELL, myEvenHandler) and in myEvenHandler() I do the following:

wm_l3info_Cell_SyncCellInfo_t *p = (wm_l3info_Cell_SyncCellInfo_t*)Info;
uint16_t mcc = p->SyncCell[0].Lai[0]; // 1st and 2nd digits
mcc |= (uint16_t)((p->SyncCell[0].Lai[1] & 0x0F) << 8); // 3rd digit
uint16_t mnc = p->SyncCell[0].Lai[2]; // 1st and 2nd digits
mnc |= (uint16_t)((p->SyncCell[0].Lai[1] & 0xF0) << 4); // 3rd digit

However, the value of the mnc is 0xF10 insead of what I expect it to be and what AT+CCED reports, i.e. 0x001.

The raw bytes of the Lai[] array from wm_l3info_Cell_SyncCellParameter_t: 0x62, 0xF2, 0x10, 0x44, 0x60 and the documentation says:

u8    Lai[5];                    ///< Location area identity : including MCC, MNC and LAC. \n
                                    ///< ______--8--7--6--5-|-4--3--2--1             \n
                                    ///< Byte 1 :MCC digit 2    |  MCC digit 1 \n
                                    ///< Byte 2 :MNC digit 3    |  MCC digit 3 \n
                                    ///< Byte 3 :MNC digit 2    |  MNC digit 1 \n
                                    ///< Byte 4 :            LAC             \n
                                    ///< Byte 5 :            LAC    (cont)      \n

My environment is:
SiWi module: WMP100
Developer Studio: 3.1.0
Open AT Framework package: 2.51.0.201206190958
Open AT OS Package: 6.51.0.201206010944
Firmware Package: 7.51.0.201205311751

Has anyone experienced similar issues? Is it a known bug in OpenAt? Should I use the AT+CCED command instead?

Thanks!

hi,
I have check the API adl_L3infoSubscribe at my end and I got the LAI array values as
2015/01/28;11:24:52:326;003;ADL;1;lai[0] 4
2015/01/28;11:24:52:326;004;ADL;1;lai[1] 244
2015/01/28;11:24:52:342;001;ADL;1;lai[2] 84
2015/01/28;11:24:52:342;002;ADL;1;lai[3] 1
2015/01/28;11:24:52:342;003;ADL;1;lai[4] 191

Also my CCED returns:
at+cced=0,3
+CCED: 404,45,01bf,b267,60,57,63,255,0,404,45,01bf,56f7,26,62,37,404,45,01bf,38,104,39,404,45,01bf,30,107,28,404,45,01bf,56f5,11,60,21

OK

So if we decode these,
MCC: 404 => MCC digit 1 =4, MCC digit 2 =0, MCC digit 3 =4
MNC: 45 => MNC digit 1 =4, MNC digit 2 =5

Byte 1 :MCC digit 2 | MCC digit 1 -> 0 | 4 => 0000 0100 => 4 (in decimal)
Byte 2 :MNC digit 3 | MCC digit 3 -> F | 4 => 1111 0100 => 244 (in decimal)
Byte 3 :MNC digit 2 | MNC digit 1 -> 5 | 4 => 0101 0100 => 84 (in decimal)
Byte 4 :LAC => 01
Byte 5 :LAC => 191 (Decimal form of BF)

Could you please decode the same at your end and see if the values are coming proper……

PS: I have attached my sample code for your reference.

Thanks,
Rex

Hi,

thanks for the reply. I finnaly solved the issue by reading the GSM standard:
3GPP TS 24.008, Table 10.5.3: Location Area Identification information element
There, it sais that "bits 5 to 8 of octet 3 shall be coded as “1111"” if that digit is not used. So it all makes sense now.