[srslte-users] srslte_pss_synch_find_pss returns peak position greater than the subframe size

Felipe Augusto Pereira de Figueiredo zz4fap at gmail.com
Mon May 15 16:20:32 UTC 2017


Hi Andre,

I don't understand. As I understand, the function srslte_ue_sync_zerocopy()
reads one subframe (5760 samples) and passes it to function
srslte_sync_find() which does a lot of things including trying to find the
PSS peak in function srslte_pss_synch_find_pss().

What I don't understand is if the peak returned is greater than 5760 how
does srslte_pss_synch_find_pss() know the peak is really in a sample that
is not in the buffer yet? Additionally, after that the
function find_peak_ok() tried to align by reading more samples.

The issue I'm seeing is that whenever the peak is greater than 5760 the
function srslte_ue_dl_decode() fails to decode data.

Thanks and Kind regards,

Felipe Augusto

On Mon, May 15, 2017 at 2:40 PM, Andre Puschmann <
andre.puschmann at softwareradiosystems.com> wrote:

> Felipe,
>
>
>
> On 15.05.2017 14:23, Felipe Augusto Pereira de Figueiredo wrote:
> > Dear Andre,
> >
> > Thanks for your reply.
> >
> > That's not the case I'm testing, I saw that during some initial phase
> > you check a 5 miliseconds long frame, however, now I'm seeing those
> > peaks greater than a subframe after that initial phase, when you only
> > read a 1ms (i.e., 5760 samples) long subframe.
>
> During the tracking phase, the PSS is searched for around an expected
> position. And that position should be the same and accurate most of the
> time. However, if you, for example, experience over flows the radio may
> drop samples and that causes the PSS not to be at the expected position.
>
> Note that the set of valid return values for the PSS find function is
> between [0, input_len+filter_len]. So having a large return value then
> the subframe size isn't a bad sign.
>
> >
> > Do you think that might be a bug in the PSS find function
> > (srslte_conv_fft_cc_run)?
>
> What's the issue you are having that make you think there is a bug?
>
> Thanks
> Andre
>
>
> >
> > Thanks and Best regards,
> >
> > Felipe Augusto
> >
> >
> >
> > On Mon, May 15, 2017 at 2:16 PM, Andre Puschmann
> > <andre.puschmann at softwareradiosystems.com
> > <mailto:andre.puschmann at softwareradiosystems.com>> wrote:
> >
> >     Hey Felipe,
> >
> >
> >     On 11.05.2017 19:34, Felipe Augusto Pereira de Figueiredo wrote:
> >     > Dear srsLTE group,
> >     >
> >     > I'm studying the srsLTE code and I`m confused by one thing I've
> found out.
> >     >
> >     > I observed that the function: srslte_pss_synch_find_pss from pss.c
> >     > sometimes returns a peak position that is greater than the
> subframe,
> >     > i.e., 5760 in the case of 5 MHz and using the sampling rate of
> 5.76 MHz.
> >
> >     During the initial find phase, we capture 5 subframes at once to make
> >     sure the samples contain one PSS sequence. Note that the PSS is
> >     transmitted twice in every frame, i.e. every 5ms. So running the PSS
> >     search on this set of samples may return a PSS position that is
> _after_
> >     the first subframe, since it is not known where exactly the PSS
> started
> >     (otherwise we would already be in sync).
> >
> >     Hope that helps.
> >
> >     Cheers
> >     Andre
> >
> >
> >
> >     >
> >     > I've checked and that function uses convolution FFT to do the
> >     > correlation, see below:
> >     > conv_output_len = srslte_conv_fft_cc_run(&q->conv_fft,
> q->tmp_input,
> >     > q->pss_signal_time[q->N_id_2], q->conv_output);
> >     >
> >     > If the peak is used to align the subframe how can it be greater
> than the
> >     > subframe? Is this behavior correct?
> >     >
> >     > Thanks in advance and Best Regards,
> >     >
> >     > Felipe Augusto
> >     >
> >     >
> >     >
> >     >
> >     >
> >     > _______________________________________________
> >     > srslte-users mailing list
> >     > srslte-users at lists.softwareradiosystems.com
> >     <mailto:srslte-users at lists.softwareradiosystems.com>
> >     > http://www.softwareradiosystems.com/mailman/listinfo/srslte-users
> >     <http://www.softwareradiosystems.com/mailman/listinfo/srslte-users>
> >     >
> >
> >
>
>
> --
> Andre Puschmann
>
> Software Radio Systems (SRS)
> http://www.softwareradiosystems.com
>
> PGP/GnuPG key: 6C42AB31
> fingerprint: 137A AE49 785B A445 257C 8AD7 D877 A498 6C42 AB31
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.softwareradiosystems.com/pipermail/srslte-users/attachments/20170515/7e8757c0/attachment-0001.html>


More information about the srslte-users mailing list