discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Maximum Frequency Hopping speed of the Ettus Tran


From: Sergio Benco
Subject: Re: [Discuss-gnuradio] Maximum Frequency Hopping speed of the Ettus Transceiver RF frontends
Date: Fri, 17 Jun 2011 10:45:49 +0200


Dear Matt Ettus,
 

 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


 
> 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. 
>> 
>> 1) 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.
> 
>> 2) Is it possible to obtain a sustained hopping rate of 1/200us? 
> 
> Probably not when the hopping is initiated from the host.
> 
>> 3) If yes, how can we get that value?
>> 
> 
> 
> Initiate the hopping on the device. This will take some FPGA work on
> your part.
> 
> Matt
> 





reply via email to

[Prev in Thread] Current Thread [Next in Thread]