[prev in list] [next in list] [prev in thread] [next in thread] 

List:       usrp-users
Subject:    Re: [USRP-users] Some questions on vector rfnoc blocks
From:       Martin Braun via USRP-users <usrp-users () lists ! ettus ! com>
Date:       2016-01-29 14:49:32
Message-ID: 56AB7BFC.7050903 () ettus ! com
[Download RAW message or body]

On 01/29/2016 10:41 AM, Anselm Karl via USRP-users wrote:
> 1)
> If i kill and restart a gnuradio test graph, the sub-channels (= the
> phase of the polyphase filter) jump. I guess that is because i didn't
> yet implement the reset properly. And so some samples are still "stuck"
> in the filter making it restart on an different phase.
>
> The "original" vector rfnoc blocks (fft and window) don't show this
> behaviour. The phase after each restart the same. (The first of N
> samples is always the same frequency component after the fft.)
>
> Do the Computational engines get a reset on starting a new transmission?
> If so, i think i just need to implement the reset properly. Or is there
> any other kind of vector synchronisation, that i am missing?

There are several ways to implement a reset. If your block is simple and
only uses NocScript (which I'd assume given your description), you can
look at fft.xml. Writing to the arg 'reset' will reset, and providing a
<value> will make sure it is always set at initialization.

For a C++-based solution, override _clear().

M

>
> 2)
> If i put a radio behind the syntheses everything works fine up to 16 MHz
> RF Sampling rate. Beyond the spectrum gets very spiky. I guess there are
> lost samples.
>
> I think, this is strange, because the block has to work on a 200 MHz
> Clock independent from the rf sampling rate. The only explanation i can
> think of is, that i am not handling tlast properly, especially at the
> fft. The fft compiler uses its tlast output to mark the end of an
> vector. The tlast input is not used. So tlast on the fft cant be used
> for marking packets. So i added some extra logic to handle the tlast.
> What i think it's happening, is that the tlast gets stuck in my logic
> until the next packet starts and "pushes out" the tlast. Maybe on lower
> rates this is less critical and still works?
>
> If i get it to work properly, i’ll publish it. I am still using System
> Generator, so it is not very compatible to the original source code. But
> i can publish the synthesized checkpoints of my system generator models,
> so that it is very easy to add them to a custom firmware build.
>
> Greetings,
> Anselm
>
> (Sorry for my new email address!)
>
>
>
>
>
>
>
> _______________________________________________
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>


_______________________________________________
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[prev in list] [next in list] [prev in thread] [next in thread]