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: Problems with setting gain (Sean Nowlan)
2. Re: Building fails on debian (Josh Blum)
3. Re: Building fails on debian (Simon Szustkowski)
4. Re: Building fails on debian (Josh Blum)
5. Live modulation swapping (Nyjil George)
6. Re: Problems with setting gain (Sean Nowlan)
7. Re: Building fails on debian (Simon Szustkowski)
8. Re: Problems with setting gain (Sean Nowlan)
9. Re: Live modulation swapping (Ben Reynwar)
10. SBX LO Lock (Perelman Nathan (Nathan))
11. Re: SBX LO Lock (Marcus D. Leech)
12. Re: Live modulation swapping (Nyjil George)
13. USRP N210 for sell (Jeff Scaparra)
14. UHD driver segault (Youri Westerman)
----------------------------------------------------------------------
Message: 1
Date: Tue, 9 Apr 2013 13:15:35 -0400
From: Sean Nowlan <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Problems with setting gain
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
Update: upgrading to 3.5.2 (including reflashing firmware and FPGA) did not fix
the problem.
Sean Nowlan <[email protected]> wrote:
>I am having trouble with setting gain consistently on the WBX board.
>Sometimes it is set correctly as requested. Many times it is set to the
>minimum gain for WBX (0 dB) and occasionally it is set to the maximum
>(31 dB).
>
>I've observed this problem in several of my own applications, but I also
>observed it using GNU Radio's benchmark_tx. Some examples:
>
>./benchmark_tx.py -m cpm --excess-bw=3 --non-differential -r 2e5 -M 10
>-f 1.36e9 --tx-amplitude=0.2 --tx-gain=10
>./benchmark_tx.py -m gmsk --bt=3 --non-differential -r 2e5 -M 10 -f
>1.36e9 --tx-amplitude=0.2 --tx-gain=10
>./benchmark_tx.py -m bpsk --non-differential -r 2e5 -M 10 -f 1.36e9
>--tx-amplitude=0.2 --tx-gain=10
>
>I verified that my GNU Radio application is producing samples with
>"sane" values, i.e., complex floats with I and Q in [-1.0, 1.0] and with
>typical values in [-0.2, 0.2]. The problem doesn't go away if I remove
>IQ & DC calibration files (mv ~/.uhd ~/.uhd_backup). Power cycling the
>USRP doesn't help.
>
>My application follows the paradigm of a Python script generated by GRC.
>In the top block __init__() function I instantiate a uhd_usrp_sink
>object and set its freq and gain. Then I instantiate other GNU Radio
>objects and connect them. Finally in the main function I call start() on
>my top block. I called get_gain() after setting it in __init__() and
>verified it was set correctly. However in the main function when I call
>get_gain() again, sometimes the value is changed to 0 or 31. I can force
>it to behave by setting the gain again, but it concerns me that the
>value is getting blown away in some cases and I don't know the root cause.
>
>My next step will be to upgrade to the 3.5.2 release and see if the
>problem goes away, but I wanted to get this message on the list as soon
>as I could.
>
>Setup:
>USRP N200 r4
>WBX r3
>UHD
>GNU C++ version 4.6.3
>Boost 104800
>UHD 3.5.0 (003.005.000-0-g5cb9779d)
>GNU Radio 3.6.2
>
>Thanks for your help!
>
>--sean
>
>_______________________________________________
>USRP-users mailing list
>[email protected]
>http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 2
Date: Tue, 09 Apr 2013 12:35:03 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Building fails on debian
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
> ERROR: unknown token[0]: x2
> Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
> Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
> Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
> Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
> Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
> Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
> make[2]: *** [lib/convert/convert_orc.c] Fehler 1
> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Fehler 2
> make: *** [all] Fehler 2
> UHD build apparently failed
> Exiting UHD build
>
> Does anyone know how to fix this?
>
>
>
Trouble with ORC, perhaps the version is too old.
* Can you tell me which version of ORC you have installed?
* Also which version of UHD you are building?
PS You can disable this with -DENABLE_ORC=OFF, and uhd will continue to
build without the orc support, which should be OK.
-josh
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Tue, 9 Apr 2013 19:41:10 +0200
From: Simon Szustkowski <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Building fails on debian
Message-ID:
<CAFcEvYFsLG9xcj1GebUX2Sd7bJAi9Gwy1pJ5AgTm9Ggx=m0...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
i have liborc-0.4 installed. It's the version debian stable provides.
However, i am building UHC from the github repo. The latest commit there is
4a860d7471<https://github.com/EttusResearch/uhd/commit/4a860d7471a55700c41671922c157d243fea6247>
2013/4/9 Josh Blum <[email protected]>
>
> > ERROR: unknown token[0]: x2
> > Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
> > Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
> > Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
> > Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
> > Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
> > Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
> > make[2]: *** [lib/convert/convert_orc.c] Fehler 1
> > make[1]: *** [lib/CMakeFiles/uhd.dir/all] Fehler 2
> > make: *** [all] Fehler 2
> > UHD build apparently failed
> > Exiting UHD build
> >
> > Does anyone know how to fix this?
> >
> >
> >
>
> Trouble with ORC, perhaps the version is too old.
>
> * Can you tell me which version of ORC you have installed?
> * Also which version of UHD you are building?
>
> PS You can disable this with -DENABLE_ORC=OFF, and uhd will continue to
> build without the orc support, which should be OK.
>
> -josh
>
> > _______________________________________________
> > 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
>
--
---
Before printing this email, think if it is really needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/39dd9ff3/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 09 Apr 2013 12:50:37 -0500
From: Josh Blum <[email protected]>
To: Simon Szustkowski <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Building fails on debian
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/09/2013 12:41 PM, Simon Szustkowski wrote:
> Hi,
>
> i have liborc-0.4 installed. It's the version debian stable provides.
> However, i am building UHC from the github repo. The latest commit there is
> 4a860d7471<https://github.com/EttusResearch/uhd/commit/4a860d7471a55700c41671922c157d243fea6247>
>
>
I see what happened. Recently we added a new findscript for orc, but
this is bypassing the pkg config check for the version:
+PKG_CHECK_MODULES(PC_ORC "orc-0.4 > 0.4.11")
So, I believe the version check should not be passing on your system. I
can fix this, but in the meantime it will be easiest to pass
-DENABLE_ORC=OFF into the cmake command when you configure the build.
-josh
>
> 2013/4/9 Josh Blum <[email protected]>
>
>>
>>> ERROR: unknown token[0]: x2
>>> Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
>>> Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
>>> Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
>>> Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
>>> Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
>>> Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
>>> make[2]: *** [lib/convert/convert_orc.c] Fehler 1
>>> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Fehler 2
>>> make: *** [all] Fehler 2
>>> UHD build apparently failed
>>> Exiting UHD build
>>>
>>> Does anyone know how to fix this?
>>>
>>>
>>>
>>
>> Trouble with ORC, perhaps the version is too old.
>>
>> * Can you tell me which version of ORC you have installed?
>> * Also which version of UHD you are building?
>>
>> PS You can disable this with -DENABLE_ORC=OFF, and uhd will continue to
>> build without the orc support, which should be OK.
>>
>> -josh
>>
>>> _______________________________________________
>>> 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: 5
Date: Tue, 9 Apr 2013 23:22:24 +0530
From: Nyjil George <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] Live modulation swapping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Dear pioneers in GNU Radio,
How to implement live modulation swapping in GNU Radio. I would like to swap
modulation scheme from QPSK, QAM16, QAM32, QAM64,QAM128 and QAM256 in a
transmitter implemented in GNU Radio latest version according to the bit stream
input 0000, 0001, 0010, 0011 and 0100.
With warm regards,
Nyjil George
This Mail Sent from Portable device.
------------------------------
Message: 6
Date: Tue, 9 Apr 2013 14:06:07 -0400
From: Sean Nowlan <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Problems with setting gain
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
Update 2: I enabled UHD logging and attached an excerpt from uhd.log. It
shows that the gain gets set to 10 dB, as I requested, but then
something else calls set_tx_gain() immediately after and overwrites it.
The only thing I can think of is that something happens when
gr_uhd_usrp_sink::start() gets called, but I can't say what that might
be. As far as I can tell, fetching the tx_streamer, setting the send
mode, etc. wouldn't have any affect on the gain setting.
On 04/09/2013 01:15 PM, Sean Nowlan wrote:
> Update: upgrading to 3.5.2 (including reflashing firmware and FPGA) did not
> fix the problem.
>
> Sean Nowlan <[email protected]> wrote:
>
>> I am having trouble with setting gain consistently on the WBX board.
>> Sometimes it is set correctly as requested. Many times it is set to the
>> minimum gain for WBX (0 dB) and occasionally it is set to the maximum
>> (31 dB).
>>
>> I've observed this problem in several of my own applications, but I also
>> observed it using GNU Radio's benchmark_tx. Some examples:
>>
>> ./benchmark_tx.py -m cpm --excess-bw=3 --non-differential -r 2e5 -M 10
>> -f 1.36e9 --tx-amplitude=0.2 --tx-gain=10
>> ./benchmark_tx.py -m gmsk --bt=3 --non-differential -r 2e5 -M 10 -f
>> 1.36e9 --tx-amplitude=0.2 --tx-gain=10
>> ./benchmark_tx.py -m bpsk --non-differential -r 2e5 -M 10 -f 1.36e9
>> --tx-amplitude=0.2 --tx-gain=10
>>
>> I verified that my GNU Radio application is producing samples with
>> "sane" values, i.e., complex floats with I and Q in [-1.0, 1.0] and with
>> typical values in [-0.2, 0.2]. The problem doesn't go away if I remove
>> IQ & DC calibration files (mv ~/.uhd ~/.uhd_backup). Power cycling the
>> USRP doesn't help.
>>
>> My application follows the paradigm of a Python script generated by GRC.
>> In the top block __init__() function I instantiate a uhd_usrp_sink
>> object and set its freq and gain. Then I instantiate other GNU Radio
>> objects and connect them. Finally in the main function I call start() on
>> my top block. I called get_gain() after setting it in __init__() and
>> verified it was set correctly. However in the main function when I call
>> get_gain() again, sometimes the value is changed to 0 or 31. I can force
>> it to behave by setting the gain again, but it concerns me that the
>> value is getting blown away in some cases and I don't know the root cause.
>>
>> My next step will be to upgrade to the 3.5.2 release and see if the
>> problem goes away, but I wanted to get this message on the list as soon
>> as I could.
>>
>> Setup:
>> USRP N200 r4
>> WBX r3
>> UHD
>> GNU C++ version 4.6.3
>> Boost 104800
>> UHD 3.5.0 (003.005.000-0-g5cb9779d)
>> GNU Radio 3.6.2
>>
>> Thanks for your help!
>>
>> --sean
>>
>> _______________________________________________
>> 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
------------------------------
*Sean M. Nowlan*
Research Engineer I
ICL/CNSD
Georgia Tech Research Institute
250 14th St NW, Suite 470
Atlanta, GA 30318
404.407.7952
[email protected]
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/063040a1/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: uhd.log
Type: text/x-log
Size: 2271 bytes
Desc: not available
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/063040a1/attachment-0001.log>
------------------------------
Message: 7
Date: Tue, 9 Apr 2013 20:24:46 +0200
From: Simon Szustkowski <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Building fails on debian
Message-ID:
<CAFcEvYFo=eGWFyeLemDWapupASG0nPbKhyZa=adcclhzk45...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Okay.
I am using UHD for gnuradio and the rtl-sdr package. I hope this will work
without ORC
2013/4/9 Josh Blum <[email protected]>
>
>
> On 04/09/2013 12:41 PM, Simon Szustkowski wrote:
> > Hi,
> >
> > i have liborc-0.4 installed. It's the version debian stable provides.
> > However, i am building UHC from the github repo. The latest commit there
> is
> > 4a860d7471<
> https://github.com/EttusResearch/uhd/commit/4a860d7471a55700c41671922c157d243fea6247
> >
> >
> >
>
> I see what happened. Recently we added a new findscript for orc, but
> this is bypassing the pkg config check for the version:
>
> +PKG_CHECK_MODULES(PC_ORC "orc-0.4 > 0.4.11")
>
> So, I believe the version check should not be passing on your system. I
> can fix this, but in the meantime it will be easiest to pass
> -DENABLE_ORC=OFF into the cmake command when you configure the build.
>
> -josh
>
> >
> > 2013/4/9 Josh Blum <[email protected]>
> >
> >>
> >>> ERROR: unknown token[0]: x2
> >>> Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
> >>> Failed to compile _convert_fc32_1_to_item32_1_nswap_orc
> >>> Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
> >>> Failed to compile _convert_item32_1_to_fc32_1_nswap_orc
> >>> Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
> >>> Failed to compile _convert_item32_1_to_sc16_1_nswap_orc
> >>> make[2]: *** [lib/convert/convert_orc.c] Fehler 1
> >>> make[1]: *** [lib/CMakeFiles/uhd.dir/all] Fehler 2
> >>> make: *** [all] Fehler 2
> >>> UHD build apparently failed
> >>> Exiting UHD build
> >>>
> >>> Does anyone know how to fix this?
> >>>
> >>>
> >>>
> >>
> >> Trouble with ORC, perhaps the version is too old.
> >>
> >> * Can you tell me which version of ORC you have installed?
> >> * Also which version of UHD you are building?
> >>
> >> PS You can disable this with -DENABLE_ORC=OFF, and uhd will continue to
> >> build without the orc support, which should be OK.
> >>
> >> -josh
> >>
> >>> _______________________________________________
> >>> 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
> >>
> >
> >
> >
>
--
---
Before printing this email, think if it is really needed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/1e82c878/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 9 Apr 2013 14:28:35 -0400
From: Sean Nowlan <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Problems with setting gain
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
I noticed there's a function called set_value in utils/gain_group.cpp
that recursively sets gains to different gain elements. Is it possible
the extra call to set_value() (shown in uhd.log previously sent) is due
to floating point rounding error on gain_left_to_distribute?
On 04/09/2013 02:06 PM, Sean Nowlan wrote:
> Update 2: I enabled UHD logging and attached an excerpt from uhd.log.
> It shows that the gain gets set to 10 dB, as I requested, but then
> something else calls set_tx_gain() immediately after and overwrites
> it. The only thing I can think of is that something happens when
> gr_uhd_usrp_sink::start() gets called, but I can't say what that might
> be. As far as I can tell, fetching the tx_streamer, setting the send
> mode, etc. wouldn't have any affect on the gain setting.
>
> On 04/09/2013 01:15 PM, Sean Nowlan wrote:
>> Update: upgrading to 3.5.2 (including reflashing firmware and FPGA) did not
>> fix the problem.
>>
>> Sean Nowlan<[email protected]> wrote:
>>
>>> I am having trouble with setting gain consistently on the WBX board.
>>> Sometimes it is set correctly as requested. Many times it is set to the
>>> minimum gain for WBX (0 dB) and occasionally it is set to the maximum
>>> (31 dB).
>>>
>>> I've observed this problem in several of my own applications, but I also
>>> observed it using GNU Radio's benchmark_tx. Some examples:
>>>
>>> ./benchmark_tx.py -m cpm --excess-bw=3 --non-differential -r 2e5 -M 10
>>> -f 1.36e9 --tx-amplitude=0.2 --tx-gain=10
>>> ./benchmark_tx.py -m gmsk --bt=3 --non-differential -r 2e5 -M 10 -f
>>> 1.36e9 --tx-amplitude=0.2 --tx-gain=10
>>> ./benchmark_tx.py -m bpsk --non-differential -r 2e5 -M 10 -f 1.36e9
>>> --tx-amplitude=0.2 --tx-gain=10
>>>
>>> I verified that my GNU Radio application is producing samples with
>>> "sane" values, i.e., complex floats with I and Q in [-1.0, 1.0] and with
>>> typical values in [-0.2, 0.2]. The problem doesn't go away if I remove
>>> IQ & DC calibration files (mv ~/.uhd ~/.uhd_backup). Power cycling the
>>> USRP doesn't help.
>>>
>>> My application follows the paradigm of a Python script generated by GRC.
>>> In the top block __init__() function I instantiate a uhd_usrp_sink
>>> object and set its freq and gain. Then I instantiate other GNU Radio
>>> objects and connect them. Finally in the main function I call start() on
>>> my top block. I called get_gain() after setting it in __init__() and
>>> verified it was set correctly. However in the main function when I call
>>> get_gain() again, sometimes the value is changed to 0 or 31. I can force
>>> it to behave by setting the gain again, but it concerns me that the
>>> value is getting blown away in some cases and I don't know the root cause.
>>>
>>> My next step will be to upgrade to the 3.5.2 release and see if the
>>> problem goes away, but I wanted to get this message on the list as soon
>>> as I could.
>>>
>>> Setup:
>>> USRP N200 r4
>>> WBX r3
>>> UHD
>>> GNU C++ version 4.6.3
>>> Boost 104800
>>> UHD 3.5.0 (003.005.000-0-g5cb9779d)
>>> GNU Radio 3.6.2
>>>
>>> Thanks for your help!
>>>
>>> --sean
>>>
>>> _______________________________________________
>>> 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/20130409/5efd8285/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 9 Apr 2013 12:07:00 -0700
From: Ben Reynwar <[email protected]>
To: Nyjil George <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Live modulation swapping
Message-ID:
<CAHXOypr-ikCHBUC4Lq_S3rS3vk1UkYqjZCbo=x8jnkg6yx9...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
The easiest way to swap the modulation scheme is to lock the flow
graph, disconnect the blocks for the old modulation scheme, connect
the blocks for the new modulation scheme, and unlock the flow graph.
On Tue, Apr 9, 2013 at 10:52 AM, Nyjil George <[email protected]> wrote:
> Dear pioneers in GNU Radio,
>
> How to implement live modulation swapping in GNU Radio. I would like to swap
> modulation scheme from QPSK, QAM16, QAM32, QAM64,QAM128 and QAM256 in a
> transmitter implemented in GNU Radio latest version according to the bit
> stream input 0000, 0001, 0010, 0011 and 0100.
>
> With warm regards,
> Nyjil George
> This Mail Sent from Portable device.
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 10
Date: Tue, 9 Apr 2013 19:28:49 -0400
From: "Perelman Nathan (Nathan)" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] SBX LO Lock
Message-ID:
<3862c5643b15b6468269546753eb2a920859e...@bltsxvs01.govsolutions.com>
Content-Type: text/plain; charset="us-ascii"
I have 2 SBX daughterboards in USRP N210s that I am using with UHD
3.4.1. After tuning (set_rx_freq()), I immediately check the lo_locked
sensor and have never gotten false back. Is this normal that the SBX LO
locks instantly from the perspective of the host? Thanks.
-Nathan Perelman
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/c9457354/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 09 Apr 2013 21:13:01 -0400
From: "Marcus D. Leech" <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] SBX LO Lock
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
> I have 2 SBX daughterboards in USRP N210s that I am using with UHD
> 3.4.1. After tuning (set_rx_freq()), I immediately check the lo_locked
> sensor and have never gotten false back. Is this normal that the SBX
> LO locks instantly from the perspective of the host? Thanks.
>
> -Nathan Perelman
>
>
It takes a few dozen usecs, typically. And with network-stack latency,
you're likely to never see it go "false", unless it's broken. By the
time you ask,
it's already happened.
--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/f3855e95/attachment-0001.html>
------------------------------
Message: 12
Date: Wed, 10 Apr 2013 08:00:53 +0530
From: Nyjil George <[email protected]>
To: Ben Reynwar <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] Live modulation swapping
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii
Thank you Reynwar,
Is there any possibilities to use sample and hold block as a switch?
Nyjil George
This Mail Sent from Portable device.
On 10-Apr-2013, at 12:37 AM, Ben Reynwar <[email protected]> wrote:
> The easiest way to swap the modulation scheme is to lock the flow
> graph, disconnect the blocks for the old modulation scheme, connect
> the blocks for the new modulation scheme, and unlock the flow graph.
>
> On Tue, Apr 9, 2013 at 10:52 AM, Nyjil George <[email protected]> wrote:
>> Dear pioneers in GNU Radio,
>>
>> How to implement live modulation swapping in GNU Radio. I would like to swap
>> modulation scheme from QPSK, QAM16, QAM32, QAM64,QAM128 and QAM256 in a
>> transmitter implemented in GNU Radio latest version according to the bit
>> stream input 0000, 0001, 0010, 0011 and 0100.
>>
>> With warm regards,
>> Nyjil George
>> This Mail Sent from Portable device.
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 13
Date: Tue, 9 Apr 2013 22:51:14 -0400
From: Jeff Scaparra <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRP N210 for sell
Message-ID:
<CALWgEa0czE8PrPFvaZ8RnA1ZQkb6oagN08dHK=tlhhh34ne...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
I am selling my USRP N210 in order to downgrade to the B100. I don't need
or use the extra capabilities as I mainly do ham radio experimenting with
it and all signals I would work with are smaller than 8MHz. I am
including the WBX daughterboard with the N210.
The USRP and daughterboard have seen little use mainly just tinkering and
are in like new condition.
These sell new for:
$1,700.00 USRP N210
$450 WBX Daughterboard
$2,150 Total
I am asking for $2,000 OBO via paypal.
Pictures listed at
http://forums.qrz.com/showthread.php?386620-USRP-N210-and-WBX-Daughterboard
Thanks for looking
Jeff N6SDR
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/49a5ee10/attachment-0001.html>
------------------------------
Message: 14
Date: Wed, 10 Apr 2013 10:29:51 +0200
From: Youri Westerman <[email protected]>
To: [email protected]
Subject: [USRP-users] UHD driver segault
Message-ID:
<CAFSNd_Qu_CqeWfZmPkfjSDDzw-s+UsiBSCX5nZAY=dfzysk...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I'm trying to get the uhd driver working properly in combination with a
B100 USRP. Unfortnuately when using the gnuradio block "UHD: USRP Sink" and
setting the send_frame_size=1023 (or any other value I've tried) libuhd
produces a segfault. UHD version: 3.4.3-1, GNU/Radio version: 3.6.4-1
(Installed trough yum on fedora18 x64 versions).
Is this a bug or am I doing something wrong here? I'm trying to get a DAB
signal produced using CRC-DabMod and:
http://opendigitalradio.org/index.php/UHD_Band_3_baseband_player
--
Youri Westerman
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130410/a7c27148/attachment-0001.html>
------------------------------
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 32, Issue 7
*****************************************
