[srslte-users] Problem with decoding SIB2 using cell_measurement example

ALEJANDRO BLANCO PIZARRO 100283180 at alumnos.uc3m.es
Tue Apr 17 15:25:56 UTC 2018


Hi Laura,

I had this issue and I finally realized that the position that it is
obtained using the LTE standard could not be the same in real scenarios.

My piece of advice: you should program a loop and go over the subframe id
and the system frame number  showing all the payloads and the positions.
With it, you are going to show all SIB payloads, afterwards, with
http://www.marben-products.com/decoder-asn1-lte/ see what is the SIB2
payload and see what are the system frame number and the subframe id
relative to SIB2, to see if you made a mistake.

 if ((srslte_ue_sync_get_sfidx(&ue_sync) == variable_loop1) &&   (sfn %
si_loc[0].period) == variable_loop2)

I know that this piece of advice is not really smart but is functional.

Tell me if you need further information.

Best,
Alejandro

2018-04-17 17:16 GMT+02:00 Laura Flueratoru <flueratorulaura at gmail.com>:

> Hi Alejandro,
>
> Yes, I know about the decoder, but my problem is that I don't know how
> to find SIB2's location, even given the information from SIB1. The way
> I tried to do it (explained in the email before) gives me a payload
> for SIB2 that is interpreted by the decoder you mentioned as a SIB1
> format. So the location I'm trying to access is clearly not the
> location of SIB2.
>
> So do you know how could I find the correct location of SIB2? Thank you!
>
> Best,
> Laura
>
> On Tue, Apr 17, 2018 at 4:53 PM, ALEJANDRO BLANCO PIZARRO
> <100283180 at alumnos.uc3m.es> wrote:
> > Hi Laura,
> >
> > I do not completely understand your problem, but have you tried to decode
> > the SIB2 payload by http://www.marben-products.com/decoder-asn1-lte/?
> >
> > Best!
> > Alejandro
> >
> > 2018-04-17 13:46 GMT+02:00 Laura Flueratoru <flueratorulaura at gmail.com>:
> >>
> >> Hi everyone,
> >>
> >> I am trying to decode SIB2 using the cell_measurement example. I have
> >> already decoded the information regarding the location of the SI
> >> messages from SIB1, and the periodicity of SIB2 should be RF8 (same as
> >> for SIB3) and the SI Window Length is 3.
> >>
> >> From this, I compute the subframe number, the periodicity and the
> >> offset according to 36.331 and try to search for the SIB2 in a loop as
> >> in the code snippet below:
> >>
> >>     if ((srslte_ue_sync_get_sfidx(&ue_sync) == si_loc[0].subframe) &&
> >>          (sfn % si_loc[0].period) == si_loc[0].mod_sfn) {
> >>         n = srslte_ue_dl_decode(&ue_dl, data, 0,
> >>                   sfn*10+srslte_ue_sync_get_sfidx(&ue_sync), acks);
> >>
> >> where:
> >>     - si_loc[0].subframe is SIB2's subframe number and has the value 0
> >>     - si_loc[0].period is SIB2's periodicity and has the value 8 (RF8)
> >>     - si_loc[0].mod_sfn is SIB2's offset and has the value 0
> >>
> >> It does find something at that location and an example payload is
> >> [40 48 a0 03 06 50 11 84 60 88 19 31 80 81 84 4c 23 61 23 18 00 00 63
> >> 9e 9d 00 00 00 00 00 00 00 65 2b 44 7c ef ]
> >> whereas the payload of SIB1 was
> >> [40 48 a0 03 06 50 11 84 60 88 19 31 80 81 84 4c 23 61 23 18 00 00 ]
> >>
> >> So I find it weird that the first part of the payload I get for SIB2
> >> would be exactly the same as for SIB1, so I think there's something
> >> wrong with the way I try to retrieve SIB2's data.
> >>
> >> Can you please tell me if there's something wrong with the way I
> >> search for the SI message? I tried to look in
> >> rrc::run_si_acquisition_procedure which seems to be computing the same
> >> location, but it seems to me that I'm doing almost the same thing here
> >> (minus specifying the window length in which to search for the SI
> >> message). Any help would be greatly appreciated. Thank you!
> >>
> >> Best regards,
> >> Laura
> >> _______________________________________________
> >> srslte-users mailing list
> >> srslte-users at lists.softwareradiosystems.com
> >> http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.srsran.com/pipermail/srsran-users/attachments/20180417/9f0050c4/attachment.htm>


More information about the srsran-users mailing list