Hi Derek,

Thanks for the advice. I tried adding in a sleep command, but the radio
still is not waiting the 15 seconds. I feel like it is an issue on the
software side since I never see a start time tagged in the packets from the
PC.

I have been digging into the GNUradio source code to see if I can identify
some of the cause and think it has to do with GNU Radio not propagating the
start time correctly. From what I can trace:
set_start_time() is implemented in rfnoc_block_impl.h, inherited as a
vertual function in rfnoc_block.h, and then inherited in rfnoc_radio.h,
which is the class it is called from.
set_start_time() sets two private variables in rfnoc_block_impl,
_start_time_set and _start_time based on the start time we give it.
In rfnoc_block_impl.cc, which handles the streaming, the TX streams never
look at this variable and the start time is never set. I can confirm this
by printing _tx.metadata.has_time_spec and _tx.metadata.time_spec.
Furthermore, these bits of metadata are intentionally purged, with the
calls:
_tx.metadata.start_of_burst = false;
_tx.metadata.end_of_burst = false;
_tx.metadata.has_time_spec = false;

If I explicitly change _tx.metadata.has_time_spec to true and
_tx.metadata.set time_spec to 15s, I observe the desired behaviour of
waiting 15s before transmitting. I think that this indicates that the
functionality is not completely integrated to GNU Radio and that there
needs to be some modification to the source in order to implement this. I
have implemented a simple fix that seems to work:
if (_start_time_set) {
      _tx.metadata.has_time_spec = true;
      _tx.metadata.time_spec = _start_time;
  } else {
      _tx.metadata.has_time_spec = false;
  }
Note that this code is only called for the first RFNoC block in my design
(which is a DmaFIFO), so I am only calling set_start_time() for the DmaFIFO
block. I'm not sure if this is a robust solution, but it seems to work for
my purposes. However, I think that this does indicate that there is
something missing with the TX start time implementation.

Thanks for your time,

~Reggie
​
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Reply via email to