[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bursty transmissions with X310?

From: Philipp Niedermayer
Subject: Re: Bursty transmissions with X310?
Date: Thu, 16 May 2024 11:30:09 +0200
User-agent: Mozilla Thunderbird

Dear Ben,

from my experience with bursty transmissions the EOB tags are more to tell the USRP to not expect any further samples (and not to scream UUUUUUUUUnderruns), rather than to switch of the transmission.
Also in the documentation it is clearly stated that: "The "tx_eob" tag refers to Transmit, End of Burst. This tag must be associated with the last sample of a burst" [1].
So in addition to tagging your stream, you should also stop it. I.e. there should be no samples sent to USRP sink between EOB and SOB.
I once implemented a custom "burst copy" block for this purpose as I couldn't find one in the core lib [2] and this works well for my use case (meanwhile i am using RFNoC which does not handle tx_eob tags, but stopping the stream still works well).

To time it, the sample with SOB should be delayed or have a "tx_time" tag too.
If you don't rely on precise timing, you can also simply set the samples between EOB and SOB to zero to achieve what you want I guess.

Best regards

[1] https://wiki.gnuradio.org/index.php/USRP_Sink#Bursty_Transmission

[2] https://git.gsi.de/p.niedermayer/exciter/-/blob/main/gr-beam_exciter/grc/beam_exciter_burstCopy.block.yml

From: Ben Wiederhake [mailto:ben.wiederhake@timelords.saarland]
Date: Wednesday, May 15, 2024 at 20:35 UTC+2
Subject: Bursty transmissions with X310?


tl;dr: I can't seem to get the bursty transmissions to work with the USRP Sink block. What am I missing?

Steps to reproduce: Run the following minimal-ish example, with two X310 devices: https://github.com/BenWiederhake/demo_no_burst?tab=readme-ov-file#demo_no_burst
Expected behavior: The receiver sees the signal from the transmitter only intermittently, the timing corresponding to the tx_sob and tx_eob tags, just like the documentation [1] explains.
Actual behavior: The receiver sees a continuous signal from the transmitter, nearly as if the USRP Sink block completely ignores my tags.

The Qt GUI Time Sink block in the flowgraph demonstrates that the tags do indeed exist as intended.

I already checked the source code of the USRP Sink block [3], but I don't fully grasp how it works or why "my" tags get ignored.

The `tags_demo` example program [3] from the GnuRadio source tree runs without any errors and transmits a continuous signal into the air, but no "timed bursts", contrary to its own description text.
However, the program hasn't been updated in several years, so perhaps it doesn't work for unrelated reasons.
Can someone double-check this program?

Some troubleshooting:
- I tested various spelling variants of the tag keys/values.
- I already updated the USRP firmware image and rebooted all devices.
- I think I'm using mostly the newest software, so it's not a known issue: GnuRadio (Python 3.11.8), UHD_4.6.0.0+ds1-5+b2
- Ettus X310 rev 13, Daughterboard UBX-160 v2

What could I be doing wrong?

With regards,
Ben Wiederhake

[1] https://wiki.gnuradio.org/index.php/USRP_Sink#Bursty_Transmission
[2] https://github.com/gnuradio/gnuradio/blob/main/gr-uhd/lib/usrp_sink_impl.cc#L459
[3] https://github.com/gnuradio/gnuradio/blob/main/gr-uhd/examples/c%2B%2B/tags_demo.cc#L71

Attachment: smime.p7s
Description: Kryptografische S/MIME-Signatur

reply via email to

[Prev in Thread] Current Thread [Next in Thread]