Dear all,
I’ve read on the Ettus transceiver daughterboards datasheet that the
PLL lock time is around 200us, which makes it suitable for some FH
systems (eg. Bluetooth). I’ve tried to measure this time (plus any other
possible latency between the Host and the USRP2) by timestamping a
sequence of “set_center_freq()” calls that swaps between two different
frequencies (2.412 GHz and 2.413 GHz) many times in a top_block run
(using only C++, not Python).
The resulting measured time values are around 400us using a USRP2 +
XCVR2450 and a quadcore host.
- How was the 200us time value measured?
- Is it possible to obtain a sustained hopping rate of 1/200us?
- If yes, how can we get that value?
Best regards,
Sergio Benco
On 06/10/2011 06:15 AM, Sergio Benco wrote:
Dear all,
I’ve read on the Ettus transceiver daughterboards datasheet that the
PLL lock time is around 200us, which makes it suitable for some FH
systems (eg. Bluetooth).
Having worked on Bluetooth systems in the past, I can tell you that
200us would be marginal at best for hopping time.
I’ve tried to measure this time (plus any other
possible latency between the Host and the USRP2) by timestamping a
sequence of “set_center_freq()” calls that swaps between two different
frequencies (2.412 GHz and 2.413 GHz) many times in a top_block run
(using only C++, not Python).
The resulting measured time values are around 400us using a USRP2 +
XCVR2450 and a quadcore host.
- How was the 200us time value measured?
This is the time between when the PLL starts the frequency change to
when it is finished. It is highly variable, and affected by numerous
settings in the chip.
- Is it possible to obtain a sustained hopping rate of 1/200us?
Probably not when the hopping is initiated from the host.
- If yes, how can we get that value?
Initiate the hopping on the device. This will take some FPGA work on
your part.
Matt
Dear Matt E.,
I have noticed that I can modify the member function:
usrp2_source_base::set_center_freq(double frequency, usrp2::tune_result
*tr)
by replacing the default:
usrp2::impl::transmit_cmd_and_wait(void *cmd, size_t len, pending_reply
*p,
double secs)
with the version without any waiting time:
usrp2::impl::transmit_cmd(void *cmd_, size_t len_)
In this way the “set frequency” call seems to return in about 10us, so
almost immediately.
My first question is that if using “transmit_cmd” could generate
problems
when changing frequency at a Bluetooth hopping rate (1600 hops/s or
625us).
I’ve read that the XCVR2450 MAXIM2829 RF transceiver provides a
CHANNEL-SWITCHING FREQUENCY SETTLING time (page 17 in the datasheet) of
about 25/30us (maybe I can even tolerate some frequency error in the
Bluetooth case so that it can be considered shorter).
The second question is how can I estimate the minimum delay required to
reach the PLL when a transmit_cmd is called?
I was wondering if I can consider the PLL lock process started when the
transmit_cmd(…) is being called in the modified set_center_freq (…)
member function. If yes, I could wait for the PLL to lock with little
error
on the next frequency hop (30us), plus the time to process the set
frequency
command (200us ?) without any return (the already measured 400us delay /
2 =
200us, I guess). Is that correct?
Best Regards,
Sergio Benco