I just read a bit more about the "Sideband-At-End" signal, and it could
indeed be the issue. However, I don't see this signal (nor |tlength|,
|ttimestamp|, |has_time|, |teov|, or |teob|) in my current block
definition. This definition was auto-generated by /rfnoc_modtool/,
similar to the one in the gain example. Do you know how I can enable or
configure this Sideband-At-End in UHD 4.8?
You're also right — I added a custom |is_last_sample| signal to mark the
last sample of my OFDM frame, in case it doesn’t align with a true end
symbol in RFNoC.
If needed, here’s my current block definition:
https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency/rfnoc/blocks/schmidl_cox.yml
Quentin
On 4/17/25 18:40, Rob Kossler wrote:
Vous n’obtenez pas souvent d’e-mail à partir de rkoss...@nd.edu.
Pourquoi c’est important <https://aka.ms/LearnAboutSenderIdentification>
OK. The AXI-Stream Data (simple) interface is the easiest for this
case in my opinion. Are you using "Sideband-At-End" in order to have
the "tlength" automatically calculated?
You need to set "tlast" like you mentioned. This is critical and not
always easy. Remember that the CHDR packet can only be about 2000
samples whereas an OFDM packet might be longer. So, your idea about
preserving the tlast from the input stream is probably needed. You
also probably want to preserve teob from the input unless you are also
detecting your own end of burst in which case you need logic to set
this on the final packet and you need to set tlast on the last sample
because the input packets will likely not have tlast set on this sample.
Note that in the past I have used "axi_rate_change" in a block such as
yours (my block was a pulse detection block based on power) because in
addition to handling a true rate change (which you don't need), it
also takes care of re-packetizing the data. This allows your own
logic to not worry about RFNoC packets. But, switching to use this
module might be more of a headache than just handling the RFNoC
packets with your own logic.
For the question you asked about receiving a new CHDR packet if an
output packet has not been produced, I think the answer is Yes, this
is no problem.
Rob
On Thu, Apr 17, 2025 at 12:16 PM Quentin Prieels
<quentin.prie...@student.uclouvain.be> wrote:
Hi Rob,
I'm not sure. I also tried forwarding the |tlast| signal of the
original |tdata| samples to force the system to send a CHDR
packet—even if my OFDM packet wasn't finished yet—but it doesn’t
seem to solve the issue.
Another question I’ve been asking myself is:/does RFNoC allow a
block to receive a new incoming CHDR packet if it hasn’t yet
produced an outgoing packet/?
I'm using the AXI-Stream Data (Simple) interface, so I assume the
NoC shell handles packet manipulation and length. I don't see
where I could modify this behavior...
If you have any ideas or insights, I’d be happy to investigate
further.
Best regards,
Quentin
On 4/17/25 17:58, Rob Kossler wrote:
Vous n’obtenez pas souvent d’e-mail à partir de rkoss...@nd.edu.
Pourquoi c’est important
<https://aka.ms/LearnAboutSenderIdentification>
Hi Quentin,
Perhaps your issue is related to the 'length' parameter of the
RFNoC packet? If you are not correcting the packet length based
on the number of samples you are dropping, then you will get
ill-formed packets coming out. Do you think that this could be
the issue?
Rob
On Thu, Apr 17, 2025 at 11:40 AM Quentin Prieels
<quentin.prie...@student.uclouvain.be> wrote:
Hello everyone,
I'm currently implementing a Schmidl & Cox OOT module on a
USRP X310 as part of my master's thesis. (For those
interested, the code is available here
<https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/tree/latency>
(https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency
<https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency>).)
The purpose of this block is to detect the beginning of an
OFDM frame — specifically, just after the Schmidl & Cox
preamble. I want the block to forward *only* the "valid"
samples (i.e., those that are part of the actual OFDM frame).
So when I call |rx_stream->recv()|, only actual data packets
should be received by my UHD application.
My first idea was to control the |tvalid| signal of the
AXI-Stream interface: setting it to |0| when the data was not
a "valid" OFDM sample, and asserting it (|1|) only when the
data was valid. However, this seems to cause some kind of
deadlock. My UHD application always times out and receives no
data. Interestingly, when I output zero-valued samples
instead of deasserting the |tvalid| signal, I can see that my
synchronization mechanism is working as expected. This
suggests the issue likely lies in my use of AXI signals or a
misunderstanding of the RFNoC protocol.
_Note_: my configured SPP (samples per packet, here 200) is
smaller than the length of the actual OFDM frame, which
consists of thousands of complex samples.
So here's my main question:
Given a continuous stream of data (currently configured as
packets with 200 samples each, where every packet is valid),
how can I output *only a subset* of this stream — a specific
sequence of continuous samples (potentially spread across
multiple packets) — such that only this valid subset is
received by the UHD application? Alternatively, how can I
mark only part of the stream as valid for the receiver, while
discarding the rest?
(For those interested in the code, this behavior corresponds
to when |output_select| is set to |2'b01| in the following
module: detector.sv
<https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency/fpga/ofdm/rfnoc_block_schmidl_cox/detector.sv>
(https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency/fpga/ofdm/rfnoc_block_schmidl_cox/detector.sv
<https://github.com/quentinprieels/TFE25-462-rnfoc-ofdm/blob/latency/fpga/ofdm/rfnoc_block_schmidl_cox/detector.sv>)
, which controls forwarding of input data only when in the
|FORWARDING| state.)
Thank you all for your help,
Quentin
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-le...@lists.ettus.com
