Hi all,
In USRP B200mini, when I start off sending, for example, a tone from TX/RX
port and receive it from RX2 port, there is an increasing amplitude signal
at the receiver that could take a pretty long time to converge (e.g. at 4
MHz sample rate, it is as long as 50 to 100 milliseconds.)
I wonder
Thank you!
> On Aug 17, 2020, at 4:13 PM, Jeff Long wrote:
>
> According to the code, the maximum value in the pattern determines the number
> of inputs. For example, if the pattern is 0,1,2,3,3,2,2,1 then there will be
> 4 inputs. Samples will be pulled from the inputs in the specified order.
According to the code, the maximum value in the pattern determines the
number of inputs. For example, if the pattern is 0,1,2,3,3,2,2,1 then there
will be 4 inputs. Samples will be pulled from the inputs in the specified
order.
On Mon, Aug 17, 2020 at 2:33 PM lannan jiang wrote:
> Hi again,
>
>
Hi again,
I took a look at the pattern interleaver, but I have a question regarding
the input of a patterned interleaver.
The documentation says that the pattern property is the vector that
represents the interleaving pattern, but I am confused with this because if I
change the vector pat
Hi Marcus,
Thank you! I’ll look into that.
Regards,
Lannan
> On Aug 17, 2020, at 12:36 PM, Marcus Müller wrote:
>
> Sounds to me like you're looking for the patterned interleaver rather
> than writing your own block, possibly :)
>
> On 17.08.20 15:29, lannan jiang wrote:
>> Hi everyone,
Sounds to me like you're looking for the patterned interleaver rather
than writing your own block, possibly :)
On 17.08.20 15:29, lannan jiang wrote:
> Hi everyone,
> I want to use the embedded python block to do this:
> - I have some source data bytes, and now I want to transmit a seque
Hi everyone,
I want to use the embedded python block to do this:
- I have some source data bytes, and now I want to transmit a sequence
of bytes before the data.
- I am thinking that the basic block is what I can use to achieve this.
However, I looked up other people’s questi
Josh,
Many thanks for your prompt reply and suggestions.
I have followed both of the porting guide documents, settling on the GRC 3.9
version install and using its particular gr_modtool variant for all OOT block
operations.
I am aware of the CMake modernisation changes through GRC 3.8, but conf
David,
I've found most of the time I get the "No module named ..." error it is due
to C++ linkage issues in setting up the CMake. There was a big jump in
CMake modernization from GR 3.7 to 3.8, so be sure to use gr_modtool (from
3.9) to create a new module and copy your blocks in from there is us
Hi,
I have been developing a number of direct spread spectrum OOT blocks as part of
a research project.
Working blocks were originally developed using GRC 3.7.11, however I wish to
move forward and have installed and persevered so far with GRC 3.9 from the
master branch.
The GRC, UHD, CMAKE (
10 matches
Mail list logo
