Hi Jiya,
That's going to be the sum of:
On the transmitter's site:
- actual time it takes for each packet to be computed in your GNU Radio blocks
- instantaneous amount of samples in buffers, due to the
· time it takes to schedule a block that has data to work on,
· Operating system thread scheduling
- host platform OS / driver overhead (non-deterministic, depends on hardware, interrupt
load, general CPU utilization, driver…)
- Hardware connection latency (USB, Ethernet, PCIe,…) (depending on the link,
non-deterministic, and might range from 100s of ns to ms)
- SDR Hardware latencies (relatively static, but not constant nor identical across
configurations, typically depends on the kind of processing done in-device)
Then, the actual RF channel (so, speed of light, essentially, considering all relevant
multipath/dispersive effects).
On the receiver's side, the same, basically, in reverse
- SDR hardware
- Hardware connection
- OS / driver
- buffer fillage
- computation time
As you can see, there's a lot of nondeterminism in that. It's hard to tell what the main
contributor is there – but most commonly it's dominated by the buffer fillage due to
processing times and CPU time competition.
You can however manage things quite a bit
1. (transmit side) Some SDRs (most prominently, all the Ettus USRPs) support "timed
commands", which allow to specify a specific time for transmission to happen – you'd put
that far enough into the future for the nondeterministic transmitter computer latency is
reliably over at that point
2. (GNU Radio data processing) Derek & Matt have written latency manager [1] to bound
latency with a credit-based flow control scheme
Best regards,
Marcus
[1]
https://www.gnuradio.org/grcon/grcon19/presentations/Managing_Latency/Matt%20Ettus%20-%20Managing%20Latency.pdf
https://www.youtube.com/watch?v=jq0RewceCwc
On 01.06.23 07:16, Jiya Johnson wrote:
Good morning,
I would like to know *how to calculate the latency if we are sending a signal or a
data packet from source to receiver in GNU Radio*.
Thanks in Advance.