Dear all,we are trying to realize an RFNoC loopback flow graph, where data from the host is streamed into, such as in this picture: The RFNoC Pulse Counter [1], RFNoC Multiply (based on the Gain example) [2] and RFNoC Modify Timestamp (to prevent "Late package" error) [3] are custom blocks, see link to sources below if required.
We observed that, when starting the flow graph, the CPU has not yet provided sufficient samples via the Tx Streamer and there are a few underruns happening. This is not surprising considering that GNU Radio has to start the block threads etc. all of which is much slower than RFNoC starting to stream data. As a result, there is a significant delay of about 50 ms between RX and TX on the USRP X310 I am testing with in the Lab. If we remove the Tx Streamer (and Multiply block) from the flowgraph, then the delay is much lower: 100 µs.
I think the reason is, that the TX Radio transmits samples as they come in (since the timestamps are removed, otherwise it would drop them due to "Late package"), but since both ends, RX and TX have a fixed 200MHz rate, and the TX will never "skip" samples, the number of samples-in-flow can only increase when an underrun happens as the host does not provide enough samples initially, but it can never decrease again. The fact that the delay is so much smaller without the stream from the host supports this understanding.
I have a few Ideas how this could eventually be mitigated, but I am not sure how to implement them, and am looking for some suggestions (or alternative approaches):
1. Delay the "start stream command" which starts the RFNoC data flow until the host is ready to provide the sampling rate --> Is this possible? If yes, how could it be done? 2. Flush all the block FIFOs shortly after starting the flow graph, maybe with a block near the end of the DSP that consumes and drops packages for a while. --> This could potentially reduce the number of samples-in-flow which have aggregated initially back to a "normal" small value 3. Instead of removing the timestamps, add a fixed offset that covers the latency (and makes it deterministic). --> The Idea was, that the TX Radio will drop late packages, skipping to the next package with a correct timestamp, and thus maintaining a constant and deterministic latency between RX and TX. --> I did try this one, but unfortunately the TX continuously spills L's to the console and does not seam to skip to the next valid package, even with a very long offset of 100ms (Is this expected behaviour?). I found "underflow_policy" block arg, and according to [4] that should drop packages, but the Radio seams to not know such a property?We would be happy for any suggestion on the matter (please keep r.si...@gsi.de in CC)
Kind regards Philipp Niedermayer[1] https://git.gsi.de/p.niedermayer/exciter/-/blob/f74c7b96651a957961957ec6d9ec57941eb2a701/rfnoc-beam_exciter/fpga/rfnoc_block_discriminating_pulse_counter/rfnoc_block_discriminating_pulse_counter.v [2] https://git.gsi.de/p.niedermayer/exciter/-/blob/f74c7b96651a957961957ec6d9ec57941eb2a701/rfnoc-beam_exciter/fpga/rfnoc_block_multiply/rfnoc_block_multiply.v#L219 [3] https://git.gsi.de/p.niedermayer/exciter/-/blob/f74c7b96651a957961957ec6d9ec57941eb2a701/rfnoc-beam_exciter/fpga/rfnoc_block_timestamp_mod/rfnoc_block_timestamp_mod.v#L265-266
[4] https://files.ettus.com/manual/structuhd_1_1stream__args__t.html UHD: 4.4.0.0 (build from source) GNU Radio: 3.10.7.0 (build from source) USRP: X310 Philipp Niedermayer Phone / Telefon: +49 6159 71 3567 p.niederma...@gsi.deGSI Helmholtzzentrum für Schwerionenforschung GmbH, Planckstraße 1, 64291 Darmstadt, Germany, www.gsi.de
Commercial Register / Handelsregister: Amtsgericht Darmstadt, HRB 1528Managing Directors / Geschäftsführung: Professor Dr. Paolo Giubellino, Jörg Blaurock Chairman of the GSI Supervisory Board / Vorsitzender des GSI-Aufsichtsrats: Ministerialdirigent Dr. Volkmar Dietz
smime.p7s
Description: Kryptografische S/MIME-Signatur
_______________________________________________ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
