In principle, you're correct. Although 64 would be a very small spp value, typically we have bigger packets but there's no technical limitation to have smaller packets.
Once you're in packet-land, however, there's no guarantee about packet timing and spacing. For reliable timing and accuracy, we use the timestamps in the headers.That said, if you have radio + DDC, the packet spacing will be pretty consistent, simply because there's not much else the FPGA can do. But by the time you're on the network, you've already incurred jitter from various places. As a counterexample, imagine you're streaming not from the radio, but from a signal source, or from DRAM. At the beginning of your transmission, the source will try to generate data as fast as possible, and packets will be generated back-to-back, no gap. Eventually, due to flow control and the host's ability to handle a certain rate, there will be backpressure, and packets will be generated at whatever rate the host can sustain. It's also not unusual for software to handle packets in a bursty manner, so the data generation on the FPGA could also be bursty. Note that RFNoC doesn't even require packets to be generated without gaps, i.e., it is possible to generate half a packet, deassert tvalid, and then reassert it when the next half is generated (but we usually avoid that, and put *packet gates* in place to make sure only full packets are produced). We try and document things as well we can, here's a lot of info on the packetization: https://uhd.readthedocs.io/en/latest/page_rfnoc_fpga.html ...but it doesn't always answer every single question directly. On Fri, Dec 19, 2025 at 11:55 AM <[email protected]> wrote: > Hello, > > I am working with RFNoC and trying to better understand how sample data is > actually delivered over CHDR after the Radio + DDC block, particularly in > terms of *packet spacing vs. bus rate*. > > My assumption is: > > - > > The RF chain (Radio + DDC) outputs samples at a configured sample > rate, e.g., 250 KHz. > - > > RFNoC groups samples into packets of SPP samples (for example, 64 > samples per CHDR packet). > - > > When a packet is produced, it is transmitted across the RFNoC fabric > at the *fabric clock rate* (e.g., 200 MHz), meaning the packet data > appears as a short *burst* of consecutive valid cycles. > - > > After that burst, there is a gap (idle time) until enough samples are > accumulated to form the next packet. > > So, for example, at: > > - > > Fs = 250 kS/s > - > > SPP = 64 > > Then we would expect: > > - > > One packet every 64 / 250k = 256 µs > - > > Packet burst duration = 64 cycles at 200 MHz ≈ 320 ns > - > > Approximately 256 µs – 320 ns of idle time before the next packet. > > My questions are: > > 1. > > Is this understanding correct? > 2. > > Is RFNoC guaranteed to behave this way, or can buffering cause > multiple packets to be sent back-to-back with no idle gap? > 3. > > Is there any official documentation describing packetization timing > behavior of Radio/DDC RFNoC fabric? > > > Thanks in advance! > _______________________________________________ > USRP-users mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ USRP-users mailing list -- [email protected] To unsubscribe send an email to [email protected]
