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. [Spectrum Sense] Output (Rog?rio Rivera)
2. Image Problem with SBX + USRP N210 (Perelman Nathan (Nathan))
3. Re: Image Problem with SBX + USRP N210 (Mike Jameson)
4. Re: B100 Requires Power Reset (Josh Blum)
5. Re: Timing constraints violations using custom_dsp_rx module
(Florian Schlembach)
----------------------------------------------------------------------
Message: 1
Date: Fri, 22 Mar 2013 17:40:15 -0300
From: Rog?rio Rivera <[email protected]>
To: [email protected]
Subject: [USRP-users] [Spectrum Sense] Output
Message-ID:
<CAP9hz17=7REx4pyg_7sZdp7U1OBBfPXFDsALm=4dvpg_fpo...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Greetings.
I am using USRP N210 with Daughterboard WBX and I am using
usrp_spectrum_sense.py and I am receiving on the terminal prompt the center
frequency. I have added the "print m.data" line to the
"usrp_spectrum_sense.py" code but so far I can't plot a spectrum graph
using the data received from the USRP.
Do I have to add any command line to the python code?
Is the "gr_plot_fft.py" relevant for me in this case?
How do I get that real time graph?
Thanks in advance,
Rogerio.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130322/c9da476a/attachment-0001.html>
------------------------------
Message: 2
Date: Fri, 22 Mar 2013 19:23:19 -0400
From: "Perelman Nathan (Nathan)" <[email protected]>
To: <[email protected]>
Subject: [USRP-users] Image Problem with SBX + USRP N210
Message-ID:
<3862c5643b15b6468269546753eb2a9208493...@bltsxvs01.govsolutions.com>
Content-Type: text/plain; charset="us-ascii"
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20130322/e3fba680/attachment-0001.html>
------------------------------
Message: 3
Date: Sat, 23 Mar 2013 00:21:35 +0000
From: Mike Jameson <[email protected]>
To: "Perelman Nathan (Nathan)" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Image Problem with SBX + USRP N210
Message-ID:
<CAJcjmiSrZ-qA3VjdwtznDgCeYUL8TuANo93g5AToFy=ypio...@mail.gmail.com>
Content-Type: text/plain; charset=windows-1252
Hi,
I have this issue with my USRP2 and WBX here in the UK due to strong
local Broadcast WFM/DAB/POCSAG/Tetra transmissions. To move the image
somewhere else just change the local oscillator frequency. For
example, set the center frequency in the GRC UHD source to the
following line:
uhd.tune_request(uhd_center_freq,
rf_freq=(uhd_center_freq+uhd_lo_offset),rf_freq_policy=uhd.tune_request.POLICY_MANUAL)
The variables 'uhd_center_freq' and 'uhd_lo_offset' need to be
specified. 'uhd_lo_offset' can be set between +/- 50e6.
Mike
--
Mike Jameson M0MIK BSc
Radio Communications Technology Specialist
Email: [email protected]
Web: http://www.scanoo.com
On 22 March 2013 23:23, Perelman Nathan (Nathan)
<[email protected]> 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
>
------------------------------
Message: 4
Date: Fri, 22 Mar 2013 20:28:24 -0500
From: Josh Blum <[email protected]>
To: Dan CaJacob <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] B100 Requires Power Reset
Message-ID: <[email protected]>
Content-Type: text/plain; charset=UTF-8
Glad to hear that helped. I think we can make the driver catch the error
and force a reload -- to be more automatic about it.
>>
>> Is the flowgraph nicely stopped or is it killed? Just curious.
>>
> I think the flowgraph is always killed. I have seen the problem in all
> three ways that I kill flowgraphs:
>
> 1. Ctrl-C from the command line on a running py file
> 2. sudo service [name] stop on a daemonized flowgraph we are running (I
> think that just kills it rather than stop, unfortunately)
> 3. In GRC, clicking the red "Kill the flowgraph" button (does this use
> stop? Besides this particular case, this button has always seemed to be
> the safest way to kill flowgraphs.)
>
>
Yea, all of those basically just kill the process. For sure its
reliable. But I guess that doesn't always leave the usb guts in a usable
state. :-)
I think GRC could use an additional block that instantiates some code to
catch one of the "lesser" kill signals and nicely stops and destructs
the flow graph. Ideally kill -9 should only be those emergency situations.
-josh
------------------------------
Message: 5
Date: Sat, 23 Mar 2013 11:55:35 +0100
From: Florian Schlembach <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Timing constraints violations using
custom_dsp_rx module
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I am just trying to dig into that problem little bit more. I think I
have narrowed down the root cause for the timing involations.
It seems like the logic within the settings_fifo_control.v is
responsible for this:
time_compare time_compare(
.time_now(vita_time_reg), .trigger_time(command_ticks_reg),
.late(late));
`else
assign late = 1;
`endif
wire time_ready = (out_command_has_time)? late : 1;
wire action = (cmd_state == EVENT_CMD) && ~result_fifo_full &&
perfs_ready && time_ready;
vita_time_reg is 64-bit wide and there still comes something after this
during one cycle. I reckon thats the root cause for the timing
violation. I'll have to see where I can insert another pipeline stage.
In general, it seems like if there is more logic put into the custom
module and the FPGA design gets bigger. Timing constraints in terms of
routing delays are more difficult to meet. Possibly, the USRP FPGA code
should be modified at this point.
May I ask for the author of the settings_control bus so we could
possibly work on a solution?
------------------------------
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 22
******************************************
