You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
rfnoc_radio_loopback with rx-timestamps set to true always results in an overflow #956
Connecting radio blocks in a loopback configuration always results in an overflow unless enable_rx_timestamps(false) is called for the receiving end.
This happens for official images and for self-built ones.
In case this is expected behavior, I think it should be documented better, at least in the official example.
I also think the name enable_rx_timestamps should be adjusted, especially with the default being that they are enabled.
Setup Details
USRP X410, UHD 4.9.0.0, Linux
Steps to reproduce the problem
Load any official image, then run the example rfnoc_radio_loopback --rx-timestamps true
Additional Information
The output of running the example always looks like this:
This is expected behaviour -- in fact, this use case is why we have that API in the first place. I agree though it's weird to not document that in the example.
As a bit of a follow up, with the RX timestamps disabled I can now successfully run the loopback example (and my own derived code).
However, as soon as I add blocks in the chain (using my own custom image) to the two radio blocks the overflow issues come back.
I have now tried pretty much everything that came to mind, my goal is to create a chain of radio -> ddc -> custom OOT block -> duc -> radio, but even with just radio -> ddc -> duc -> radio, an overflow shows up.
No matter the image's CHDR width, the buffer sizes of the stream endpoints and whether I connect them statically or dynamically.
Is there something I'm missing? In my current version the CHDR width is 256 and each endpoint has a buffer size of 65536. I then connect everything up dynamically with each block having 2 dedicated stream endpoints (since NUM_PORTS is set to 2 for each of the 3).
Could this be a limitation of the single-sample implementation of DDC and DUC of UHD 4.9.0.0 so I'd have to either update to 4.11.0.0 or lower the bandwidth?
Activity
mbr0wn commentedon Nov 13, 2026
This is expected behaviour -- in fact, this use case is why we have that API in the first place. I agree though it's weird to not document that in the example.
climb4 commentedon Nov 13, 2026
Thank you very much for clarifying.
As a bit of a follow up, with the RX timestamps disabled I can now successfully run the loopback example (and my own derived code).
However, as soon as I add blocks in the chain (using my own custom image) to the two radio blocks the overflow issues come back.
I have now tried pretty much everything that came to mind, my goal is to create a chain of radio -> ddc -> custom OOT block -> duc -> radio, but even with just radio -> ddc -> duc -> radio, an overflow shows up.
No matter the image's CHDR width, the buffer sizes of the stream endpoints and whether I connect them statically or dynamically.
Is there something I'm missing? In my current version the CHDR width is 256 and each endpoint has a buffer size of 65536. I then connect everything up dynamically with each block having 2 dedicated stream endpoints (since NUM_PORTS is set to 2 for each of the 3).
climb4 commentedon Nov 13, 2026
For reference, this is the image_core.yml I'm using:
And the graphviz dot file for the connected graph:
Could this be a limitation of the single-sample implementation of DDC and DUC of UHD 4.9.0.0 so I'd have to either update to 4.11.0.0 or lower the bandwidth?