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

Andre Puschmann andre.puschmann at softwareradiosystems.com
Wed May 17 17:04:35 UTC 2017


Hey,

On 15.05.2017 18:20, Felipe Augusto Pereira de Figueiredo wrote:
> 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 max output length of that correlation is the input length plus the
filter length. So having a peak that is beyond the subframe length,
i.e., the input length is ok.

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

That probably means you are experiencing overflows somewhere, drop
samples and then loose sync, and I'd say that is also why you cant
decode anything from then on.

Cheers
Andre


> 
> Thanks and Kind regards,
> 
> Felipe Augusto
> 
> On Mon, May 15, 2017 at 2:40 PM, Andre Puschmann
> <andre.puschmann at softwareradiosystems.com
> <mailto: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>
>     > <mailto: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>
>     >     <mailto: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>
>     >   
>      <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
>     <http://www.softwareradiosystems.com>
> 
>     PGP/GnuPG key: 6C42AB31
>     fingerprint: 137A AE49 785B A445 257C 8AD7 D877 A498 6C42 AB31
> 
> 


-- 
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


More information about the srslte-users mailing list