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. Re: Digital Hopping (Nuria Ibrahim)
2. Re: Digital Hopping (Josh Blum)
3. streamers+boost:serial_port=problem ? (Per Zetterberg)
4. Re: streamers+boost:serial_port=problem ? (Per Zetterberg)
5. Re: streamers+boost:serial_port=problem ? (Patrik Tast)
----------------------------------------------------------------------
Message: 1
Date: Thu, 10 Jan 2013 22:22:12 -0800 (PST)
From: Nuria Ibrahim <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Digital Hopping
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
--- On Thu, 1/10/13, Nuria Ibrahim <[email protected]> wrote:
From: Nuria Ibrahim <[email protected]>
Subject: Re: [USRP-users] Digital Hopping
To: [email protected]
Date: Thursday, January 10, 2013, 10:20 PM
?Dear Josh
Thanks, It was very helpful
My question is regarding the
rf_freq_policy, in one of your replay to digital hopping question,
you have said if we set rf_freq_policy to NONE that the RF
front-end frequency will not be affected by the retuning request. for
example if I initially tune my USRP simply using
set_rx_freq(936.4Mhz?) with the default rf_freq_policy , then
later in the digital hopping process I tune it to hope_freq with
rf_freq_policy set to NONE I expected the get_rx_freq() function
to return 936.4Mh instead of hope_freq, however it returned
hope_freq.please shed some light on this
Thanks
--- On Thu, 1/10/13, Josh Blum <[email protected]> wrote:
From: Josh Blum <[email protected]>
Subject: Re: [USRP-users] Digital Hopping
To: [email protected]
Date: Thursday, January 10, 2013, 7:35 AM
> .
>? ???%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
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130110/c8609b74/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 11 Jan 2013 00:32:21 -0600
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Digital Hopping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> My question is regarding the
> rf_freq_policy, in one of your replay to digital hopping question,
> you have said if we set rf_freq_policy to NONE that the RF
> front-end frequency will not be affected by the retuning request. for
> example if I initially tune my USRP simply using
> set_rx_freq(936.4Mhz ) with the default rf_freq_policy , then
> later in the digital hopping process I tune it to hope_freq with
> rf_freq_policy set to NONE I expected the get_rx_freq() function
> to return 936.4Mh instead of hope_freq, however it returned
> hope_freq.please shed some light on this
> Thanks
>
>
get_rx_freq returns the overall center frequency of the receiver chain
(not only the LO, but combined LO and CORDIC in the DSP)
-josh
------------------------------
Message: 3
Date: Fri, 11 Jan 2013 12:38:46 +0000
From: Per Zetterberg <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [USRP-users] streamers+boost:serial_port=problem ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Dear Josh and List,
I have the following problem. I have an app in development that (at present)
just sets up USPRs and then exists. The last six lines are as follows:
// Open streamers
rx_stream = d_mdev->get_rx_stream(stream_args);
tx_stream = d_mdev->get_tx_stream(stream_args);
// Open serial GPS
boost::asio::io_service io;
boost::asio::serial_port port( io );
port.open("/dev/ttyUSB0" );
exit(1);
The programs takes about nine seconds. If I remove the first two lines
("rx_stream, tx_stream) it takes around six seconds. If I remove
"port.open("/dev/ttyUSB0" )" but keep the first two lines (i.e. "rx_stream,
tx_stream") it also takes around six seconds. If I remove all these three lines
it also takes about six seconds. Thus some problem arises due to some kind of
conflict between the streamers and the serial device.
The serial device is a GPS. I bought this a long time before Ettus provided
GPSs.
BR/
Per
------------------------------
Message: 4
Date: Fri, 11 Jan 2013 13:34:41 +0000
From: Per Zetterberg <[email protected]>
To: "[email protected]" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] streamers+boost:serial_port=problem ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
>From: USRP-users [[email protected]] on behalf of Per
>Zetterberg [[email protected]]
>Sent: Friday, January 11, 2013 1:38 PM
>To: [email protected]
>Cc: [email protected]
>Subject: [USRP-users] streamers+boost:serial_port=problem ?
>
>Dear Josh and List,
>
>
>I have the following problem. I have an app in development that (at present)
>just sets up USPRs and then exists. The last six lines are as follows:
>
> // Open streamers
> rx_stream = d_mdev->get_rx_stream(stream_args);
> tx_stream = d_mdev->get_tx_stream(stream_args);
>
> // Open serial GPS
> boost::asio::io_service io;
> boost::asio::serial_port port( io );
> port.open("/dev/ttyUSB0" );
> exit(1);
>The programs takes about nine seconds. If I remove the first two lines
>("rx_stream, tx_stream) it takes around six seconds. If I remove
>>"port.open("/dev>>>/ttyUSB0" )" but keep the first two lines (i.e.
>"rx_stream, tx_stream") it also takes around six seconds. If I remove all
>these three lines >it also takes about six >seconds. Thus some problem arises
>due to some kind of conflict between the streamers and the serial device.
>The serial device is a GPS. I bought this a long time before Ettus provided
>GPSs.
I have found something. In the beginning of the program I am using the
following:
if (!(uhd::set_thread_priority_safe(1,true))) {
std::cout << "Problem setting thread priority" << std::endl;
return 1;
};
(which I obviously have taken from Josh's examples). However, if I remove these
lines, the program takes around six seconds in all cases.
BR/
Per
------------------------------
Message: 5
Date: Fri, 11 Jan 2013 18:21:08 +0200
From: Patrik Tast <[email protected]>
To: Per Zetterberg <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] streamers+boost:serial_port=problem ?
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hej Per,
Just a thought/guess, perhaps if you don't have credentials to connect
to /dev/ttyUSBx the port.open(...) will retry and retry until finally
*give up*?
If so, check your /etc/udev/rules.d/ here is what works for me, see
README
https://github.com/poes-weather/Sensor-Benchmark
I use qextserialport port for serial traffic in this example. GPS code
if interested
https://github.com/poes-weather/Sensor-Benchmark/blob/master/gps/gps.cpp
Attached a screenshot
Patrik
-----Original Message-----
From: Per Zetterberg <[email protected]>
To: [email protected] <[email protected]>
Cc: [email protected] <[email protected]>
Subject: Re: [USRP-users] streamers+boost:serial_port=problem ?
Date: Fri, 11 Jan 2013 13:34:41 +0000
>From: USRP-users [[email protected]] on behalf of Per
>Zetterberg [[email protected]]
>Sent: Friday, January 11, 2013 1:38 PM
>To: [email protected]
>Cc: [email protected]
>Subject: [USRP-users] streamers+boost:serial_port=problem ?
>
>Dear Josh and List,
>
>
>I have the following problem. I have an app in development that (at present)
>just sets up USPRs and then exists. The last six lines are as follows:
>
> // Open streamers
> rx_stream = d_mdev->get_rx_stream(stream_args);
> tx_stream = d_mdev->get_tx_stream(stream_args);
>
> // Open serial GPS
> boost::asio::io_service io;
> boost::asio::serial_port port( io );
> port.open("/dev/ttyUSB0" );
> exit(1);
>The programs takes about nine seconds. If I remove the first two lines
>("rx_stream, tx_stream) it takes around six seconds. If I remove
>>"port.open("/dev>>>/ttyUSB0" )" but keep the first two lines (i.e.
>"rx_stream, tx_stream") it also takes around six seconds. If I remove all
>these three lines >it also takes about six >seconds. Thus some problem arises
>due to some kind of conflict between the streamers and the serial device.
>The serial device is a GPS. I bought this a long time before Ettus provided
>GPSs.
I have found something. In the beginning of the program I am using the
following:
if (!(uhd::set_thread_priority_safe(1,true))) {
std::cout << "Problem setting thread priority" << std::endl;
return 1;
};
(which I obviously have taken from Josh's examples). However, if I remove these
lines, the program takes around six seconds in all cases.
BR/
Per
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Qt-GPS-test.jpg
Type: image/jpeg
Size: 157894 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130111/79cfd602/attachment-0001.jpg>
------------------------------
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 11
******************************************
