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

Felipe Augusto Pereira de Figueiredo zz4fap at gmail.com
Wed May 17 14:20:58 UTC 2017


Dear Andre,

Do you have any update on that possible issue I sent you?

Thanks and Best Regards,

Felipe Augusto

On Mon, May 15, 2017 at 6:20 PM, Felipe Augusto Pereira de Figueiredo
<zz4fap at gmail.com> 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 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
>
>


More information about the srslte-users mailing list