[USRP-users] Frequency hopping on short time scale using DSP tuning

Richard Joseph Muri ri28856 at mit.edu
Tue Jan 28 16:59:17 EST 2020


I have an application that schedules transmissions/receives on a short time scale (order of tens of microseconds). I'm attempting to gauge the feasibility of using a x310 with UBX-160 daughterboards and 10Gb ethernet for the application.

I wrote a quick test to see approximately how long it would take to schedule a bunch of DSP retunes:

for (int i = 0; i < packets_to_send; i += batch_size)
        start = std::chrono::system_clock::now();
        for (int j = 0; j < batch_size; j++)
            // Hop at a scheduled time
            cmd_time += schedule_increment;
        stop = std::chrono::system_clock::now();
        elapsed = std::chrono::duration_cast<std::chrono::microseconds>(stop - start).count();
        if (elapsed < batch_latency)
            busyCheck(batch_latency - elapsed);
            std::cout << elapsed << ", ";

The behavior is slightly different than I would expect. I know the USRP has a command FIFO with approximately 16 slots to queue up commands. I would expect that the first chunk of commands would execute quickly, and then the set_tx_freq call would start blocking as it waits for the queue to have space. Instead I see that the first handful of commands take on the order of 1000 us, and it steadily decreases in time until hitting a steady state where it takes 250 - 300 us to schedule a command.

Are there any obvious mistakes in my test setup? Can I reduce my retune command times to under 100 us?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20200128/deab16c8/attachment.html>

More information about the USRP-users mailing list