Send USRP-users mailing list submissions to
[email protected]
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
or, via email, send a message with subject or body 'help' to
[email protected]
You can reach the person managing the list at
[email protected]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of USRP-users digest..."
Today's Topics:
1. Digital Hopping (Nuria Ibrahim)
2. Re: Digital Hopping (Josh Blum)
3. Re: Problems with Tx-MIMO (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Wed, 9 Jan 2013 23:33:18 -0800 (PST)
From: Nuria Ibrahim <[email protected]>
To: [email protected]
Subject: [USRP-users] Digital Hopping
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Dear Josh
I have a few questions
regarding digital hopping(DSP/Cord) and? streaming data from
usrp2
as follows:
Q#1. in digital hopping as you have
stated we can leave the LO fixed and tune from the DSP or Cord and in
my understanding I thought the RF front-end(Local Oscillator ) will
remain stable locked regardless of retuning request because the ?
rf_freq_policy is set? to None .However when I call?
get_rx_freq() it returns the new frequency why?
please clarify,
here is an example
with piece of code-
?? freq = 936.4Mhz???
???
???
m_pSdev->set_rx_freq(freq); % tunes to my beacon frequency
???
m_pSdev->get_rx_freq() ;???? %returns
936.4Mhz as expected
????
??????
.
??????
.???????????????????????????????????
% I have done some decoding on that frequency
??????
.
??? %Switch to frequency Hopping
???????
cmd_time = uhd::time_spec_t(time_ahead); %planning to tune at
time time_ahead in advance?
??? ???
??? ?m_pSdev->set_command_time(cmd_time);%set
command_time on device??? ??? ???
??? ??? ?
???
??? ??? ?uhd::tune_request_t
tune_req(hope_freq);??? % request to retune to new
hope_freq ?
??? ??? ???
?tune_req.rf_freq_policy=uhd::tune_request_t::policy_t('N');
%set RF ploicy to None
??? ??? ???
?m_pSdev->set_rx_freq(tune_req);
??? ???
??? ?float sleep_milliseconds = ( time_ahead -
m_pSdev->get_time_now() ).get_real_secs();??? ???
???
??boost::this_thread::sleep(boost::posix_time::milliseconds(
sleep_milliseconds));%sleep to prevent command from
overwritting
??? ??? ???
?m_pSdev->clear_command_time();???
???
??? ??? ?time_ahead+=
hopping_prd;% update time_ahead for next hop
?
Q#2. I have set my streaming mode to
continuous using the following command
uhd::stream_cmd_t
stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
in digital hopping is there any
possibility where by the usrp could go unstable in retuning
process?if Yes , does this mean that when I process data on my Queue
I should be careful enough to skip all timestamped samples that are
received before the usrp attains locking state?again if Yes in my
application I have measured tuning latency to be in the range of 190
-217 micro-seconds. And as you have mentioned in the forum worst
case tuning latency is 300micro-seconds.now suppose I have requested
tuning at time x and would need to skip(in processing) all samples
between x and x+tau, where tau could assume any value in the
range(190 ? 300micro-seconds).however my confusion is which value
of tau should I take in my calculation?because my application must
stay synchronized through all hopping frequencies and is there any
means where I could know the exact time usrp achieves a lock using
the get_rx_lo_locked() function so that I will be more accurate in my
calculation?
THANKS!
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130109/cf10732a/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 10 Jan 2013 09:35:53 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Digital Hopping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
> .
> %Switch to frequency Hopping
>
> cmd_time = uhd::time_spec_t(time_ahead); %planning to tune at
> time time_ahead in advance
>
> m_pSdev->set_command_time(cmd_time);%set
> command_time on device
>
>
> uhd::tune_request_t
> tune_req(hope_freq); % request to retune to new
> hope_freq
>
> tune_req.rf_freq_policy=uhd::tune_request_t::policy_t('N');
> %set RF ploicy to None
>
> m_pSdev->set_rx_freq(tune_req);
>
> float sleep_milliseconds = ( time_ahead -
> m_pSdev->get_time_now() ).get_real_secs();
>
>
> boost::this_thread::sleep(boost::posix_time::milliseconds(
> sleep_milliseconds));%sleep to prevent command from
> overwritting
>
> m_pSdev->clear_command_time();
>
> time_ahead+=
> hopping_prd;% update time_ahead for next hop
>
>
The code looks to be the right idea. I am a little confused about the issue.
* Is the problem that after set_rx_freq(tune_req), get_rx_freq() returns
a value != hop_freq? If this is the case, what is it returning?
* Or is the issue that you expected get_rx_freq() to readback hop_freq
after time_ahead, but instead it was immediate? In this case, i can see
how thats undesirable, but the setting is shadowed immediately in the
driver once the command is set, it doesnt have knowledge of the the
FPGA's internal control execution.
>
> Q#2. I have set my streaming mode to
> continuous using the following command
>
> uhd::stream_cmd_t
> stream_cmd(uhd::stream_cmd_t::STREAM_MODE_START_CONTINUOUS);
>
> in digital hopping is there any
> possibility where by the usrp could go unstable in retuning
> process?if Yes , does this mean that when I process data on my Queue
> I should be careful enough to skip all timestamped samples that are
> received before the usrp attains locking state?again if Yes in my
Yes
> application I have measured tuning latency to be in the range of 190
> -217 micro-seconds. And as you have mentioned in the forum worst
> case tuning latency is 300micro-seconds.now suppose I have requested
> tuning at time x and would need to skip(in processing) all samples
> between x and x+tau, where tau could assume any value in the
> range(190 ? 300micro-seconds).however my confusion is which value
> of tau should I take in my calculation?because my application must
300us is the worse case lock time, so I would assume the worst case to
be safe
> stay synchronized through all hopping frequencies and is there any
> means where I could know the exact time usrp achieves a lock using
> the get_rx_lo_locked() function so that I will be more accurate in my
> calculation?
>
>
It dependents on the implementation of get_rx_lo_locked(). Supposing a
GPIO triggers high on lock, the host could get a timestamped event. This
isnt implemented yet, but should be possible on SBX/WBX.
However, some daughterboards lock detects are implemented through spi
readback, so there really cant be an async event anyway. Your best
option is the time window.
FWIW, a gnuradio developer does have a special branch of UHD w/ mods to
send async messages on GPIO changes:
http://www.gnuradio.org/cgit/jcorgan-uhd.git/log/?h=gpio
-josh
------------------------------
Message: 3
Date: Thu, 10 Jan 2013 10:09:46 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Problems with Tx-MIMO
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> Setting device timestamp to 0...
> Checking TX: LO: locked ...
> Checking TX: Ref: locked ...
> Press Ctrl + C to stop streaming...
> SSSSSSSSSSSSSSSSSSSSSSSSSSSSS^C
> Done!
>
> I've search the uhd source code, but all I can find is that "O"s and "U"s may
> be printed if over- or under-flow occurs.
>
>
Thats a sequence error in transmit. It would be expected if packets were
not being sent, but the driver thought they were due to this ENOBUFS
Here is the patch for freebsd, a little cleaned up w/ comments. I was
wondering if you would try it out. I dont have a way to test freebsd
ATM, and my VM isnt a good substitute anyway.
http://pastebin.com/kMci34ub
-josh
------------------------------
Subject: Digest Footer
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
End of USRP-users Digest, Vol 29, Issue 10
******************************************
