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: help: USRP1 + WBX 50-2200 (Marcus M?ller)
2. Re: Computation engine clock rates (Matt Ettus)
3. Re: UHD and Thread Safety (Ben Hilburn)
4. Re: UHD and Thread Safety (Ben Hilburn)
5. Re: UHD and Thread Safety (Ben Hilburn)
6. Re: UHD and Thread Safety (Andy Walls)
7. Re: Using an X310 as an NI RIO (Patrick Sisterhen)
8. Re: UHD and Thread Safety (Balint Seeber)
9. Re: UHD and Thread Safety (Andy Walls)
10. Re: UHD and Thread Safety (Michael West)
11. Re: LFTX output amplitude (Michael Rahaim) (Louis Brown)
12. Re: LFTX output amplitude (Michael Rahaim) (Ian Buckley)
13. Re: UHD and Thread Safety (Andy Walls)
14. Re: LFTX output amplitude (Michael Rahaim) (Michael Rahaim)
15. Re: LFTX output amplitude (Michael Rahaim) (Marcus M?ller)
----------------------------------------------------------------------
Message: 1
Date: Thu, 11 Dec 2014 18:25:48 +0100
From: Marcus M?ller <[email protected]>
To: Thesis 2015 <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] help: USRP1 + WBX 50-2200
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8
Hello SKA15!
A few ideas,:
* This is getting a GNU Radio-related discussion; there's a very active
mailing list [1] for GNU Radio.
* The 96k sampling rate is not supported by every audio device; try 48k
and match the interpolation.
* The GNU Radio companion has a nice screenshot feature which will
export PNG images that are easier to read ;)
* Make sure the antenna is connected to the right port (RX2)
But most importantly, you forgot to share the output of uhd_usrp_probe.
This would be nice to have, because it might explain why you can't set
the 88.1MHz, which is the gravest problem so far.
Greetings,
Marcus
[1] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 12/11/2014 06:15 PM, Thesis 2015 wrote:
> oh...thank you for your reply...
>
>
> The sampling rate of the usrp_source block is 5Msps. The picture attached
> is a screenshot of the flow graph:
>
>
>
> On Thu, Dec 11, 2014 at 1:27 AM, Marcus M?ller <[email protected]>
> wrote:
>
>> Hello SKA15,
>>
>> nice meeting you here :)
>>
>> There is one thing that is most probably easy to solve: We're seeing a lot
>> of 'O', meaning overflow, which means that your system can't cope with the
>> samples that the USRP1 is producing fast enough. What is the sampling rate
>> you use in the usrp_source block? The USRP1, bound by USB2 speeds, can't
>> really produce very high sampling rates, so unless the PC you are using to
>> do this is really slow, this points to your sound card's sampling rate
>> being significantly slower than the sample rate the USRP pushes through the
>> flow graph. Do you resample to match your sample rate to the one you use
>> for your alsa sink? Which one is that?
>>
>> The "not being able to tune to 88.1MHz" warning is indeed strange; could
>> you run "uhd_usrp_probe" on a console and attach the textual output of that
>> command?
>>
>> Greetings,
>> Marcus
>>
>>
>> On 12/10/2014 03:53 AM, Thesis 2015 via USRP-users wrote:
>>
>> Good day,
>>
>> We are beginners using the USRP1 with WBX v.3 50-2200 daughterboard and GNU
>> radio Companion version 3.7.5.1 with UHD_003.008.000-18-g864f84b5 installed
>> on Ubuntu 14.04 LTS operating system. Our goal in using these is to create
>> an SDR WBFM receiver.
>>
>> We have followed what was done in the video posted by the ettus research
>> (http://www.ettus.com/kb/detail/sdr-for-beginners-building-an-fm-receiver-with-the-usrp-and-gnu-radio)
>> but have encountered some problems. As we ran the GRC file, both the fft
>> plot and scope plot appeared but all we could hear are static sounds
>> together with the script shown below:
>>
>> Executing: "/media/thesis/Data/Downloads/Thesis/FM Reciever using
>> GRC/fm_example.py"
>>
>> linux; GNU C++ version 4.8.2; Boost_105400; UHD_003.008.000-18-g864f84b5
>>
>> Using Volk machine: sse4_1_64_orc
>> -- Opening a USRP1 device...
>> -- Loading FPGA image: /usr/local/share/uhd/images/usrp1_fpga.rbf... done
>> -- Using FPGA clock rate of 64.000000MHz...
>> WARN: Sensor 'lo_locked' failed to lock within timeout on channel 0.
>>
>> UHD Warning:
>> Tune Request: 88.100000 MHz
>> The requested RX frequency is outside of the system range, and has
>> been clipped:
>> Target Frequency: 88.100000 MHz
>> Clipped Target Frequency: 0.000000 MHz
>> Successfully tuned to 0.000000 MHz
>> INFO: Audio sink arch: alsa
>> OOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO
>>
>> Done
>>
>> We are hoping that you could help us with this problem. Thank you.
>>
>> -SKA15-
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing
>> [email protected]http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
------------------------------
Message: 2
Date: Thu, 11 Dec 2014 10:24:58 -0800
From: Matt Ettus <[email protected]>
To: [email protected]
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Computation engine clock rates
Message-ID:
<CAN=1kn-_eu8oqvpUOi6w7tgn8=uy2dxat3jqsoscirc_qxs...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
To a first order, you can use any clock rate you like for computation
engines, either slower or faster than the bus clock. However, if you go
too slowly, then your block can dribble data out to the rest of the system
and cause congestion.
If you need to have a really slow clock, you are probably better off
running the noc_shell and axi_wrapper at bus_clk rates and do your own
clock crossing within your logic to operate at a lower rate.
Matt
On Thu, Dec 11, 2014 at 6:16 AM, seb fenn via USRP-users <
[email protected]> wrote:
> Hello
>
> Are there any constraints on the clock rates that can be used with CEs?
>
> In the rfnoc_ce_auto_inst.v example and x300_core.v I see that the CEs
> generally have their CE clocks connected to the 166.67MHz bus clock,
> although I think the radios use 200MHz for the CE clock.
>
> Can I use any clock I want for the ce_clk input, say 50MHz, or does going
> slower than the bus clock cause problems?
>
> Thanks in advance.
>
> Seb
>
>
> ________________________________
> This message is intended for the use only of the person(s) (?Intended
> Recipient?) to whom it is addressed. It may contain information that is
> privileged and confidential. Accordingly any dissemination, distribution,
> copying or other use of this message or any of its content by any person
> other than the Intended Recipient may constitute a breach of civil or
> criminal law and is strictly prohibited. If you are not the Intended
> Recipient, please contact the sender as soon as possible.
>
> TRL Technology Limited is a private company registered in England with the
> company number 1705039 whose registered office is at Sigma Close, Shannon
> Way, Tewkesbury GLOS. GL20 8ND, UK.
> _______________________________________________
> 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/20141211/c075c856/attachment-0001.html>
------------------------------
Message: 3
Date: Thu, 11 Dec 2014 12:12:10 -0800
From: Ben Hilburn <[email protected]>
To: "Perelman, Nathan" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID:
<CAOEVZkJQaM-bDQcf1tETxZroE4XMbP=vWfgem5z=61vbwle...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Nathan -
Generally, any UHD function that doesn't involve streaming is *not
*thread-safe.
So if you called "get_time_now" from two separate threads at the same time,
that is *not* a thread-safe operation.
If all you are doing is polling sensors from a thread that is different
from the thread in which you started streaming, you should be OK. But, it
is not technically thread safe.
Cheers,
Ben
On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
[email protected]> wrote:
> I?ve been assuming that calls to UHD functions that don?t change settings
> on the USRP are generally thread safe and can be called from another thread
> even while a capture is ongoing. Is this an accurate assumption? The
> functions I?m calling are get_mboard_sensor() (for GPS information and
> ref_locked) and get_time_now(). Thanks.
>
> -Nathan Perelman
>
> _______________________________________________
> 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/20141211/76bc55e5/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 11 Dec 2014 12:14:45 -0800
From: Ben Hilburn <[email protected]>
To: "Perelman, Nathan" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID:
<caoevzklkgw68zhozjunjoszt-tay0ca_qze4eadxsujgewq...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Actually, what I just said is wrong, because calling those functions will
result in packets being sent from the device.
So, no. Nothing is thread safe, and even polling for sensor data could
cause issues.
Cheers,
Ben
On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <[email protected]> wrote:
> Hi Nathan -
>
> Generally, any UHD function that doesn't involve streaming is *not
> *thread-safe.
> So if you called "get_time_now" from two separate threads at the same time,
> that is *not* a thread-safe operation.
>
> If all you are doing is polling sensors from a thread that is different
> from the thread in which you started streaming, you should be OK. But, it
> is not technically thread safe.
>
> Cheers,
> Ben
>
> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
> [email protected]> wrote:
>
>> I?ve been assuming that calls to UHD functions that don?t change settings
>> on the USRP are generally thread safe and can be called from another thread
>> even while a capture is ongoing. Is this an accurate assumption? The
>> functions I?m calling are get_mboard_sensor() (for GPS information and
>> ref_locked) and get_time_now(). Thanks.
>>
>> -Nathan Perelman
>>
>> _______________________________________________
>> 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/20141211/c6f56dc3/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 11 Dec 2014 12:16:41 -0800
From: Ben Hilburn <[email protected]>
To: "Perelman, Nathan" <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID:
<CAOEVZk+=fwvtj9x6wweyqtek3h5gdva0rcd671y79ycvonw...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Okay, we are debating the safety of polling for sensor data here within the
R&D team. At this point, we have flip-flopped several times.
Balint will respond shortly with our final guidance =)
Cheers,
Ben
On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn <[email protected]> wrote:
> Actually, what I just said is wrong, because calling those functions will
> result in packets being sent from the device.
>
> So, no. Nothing is thread safe, and even polling for sensor data could
> cause issues.
>
> Cheers,
> Ben
>
> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <[email protected]>
> wrote:
>
>> Hi Nathan -
>>
>> Generally, any UHD function that doesn't involve streaming is *not
>> *thread-safe.
>> So if you called "get_time_now" from two separate threads at the same time,
>> that is *not* a thread-safe operation.
>>
>> If all you are doing is polling sensors from a thread that is different
>> from the thread in which you started streaming, you should be OK. But, it
>> is not technically thread safe.
>>
>> Cheers,
>> Ben
>>
>> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
>> [email protected]> wrote:
>>
>>> I?ve been assuming that calls to UHD functions that don?t change
>>> settings on the USRP are generally thread safe and can be called from
>>> another thread even while a capture is ongoing. Is this an accurate
>>> assumption? The functions I?m calling are get_mboard_sensor() (for GPS
>>> information and ref_locked) and get_time_now(). Thanks.
>>>
>>> -Nathan Perelman
>>>
>>> _______________________________________________
>>> 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/20141211/4282ff8b/attachment-0001.html>
------------------------------
Message: 6
Date: Thu, 11 Dec 2014 15:27:25 -0500
From: Andy Walls <[email protected]>
To: Ben Hilburn <[email protected]>, Ben Hilburn via USRP-users
<[email protected]>, "Perelman, Nathan"
<[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
FWIW, I use a custom GNURadio block for closed loop monitoring of GPSDO and
USRP time between the host and the USRP. Polling every two seconds, 25 msec
after the PPS, I occasionally see UHD gripe about the GPRMC message not being
available. I never bothered to track down the cause.
-Andy
On December 11, 2014 3:16:41 PM EST, Ben Hilburn via USRP-users
<[email protected]> wrote:
>Okay, we are debating the safety of polling for sensor data here within
>the
>R&D team. At this point, we have flip-flopped several times.
>
>Balint will respond shortly with our final guidance =)
>
>Cheers,
>Ben
>
>On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn <[email protected]>
>wrote:
>
>> Actually, what I just said is wrong, because calling those functions
>will
>> result in packets being sent from the device.
>>
>> So, no. Nothing is thread safe, and even polling for sensor data
>could
>> cause issues.
>>
>> Cheers,
>> Ben
>>
>> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <[email protected]>
>> wrote:
>>
>>> Hi Nathan -
>>>
>>> Generally, any UHD function that doesn't involve streaming is *not
>*thread-safe.
>>> So if you called "get_time_now" from two separate threads at the
>same time,
>>> that is *not* a thread-safe operation.
>>>
>>> If all you are doing is polling sensors from a thread that is
>different
>>> from the thread in which you started streaming, you should be OK.
>But, it
>>> is not technically thread safe.
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
>>> [email protected]> wrote:
>>>
>>>> I?ve been assuming that calls to UHD functions that don?t change
>>>> settings on the USRP are generally thread safe and can be called
>from
>>>> another thread even while a capture is ongoing. Is this an accurate
>>>> assumption? The functions I?m calling are get_mboard_sensor() (for
>GPS
>>>> information and ref_locked) and get_time_now(). Thanks.
>>>>
>>>> -Nathan Perelman
>>>>
>>>> _______________________________________________
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>>
>>
>
>
>------------------------------------------------------------------------
>
>_______________________________________________
>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/20141211/7294b317/attachment-0001.html>
------------------------------
Message: 7
Date: Thu, 11 Dec 2014 17:20:19 -0600
From: Patrick Sisterhen <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Using an X310 as an NI RIO
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="us-ascii"
Jeremy,
Good question. As you've seen, the LabVIEW code on the host is looking
for supported daughterboard IDs in the device flash. Luckily, we ship
utilities that can populate these.
1. Make sure you have the newest NI-USRP (14.0) installed.
2. Open <Program Files (x86)>\National Instruments\LabVIEW
2014\vi.lib\LabVIEW Targets\FPGA\USRP\niusrprio_tools.llb\Examine Flash.vi
Select your device's RIO name (e.g. "RIO0") and Run it.
Note the values in the EEPROM Header section that are populated when
you run the VI on your device.
3. Open <Program Files (x86)>\National Instruments\LabVIEW
2014\vi.lib\LabVIEW Targets\FPGA\USRP\niusrprio_tools.llb\Write EEPROM
Header.vi
Copy the values from the Examine Flash VI to the corresponding fields
in the Write EEPROM Header VI...
EXCEPT: fill in the values of your Daughterboard IDs in those
fields.
Double check that you're not changing anything on your device other
than the Daughterboard IDs, then Run the VI.
After that, the VIs in the niUsrpRio Configuration Host VIs (which were
complaining before) should let you use the device with LabVIEW FPGA.
Notes:
- Your Ettus-branded device will not have any correction data in the
flash, so the host LV VIs might complain about that. You'll have to use
the Configure Signal (Gain) variants of the Configure Signal VI. Also,
you'll have to set the "Correct Impairments?" input to False on that VI.
- Take your time and be careful updating the flash. You only want to
change the Daughterboard IDs
Patrick Sisterhen
National Instruments
----- Message from Jeremy Hershberger <[email protected]> on
Thu, 4 Dec 2014 12:09:08 -0500 -----
To:
[email protected]
Subject:
[USRP-users] Using an X310 as an NI RIO
What changes are required to use an X310 over PCI in LabView as an NI RIO?
I have tried overwriting the X310's image with the NI RIO's image from the
LabView FPGA tool but when running a LabView VI that works on the RIO,
LabView throws an error that the daughtercards are not recognized.
I have also tried removing the daughtercards from a RIO and installing
them into the X310 but LabView still says the daughtercards are not
recognized.
It is easy to turn an NI RIO into an X310 by overwriting the RIO's image
with the standard X310 image, but why is the other direction more
difficult?
-Jeremy
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141211/d0267137/attachment-0001.html>
------------------------------
Message: 8
Date: Thu, 11 Dec 2014 16:06:36 -0800
From: Balint Seeber <[email protected]>
To: Andy Walls <[email protected]>
Cc: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID:
<capcb_2rrrk3ulixyufhyye_qxz6atgyyofjrpx+byuhwcns...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi all,
Apologies - I advised Ben a little too soon before double checking all the
code paths.
The following applies to third generation radios (B2x0, E310 & X3x0) -
these use radio_ctrl_core_3000 so send control/configuration packets to the
radios on these devices:
Settings bus registers are updated in/results are read back from each radio
core in the FPGA by performing a peek or poke. peek32, peek64 and poke32
are provided by radio_ctrl_core_3000, and each of these individual
operations are thread safe (there is a mutex in each function). These calls
are also blocking, so they will wait for an ACK to come back from the core
(this contains the result in the case of a peek). As a side note, if you
have a transport failure, then you'll see the standard 'timed out waiting
for ACK' exception thrown from radio_ctrl_core_3000.
Now to those specific functions:
- get_time_now (from time_core_3000): a single peek64, so it *is* thread
safe (you can call this from any thread, and probably will in complex
applications that might have a main app thread, a thread for RX, another
for TX, and perhaps something to handle TX asynchronous messages and/or
other device status like PLL/ref lock, GPS, etc). Same applies to
'get_time_last_pps'.
set_time_now/set_time_next_pps are implemented as three poke32 calls,
and those calls are *not* in a mutex, so you wouldn't want to call them
from different threads - but then again you probably would never do this
anyway, since it doesn't make sense to do so (you generally would call one
of the two once during device init).
- Anything to do with the GPS is *not* thread safe. You should
synchronise calls to the sensors API only if you're doing this from
different threads. If you know you'll only be doing this from one thread
*only*, then it's *not* necessary to synchronise (i.e. you don't need to
synchronise *all* accesses to *any* function in one multi_usrp instance).
Moreover, since much of multi_user actually sets/gets items on the device
instance's property tree, it's worth noting that manipulating the
*structure* of the property is thread safe, but actually setting/getting
node values (i.e. triggering publishers/subscribers/coercers) is *not*
thread safe (i.e. thread safety relies on the underlying implementation(s)
that get(s) called).
Andy, when you say 'complain' you mean UHD output a log message, but didn't
throw an exception? I imagine this had to do with the last received RMC not
being considered 'fresh' any more, and perhaps a new one has not arrived
yet in the buffer due to delays on the transport. You might want to match
the message up with uhd/host/lib/usrp/gps_ctrl.cpp.
Hope that helps and doesn't cause any race conditions for you!
Kind regards,
Balint
On Thu, Dec 11, 2014 at 12:27 PM, Andy Walls via USRP-users <
[email protected]> wrote:
> FWIW, I use a custom GNURadio block for closed loop monitoring of GPSDO
> and USRP time between the host and the USRP. Polling every two seconds, 25
> msec after the PPS, I occasionally see UHD gripe about the GPRMC message
> not being available. I never bothered to track down the cause.
>
> -Andy
>
>
> On December 11, 2014 3:16:41 PM EST, Ben Hilburn via USRP-users <
> [email protected]> wrote:
>>
>> Okay, we are debating the safety of polling for sensor data here within
>> the R&D team. At this point, we have flip-flopped several times.
>>
>> Balint will respond shortly with our final guidance =)
>>
>> Cheers,
>> Ben
>>
>> On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn <[email protected]>
>> wrote:
>>
>>> Actually, what I just said is wrong, because calling those functions
>>> will result in packets being sent from the device.
>>>
>>> So, no. Nothing is thread safe, and even polling for sensor data could
>>> cause issues.
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <[email protected]>
>>> wrote:
>>>
>>>> Hi Nathan -
>>>>
>>>> Generally, any UHD function that doesn't involve streaming is *not
>>>> *thread-safe.
>>>> So if you called "get_time_now" from two separate threads at the same time,
>>>> that is *not* a thread-safe operation.
>>>>
>>>> If all you are doing is polling sensors from a thread that is different
>>>> from the thread in which you started streaming, you should be OK. But, it
>>>> is not technically thread safe.
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
>>>> [email protected]> wrote:
>>>>
>>>>> I?ve been assuming that calls to UHD functions that don?t change
>>>>> settings on the USRP are generally thread safe and can be called from
>>>>> another thread even while a capture is ongoing. Is this an accurate
>>>>> assumption? The functions I?m calling are get_mboard_sensor() (for GPS
>>>>> information and ref_locked) and get_time_now(). Thanks.
>>>>>
>>>>> -Nathan Perelman
>>>>>
>>>>> _______________________________________________
>>>>> USRP-users mailing list
>>>>> [email protected]
>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>
>>>>>
>>>>
>>>
>> ------------------------------
>>
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>>
> _______________________________________________
> 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/20141211/8a91f293/attachment-0001.html>
------------------------------
Message: 9
Date: Thu, 11 Dec 2014 19:28:43 -0500
From: Andy Walls <[email protected]>
To: Balint Seeber <[email protected]>
Cc: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="utf-8"
Hi Balint,
I force a UHD NMEA cache refresh by fetching gps_time 26 msec after the PPS.
See the code segment here:
http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-August/010469.html
. I dont think it is a freshness issue.
I'll reproduce the error tomorrow at work to hunt down the message. It happens
less than once per hour as an estimate. It has no ill effects for me, so meh.
-Andy
On December 11, 2014 7:06:36 PM EST, Balint Seeber <[email protected]>
wrote:
>Hi all,
>
>Apologies - I advised Ben a little too soon before double checking all
>the
>code paths.
>
>The following applies to third generation radios (B2x0, E310 & X3x0) -
>these use radio_ctrl_core_3000 so send control/configuration packets to
>the
>radios on these devices:
>
>Settings bus registers are updated in/results are read back from each
>radio
>core in the FPGA by performing a peek or poke. peek32, peek64 and
>poke32
>are provided by radio_ctrl_core_3000, and each of these individual
>operations are thread safe (there is a mutex in each function). These
>calls
>are also blocking, so they will wait for an ACK to come back from the
>core
>(this contains the result in the case of a peek). As a side note, if
>you
>have a transport failure, then you'll see the standard 'timed out
>waiting
>for ACK' exception thrown from radio_ctrl_core_3000.
>
>Now to those specific functions:
>
>- get_time_now (from time_core_3000): a single peek64, so it *is*
>thread
> safe (you can call this from any thread, and probably will in complex
>applications that might have a main app thread, a thread for RX,
>another
>for TX, and perhaps something to handle TX asynchronous messages and/or
> other device status like PLL/ref lock, GPS, etc). Same applies to
> 'get_time_last_pps'.
>
> set_time_now/set_time_next_pps are implemented as three poke32 calls,
>and those calls are *not* in a mutex, so you wouldn't want to call them
>from different threads - but then again you probably would never do
>this
>anyway, since it doesn't make sense to do so (you generally would call
>one
> of the two once during device init).
>
> - Anything to do with the GPS is *not* thread safe. You should
> synchronise calls to the sensors API only if you're doing this from
>different threads. If you know you'll only be doing this from one
>thread
>*only*, then it's *not* necessary to synchronise (i.e. you don't need
>to
>synchronise *all* accesses to *any* function in one multi_usrp
>instance).
>
>Moreover, since much of multi_user actually sets/gets items on the
>device
>instance's property tree, it's worth noting that manipulating the
>*structure* of the property is thread safe, but actually
>setting/getting
>node values (i.e. triggering publishers/subscribers/coercers) is *not*
>thread safe (i.e. thread safety relies on the underlying
>implementation(s)
>that get(s) called).
>
>Andy, when you say 'complain' you mean UHD output a log message, but
>didn't
>throw an exception? I imagine this had to do with the last received RMC
>not
>being considered 'fresh' any more, and perhaps a new one has not
>arrived
>yet in the buffer due to delays on the transport. You might want to
>match
>the message up with uhd/host/lib/usrp/gps_ctrl.cpp.
>
>Hope that helps and doesn't cause any race conditions for you!
>
>Kind regards,
>Balint
>
>On Thu, Dec 11, 2014 at 12:27 PM, Andy Walls via USRP-users <
>[email protected]> wrote:
>
>> FWIW, I use a custom GNURadio block for closed loop monitoring of
>GPSDO
>> and USRP time between the host and the USRP. Polling every two
>seconds, 25
>> msec after the PPS, I occasionally see UHD gripe about the GPRMC
>message
>> not being available. I never bothered to track down the cause.
>>
>> -Andy
>>
>>
>> On December 11, 2014 3:16:41 PM EST, Ben Hilburn via USRP-users <
>> [email protected]> wrote:
>>>
>>> Okay, we are debating the safety of polling for sensor data here
>within
>>> the R&D team. At this point, we have flip-flopped several times.
>>>
>>> Balint will respond shortly with our final guidance =)
>>>
>>> Cheers,
>>> Ben
>>>
>>> On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn
><[email protected]>
>>> wrote:
>>>
>>>> Actually, what I just said is wrong, because calling those
>functions
>>>> will result in packets being sent from the device.
>>>>
>>>> So, no. Nothing is thread safe, and even polling for sensor data
>could
>>>> cause issues.
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn
><[email protected]>
>>>> wrote:
>>>>
>>>>> Hi Nathan -
>>>>>
>>>>> Generally, any UHD function that doesn't involve streaming is *not
>*thread-safe.
>>>>> So if you called "get_time_now" from two separate threads at the
>same time,
>>>>> that is *not* a thread-safe operation.
>>>>>
>>>>> If all you are doing is polling sensors from a thread that is
>different
>>>>> from the thread in which you started streaming, you should be OK.
>But, it
>>>>> is not technically thread safe.
>>>>>
>>>>> Cheers,
>>>>> Ben
>>>>>
>>>>> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
>>>>> [email protected]> wrote:
>>>>>
>>>>>> I?ve been assuming that calls to UHD functions that don?t change
>>>>>> settings on the USRP are generally thread safe and can be called
>from
>>>>>> another thread even while a capture is ongoing. Is this an
>accurate
>>>>>> assumption? The functions I?m calling are get_mboard_sensor()
>(for GPS
>>>>>> information and ref_locked) and get_time_now(). Thanks.
>>>>>>
>>>>>> -Nathan Perelman
>>>>>>
>>>>>> _______________________________________________
>>>>>> USRP-users mailing list
>>>>>> [email protected]
>>>>>>
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>
>>>>>>
>>>>>
>>>>
>>> ------------------------------
>>>
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>> _______________________________________________
>> 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/20141211/f62ebae2/attachment-0001.html>
------------------------------
Message: 10
Date: Thu, 11 Dec 2014 16:42:03 -0800
From: Michael West <[email protected]>
To: Andy Walls <[email protected]>
Cc: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID:
<cam4xkrqpo_xqroqa3wu0b6stgczse4n+xcys5qr8mkpzfjm...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Andy,
There are some issues that have come up with NMEA string freshness. The
attached patch fixed the issue another user was having where occasionally
he would see the time skip a second, but I believe it may resolve your
issue as well. It basically increases the frequency that the gps_ctrl
polls for updated NMEA strings. Give it a try and let us know if it
works. If it does, we will see if we can get it worked into UHD.
Regards,
Michael E. West
On Thu, Dec 11, 2014 at 4:28 PM, Andy Walls via USRP-users <
[email protected]> wrote:
> Hi Balint,
>
> I force a UHD NMEA cache refresh by fetching gps_time 26 msec after the
> PPS. See the code segment here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-August/010469.html
> . I dont think it is a freshness issue.
>
> I'll reproduce the error tomorrow at work to hunt down the message. It
> happens less than once per hour as an estimate. It has no ill effects for
> me, so meh.
>
> -Andy
>
>
> On December 11, 2014 7:06:36 PM EST, Balint Seeber <
> [email protected]> wrote:
>>
>> Hi all,
>>
>> Apologies - I advised Ben a little too soon before double checking all
>> the code paths.
>>
>> The following applies to third generation radios (B2x0, E310 & X3x0) -
>> these use radio_ctrl_core_3000 so send control/configuration packets to the
>> radios on these devices:
>>
>> Settings bus registers are updated in/results are read back from each
>> radio core in the FPGA by performing a peek or poke. peek32, peek64 and
>> poke32 are provided by radio_ctrl_core_3000, and each of these individual
>> operations are thread safe (there is a mutex in each function). These calls
>> are also blocking, so they will wait for an ACK to come back from the core
>> (this contains the result in the case of a peek). As a side note, if you
>> have a transport failure, then you'll see the standard 'timed out waiting
>> for ACK' exception thrown from radio_ctrl_core_3000.
>>
>> Now to those specific functions:
>>
>> - get_time_now (from time_core_3000): a single peek64, so it *is*
>> thread safe (you can call this from any thread, and probably will in
>> complex applications that might have a main app thread, a thread for RX,
>> another for TX, and perhaps something to handle TX asynchronous messages
>> and/or other device status like PLL/ref lock, GPS, etc). Same applies to
>> 'get_time_last_pps'.
>>
>> set_time_now/set_time_next_pps are implemented as three poke32 calls,
>> and those calls are *not* in a mutex, so you wouldn't want to call
>> them from different threads - but then again you probably would never do
>> this anyway, since it doesn't make sense to do so (you generally would
>> call
>> one of the two once during device init).
>>
>> - Anything to do with the GPS is *not* thread safe. You should
>> synchronise calls to the sensors API only if you're doing this from
>> different threads. If you know you'll only be doing this from one thread
>> *only*, then it's *not* necessary to synchronise (i.e. you don't need
>> to synchronise *all* accesses to *any* function in one multi_usrp
>> instance).
>>
>> Moreover, since much of multi_user actually sets/gets items on the device
>> instance's property tree, it's worth noting that manipulating the
>> *structure* of the property is thread safe, but actually setting/getting
>> node values (i.e. triggering publishers/subscribers/coercers) is *not*
>> thread safe (i.e. thread safety relies on the underlying implementation(s)
>> that get(s) called).
>>
>> Andy, when you say 'complain' you mean UHD output a log message, but
>> didn't throw an exception? I imagine this had to do with the last received
>> RMC not being considered 'fresh' any more, and perhaps a new one has not
>> arrived yet in the buffer due to delays on the transport. You might want to
>> match the message up with uhd/host/lib/usrp/gps_ctrl.cpp.
>>
>> Hope that helps and doesn't cause any race conditions for you!
>>
>> Kind regards,
>> Balint
>>
>> On Thu, Dec 11, 2014 at 12:27 PM, Andy Walls via USRP-users <
>> [email protected]> wrote:
>>
>>> FWIW, I use a custom GNURadio block for closed loop monitoring of GPSDO
>>> and USRP time between the host and the USRP. Polling every two seconds, 25
>>> msec after the PPS, I occasionally see UHD gripe about the GPRMC message
>>> not being available. I never bothered to track down the cause.
>>>
>>> -Andy
>>>
>>>
>>> On December 11, 2014 3:16:41 PM EST, Ben Hilburn via USRP-users <
>>> [email protected]> wrote:
>>>>
>>>> Okay, we are debating the safety of polling for sensor data here within
>>>> the R&D team. At this point, we have flip-flopped several times.
>>>>
>>>> Balint will respond shortly with our final guidance =)
>>>>
>>>> Cheers,
>>>> Ben
>>>>
>>>> On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn <[email protected]>
>>>> wrote:
>>>>
>>>>> Actually, what I just said is wrong, because calling those functions
>>>>> will result in packets being sent from the device.
>>>>>
>>>>> So, no. Nothing is thread safe, and even polling for sensor data could
>>>>> cause issues.
>>>>>
>>>>> Cheers,
>>>>> Ben
>>>>>
>>>>> On Thu, Dec 11, 2014 at 12:12 PM, Ben Hilburn <[email protected]>
>>>>> wrote:
>>>>>
>>>>>> Hi Nathan -
>>>>>>
>>>>>> Generally, any UHD function that doesn't involve streaming is *not
>>>>>> *thread-safe.
>>>>>> So if you called "get_time_now" from two separate threads at the same
>>>>>> time,
>>>>>> that is *not* a thread-safe operation.
>>>>>>
>>>>>> If all you are doing is polling sensors from a thread that is
>>>>>> different from the thread in which you started streaming, you should be
>>>>>> OK.
>>>>>> But, it is not technically thread safe.
>>>>>>
>>>>>> Cheers,
>>>>>> Ben
>>>>>>
>>>>>> On Tue, Dec 9, 2014 at 1:31 PM, Perelman, Nathan via USRP-users <
>>>>>> [email protected]> wrote:
>>>>>>
>>>>>>> I?ve been assuming that calls to UHD functions that don?t change
>>>>>>> settings on the USRP are generally thread safe and can be called from
>>>>>>> another thread even while a capture is ongoing. Is this an accurate
>>>>>>> assumption? The functions I?m calling are get_mboard_sensor() (for GPS
>>>>>>> information and ref_locked) and get_time_now(). Thanks.
>>>>>>>
>>>>>>> -Nathan Perelman
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> USRP-users mailing list
>>>>>>> [email protected]
>>>>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> ------------------------------
>>>>
>>>> USRP-users mailing list
>>>> [email protected]
>>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>>
>>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>>
>>
> _______________________________________________
> 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/20141211/bbfdd874/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: gps_freshness.patch
Type: text/x-patch
Size: 2409 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20141211/bbfdd874/attachment-0001.patch>
------------------------------
Message: 11
Date: Thu, 11 Dec 2014 21:26:35 -0600
From: Louis Brown <[email protected]>
To: Michael Rahaim <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] LFTX output amplitude (Michael Rahaim)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Not that I know of.
On your initial post you mentioned having a signal ranging from -1 to +1 into
the UHD sink. You may want to back that off to at least 1/2 that amplitude as
something may be overflowing.
Maybe post your GRC file.
Lou
> On Dec 11, 2014, at 9:53 AM, Michael Rahaim <[email protected]> wrote:
>
> Thanks Lou. I think I get what you're saying, but the end result seems to end
> up as a channel gain as opposed to a DC offset. For example, if I set my
> signal so that it initializes to a sine wave with peak to peak amplitude of
> 1V, after turning the carrier on and off it might end up having a pk-pk
> amplitude of 0.5V or 0.2V or 0.8V.
>
> Is there a way to reset via software such that the accumulator gets set back
> to 0?
>
> Thanks again,
>
> -Mike
------------------------------
Message: 12
Date: Thu, 11 Dec 2014 23:42:52 -0800
From: Ian Buckley <[email protected]>
To: Michael Rahaim <[email protected]>
Cc: Louis Brown <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] LFTX output amplitude (Michael Rahaim)
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
OK, time for a DSP recap I think. Whilst it makes life easier when we draw a
system diagram and get to add a single block labelled CORDIC, I think we run
the risk of forgetting what function it's actually performing.
Referring to a nice old fashioned pencil diagram:
http://www.ionconcepts.com/files/CORDIC.jpg
In the context of a DDC/DUC we are using a CORDIC algorithm processor to
replace a logical DDS and complex mixer, which in practical terms amounts to a
PHASE accumulator that endlessly counts 0->2*Pi then wraps at a rate determined
by the PHASE_INCrementor.
That PHASE value is the input to lookup tables for SIN and COS functions thus
synthesizing a complex sinusoid digitally.
To effect a frequency shift of a complex signal we mix that DDS output with the
input signal, which in terms of digital operations means we are doing a complex
multiply of the SIN/COS values with the complex components of the input signal.
So when PHASE = 0 and PHASE_INC = 0, IOUT = IIN and QOUT= QIN. Now whilst
streaming if we retune the CORDIC and introduce a frequency translation,
PHASE_INC != 0 and PHASE increments by PHASE_INC every clock cycle. We then
later retune the CORDIC so that no frequency translation is introduced and now
PHASE_INC = 0 again. However PHASE is left at an unknown and likely non-zero
value which means our complex input signal is still rotated around the
unit-circle. to produce the output signal:
IOUT = IIN*COS(PHASE) + QIN*SIN(PHASE) and QOUT = QIN*COS(PHASE) - SIN(PHASE)
Now, referring back to Michaels original post he has a flow graph that
introduces a real only signal into the I channel and leaves the Q channel at
0?I think the problem becomes apparent. Now if the input signal is instead
complex valued then the issue goes away.
When a new streamer is set up, (TX or RX) PHASE will be initialized to 0, and
PHASE_INC will have been step-up by UHD to satisfy the current tuning request.
The only way to return PHASE to zero predictably is to restart the streamer.
-Ian
On Dec 11, 2014, at 7:53 AM, Michael Rahaim via USRP-users
<[email protected]> wrote:
> Thanks Lou. I think I get what you're saying, but the end result seems to end
> up as a channel gain as opposed to a DC offset. For example, if I set my
> signal so that it initializes to a sine wave with peak to peak amplitude of
> 1V, after turning the carrier on and off it might end up having a pk-pk
> amplitude of 0.5V or 0.2V or 0.8V.
>
> Is there a way to reset via software such that the accumulator gets set back
> to 0?
>
> Thanks again,
>
> -Mike
>
> On Thu, Dec 11, 2014 at 9:08 AM, Louis Brown <[email protected]> wrote:
> Ok what you are describing is the phase accumulator halting to a non zero
> state when you tune the oscillator back to 0 Hz. Try generating a very low
> frequency sine wave (a few Hz) and you see what I mean when you tune it away
> from 0 Hz and then return it. When you start you flow with a 0 Hz source,
> the accumulator is initialized to zero, then it starts accumulating when you
> tune it to some frequency. Return it to 0 Hz and it stops at a non-zero
> phase, which is equivalent to a DC offset. I'm sure this is the way it is
> supposed to work, and is what I have observed before.
> Lou
>
>
> On Dec 11, 2014, at 07:21, Michael Rahaim <[email protected]> wrote:
>
>> Hi Lou,
>>
>> I have the output of the LFTX connected to a scope. I'm not using the LFRX
>> in the test loop.
>>
>> Best,
>>
>> -Mike
>>
>> On Wed, Dec 10, 2014 at 7:44 PM, Louis Brown via USRP-users
>> <[email protected]> wrote:
>> How are you measuring the LFTX output? With additional test equipment or
>> looping it back into the LFRX?
>>
>> Lou
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>
>
> _______________________________________________
> 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/20141211/b3bac788/attachment-0001.html>
------------------------------
Message: 13
Date: Fri, 12 Dec 2014 09:22:14 -0500
From: Andy Walls <[email protected]>
To: Balint Seeber <[email protected]>
Cc: Ben Hilburn via USRP-users <[email protected]>
Subject: Re: [USRP-users] UHD and Thread Safety
Message-ID: <1418394134.5807.8.camel@localhost>
Content-Type: text/plain; charset="UTF-8"
The error message is:
"UHD Warning:
get_time: ValueError: get_nmea(): no GPRMC message found"
which is originating from here:
https://github.com/EttusResearch/uhd/blob/release_003_008_000/host/lib/usrp/gps_ctrl.cpp#L272
But one dropped UDP packet is enough to account for this error, so I'm
not worried about it. Time marches on, and I get the next $GPRMC the
next second.
I only mentioned it as a symptom that may have been related to thread
safety. Since it happened so rarely, I thought it may have been
indicative of a race.
After reading Balint's analysis and looking at what I'm doing, I don't
have "thread safety" problems.
Regards,
Andy
On Thu, 2014-12-11 at 19:28 -0500, Andy Walls wrote:
> Hi Balint,
>
> I force a UHD NMEA cache refresh by fetching gps_time 26 msec after
> the PPS. See the code segment here:
> http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/2014-August/010469.html
> . I dont think it is a freshness issue.
>
> I'll reproduce the error tomorrow at work to hunt down the message. It
> happens less than once per hour as an estimate. It has no ill effects
> for me, so meh.
>
> -Andy
>
> On December 11, 2014 7:06:36 PM EST, Balint Seeber
> <[email protected]> wrote:
> Hi all,
>
>
> Apologies - I advised Ben a little too soon before double
> checking all the code paths.
>
>
> The following applies to third generation radios (B2x0, E310 &
> X3x0) - these use radio_ctrl_core_3000 so send
> control/configuration packets to the radios on these devices:
>
>
> Settings bus registers are updated in/results are read back
> from each radio core in the FPGA by performing a peek or poke.
> peek32, peek64 and poke32 are provided by
> radio_ctrl_core_3000, and each of these individual operations
> are thread safe (there is a mutex in each function). These
> calls are also blocking, so they will wait for an ACK to come
> back from the core (this contains the result in the case of a
> peek). As a side note, if you have a transport failure, then
> you'll see the standard 'timed out waiting for ACK' exception
> thrown from radio_ctrl_core_3000.
>
>
> Now to those specific functions:
> * get_time_now (from time_core_3000): a single peek64,
> so it is thread safe (you can call this from any
> thread, and probably will in complex applications that
> might have a main app thread, a thread for RX, another
> for TX, and perhaps something to handle TX
> asynchronous messages and/or other device status like
> PLL/ref lock, GPS, etc). Same applies to
> 'get_time_last_pps'.
>
> set_time_now/set_time_next_pps are implemented as
> three poke32 calls, and those calls are not in a
> mutex, so you wouldn't want to call them from
> different threads - but then again you probably would
> never do this anyway, since it doesn't make sense to
> do so (you generally would call one of the two once
> during device init).
>
> * Anything to do with the GPS is not thread safe. You
> should synchronise calls to the sensors API only if
> you're doing this from different threads. If you know
> you'll only be doing this from one thread only, then
> it's not necessary to synchronise (i.e. you don't need
> to synchronise all accesses to any function in one
> multi_usrp instance).
>
> Moreover, since much of multi_user actually sets/gets items on
> the device instance's property tree, it's worth noting that
> manipulating the structure of the property is thread safe, but
> actually setting/getting node values (i.e. triggering
> publishers/subscribers/coercers) is not thread safe (i.e.
> thread safety relies on the underlying implementation(s) that
> get(s) called).
>
>
> Andy, when you say 'complain' you mean UHD output a log
> message, but didn't throw an exception? I imagine this had to
> do with the last received RMC not being considered 'fresh' any
> more, and perhaps a new one has not arrived yet in the buffer
> due to delays on the transport. You might want to match the
> message up with uhd/host/lib/usrp/gps_ctrl.cpp.
>
>
> Hope that helps and doesn't cause any race conditions for you!
>
>
> Kind regards,
> Balint
>
>
>
>
> On Thu, Dec 11, 2014 at 12:27 PM, Andy Walls via USRP-users
> <[email protected]> wrote:
> FWIW, I use a custom GNURadio block for closed loop
> monitoring of GPSDO and USRP time between the host and
> the USRP. Polling every two seconds, 25 msec after the
> PPS, I occasionally see UHD gripe about the GPRMC
> message not being available. I never bothered to track
> down the cause.
>
> -Andy
>
>
> On December 11, 2014 3:16:41 PM EST, Ben Hilburn via
> USRP-users <[email protected]> wrote:
> Okay, we are debating the safety of polling
> for sensor data here within the R&D team. At
> this point, we have flip-flopped several
> times.
>
>
> Balint will respond shortly with our final
> guidance =)
>
>
> Cheers,
> Ben
>
> On Thu, Dec 11, 2014 at 12:14 PM, Ben Hilburn
> <[email protected]> wrote:
> Actually, what I just said is wrong,
> because calling those functions will
> result in packets being sent from the
> device.
>
>
> So, no. Nothing is thread safe, and
> even polling for sensor data could
> cause issues.
>
>
> Cheers,
> Ben
>
> On Thu, Dec 11, 2014 at 12:12 PM, Ben
> Hilburn <[email protected]> wrote:
> Hi Nathan -
>
>
> Generally, any UHD function
> that doesn't involve streaming
> is not thread-safe. So if you
> called "get_time_now" from two
> separate threads at the same
> time, that is not a
> thread-safe operation.
>
>
> If all you are doing is
> polling sensors from a thread
> that is different from the
> thread in which you started
> streaming, you should be OK.
> But, it is not technically
> thread safe.
>
>
> Cheers,
> Ben
>
> On Tue, Dec 9, 2014 at 1:31
> PM, Perelman, Nathan via
> USRP-users
> <[email protected]>
> wrote:
> I?ve been assuming
> that calls to UHD
> functions that don?t
> change settings on the
> USRP are generally
> thread safe and can be
> called from another
> thread even while a
> capture is ongoing. Is
> this an accurate
> assumption? The
> functions I?m calling
> are
> get_mboard_sensor()
> (for GPS information
> and ref_locked) and
> get_time_now().
> Thanks.
>
> -Nathan Perelman
>
>
>
>
> _______________________________________________
> USRP-users mailing
> list
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
>
>
>
>
>
> ______________________________________________
>
> USRP-users mailing list
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
------------------------------
Message: 14
Date: Fri, 12 Dec 2014 09:50:19 -0500
From: Michael Rahaim <[email protected]>
To: Ian Buckley <[email protected]>
Cc: Louis Brown <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] LFTX output amplitude (Michael Rahaim)
Message-ID:
<cafnkdpnr6vwh6na-_vq481ptg_3eplfhhnkyvgrscwb0sdj...@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Hi Ian,
Thanks for the reply. I'm not extremely familiar with the details of the
hardware implementation within the USRP - Am I correct in saying that the
CORDIC processor implements the interpolation on the FPGA within the USRP
motherboard and the LFTX implements the complex multiplication of the up
sampled signal with the carrier?
In that case, the "attenuated" signal that I'm seeing is in fact due to the
interpolation and depends on the phase value when I set the carrier back to
0. This seems to imply that the LFTX is in fact passing the I and Q
components through when the carrier is set to 0; but my the real valued
signal that was passed to the USRP has been transformed to a complex value
that is dependent on the value of PHASE before it reaches the LFTX. This
makes sense since I see the signal split across the LFTX outputs (A and B)
which I'm assuming are the I and Q components of the carrier multiplied
complex signal. (Please feel free to send me a virtual slap if I'm saying
something nonsensical).
Regarding my reason for asking, I'm working with an IM/DD optical wireless
setup that can either utilize real valued baseband techniques or passband
techniques at a low frequency carrier. I'd like to be able to switch
between techniques dynamically, but I never know what the amplitude of my
signal will be when I go back to the baseband modulation. I could stop and
restart the flow graph whenever I switch, but I was curious if there was a
way to reinitialize on the fly.
Thanks again for your help,
-Mike
On Fri, Dec 12, 2014 at 2:42 AM, Ian Buckley <[email protected]> wrote:
> OK, time for a DSP recap I think. Whilst it makes life easier when we draw
> a system diagram and get to add a single block labelled CORDIC, I think we
> run the risk of forgetting what function it's actually performing.
>
> Referring to a nice old fashioned pencil diagram:
> http://www.ionconcepts.com/files/CORDIC.jpg
>
> In the context of a DDC/DUC we are using a CORDIC algorithm processor to
> replace a logical DDS and complex mixer, which in practical terms amounts
> to a PHASE accumulator that endlessly counts 0->2*Pi then wraps at a rate
> determined by the PHASE_INCrementor.
> That PHASE value is the input to lookup tables for SIN and COS functions
> thus synthesizing a complex sinusoid digitally.
> To effect a frequency shift of a complex signal we mix that DDS output
> with the input signal, which in terms of digital operations means we are
> doing a complex multiply of the SIN/COS values with the complex components
> of the input signal.
>
> So when PHASE = 0 and PHASE_INC = 0, IOUT = IIN and QOUT= QIN. Now whilst
> streaming if we retune the CORDIC and introduce a frequency translation,
> PHASE_INC != 0 and PHASE increments by PHASE_INC every clock cycle. We then
> later retune the CORDIC so that no frequency translation is introduced and
> now PHASE_INC = 0 again. However PHASE is left at an unknown and likely
> non-zero value which means our complex input signal is still rotated around
> the unit-circle. to produce the output signal:
> IOUT = IIN*COS(PHASE) + QIN*SIN(PHASE) and QOUT = QIN*COS(PHASE) -
> SIN(PHASE)
>
> Now, referring back to Michaels original post he has a flow graph that
> introduces a real only signal into the I channel and leaves the Q channel
> at 0?I think the problem becomes apparent. Now if the input signal is
> instead complex valued then the issue goes away.
>
> When a new streamer is set up, (TX or RX) PHASE will be initialized to 0,
> and PHASE_INC will have been step-up by UHD to satisfy the current tuning
> request. The only way to return PHASE to zero predictably is to restart the
> streamer.
>
> -Ian
>
>
> On Dec 11, 2014, at 7:53 AM, Michael Rahaim via USRP-users <
> [email protected]> wrote:
>
> Thanks Lou. I think I get what you're saying, but the end result seems to
> end up as a channel gain as opposed to a DC offset. For example, if I set
> my signal so that it initializes to a sine wave with peak to peak amplitude
> of 1V, after turning the carrier on and off it might end up having a pk-pk
> amplitude of 0.5V or 0.2V or 0.8V.
>
> Is there a way to reset via software such that the accumulator gets set
> back to 0?
>
> Thanks again,
>
> -Mike
>
> On Thu, Dec 11, 2014 at 9:08 AM, Louis Brown <[email protected]> wrote:
>
>> Ok what you are describing is the phase accumulator halting to a non zero
>> state when you tune the oscillator back to 0 Hz. Try generating a very low
>> frequency sine wave (a few Hz) and you see what I mean when you tune it
>> away from 0 Hz and then return it. When you start you flow with a 0 Hz
>> source, the accumulator is initialized to zero, then it starts accumulating
>> when you tune it to some frequency. Return it to 0 Hz and it stops at a
>> non-zero phase, which is equivalent to a DC offset. I'm sure this is the
>> way it is supposed to work, and is what I have observed before.
>> Lou
>>
>>
>> On Dec 11, 2014, at 07:21, Michael Rahaim <[email protected]> wrote:
>>
>> Hi Lou,
>>
>> I have the output of the LFTX connected to a scope. I'm not using the
>> LFRX in the test loop.
>>
>> Best,
>>
>> -Mike
>>
>> On Wed, Dec 10, 2014 at 7:44 PM, Louis Brown via USRP-users <
>> [email protected]> wrote:
>>
>>> How are you measuring the LFTX output? With additional test equipment
>>> or looping it back into the LFRX?
>>>
>>> Lou
>>>
>>>
>>> _______________________________________________
>>> USRP-users mailing list
>>> [email protected]
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>
>>
> _______________________________________________
> 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/20141212/aa788dd2/attachment-0001.html>
------------------------------
Message: 15
Date: Fri, 12 Dec 2014 16:00:39 +0100
From: Marcus M?ller <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] LFTX output amplitude (Michael Rahaim)
Message-ID: <[email protected]>
Content-Type: text/plain; charset=windows-1252
Hi Mike,
On 12/12/2014 03:50 PM, Michael Rahaim via USRP-users wrote:
> Hi Ian,
>
> Thanks for the reply. I'm not extremely familiar with the details of
> the hardware implementation within the USRP - Am I correct in saying
> that the CORDIC processor implements the interpolation on the FPGA
> within the USRP motherboard and the LFTX implements the complex
> multiplication of the up sampled signal with the carrier?
>
No, not quite: the CORDIC is the sine-generating part of the
downconverter/upconverter. Interpolation is mathematically just "padding
with zeros", and you need a filter after that to get rid of images.
The point that Ian tried to make is: for a phase value of 0, the
CORDIC-mixer is just an I/Q passthrough. For any phase value !=0, it
mixes I and Q.
Greetings,
Marcus
------------------------------
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 52, Issue 14
******************************************
