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: E110 upgrade failure (Josh Blum)
2. Re: E110 upgrade failure (Philip Balister)
3. Re: E1XX updates, strike 2 (Alex Gladd)
4. Re: CORDIC rise time (Matt Ettus)
5. USRPs in Brazil (Matt Ettus)
6. Re: N210 RX Customization How-To (Florian Schlembach)
7. Re: No signal on TX/RX port (Jawad Seddar)
8. Info about GPSDO for N2XX and E100 series signals
([email protected])
9. Building fails on debian (Simon Szustkowski)
10. Re: Info about GPSDO for N2XX and E100 series signals
(Mike Jameson)
11. Problems with setting gain (Sean Nowlan)
----------------------------------------------------------------------
Message: 1
Date: Mon, 08 Apr 2013 11:55:01 -0500
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] E110 upgrade failure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/06/2013 03:26 AM, [email protected] wrote:
> Hi all, I also upgraded using opkg recently and experienced 'O' over
> run errors when using an E100, likely related to kernel FPGA timing
> change. I since rolled back to a stock e1xx-003 firmware and
> functionality is restored. All UHD examples gave me the overrun
> issue.
>
Thats interesting because the timing changes were related to the
transmit half of the device. I can't say that anything changed about RX
in terms of packets or timing.... Hmmm
-josh
>
> On 3 Apr 2013, at 13:41, Philip Balister <[email protected]> wrote:
>
>> On 04/03/2013 08:35 AM, Christopher Roussi wrote:
>>> I just opened our E110 yesterday, and can confirm that doing the
>>> upgrade is not a good thing. Of course, after reconstructing the
>>> SD card, I did it again, just to make sure...this is
>>> time-consuming. ;-{)}
>>
>> We tracked down the problem with the E110 (not E100) last night.
>> We'll get the ipks updated ASAP.
>>
>> Philip
>>
>>>
>>> Chris Roussi Michigan Tech Research Inst.
>>>
>>> Sent from...well, you know.
>>>
>>> _______________________________________________ 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: 2
Date: Mon, 08 Apr 2013 13:30:59 -0400
From: Philip Balister <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] E110 upgrade failure
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 04/08/2013 12:55 PM, Josh Blum wrote:
>
>
> On 04/06/2013 03:26 AM, [email protected] wrote:
>> Hi all, I also upgraded using opkg recently and experienced 'O' over
>> run errors when using an E100, likely related to kernel FPGA timing
>> change. I since rolled back to a stock e1xx-003 firmware and
>> functionality is restored. All UHD examples gave me the overrun
>> issue.
>>
Can you post the exact commands you ran?
The updates fixed the S (the fpga did missed seeing a packet from the
arm) issue people were seeing, not O (overruns).
Philip
>
> Thats interesting because the timing changes were related to the
> transmit half of the device. I can't say that anything changed about RX
> in terms of packets or timing.... Hmmm
>
> -josh
>
>>
>> On 3 Apr 2013, at 13:41, Philip Balister <[email protected]> wrote:
>>
>>> On 04/03/2013 08:35 AM, Christopher Roussi wrote:
>>>> I just opened our E110 yesterday, and can confirm that doing the
>>>> upgrade is not a good thing. Of course, after reconstructing the
>>>> SD card, I did it again, just to make sure...this is
>>>> time-consuming. ;-{)}
>>>
>>> We tracked down the problem with the E110 (not E100) last night.
>>> We'll get the ipks updated ASAP.
>>>
>>> Philip
>>>
>>>>
>>>> Chris Roussi Michigan Tech Research Inst.
>>>>
>>>> Sent from...well, you know.
>>>>
>>>> _______________________________________________ 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
>
>
------------------------------
Message: 3
Date: Mon, 8 Apr 2013 13:33:20 -0400
From: "Alex Gladd" <[email protected]>
To: "'Philip Balister'" <[email protected]>,
<[email protected]>, "'GNURadio Discussion List'"
<[email protected]>
Subject: Re: [USRP-users] E1XX updates, strike 2
Message-ID: <008d01ce347f$29b14f20$7d13ed60$@com>
Content-Type: text/plain; charset="us-ascii"
This morning I re-flashed to a fresh image and did a full system upgrade on
one of our E110s with no issues.
Thanks for resolving this so quickly!
~Alex
-----Original Message-----
From: Philip Balister [mailto:[email protected]]
Sent: Wednesday, April 03, 2013 3:59 PM
To: [email protected]; GNURadio Discussion List
Subject: [USRP-users] E1XX updates, strike 2
OK, the bad file causing E110's to hang after updating has been fixed.
You should be able to opkg update; opkg upgrade on both e100 and e110's now.
Sorry for the trouble.
Philip
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
------------------------------
Message: 4
Date: Mon, 8 Apr 2013 11:33:10 -0700
From: Matt Ettus <[email protected]>
To: Robert Palumbo <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: Re: [USRP-users] CORDIC rise time
Message-ID:
<CAN=1kn-S=sso7bf58yia8lnaydy_n44fh8nhesux5f27mxo...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The CORDIC does not have a rise time, but it does have a group delay. Each
stage of the cordic takes one cycle at 100 MHz. Rise time is associated
with filters, which the CORDIC is not. It is really only an efficient way
to do a complex multiplication.
Matt
On Sat, Apr 6, 2013 at 12:27 AM, Robert Palumbo <[email protected]> wrote:
> Hi everyone,
>
> Has anyone ever observed a rise time associated with samples through
> either the CORDIC or digital FIR filters in the DDC chain of the USRP (
> specifically the N210)? I know that the filters should have a rise time,
> which can be accurately predicted in Matlab or in theory, but I was curious
> if the CORDIC would have one as well.
>
> I'm currently using the USRP in a pulsed mode operation, so I'm
> continuously pulsing the DDC chain with samples.
>
> Thanks, any help or advice is appreciated.
>
> Rob
>
> _______________________________________________
> 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/20130408/09ee319b/attachment-0001.html>
------------------------------
Message: 5
Date: Mon, 8 Apr 2013 11:40:29 -0700
From: Matt Ettus <[email protected]>
To: "[email protected]" <[email protected]>
Subject: [USRP-users] USRPs in Brazil
Message-ID:
<CAN=1kn-g11ftg_2kup2k-+uacsrbu3cc-n7tv+2jwcm9-qc...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi everyone. I'm traveling in Sao Paulo this week for NI Days Brasil (
http://brasil.ni.com/nidays ), and I have some free time. If you would
like to get together to talk about GNU Radio and USRPs, what is coming from
Ettus Research, or anything else SDR, send me an email. If you have a
group and some space on Friday, I can even do a presentation and show you a
cool prototype system we've been working on.
Muito obrigado,
Matt
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130408/ca14389a/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 09 Apr 2013 10:56:26 +0200
From: Florian Schlembach <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] N210 RX Customization How-To
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Fantastic tutorial, great work! I wish I had a similar tutorial before I
started implementing things on an USRP.
------------------------------
Message: 7
Date: Tue, 9 Apr 2013 14:49:10 +0200
From: Jawad Seddar <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] No signal on TX/RX port
Message-ID:
<cae9wgf-n1mojkdqkq1pn+pmnkbggm01mzxco7cmexo4gx2l...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi again,
Now it seems I cannot receive on the RX2 port as well...
Should I consider my daughter board dead?
Regards,
Jawad
2013/4/5 Jawad Seddar <[email protected]>
> Hello,
>
> I have 2 USRP1 each equiped with a RFX900 daughter board.
> I have put antennas on each port of those cards (both RX2 and TX/RX).
>
> When I transmit from one USRP using the TX/RX port, I can only receive on
> the other USRP using the RX2 port, I don't see any signal on the TX/RX port.
>
> Simply put, here what happens :
> USRP #1 TX/RX -> USRP #2 RX2 == OK
>
> USRP #1 TX/RX -> USRP #2 TX/RX == Not OK
>
> The same happens the other way around (from USRP #2 to USRP #1)
>
> I have attached the simple flow graphs I used for testing purposes as well
> as the results I obtained.
>
> Is this a normal behaviour or am I doing something wrong?
>
> Thanks for the help,
> Seddar Jawad
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/8f73d60a/attachment-0001.html>
------------------------------
Message: 8
Date: Tue, 9 Apr 2013 10:59:53 -0230
From: <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Info about GPSDO for N2XX and E100 series
signals
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Hi I have some questions about the GPSDO module.
I'm not exactly familiar with GPS timing so please bear with me if some of
these questions seem like common sense.
The PPS output signal. I understand this is a signal that helps the accuracy
of the 10 MHz clock. Could somebody please provide some input about what
exactly is going on in the receiver when it receives this signal? Frequency,
etc?
The RS232 signal? Is this just so that software like gnuradio automatically
detects this feature broadcasted through the receiver to the computer? Or if
you set the jumpers correctly and have your 10 MHz signal and PPS signal
connected correctly without the RS232 connection. Will everything run fine?
If anyone would care to answer and needs anymore info or I haven't elaborated
enough please do not hesitate to ask me to elaborate.
Thank you,
Mike Scott
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/5a2b6a47/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 9 Apr 2013 15:50:16 +0200
From: Simon Szustkowski <[email protected]>
To: [email protected]
Subject: [USRP-users] Building fails on debian
Message-ID:
<cafcevyha0f6yn7a_m3benzhuchsifbs0jv_5vgqdyaft9k0...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
i am trying to build on debian stable, but it fails with the following
error:
Generating file member index...
finalizing index lists...
finished...
[ 0%] Built target doxygen_docs
[ 0%] Generating /home/simonszu/uhd/host/build/docs/index.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/identification.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/build.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/calibration.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/coding.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/dboards.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/gpsdo.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/general.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/images.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/stream.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/sync.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/transport.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/usrp1.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/usrp2.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/usrp_b100.html
[ 0%] Generating /home/simonszu/uhd/host/build/docs/usrp_e1x0.html
[ 8%] Built target manual_html
[ 9%] Generating
/home/simonszu/uhd/host/build/lib/transport/vrt_if_packet.cpp
[ 9%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/adf4350_regs.hpp
[ 10%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/adf4351_regs.hpp
[ 10%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/adf4360_regs.hpp
[ 11%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/ad9510_regs.hpp
[ 11%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/ad9777_regs.hpp
[ 12%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/ad5623_regs.hpp
[ 13%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/ad7922_regs.hpp
[ 13%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/max2829_regs.hpp
[ 14%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/max2118_regs.hpp
[ 14%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/max2112_regs.hpp
[ 15%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/ad9862_regs.hpp
[ 15%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/ad9522_regs.hpp
[ 16%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/ads62p44_regs.hpp
[ 16%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/tuner_4937di5_regs.hpp
[ 17%] Generating
/home/simonszu/uhd/host/build/lib/ic_reg_maps/tda18272hnm_regs.hpp
[ 17%] Generating convert/convert_orc.c
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: x2
ERROR: unknown token[0]: swaplq
ERROR: unknown token[0]: x2
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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130409/c274486c/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 9 Apr 2013 14:55:01 +0100
From: Mike Jameson <[email protected]>
To: [email protected]
Cc: [email protected]
Subject: Re: [USRP-users] Info about GPSDO for N2XX and E100 series
signals
Message-ID:
<CAJcjmiTC2iTW0S3UgMY-D1b6h5wLgSpEtHqNXh=z+emmdr+...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi Mike,
The 1PPS signal is used to latch a time into the USRP device. The 1PPS
signal is not required to utilise the 10MHz reference clock accuracy and is
only used to set an exact start time as such.
See here for more info:
http://files.ettus.com/uhd_docs/manual/html/sync.html
Cheers,
Mike
--
Mike Jameson M0MIK BSc
Email: [email protected]
Web: http://scanoo.com
On 9 April 2013 14:29, <[email protected]> wrote:
> **
> Hi I have some questions about the GPSDO module.
>
> I'm not exactly familiar with GPS timing so please bear with me if some of
> these questions seem like common sense.
>
> The PPS output signal. I understand this is a signal that helps the
> accuracy of the 10 MHz clock. Could somebody please provide some input
> about what exactly is going on in the receiver when it receives this
> signal? Frequency, etc?
>
> The RS232 signal? Is this just so that software like gnuradio
> automatically detects this feature broadcasted through the receiver to the
> computer? Or if you set the jumpers correctly and have your 10 MHz signal
> and PPS signal connected correctly without the RS232 connection. Will
> everything run fine?
>
> If anyone would care to answer and needs anymore info or I haven't
> elaborated enough please do not hesitate to ask me to elaborate.
>
> Thank you,
>
> Mike Scott
>
> _______________________________________________
> 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/afc8bff5/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 9 Apr 2013 11:35:20 -0400
From: Sean Nowlan <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Problems with setting gain
Message-ID: <[email protected]>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
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
------------------------------
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 6
*****************************************
