What's the latency of bladeRF?

Off topic threads and discussions

Moderator: robert.ghilduta

Post Reply
Posts: 455
Joined: Thu Jun 06, 2013 8:15 pm

Re: What's the latency of bladeRF?

Post by jynik » Tue Jan 05, 2016 8:49 am

What is your target application, and what type of latency are you looking for and referring to? There is no specific number -- this all depends on how you use and configure the device, as well as what optimizations you're willing to implement.

When moving samples between a host machine and the RF Front End (RFFE), there are a number sources of potential latency, each of which can be configured and tweaked, depending on your needs
  • Your host-side software and how it buffers data or introduces delay (e.g., buffer exchange between processing blocks, filter group delay)
  • libbladeRF buffering - you can configure the number of host-side buffers and USB transfers used, as well as the size of buffers used. Larger and more buffers will help provide elasticity. For example when RX'ing, if your host is momentarily busy, having more, larger, buffers will ensure there is somewhere for samples to be stored until you can process them. However, this may come with a trade-off in increased latency. On the other hand, using smaller, fewer buffers can yield decreased latency, but requires your processing can keep up with the data rate.
  • The USB interface and the FX3 firmware - You may find measurable differences between USB host controllers and USB stacks/drivers in terms of their maximum transfer rates and any overhead. Additionally, there are DMA buffers in the FX3 firmware that move samples between USB endpoints and the FPGA -- the size and number of these may be modified in the code.
  • The FPGA sample FIFOs - If I recall correctly, these are 4096 samples deep. There's one for RX and one for TX. Again, you're free to modify the HDL to change this.
If you are targeting a very low-latency application, you will likely want to prototyping with the host software, but then port your final implementation to the FPGA, eliminating the host-side and USB-related overhead/latency.

If you definitely are pursuing a host-based implementation, I would advise reviewing the support for metadata and timestamps. This allows you to schedule reception, transmission, and tuning.

I know that's probably a lot more than you were looking for, but I hope this helps.
- Jon

Post Reply