On 2022-05-11 15:24, Dobler, Anton wrote:
I use a n310 and have two 10gigbit for data streaming and one 1gigbit
for managing the device… the strange thing about it is that the
example flowgraph with rx radio downconverter and rx streamer works
without any problems…
I run the application on
On 2022-05-11 14:45, Dobler, Anton wrote:
Dear Community,
I try to set up a basic flowgraph in GRC consisting out of a null
source, a tx streamer and DUC and a TX radio.
I use UHD4.0 and GR3.8.2.
However, I get the following error message:
/RuntimeError: RuntimeError: Error during RPC
On Wed, May 11, 2022 at 2:18 PM Marcus D. Leech
wrote:
> On 2022-05-11 14:10, rbl...@swri.org wrote:
> >
> > A question for anyone: when changing the frequency of a DUC (or DDC)
> > would you expect the output of the block to be phase continuous
> > through the change? Phase-continuous behavior
On 2022-05-11 14:10, rbl...@swri.org wrote:
A question for anyone: when changing the frequency of a DUC (or DDC)
would you expect the output of the block to be phase continuous
through the change? Phase-continuous behavior would be typical for
many DDC implementations, but with the RFNoc
A question for anyone: when changing the frequency of a DUC (or DDC) would you
expect the output of the block to be phase continuous through the change?
Phase-continuous behavior would be typical for many DDC implementations, but
with the RFNoc block I am seeing big, arbitrary phase jumps
Can you also share your block's YML and the noc_shell you generated?
Wade
On Wed, May 11, 2022 at 4:27 AM Jeffrey Cuenco wrote:
> Hi Wade,
>
> Yes, I have the ctrlport:has_status set to False in the block YAML... I
> ended up having to comment out that test sequence to move onto the part
>
Hi sp,
The critical warning you mention means that the clock constraints created a
new clock constraint that replaces another one. I think this is expected
and is not related to your code.
The ValueError means it received a packet with a bad header or a bad length
field in the header. Most
On 2022-05-11 09:51, Marcin Puchlik wrote:
Will it be enough to clock USRP from the external 10 MHz signal
generator? When I run the flowgraph I cannot see the information that
is using the external clock. Here is the output from GNU Radio:
[INFO] [UHD] linux; GNU C++ version 9.4.0;
Will it be enough to clock USRP from the external 10 MHz signal generator?
When I run the flowgraph I cannot see the information that is using the
external clock. Here is the output from GNU Radio:
[INFO] [UHD] linux; GNU C++ version 9.4.0; Boost_107100;
UHD_3.15.0.HEAD-0-gaea0e2de
[INFO] [B200]
On 2022-05-11 09:18, Marcin Puchlik wrote:
Marcus,
Thank you very much for the answer. Does it mean that 1 PPS signal is
optional? Can I only provide an external 10 MHz clock without 1 PPS?
*Z poważaniem *
*Marcin Puchlik*
*Yes, absolutely. If timestamp synchronization is not important to
Marcus,
Thank you very much for the answer. Does it mean that 1 PPS signal is
optional? Can I only provide an external 10 MHz clock without 1 PPS?
*Z poważaniem *
*Marcin Puchlik*
śr., 11 maj 2022 o 14:24 Marcus D. Leech
napisał(a):
> On 2022-05-11 06:17, Marcin Puchlik wrote:
>
> Hello
On 2022-05-11 06:17, Marcin Puchlik wrote:
Hello Community,
Like in the topic, I know that a stable 10 MHz source is needed as a
clock signal but why do we need 1 PPS signal? How is it used by the
USRP hardware? Can someone explain that to me?
Thanks
Marcin
Hello Community,
Like in the topic, I know that a stable 10 MHz source is needed as a clock
signal but why do we need 1 PPS signal? How is it used by the USRP
hardware? Can someone explain that to me?
Thanks
Marcin
___
USRP-users mailing list --
Hi Wade,
Yes, I have the ctrlport:has_status set to False in the block YAML... I
ended up having to comment out that test sequence to move onto the part
that sends samples into and out of the block; now I have an error that
states
*Fatal: Timeout: Test "Test passing through samples" time limit
14 matches
Mail list logo
