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: How long does USRP need to switch its center frequency
(Nick Foster)
2. Re: Image Problem with SBX + USRP N210 (Perelman Nathan (Nathan))
3. Re: Image Problem with SBX + USRP N210 (Ian Buckley)
4. Wireshark dissectors (Dario Lombardo)
5. Custom Block in FPGA code of USRP N210 (Vaibhav Vaidya)
6. USRP E100 segmentation faults (Xavier Clinquart)
7. Re: USRP E100 segmentation faults (Philip Balister)
8. Re: USRP E100 segmentation faults ([email protected])
9. Re: USRP E100 segmentation faults (Macre, William R)
10. Re: USRP E100 segmentation faults (Macre, William R)
11. Re: USRP E100 segmentation faults ([email protected])
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Mar 2013 10:02:23 -0700
From: Nick Foster <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] How long does USRP need to switch its center
frequency
Message-ID: <[email protected]>
Content-Type: text/plain; charset="iso-8859-1"; Format="flowed"
On 03/25/2013 06:44 AM, lwei wrote:
> Hi all,
>
> I know this is a rather basic question, but I notice the function
> usrp->set_rx_freq(freq); actually takes around 19 ms to return.
>
> So I then tried to use wireshark to capture the packets, the I notice
> between there are 32 UDP packets, sent with 36 bytes payload...and the
> time spent on those packets are about 19 ms, which corresponds with the
> software delay I measured with cpp binary
>
> I am using Boost_104000, UHD_003.001.000-9f1e49e (ye..a bit out of date
> I know, hope this is not where things go wrong).
>
> Does anyone know why it takes so long to set the frequency? is there
> something I am doing wrong or is this issue already solved by a newer
> uhd version?
>
> Kind regards,
>
Changing the RF frequency is slower and requiresSPI writes as well as
waiting for the PLL to lock onto the new frequency. If you are hopping
around within the 40MHz baseband bandwidth,you can tune the DDC/DUC in
the FPGA much faster using the advanced tuning parameters.
--n
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/e9da01f9/attachment-0001.html>
------------------------------
Message: 2
Date: Mon, 25 Mar 2013 14:18:26 -0400
From: "Perelman Nathan (Nathan)" <[email protected]>
To: <[email protected]>
Subject: Re: [USRP-users] Image Problem with SBX + USRP N210
Message-ID:
<3862c5643b15b6468269546753eb2a9208493...@bltsxvs01.govsolutions.com>
Content-Type: text/plain; charset="us-ascii"
No, I meant when feeding a signal in at 1502 MHz (1.502 GHz), I see an
image at 498 MHz (when capturing with a 500 MHz center frequency). My
best guess is that this has something to do with the third harmonic of
the LO.
-Nathan
From: USRP-users [mailto:[email protected]] On Behalf
Of Nick Foster
Sent: Saturday, March 23, 2013 4:26 PM
To: [email protected]
Subject: Re: [USRP-users] Image Problem with SBX + USRP N210
On 03/22/2013 04:23 PM, Perelman Nathan (Nathan) wrote:
Using an SBX in an USRP N210, I'm having an issue where when a
signal is fed in at a high frequency, an image of the signal appears at
a lower frequency. For example, when I connect a signal generator at
1502 MHz, then perform a 25 MHz capture centered at 500 MHz, I see an
image of the signal at 498 MHz. Sweeping the input signal around at 1500
MHz produces the corresponding opposite movement around 500 MHz.
Connecting to a spectrum analyzer instead shows no sign of a signal at
500 MHz, so it does appear to be an issue in the USRP. Any suggestions
for eliminating this image? A preselect filter does remove it, but is
not an option for my setup. Thanks.
-Nathan Perelman
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I'm assuming you meant 502MHz, not 1502MHz. This is IQ imbalance and is
normal in a direct conversion architecture. Mike Jameson's suggestion to
move the LO using the advanced tuning parameters is appropriate. If that
suggestion isn't possible for you for some reason, the calibration
utilities included in recent UHD distributions (specifically,
uhd_cal_rx_iq_balance) should help minimize the effect.
--n
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130325/bac16d1c/attachment-0001.html>
------------------------------
Message: 3
Date: Mon, 25 Mar 2013 12:20:51 -0700
From: Ian Buckley <[email protected]>
To: Perelman Nathan (Nathan) <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Image Problem with SBX + USRP N210
Message-ID: <[email protected]>
Content-Type: text/plain; charset="windows-1252"
Nathan,
What was the spec of the pre-select filter that seems to stop this manifesting?
-Ian
On Mar 25, 2013, at 11:18 AM, Perelman Nathan (Nathan)
<[email protected]> wrote:
> No, I meant when feeding a signal in at 1502 MHz (1.502 GHz), I see an image
> at 498 MHz (when capturing with a 500 MHz center frequency). My best guess is
> that this has something to do with the third harmonic of the LO.
> -Nathan
>
> From: USRP-users [mailto:[email protected]] On Behalf Of
> Nick Foster
> Sent: Saturday, March 23, 2013 4:26 PM
> To: [email protected]
> Subject: Re: [USRP-users] Image Problem with SBX + USRP N210
>
> On 03/22/2013 04:23 PM, Perelman Nathan (Nathan) wrote:
> Using an SBX in an USRP N210, I?m having an issue where when a signal is fed
> in at a high frequency, an image of the signal appears at a lower frequency.
> For example, when I connect a signal generator at 1502 MHz, then perform a 25
> MHz capture centered at 500 MHz, I see an image of the signal at 498 MHz.
> Sweeping the input signal around at 1500 MHz produces the corresponding
> opposite movement around 500 MHz. Connecting to a spectrum analyzer instead
> shows no sign of a signal at 500 MHz, so it does appear to be an issue in the
> USRP. Any suggestions for eliminating this image? A preselect filter does
> remove it, but is not an option for my setup. Thanks.
> -Nathan Perelman
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> I'm assuming you meant 502MHz, not 1502MHz. This is IQ imbalance and is
> normal in a direct conversion architecture. Mike Jameson's suggestion to move
> the LO using the advanced tuning parameters is appropriate. If that
> suggestion isn't possible for you for some reason, the calibration utilities
> included in recent UHD distributions (specifically, uhd_cal_rx_iq_balance)
> should help minimize the effect.
>
> --n
> _______________________________________________
> 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/20130325/021b544b/attachment-0001.html>
------------------------------
Message: 4
Date: Tue, 26 Mar 2013 10:39:06 +0100
From: Dario Lombardo <[email protected]>
To: [email protected]
Subject: [USRP-users] Wireshark dissectors
Message-ID:
<caoyjjfucwymc+xszejcwf_jpmc-acdf3xmy3qmfzrxwi5mp...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello list!
I'm pleased to announce you that both the dissectors for VRT/VITA 49 and
UHD have been accepted into the wireshark trunk. They are alredy available
if you use the SVN version, while, to have them into you wireshark
distribution package, you have to wait that the revision number 48550 is
put into the distribution.
Happy dissections!
Dario
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/286f9413/attachment-0001.html>
------------------------------
Message: 5
Date: Tue, 26 Mar 2013 16:59:24 +0530
From: Vaibhav Vaidya <[email protected]>
To: [email protected]
Subject: [USRP-users] Custom Block in FPGA code of USRP N210
Message-ID:
<CAApVcXij8qw7Jbgqo2DjdT+x=pu0lvrxhnkg+_nz5h9kasx...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hi,
I am trying to make few changes in the code of USRP 210 FPGA. I have read
many posts that tell how to go about it.
I instantiated a module that just EX-ORs the input with itself, between the
ddc_chain and vita _rx_framer blocks. Now when I run benchmark_tx.py(on
another computer) and benchmark_rx.py(with the modified fpga code
ofcourse), it gets stuck.
Moreover, I tried to run usrp_spectrum_sense.py, but it gave me the same
output that i got on any other machine(with the default fpga code).
The receiver should have given me zero as output.
I dont know whats wrong. Please help.
Thanks.
Vaibhav
--
28 States
7 Union Territories
1652 Languages
3000+ Castes
6 Major Religions
29 Major Festivals
but still
United We Stand as INDIA
JAI HIND
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/2e83ca05/attachment-0001.html>
------------------------------
Message: 6
Date: Tue, 26 Mar 2013 14:03:41 +0100
From: Xavier Clinquart <[email protected]>
To: [email protected]
Subject: [USRP-users] USRP E100 segmentation faults
Message-ID:
<caayuuvq9ugswzoubr62vgf2qtg3ygp+o66fxzyvno3icm5n...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Hello ,
I am Xavier Clinquart student at the Denayer institute Belgium. And I'm
currently working with the USRP E100 for my thesis .
Now i have been having this segmentation fault that keeps repeating itself
when i try to use the gnuradio-companion. Or when i try to minimise any
other window open at that current time.
I am using the latest image and build from the ettus website and have not
made Any changes to it.
is there anyone who had this problem and found a solution to it?
Greetings
Xavier
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/3b8fff53/attachment-0001.html>
------------------------------
Message: 7
Date: Tue, 26 Mar 2013 09:20:02 -0400
From: Philip Balister <[email protected]>
To: Xavier Clinquart <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP E100 segmentation faults
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 03/26/2013 09:03 AM, Xavier Clinquart wrote:
> Hello ,
>
>
> I am Xavier Clinquart student at the Denayer institute Belgium. And I'm
> currently working with the USRP E100 for my thesis .
> Now i have been having this segmentation fault that keeps repeating itself
> when i try to use the gnuradio-companion. Or when i try to minimise any
> other window open at that current time.
>
> I am using the latest image and build from the ettus website and have not
> made Any changes to it.
>
> is there anyone who had this problem and found a solution to it?
Can you send me the output for the console when it segfaults?
Philip
>
> Greetings
>
> Xavier
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 8
Date: Tue, 26 Mar 2013 09:50:30 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] USRP E100 segmentation faults
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 26 Mar 2013 09:20, Philip Balister wrote:
> On 03/26/2013 09:03
AM, Xavier Clinquart wrote:
>
>> Hello , I am Xavier Clinquart student
at the Denayer institute Belgium. And I'm currently working with the
USRP E100 for my thesis . Now i have been having this segmentation fault
that keeps repeating itself when i try to use the gnuradio-companion. Or
when i try to minimise any other window open at that current time. I am
using the latest image and build from the ettus website and have not
made Any changes to it. is there anyone who had this problem and found a
solution to it?
>
> Can you send me the output for the console when it
segfaults?
>
> Philip
>
>> Greetings Xavier
_______________________________________________ USRP-users mailing list
[email protected] [1]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com [2]
>
> _______________________________________________
> USRP-users mailing
list
> [email protected]
>
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
I've
observed, with the latest Gnu Radio on x86_64 that gnuradio-companion
segfaults on exit, so I don't think this is necessarily an E100 issue.
Links:
------
[1] mailto:[email protected]
[2]
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/20130326/ef1365b2/attachment-0001.html>
------------------------------
Message: 9
Date: Tue, 26 Mar 2013 14:21:43 +0000
From: "Macre, William R" <[email protected]>
To: Xavier Clinquart <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [USRP-users] USRP E100 segmentation faults
Message-ID:
<5e9bdf6832e57149b46d9becf6ab21510cf1e...@rrc-ats-exmb2.ats.atsinnovate.com>
Content-Type: text/plain; charset="us-ascii"
Xavier:
I am using the USRP E110. When you say "segmentation fault" I assume you are
referring to the "S" character being blasted to the terminal while
transmitting. I get this error when using tx_sample_from_file to transmit a
repeated frame. I have found in my case that setting the "-delay=" option to
250ms clears the problem. Josh and Philip are aware of this problem and the
fix should be in the next UHD release.
Wrm
From: USRP-users [mailto:[email protected]] On Behalf Of
Xavier Clinquart
Sent: Tuesday, March 26, 2013 9:04 AM
To: [email protected]
Subject: [USRP-users] USRP E100 segmentation faults
Hello ,
I am Xavier Clinquart student at the Denayer institute Belgium. And I'm
currently working with the USRP E100 for my thesis .
Now i have been having this segmentation fault that keeps repeating itself when
i try to use the gnuradio-companion. Or when i try to minimise any other window
open at that current time.
I am using the latest image and build from the ettus website and have not made
Any changes to it.
is there anyone who had this problem and found a solution to it?
Greetings
Xavier
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/d7205bdf/attachment-0001.html>
------------------------------
Message: 10
Date: Tue, 26 Mar 2013 14:27:48 +0000
From: "Macre, William R" <[email protected]>
To: "Macre, William R" <[email protected]>, Xavier Clinquart
<[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] USRP E100 segmentation faults
Message-ID:
<5e9bdf6832e57149b46d9becf6ab21510cf1e...@rrc-ats-exmb2.ats.atsinnovate.com>
Content-Type: text/plain; charset="us-ascii"
Sorry:
I confused "segment number error"(USRP) with "segmentation fault"(KERNEL)
both of which I have encountered during transmitting on the E110. I have not
been able to reproduce the "segmentation fault" in quite awhile however.
Wrm
From: USRP-users [mailto:[email protected]] On Behalf Of
Macre, William R
Sent: Tuesday, March 26, 2013 10:22 AM
To: Xavier Clinquart; [email protected]
Subject: Re: [USRP-users] USRP E100 segmentation faults
Xavier:
I am using the USRP E110. When you say "segmentation fault" I assume you are
referring to the "S" character being blasted to the terminal while
transmitting. I get this error when using tx_sample_from_file to transmit a
repeated frame. I have found in my case that setting the "-delay=" option to
250ms clears the problem. Josh and Philip are aware of this problem and the
fix should be in the next UHD release.
Wrm
From: USRP-users [mailto:[email protected]] On Behalf Of
Xavier Clinquart
Sent: Tuesday, March 26, 2013 9:04 AM
To: [email protected]<mailto:[email protected]>
Subject: [USRP-users] USRP E100 segmentation faults
Hello ,
I am Xavier Clinquart student at the Denayer institute Belgium. And I'm
currently working with the USRP E100 for my thesis .
Now i have been having this segmentation fault that keeps repeating itself when
i try to use the gnuradio-companion. Or when i try to minimise any other window
open at that current time.
I am using the latest image and build from the ettus website and have not made
Any changes to it.
is there anyone who had this problem and found a solution to it?
Greetings
Xavier
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/92c4ce1c/attachment-0001.html>
------------------------------
Message: 11
Date: Tue, 26 Mar 2013 10:33:21 -0400
From: [email protected]
To: <[email protected]>
Subject: Re: [USRP-users] USRP E100 segmentation faults
Message-ID: <[email protected]>
Content-Type: text/plain; charset="utf-8"
On 26 Mar 2013 10:27, Macre, William R wrote:
> Sorry:
>
> I
confused "segment number error"(USRP) with "segmentation fault"(KERNEL)
both of which I have encountered during transmitting on the E110. I have
not been able to reproduce the "segmentation fault" in quite awhile
however.
>
> Wrm
A "Segmentation Fault" is an error that occurs when
a running process attempts to access a virtual address that is outside
its address space. Most usually because the app is either trying to
indirect through a NULL pointer (insufficient error checking of
pointer-returns from function calls) or it runs off the end of an array,
trashing an adjacent pointer, which is subsequently used, and the
garbage value is outside the virtual address space of the process.
The
kernel gets a trap from the MMU, and turns it into a SIGSEGV delivered
to the process, which then, if it hasn't "caught" SIGSEGV, causes it to
terminate, and optionally, to produce a core dump file.
This is
standard Linux stuff, and not specific to E100. Any Linux system that
runs on MMU-capable hardware works this way.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130326/de96cae8/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 31, Issue 25
******************************************
