usrp-users@lists.ettus.com
Discussion and technical support related to USRP, UHD, RFNoC
View all threadsX310 Appears Laggy Using UHD 4.5
Hello,
We are developing a radar application built on the Ettus SDR platforms. Our code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and a B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to take advantage of recent power calibration utilities and other features not present in UHD 3.15, so I am now trying to run our code on an X310 with the most recent UHD 4.5 release.
When running our code on the X310 with UHD 4.5 I get warnings for both radio 0 and radio 1 (we transmit on one UBX160 and receive on the other): [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping. The code uses timed commands to transmit and receive samples from a frequency-swept pulse at a consistent interval (pulse repetition frequency). Our application requires a high PRF and we can tolerate some late command errors, but need to log them for post-processing. Using UHD 4.5, the behavior is not as expected in that something seems to be hanging. At some point during the process—I think once we first hit a late command error—the timing becomes very off from what it should be, and eventually, samples stop being transmitted or received and the application just hangs. Sometimes when killing the application, I get this warning: [WARNING] [RFNOC::GRAPH::DETAIL] Cannot forward action tx_event from 0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen when running the application with UHD 3.15.
I have tried running the benchmark_rate example with the same host computer and X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high sample rates, I get an error: uhd::op_timeout: RfnocError: OpTimeout: Control operation timed out waiting for ACK, which stops the test before it begins running. Lower sample rates in UHD 4.5 run, but produce more errors (including sequence errors) than the same set up running UHD 3.15.
I have tried refreshing the FPGA image for UHD 4.5 with no change in behavior. The behavior is replicable using multiple host computers (Mac and Ubuntu). If anyone has suggestions on debugging steps, or potential reasons why UHD 4.5 would seem laggy compared to UHD 3.15 (despite running well with UHD 4.x on the B205mini), I would greatly appreciate them. I suspect it may have something to do with the command queue and how it evolves after getting behind.
Thanks,
Anna Broome
Hello Ms. Broome,
that does sound complicated and undesirable. From the top of my head, I have no idea what
could cause this. Barring any method of directly debug this – how quickly does
reproduction for you work? Meaning, from the start of your application to the application
hanging or no samples flowing, how long does it take?
Let me quickly throw in my thoughts on the things you write, so that we maybe find a good
way forward, or maybe someone else spots something:
On 28.09.23 19:54, Anna Lamkin Broome wrote:
When running our code on the X310 with UHD 4.5 I get warnings for both radio 0 and radio
1 (we transmit on one UBX160 and receive on the other): *[WARNING] [0/Radio#0]
*Attempting to set tick rate to 0. Skipping.
The ability to emit that warning was added in UHD 4.0.0.0; I think it's quite normal to
see this during initialization.
The code uses timed commands to transmit and receive samples from a frequency-swept
pulse at a consistent interval (pulse repetition frequency). Our application requires a
high PRF and we can tolerate some late command errors, but need to log them for
post-processing.
Sounds good to me.
Using UHD 4.5, the behavior is not as expected in that something seems to be hanging. At
some point during the process—I think once we first hit a late command error—the timing
becomes very off from what it should be, and eventually, samples stop being transmitted
or received and the application just hangs. Sometimes when killing the application, I
get this warning: *[WARNING] [RFNOC::GRAPH::DETAIL] *Cannot forward action tx_event from
0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen when running
the application with UHD 3.15.
I think this is just the fact that in UHD 4, RFNoC is much tighter in integration with the
host-side UHD. (The USRP's FPGA conains a flowgraph, conceptually not too different from a
flowgraph as in GNU Radio or Simulink, to handle the samples. Now, at host-side
application teardown, we need to tell the components of that graph to shut down, and
disengage. This might be a minor misunderstanding about what is still there during shutdown.)
I have tried running the benchmark_rate example with the same host computer and X310
running UHD 3.15 and UHD 4.5. With UHD 4.5 and high sample rates, I get an error:
uhd::op_timeout: RfnocError: OpTimeout: Control operation timed out waiting for ACK,
which stops the test before it begins running. Lower sample rates in UHD 4.5 run, but
produce more errors (including sequence errors) than the same set up running UHD 3.15.
Great work! Just to get a feeling: at which rates does this happen now, at which it did
work on 3.15?
I have tried refreshing the FPGA image for UHD 4.5 with no change in behavior. The
behavior is replicable using multiple host computers (Mac and Ubuntu). If anyone has
suggestions on debugging steps, or potential reasons why UHD 4.5 would seem laggy
compared to UHD 3.15 (despite running well with UHD 4.x on the B205mini), I would
greatly appreciate them. I suspect it may have something to do with the command queue
and how it evolves after getting behind.
Yeah, that would be a suspicion I share – but here's where I'll have to admit that I
haven't followed the changes to the radio ctrl changes lately, and flow control under UHD
4 is indeed a bit different than under 3.15.
Best,
Marcus M
Hi Anna,
I do not have a response to your direct question regarding performance.
However, I have a suggestion that may make the performance irrelevant.
The X310 image comes with a Replay block that accesses the DRAM chip for
storage. Given that you are sending a repeatable waveform, you should have
plenty of room to store this ahead of time and playout from the Replay
block. This is exactly how I do all of my radar testing. While it will take
some effort to make your application play nice with the Replay block, it
will be worth it because you will never fight "Late" or "Underrun" again.
(Note that there may be a RAM I/O bottleneck if trying to play both
channels simultaneously from the Replay block at 200 MS/s, but one channel
will be no problem).
Rob
On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome abroome@stanford.edu
wrote:
Hello,
We are developing a radar application built on the Ettus SDR platforms.
Our code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and
a B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to
take advantage of recent power calibration utilities and other features not
present in UHD 3.15, so I am now trying to run our code on an X310 with the
most recent UHD 4.5 release.
When running our code on the X310 with UHD 4.5 I get warnings for both
radio 0 and radio 1 (we transmit on one UBX160 and receive on the other): *[WARNING]
[0/Radio#0] *Attempting to set tick rate to 0. Skipping. The code uses
timed commands to transmit and receive samples from a frequency-swept pulse
at a consistent interval (pulse repetition frequency). Our application
requires a high PRF and we can tolerate some late command errors, but need
to log them for post-processing. Using UHD 4.5, the behavior is not as
expected in that something seems to be hanging. At some point during the
process—I think once we first hit a late command error—the timing becomes
very off from what it should be, and eventually, samples stop being
transmitted or received and the application just hangs. Sometimes when
killing the application, I get this warning: *[WARNING]
[RFNOC::GRAPH::DETAIL] *Cannot forward action tx_event from
0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen
when running the application with UHD 3.15.
I have tried running the benchmark_rate example with the same host
computer and X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high
sample rates, I get an error: uhd::op_timeout: RfnocError: OpTimeout:
Control operation timed out waiting for ACK, which stops the test before
it begins running. Lower sample rates in UHD 4.5 run, but produce more
errors (including sequence errors) than the same set up running UHD 3.15.
I have tried refreshing the FPGA image for UHD 4.5 with no change in
behavior. The behavior is replicable using multiple host computers (Mac and
Ubuntu). If anyone has suggestions on debugging steps, or potential reasons
why UHD 4.5 would seem laggy compared to UHD 3.15 (despite running well
with UHD 4.x on the B205mini), I would greatly appreciate them. I suspect
it may have something to do with the command queue and how it evolves after
getting behind.
Thanks,
Anna Broome
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
One more thing. One difference between 3.15 and 4.xx might be the length
of FIFOs on the FPGA for buffering Tx data arriving from the host. If the
4.xx buffers are smaller, then it may be more likely for a "glitch" to
occur if your host is a bit "bursty" when providing the samples. If this
is true, then perhaps you could build a custom X310 image with larger
buffers.
On Thu, Sep 28, 2023 at 3:26 PM Rob Kossler rkossler@nd.edu wrote:
Hi Anna,
I do not have a response to your direct question regarding performance.
However, I have a suggestion that may make the performance irrelevant.
The X310 image comes with a Replay block that accesses the DRAM chip for
storage. Given that you are sending a repeatable waveform, you should have
plenty of room to store this ahead of time and playout from the Replay
block. This is exactly how I do all of my radar testing. While it will take
some effort to make your application play nice with the Replay block, it
will be worth it because you will never fight "Late" or "Underrun" again.
(Note that there may be a RAM I/O bottleneck if trying to play both
channels simultaneously from the Replay block at 200 MS/s, but one channel
will be no problem).
Rob
On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome abroome@stanford.edu
wrote:
Hello,
We are developing a radar application built on the Ettus SDR platforms.
Our code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and
a B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to
take advantage of recent power calibration utilities and other features not
present in UHD 3.15, so I am now trying to run our code on an X310 with the
most recent UHD 4.5 release.
When running our code on the X310 with UHD 4.5 I get warnings for both
radio 0 and radio 1 (we transmit on one UBX160 and receive on the other): *[WARNING]
[0/Radio#0] *Attempting to set tick rate to 0. Skipping. The code uses
timed commands to transmit and receive samples from a frequency-swept pulse
at a consistent interval (pulse repetition frequency). Our application
requires a high PRF and we can tolerate some late command errors, but need
to log them for post-processing. Using UHD 4.5, the behavior is not as
expected in that something seems to be hanging. At some point during the
process—I think once we first hit a late command error—the timing becomes
very off from what it should be, and eventually, samples stop being
transmitted or received and the application just hangs. Sometimes when
killing the application, I get this warning: *[WARNING]
[RFNOC::GRAPH::DETAIL] *Cannot forward action tx_event from
0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen
when running the application with UHD 3.15.
I have tried running the benchmark_rate example with the same host
computer and X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high
sample rates, I get an error: uhd::op_timeout: RfnocError: OpTimeout:
Control operation timed out waiting for ACK, which stops the test before
it begins running. Lower sample rates in UHD 4.5 run, but produce more
errors (including sequence errors) than the same set up running UHD 3.15.
I have tried refreshing the FPGA image for UHD 4.5 with no change in
behavior. The behavior is replicable using multiple host computers (Mac and
Ubuntu). If anyone has suggestions on debugging steps, or potential reasons
why UHD 4.5 would seem laggy compared to UHD 3.15 (despite running well
with UHD 4.x on the B205mini), I would greatly appreciate them. I suspect
it may have something to do with the command queue and how it evolves after
getting behind.
Thanks,
Anna Broome
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
Hi Marcus,
After a bit more testing, I am increasingly convinced that the application begins to hang only after encountering a late command error for the first time. If this is indeed the case, the time it takes from start of application to hanging depends on the number of samples transmitted/received and the PRF. Basically it happens faster (on the order of 1s to low 10s of seconds) at higher duty cycles and may not happen at all at lower duty cycles. The tests I am currently doing attempt collect 100,000 pulses worth of data and should finish in about 50 seconds given the specified PRF. If I slow the PRF down, the late command errors don’t happen and the application never hangs.
Thanks for the information about the warnings being added in UHD 4.0—that certainly explains why I wasn’t seeing them before. When you say that "in UHD 4 RFNoC is much more tightly integrated with the host-side UHD” what do you mean by that? Forgive me if this is an overly broad question, I’m not all that familiar with FPGA architecture.
I can get exact numbers next week (no longer in lab today), but I think I was able to run the benchmark_rate example in UHD 3.15 in full duplex at around 10-20 MHz sample rates with no major problems (over 1GbE), whereas in UHD 4.15 a 20 MHz sample rate causes the control op error within the first couple of seconds.
Hi Rob—Yes, I totally agree that the Replay block is probably very useful to us and may ultimately be the way we end up going. I don’t think it was available in the standard release FPGA image until UHD 4.1 or 4.2 and my thought was to get our existing code working with the newer UHD prior to going down that path. Part of the upside of our application is that it can be run on multiple SDRs in the Ettus family. So the other reason we haven’t gone full steam into the Replay block is a desire to see if we could get the job done well enough with our non-RFNoC application and maintain the exact same code minus a configuration file for running on the X310 and B205mini.
Thanks for pointing out the potential difference in FIFO lengths between the UHD releases. I’ll look into that more.
Best,
Anna
On Sep 28, 2023, at 12:31 PM, Rob Kossler rkossler@nd.edu wrote:
One more thing. One difference between 3.15 and 4.xx might be the length of FIFOs on the FPGA for buffering Tx data arriving from the host. If the 4.xx buffers are smaller, then it may be more likely for a "glitch" to occur if your host is a bit "bursty" when providing the samples. If this is true, then perhaps you could build a custom X310 image with larger buffers.
On Thu, Sep 28, 2023 at 3:26 PM Rob Kossler <rkossler@nd.edumailto:rkossler@nd.edu> wrote:
Hi Anna,
I do not have a response to your direct question regarding performance. However, I have a suggestion that may make the performance irrelevant. The X310 image comes with a Replay block that accesses the DRAM chip for storage. Given that you are sending a repeatable waveform, you should have plenty of room to store this ahead of time and playout from the Replay block. This is exactly how I do all of my radar testing. While it will take some effort to make your application play nice with the Replay block, it will be worth it because you will never fight "Late" or "Underrun" again. (Note that there may be a RAM I/O bottleneck if trying to play both channels simultaneously from the Replay block at 200 MS/s, but one channel will be no problem).
Rob
On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome <abroome@stanford.edumailto:abroome@stanford.edu> wrote:
Hello,
We are developing a radar application built on the Ettus SDR platforms. Our code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and a B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to take advantage of recent power calibration utilities and other features not present in UHD 3.15, so I am now trying to run our code on an X310 with the most recent UHD 4.5 release.
When running our code on the X310 with UHD 4.5 I get warnings for both radio 0 and radio 1 (we transmit on one UBX160 and receive on the other): [WARNING] [0/Radio#0] Attempting to set tick rate to 0. Skipping. The code uses timed commands to transmit and receive samples from a frequency-swept pulse at a consistent interval (pulse repetition frequency). Our application requires a high PRF and we can tolerate some late command errors, but need to log them for post-processing. Using UHD 4.5, the behavior is not as expected in that something seems to be hanging. At some point during the process—I think once we first hit a late command error—the timing becomes very off from what it should be, and eventually, samples stop being transmitted or received and the application just hangs. Sometimes when killing the application, I get this warning: [WARNING] [RFNOC::GRAPH::DETAIL] Cannot forward action tx_event from 0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen when running the application with UHD 3.15.
I have tried running the benchmark_rate example with the same host computer and X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high sample rates, I get an error: uhd::op_timeout: RfnocError: OpTimeout: Control operation timed out waiting for ACK, which stops the test before it begins running. Lower sample rates in UHD 4.5 run, but produce more errors (including sequence errors) than the same set up running UHD 3.15.
I have tried refreshing the FPGA image for UHD 4.5 with no change in behavior. The behavior is replicable using multiple host computers (Mac and Ubuntu). If anyone has suggestions on debugging steps, or potential reasons why UHD 4.5 would seem laggy compared to UHD 3.15 (despite running well with UHD 4.x on the B205mini), I would greatly appreciate them. I suspect it may have something to do with the command queue and how it evolves after getting behind.
Thanks,
Anna Broome
USRP-users mailing list -- usrp-users@lists.ettus.commailto:usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.commailto:usrp-users-leave@lists.ettus.com
Hi Anna,
On 28.09.23 23:49, Anna Lamkin Broome wrote:
Hi Marcus,
After a bit more testing, I am increasingly convinced that the application begins to
hang only after encountering a late command error for the first time. If this is indeed
the case, the time it takes from start of application to hanging depends on the number
of samples transmitted/received and the PRF. Basically it happens faster (on the order
of 1s to low 10s of seconds) at higher duty cycles and may not happen at all at lower
duty cycles. The tests I am currently doing attempt collect 100,000 pulses worth of data
and should finish in about 50 seconds given the specified PRF. If I slow the PRF down,
the late command errors don’t happen and the application never hangs.
Yeah, that seems to be a relatively solid indication.
Thanks for the information about the warnings being added in UHD 4.0—that certainly
explains why I wasn’t seeing them before. When you say that "in UHD 4 RFNoC is much more
tightly integrated with the host-side UHD” what do you mean by that? Forgive me if this
is an overly broad question, I’m not all that familiar with FPGA architecture.
Always appreciated here to ask such questions! So, I'm myself not too familiar with the
UHD4/RFNoC4 internals myself. But: whereas RFNoC started out as "added functionality" on
UHD 3, where it just "something between the radio controller and the streamers going to
the host PC", UHD 4 is pretty consequent in that the FPGA image is made of RFNoC
components. Cleaner, but also means that the host has more insight into what happens.
I can get exact numbers next week (no longer in lab today), but I think I was able to
run the benchmark_rate example in UHD 3.15 in full duplex at around 10-20 MHz sample
rates with no major problems (over 1GbE), whereas in UHD 4.15 a 20 MHz sample rate
causes the control op error within the first couple of seconds.
Ah, so, rather low rates, and no 10 GbE!
Gotta think about that.
Best,
Marcus
Hi Rob—Yes, I totally agree that the Replay block is probably very useful to us and may
ultimately be the way we end up going. I don’t think it was available in the standard
release FPGA image until UHD 4.1 or 4.2 and my thought was to get our existing code
working with the newer UHD prior to going down that path. Part of the upside of our
application is that it can be run on multiple SDRs in the Ettus family. So the other
reason we haven’t gone full steam into the Replay block is a desire to see if we could
get the job done well enough with our non-RFNoC application and maintain the exact same
code minus a configuration file for running on the X310 and B205mini.
Thanks for pointing out the potential difference in FIFO lengths between the UHD
releases. I’ll look into that more.
Best,
Anna
On Sep 28, 2023, at 12:31 PM, Rob Kossler rkossler@nd.edu wrote:
One more thing. One difference between 3.15 and 4.xx might be the length of FIFOs on
the FPGA for buffering Tx data arriving from the host. If the 4.xx buffers are
smaller, then it may be more likely for a "glitch" to occur if your host is a bit
"bursty" when providing the samples. If this is true, then perhaps you could build a
custom X310 image with larger buffers.
On Thu, Sep 28, 2023 at 3:26 PM Rob Kossler rkossler@nd.edu wrote:
Hi Anna,
I do not have a response to your direct question regarding performance. However, I
have a suggestion that may make the performance irrelevant. The X310 image comes
with a Replay block that accesses the DRAM chip for storage. Given that you are
sending a repeatable waveform, you should have plenty of room to store this ahead
of time and playout from the Replay block. This is exactly how I do all of my radar
testing. While it will take some effort to make your application play nice with the
Replay block, it will be worth it because you will never fight "Late" or "Underrun"
again. (Note that there may be a RAM I/O bottleneck if trying to play both
channels simultaneously from the Replay block at 200 MS/s, but one channel will be
no problem).
Rob
On Thu, Sep 28, 2023 at 1:55 PM Anna Lamkin Broome <abroome@stanford.edu> wrote:
Hello,
We are developing a radar application built on the Ettus SDR platforms. Our
code runs well on an X310 with UBX160 daughterboards using UHD 3.15 and a
B205mini-i using UHD 4.1 and another B205mini-i using UHD 4.4. We want to take
advantage of recent power calibration utilities and other features not present
in UHD 3.15, so I am now trying to run our code on an X310 with the most recent
UHD 4.5 release.
When running our code on the X310 with UHD 4.5 I get warnings for both radio 0
and radio 1 (we transmit on one UBX160 and receive on the other): *[WARNING]
[0/Radio#0] *Attempting to set tick rate to 0. Skipping. The code uses timed
commands to transmit and receive samples from a frequency-swept pulse at a
consistent interval (pulse repetition frequency). Our application requires a
high PRF and we can tolerate some late command errors, but need to log them for
post-processing. Using UHD 4.5, the behavior is not as expected in that
something seems to be hanging. At some point during the process—I think once we
first hit a late command error—the timing becomes very off from what it should
be, and eventually, samples stop being transmitted or received and the
application just hangs. Sometimes when killing the application, I get this
warning: *[WARNING] [RFNOC::GRAPH::DETAIL] *Cannot forward action tx_event from
0/Radio#0:INPUT_EDGE:0, no neighbour found! These warnings do not happen when
running the application with UHD 3.15.
I have tried running the benchmark_rate example with the same host computer and
X310 running UHD 3.15 and UHD 4.5. With UHD 4.5 and high sample rates, I get an
error: uhd::op_timeout: RfnocError: OpTimeout: Control operation timed out
waiting for ACK, which stops the test before it begins running. Lower sample
rates in UHD 4.5 run, but produce more errors (including sequence errors) than
the same set up running UHD 3.15.
I have tried refreshing the FPGA image for UHD 4.5 with no change in behavior.
The behavior is replicable using multiple host computers (Mac and Ubuntu). If
anyone has suggestions on debugging steps, or potential reasons why UHD 4.5
would seem laggy compared to UHD 3.15 (despite running well with UHD 4.x on the
B205mini), I would greatly appreciate them. I suspect it may have something to
do with the command queue and how it evolves after getting behind.
Thanks,
Anna Broome
_______________________________________________
USRP-users mailing list -- usrp-users@lists.ettus.com
To unsubscribe send an email to usrp-users-leave@lists.ettus.com
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com
Hi Rob,
RFNoC_Replay as you mentioned is great without any underrun even with higher sample rate.
1- I have a same radar application and I implemented the TX/RX code with two methods in GNU Radio: with RFNoC_Replay and also with simple USRP sink/source blocks.
-with USRP sink/source blocks, while it transmits and receive radar waveform, I can save both of those TX and RX signals that needed for post processing.
-but when I use RFNoC_Replay, radar waveform first loaded to the DRAM in USRP and then transmitted directly from there to the antenna, so while the echo signals from targets can be received and save to file, but how can I save the transmitted waveform?
2- also here is the other question, while I am saving these TX and RX signals to file, how can I save timing information, like when each sample received. it is important because of the underurn and overflow happen during TX and RX. any suggestions?
Thank you.
re 2-:
Your recv call fills in a metadata object, which has a timespec member. You could use
that. I've hacked together debugging receivers in the past where I just wrote the
timespecs and the samples they belong to interleaved to a separate file, something like
(this is just copied together from code snippets I wrote elsewhere; no guarantees it works:)
#include <complex>
#include <cstdint>
#include <cstdio>
#include <fstream>
#include <ios>
#include <uhd/rfnoc_graph.hpp>
#include <uhd/types/metadata.hpp>
#include <uhd/types/stream_cmd.hpp>
#include <uhd/types/time_spec.hpp>
#include <vector>
constexpr size_t total_samples_to_get = 50'000'000;
struct timespec_entry {
uint64_t sample;
uhd::time_spec_t timespec;
};
int main(int argc, char *argv[]) {
if (argc != 3) {
std::cerr
<< "Got " << argc - 1
<< " arguments, but need two arguments: sample_file timespecs_file\n";
return -1;
}
std::ofstream sample_file(argv[1], std::ios_base::binary);
std::ofstream timespecs_file(argv[2], std::ios_base::binary);
size_t samples_received = 0;
// …
auto nocgraph = uhd::rfnoc::rfnoc_graph::make("");
// … set up the graph …
// … set up the gain, frequency and stuff …
auto rx = nocgraph->create_rx_streamer(1, {"fc32", "sc16"});
// … connect rx to the last noc block …
uhd::stream_cmd_t rx_command(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
rx_command.num_samps = 0;
rx_command.stream_now = true;
rx_command.time_spec = uhd::time_spec_t{};
rx->issue_stream_cmd(rx_command);
std::vector<std::complex<float>> sample_buffer(1 << 16);
while (total_samples_to_get > samples_received) {
uhd::rx_metadata_t metadata;
auto current_n_recv =
rx->recv(sample_buffer.data(), // where do the samples go
std::min(total_samples_to_get - samples_received,
sample_buffer.size()), // how many samples
metadata, // where does the metadata go
2.0 // timeout
);
sample_file.write(reinterpret_cast<char *>(sample_buffer.data()),
current_n_recv *
sizeof(decltype(sample_buffer)::value_type));
if (metadata.has_time_spec) {
timespec_entry entry{samples_received, metadata.time_spec};
timespecs_file.write(reinterpret_cast<char *>(&entry), sizeof(entry));
}
samples_received += current_n_recv;
}
rx->issue_stream_cmd({uhd::stream_cmd_t::STREAM_MODE_STOP_CONTINUOUS});
sample_file.close();
timespecs_file.close();
return 0;
}
On 30.09.23 06:21, h57jafari@gmail.com wrote:
Hi Rob,
RFNoC_Replay as you mentioned is great without any underrun even with higher sample rate.
1- I have a same radar application and I implemented the TX/RX code with two methods in
GNU Radio: with RFNoC_Replay and also with simple USRP sink/source blocks.
-with USRP sink/source blocks, while it transmits and receive radar waveform, I can save
both of those TX and RX signals that needed for post processing.
-but when I use RFNoC_Replay, radar waveform first loaded to the DRAM in USRP and then
transmitted directly from there to the antenna, so while the echo signals from targets
can be received and save to file, but how can I save the transmitted waveform?
2- also here is the other question, while I am saving these TX and RX signals to file,
how can I save timing information, like when each sample received. it is important
because of the underurn and overflow happen during TX and RX. any suggestions?
Thank you.
USRP-users mailing list --usrp-users@lists.ettus.com
To unsubscribe send an email tousrp-users-leave@lists.ettus.com