Did you, by any chance, set the action forwarding policy to ONE_TO_ALL? I
sketched your RFNoC flow graph and there's a loopback going from Radio ->
PolConverter -> Split Stream 0 -> DUC -> Radio. (Loopbacks are fine in
RFNoC!).
If you have the action forwarding to ONE_TO_ALL, then the PolConverter
Thx Marcus,
For your fast and informative answers. Sorry it took me a while to reply,
but I'm still trying to get:
tune_request(freq, lo_off)
to work in C.
My X310 has 2 SBX-120 boards. Using uhd 4.6.0 in Ubuntu 24.04.
True about the tuner. Much cheaper and easier to implement it in analog.
I am u
On 2025-05-22 21:31, Nikos Balkanas wrote:
The spike is very clean to come from outside.
Must be from my X310. My tuner must be adding a signal to the
center frequency. The small artifact at 2 Ghz is probably the tuner not
equilibrating fully.
I recently updated my FPGA image. Is that where the t
The spike is very clean to come from outside.
Must be from my X310. My tuner must be adding a signal to the
center frequency. The small artifact at 2 Ghz is probably the tuner not
equilibrating fully.
I recently updated my FPGA image. Is that where the tuner lives?
On Fri, May 23, 2025 at 3:19 AM
Effectively I tried and I can avoid step 3 if I get the frequency offset with
respect to the radio_control desired frequency and then sum it to the DUC
desired frequency.
Actually there is no problem to me in calling these functions for every channel
of the DUC, what I was saying is that at fi
Hi Kevin,\
\
As per the [RFNoC
specification](https://files.ettus.com/app_notes/RFNoC_Specification.pdf)
Section 2.2.2.1, if you are using bursts, only the first packet of each burst
is required to have a timestamp. All subsequent packets of the same burst do
not need to have a timestamp includ
Note that every packet doesn't need to have a time stamp (assuming that the
previous packet does not have EOB set). If the first packet has a
timestamp and is not the final packet in a burst, then the subsequent
packet will be assumed to be continuous to the previous packet such that no
new timest
Hi Kevin,
Try issuing the stream command directly on the Radio block rather than the
rx_streamer. I don't know why you are getting the warnings you are
getting, but trying this step might produce a different result.
On another note, since you are using timed commands, there will be a time
stamp i
Hi,
Must the timestamp of every packet in an rfnoc network must remain locked to
the time source the radio used when it timestamped the first adc sample of
that packet?
In other words, if I have a decimator must I figure out the time offset of
the first sample of my decimated packets to wit
Hi,
I have an rfnoc block with two output ports which is feeding the splitter
block to duplicate each port.
One pair is used to stream to the host, and the other is looped back to the
radio via the DUC block.
The active connections are reported as:
Active connections:
* 0/Radio#0:0
Agree with Rob here. The purpose of the tune request to the graph is to
avoid both steps 2 and 4 and replace it with something more familiar to
people coming from the multi_usrp world.
Maybe a general comment on the RFNoC API is useful here: With RFNoC, you
get a much more fine-grained control ov
11 matches
Mail list logo
