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).) 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) , which controls forwarding of input data only when in the |FORWARDING| state.) Thank you all for your help, Quentin

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.prieels@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).) > > 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) > , 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-leave@lists.ettus.com >

 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-leave@lists.ettus.com

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 rkossler@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.prieels@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-leave@lists.ettus.com >

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.prieels@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 rkossler@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.prieels@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).) >> >> 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) >> , 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-leave@lists.ettus.com >> >

 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 rkossler@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.prieels@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-leave@lists.ettus.com

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 rkossler@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.prieels@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 rkossler@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.prieels@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-leave@lists.ettus.com >>

Quentin, Before proceeding, make sure you *backup your verilog implementation* because changing to the axis-data interface will *delete the block verilog folder* you have been working in (testbench, block code, Makefile, etc). The information below is based on the rfnoc spec ( https://files.ettus.com/app_notes/RFNoC_Specification.pdf) section 4.2.2 You will need to change the block description YAML file to have an axis-data interface, then run the create_verilog.py (uhd/host/utils/rfnoc_blocktool/rfnoc_create_verilog.py) script. An example is shown below of the minimum change needed for an axis-data interface: [image: image.png] After running the create_verilog script the new block will have the signals Rob mentioned. These will be at the noc_shell module interface, with some new clock names: [image: image.png] Thanks, David On Thu, Apr 17, 2025 at 10:17 AM Quentin Prieels < quentin.prieels@student.uclouvain.be> wrote: > 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 rkossler@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.prieels@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 rkossler@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.prieels@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).) >>> >>> 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) >>> , 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-leave@lists.ettus.com >>> >> _______________________________________________ > USRP-users mailing list -- usrp-users@lists.ettus.com > To unsubscribe send an email to usrp-users-leave@lists.ettus.com >