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: SBX RF board simultaneous mode with USRP Hardware Support
for MATLAB (Marc Erickson)
2. Limiting Factor in N210 Operating Temperature (Robert Palumbo)
3. Re: Limiting Factor in N210 Operating Temperature (Nick Foster)
4. Re: USRP receive issues (Rob Rhinehart)
5. Re: USRP-users Digest, Vol 23, Issue 5 (Farrukh Aziz)
6. Timeout while streaming N210+DBSRX2 at 50Msps (Juan Manuel Parro)
7. Re: Timeout while streaming N210+DBSRX2 at 50Msps (Josh Blum)
----------------------------------------------------------------------
Message: 1
Date: Thu, 5 Jul 2012 17:18:54 +0000
From: Marc Erickson <[email protected]>
To: Stan Gamla <[email protected]>, "[email protected]"
<[email protected]>
Subject: Re: [USRP-users] SBX RF board simultaneous mode with USRP
Hardware Support for MATLAB
Message-ID:
<d7bde6ca6982b54bb6aa1e2e5373d36605d40...@exmb-01-ah.ad.mathworks.com>
Content-Type: text/plain; charset="us-ascii"
Hi Stan,
Sorry for the confusion about our support. We have stated some limitations of
our support in the product release notes which are available in the download
package. Type 'help sdru' and follow the 'Help and Examples' link. Then
click on the link under 'Release Notes'. The relevant limitation is stated as
follows:
"Communications with USRP(tm) only supports half-duplex applications. MATLAB
and Simulink applications must be receive-only or transmit-only. Full-duplex is
not supported."
Our package has separate Rx and Tx blocks (for Simulink) and separate Rx and Tx
System objects (for MATLAB) with their own configuration parameters. We allow
binding the Rx and Tx to the same board in order to support some duplex
operations. Full duplex operation might be possible when adhering to some
modeling constraints.
Please feel free to contact us directly to discuss any use-cases and specific
applications you might be interested in pursuing and we'd be happy to work with
you.
Regards,
Marc
From: [email protected]
[mailto:[email protected]] On Behalf Of Stan Gamla
Sent: Friday, June 29, 2012 7:03 AM
To: [email protected]
Subject: [USRP-users] SBX RF board simultaneous mode with USRP Hardware Support
for MATLAB
As far as I understand, the Ettus SBX RF board comprises a full-duplex
transceiver with separate receive and transmit chains, each having its own
local oscillator.
https://www.ettus.com/product#tabs-3 states that:
"The SBX is a wide bandwidth transceiver that provides up to 100 mW of output
power, and a typical noise figure of 5 dB. The local oscillators for the
receive and transmit chains operate independently, which allows dual-band
operation. The SBX is MIMO capable, and provides 40 MHz of bandwidth. The SBX
is ideal for applications requiring access to a variety of bands in the 400
MHz-4400 MHz range. Example application areas include WiFi, WiMax, S-band
transceivers and 2.4 GHz ISM band transceivers."
Further, according to their website "The MathWorks USRP(r) Hardware Support
from [sic] MATLAB and Simulink is compatible with UHD(tm)-based Ettus radios".
http://www.mathworks.com/discovery/sdr/usrp.html viz:
"MATLAB and Simulink support for USRP(r) devices has been tested on N210 and
USRP2(r) devices with WBX, SBX, XCVR2450, TVRX, TVRX2, LFRX, LFTX, DBSRX, and
DBSRX2 daughterboards. Support may also extend to other UHD(tm)-based radios
and daughterboards from National Instruments(r)."
Are both of these statements correct, I wonder?
If The MathWorks is tuned in to this channel, could you please comment and
perhaps provide an illustration of how to configure the N210/SBX using both
MATLAB and Simulink so that a signal is transmitted from the RF1 port and
received by the RF2. As a suggestion, slider controls could be used in Simulink
to independently adjust the RF settings of both the transmitter and receiver to
include at least gain and center frequency. A spectrum of the received signal
should be displayed.
On the other hand, if I have misunderstood what is meant by the word
"supported" could either Ettus or The MathWorks comment please.
Thanks,
Stan
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120705/b2def5d3/attachment-0001.html>
------------------------------
Message: 2
Date: Thu, 5 Jul 2012 14:17:43 -0400
From: Robert Palumbo <[email protected]>
To: [email protected]
Subject: [USRP-users] Limiting Factor in N210 Operating Temperature
Message-ID:
<cakwzk9zkpqbgvttcqspczoqdsbqjcvagw7gvkyu0hk0en53...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Hello Everyone,
The N210 specification sheet lists the operating temperature as 0degC
to 55degC. What is the limiting component in this temperature range?
For example, the 3400a DSP chip is rated up to 70degC, for example.
Has anyone out there ever done a thermal cycle test or other
temperature tests to confirm the operating range? I've tested it up to
40 degC with no issues in my setup, but I don't have the equipment to
do an actual thermal test on the device.
Thanks for any advice anyone can give,
Rob
--
Robert A Palumbo
University of Massachusetts Amherst
[email protected]
------------------------------
Message: 3
Date: Thu, 5 Jul 2012 11:33:27 -0700
From: Nick Foster <[email protected]>
To: Robert Palumbo <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Limiting Factor in N210 Operating
Temperature
Message-ID:
<calalhjviajrl2fuugbefsck2tilbtw82vizk-zuzlpov_15...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
The USRP N210 is rated to 55C because that's the highest temperature it's
been tested at. It's possible that it will work at higher temperatures, but
we don't warrant or support it. If your application requires operation at
higher ambient temperatures, you should ensure correct operation under
those conditions.
That said, the hottest-running parts on the N210 will be the AD9510 clock
distribution chip and the FPGA. You should also pay close attention to the
mixers and synthesizers on the daughterboards.
--n
On Thu, Jul 5, 2012 at 11:17 AM, Robert Palumbo <[email protected]> wrote:
> Hello Everyone,
>
> The N210 specification sheet lists the operating temperature as 0degC
> to 55degC. What is the limiting component in this temperature range?
> For example, the 3400a DSP chip is rated up to 70degC, for example.
>
> Has anyone out there ever done a thermal cycle test or other
> temperature tests to confirm the operating range? I've tested it up to
> 40 degC with no issues in my setup, but I don't have the equipment to
> do an actual thermal test on the device.
>
> Thanks for any advice anyone can give,
>
> Rob
>
> --
> Robert A Palumbo
> University of Massachusetts Amherst
> [email protected]
>
> _______________________________________________
> 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/20120705/2e2756dd/attachment-0001.html>
------------------------------
Message: 4
Date: Thu, 5 Jul 2012 12:24:47 -0700
From: Rob Rhinehart <[email protected]>
To: "Marcus D. Leech" <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP receive issues
Message-ID:
<CA+W74gaEb0=uwoxtcyhl+pqvbd8pagdmvbunns_je_b2aji...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
On Wed, Jul 4, 2012 at 6:26 AM, Marcus D. Leech <[email protected]> wrote:
> Hello,
>>
>> I have a straightforward setup using gnuradio and a USRP B100 to transmit
>> CW to an E100 (SBX and WBX daughterboards, respectively). I have verified
>> the RF output of the B100 with a spectrum analyzer and the receive
>> capability of the E100 with a signal generator, but when I connect the two
>> directly with coax I see a strange pattern on the receiver FFT (see
>> attachment), when I'm expecting a spike at the center frequency. The
>> receive window only shows 1MHz of bandwidth but I've looked at the spectrum
>> around the center frequency and the spike is nowhere to be found. My sample
>> rates are 500k
>>
>> Has anyone else seen this before? Suggestions would be very welcome.
>>
>> Thank you!
>> Rob
>>
> A piece of coax or a piece of coax with 30-60dB of attenuation in it?
>
> If you connected your TX directly to an RX with no attenuation, then very
> likely you have damaged/destroyed the LNA on the RX
> chain. LNAs aren't designed for high power levels--the output of the TX
> is generally 30 to 50dB stronger than any signal it is
> likely to receive from an antenna, and the RX chains on these cards are
> designed for "off air" work and "expect" to be connected
> to an antenna, or connected to a signal source through appropriate
> attenuators.
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
I am not using attenuators but I set the gain on the USRP low enough so as
to not damage the LNA. I have verified the output of TX is about -20dBm
with a spectrum analyzer, and the fact that the RX chain can receive and
demodulate a -20dBm signal with a signal generator. I have tried with
antennas as well but the only response I get is the strange pattern
attached in the original email. Could it be something else?
Thank you,
Rob
> ______________________________**_________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/**mailman/listinfo/usrp-users_**lists.ettus.com<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/20120705/c4785dcf/attachment-0001.html>
------------------------------
Message: 5
Date: Thu, 5 Jul 2012 14:52:44 -0700 (PDT)
From: Farrukh Aziz <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 23, Issue 5
Message-ID:
<[email protected]>
Content-Type: text/plain; charset="iso-8859-1"
Josh can I install Python at this stage or do I need to uninstall gnuradio
first and then install everything again.
thanks
Farrukh Aziz Bhatti
Department of Electrical & Computer Engineering
University of Auckland+64 21 02973964
--- On Thu, 5/7/12, [email protected]
<[email protected]> wrote:
From: [email protected] <[email protected]>
Subject: USRP-users Digest, Vol 23, Issue 5
To: [email protected]
Received: Thursday, 5 July, 2012, 9:00 PM
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: usrp1 fpga source in uhd can not generate binary as good
? ? ? as the one in gnuradio and question about halfband _decim (Josh Blum)
???2. Re: USRP-users Digest, Vol 23, Issue 2 (Josh Blum)
???3. Re: Fwd: tunnel.py doesn't receive packages when transmit and
? ? ? receive frequencies are different (Josh Blum)
???4. Re: Frequency Hopping (Birhane Alemayoh)
----------------------------------------------------------------------
Message: 1
Date: Wed, 04 Jul 2012 14:44:50 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] usrp1 fpga source in uhd can not generate
??? binary as good as the one in gnuradio and question about halfband
??? _decim
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/04/2012 05:19 AM, Page Jack wrote:
> Hi list,
> I need to modify usrp1 fpga logic.
> I get the fpga source from uhd git. I choose config to generate
> inband_2rxhb_2tx.rbf but the binary generated is not as good
> as the inband_2rxhb_2tx.rbf in gnuradio. the major problem is the gain is
> smaller than the one in gnuradio. the average
> level the signal received using compiled inband_2rxhb_2tx.rbf is about 2/3
> as the signal received using inband_2rxhb_2tx.rbf
> in gnuradio.
The FPGA image is built from usrp_std not inband see the
fpga/README.txt. That inband work was never used. And to make things
more confusing, the USRP1 openbts driver uses a modified version of
inband, but we dont know which source produced the image.
> and I have some question with the code in halfband_decim.v
>
>? ? assign clear = start_d4; // was dC
>? ? wire???latch_result = start_d4; // was dC
>? ? assign strobe_out = start_d5; // was dD
>
> this code confuse me. I thought that if set latch_result as start_d4 will
> latch data before halfband decim finished.
> So I believe that the value d4 should be dC and d5 should be dD, but both
> d4 and dC works which is so weird.
>
>? ? coeff_rom coeff_rom (.clock(clock),.addr(phase[2:0]-3'd1),.data(coeff));
>
> I think the addr should be phase[2:0] rather than phase[2:0]-3'd1 for phase
> is active from 0~7, and the coeff_rom only deal with
> addr from 0~7.
>
> can somebody explain me the question above.
>
Perhaps you are seeing some clever pipelining of the result. You might
also want to take a look at the halfband implementations in the
usrp2/sdr_lib directories for a comparison.
-josh
------------------------------
Message: 2
Date: Wed, 04 Jul 2012 14:45:49 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 23, Issue 2
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/03/2012 08:43 PM, Farrukh Aziz wrote:
> Hi Josh, the problem has been solved as I removed all UHD folders along with
> gnuradio, and did a fresh installation using this bash script:
> http://www.sbrac.org/files/build-gnuradio
>
> I then burnt the compatible fpga and firmware images, using
> uhd_images_downloader.py and the N210 is now responding to uhd_usrp_probe.
>
> However when I run GRC I get this error
> --------------------------------------------------------
> Traceback (most recent call last):
>???File "/home/fbha004/GRC files/top_block.py", line 13, in <module>
>? ???from grc_gnuradio import wxgui as grc_wxgui
> ImportError: cannot import name wxgui
> ---------------------------------------------------------
> Secondly, in the previous version of GRC, I had oscilloscope and spectrum
> analyzer (FFT) block, but I cannot find these in the new version (GNU Radio
> Companion 3.6.2git-117-gf8581fb4) that has been installed.
>
> thanks
> Farrukh Aziz Bhatti
> Department of Electrical & Computer Engineering
> University of Auckland
>
Looks like for both errors, gnuradio was built without wx python installed.
-josh
>
>
> --- On Mon, 2/7/12, [email protected]
> <[email protected]> wrote:
>
> From: [email protected] <[email protected]>
> Subject: USRP-users Digest, Vol 23, Issue 2
> To: [email protected]
> Received: Monday, 2 July, 2012, 9:00 PM
>
> 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. Updating compatible UHD and firmware (Farrukh Aziz)
>? ? 2. Re: Updating compatible UHD and firmware (Josh Blum)
>? ? 3. ExtIO / UHD compatibility (Armand Sperduti)
>? ? 4. Re: ExtIO / UHD compatibility (Dean Ferraro)
>? ? 5. Re: ExtIO / UHD compatibility (Simon HB9DRV)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sun, 1 Jul 2012 15:35:59 -0700 (PDT)
> From: Farrukh Aziz <[email protected]>
> To: USRP user forum <[email protected]>
> Subject: [USRP-users] Updating compatible UHD and firmware
> Message-ID:
>? ???<[email protected]>
> Content-Type: text/plain; charset="iso-8859-1"
>
> I have installed a new version of UHD, and now trying to load a compatible
> firmware and fpga image on my N210. I initially tried doing this through
> uhd_images_downloader.py but it gave this error:
> ----------------------------------------------------------------------------------
> Traceback (most recent call last):
> ? File "uhd_images_downloader.py", line 47, in <module>
> ??? u = urllib2.urlopen(images_src)
> ? File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
> ??? return _opener.open(url, data, timeout)
> ? File "/usr/lib/python2.7/urllib2.py", line 383, in open
> ??? protocol = req.get_type()
> ? File "/usr/lib/python2.7/urllib2.py", line 245, in get_type
> ??? raise ValueError, "unknown url type: %s" % self.__original
> ValueError: unknown url type: @UHD_IMAGES_DOWNLOAD_SRC@
> ----------------------------------------------------------------------------------
> I then manually downloaded several firmware/fpga images but after burning
> them on the N210 I get the following error when I run uhd_usrp_probe:
>
> ----------------------------------------------------------------------------------
> -- Opening a USRP2/N-Series device...
> Error: RuntimeError:
> Please update the firmware and FPGA images for your device.
> See the application notes for USRP2/N-Series for instructions.
> Expected protocol compatibility number [7 to 10], but got 11:
> The firmware build is not compatible with the host code build.
> ----------------------------------------------------------------------------------
>
> Any comments would be much appreciated. thanks
>
> Farrukh Aziz Bhatti
> Department of Electrical & Computer Engineering
> University of Auckland
>
> -------------- next part --------------
> An HTML attachment was scrubbed...
> URL:
> <http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120701/b9a8684c/attachment-0001.html>
>
> ------------------------------
>
> Message: 2
> Date: Sun, 01 Jul 2012 15:55:55 -0700
> From: Josh Blum <[email protected]>
> To: [email protected]
> Subject: Re: [USRP-users] Updating compatible UHD and firmware
> Message-ID: <[email protected]>
> Content-Type: text/plain; charset=ISO-8859-1
>
>
>
> On 07/01/2012 03:35 PM, Farrukh Aziz wrote:
>> I have installed a new version of UHD, and now trying to load a compatible
>> firmware and fpga image on my N210. I initially tried doing this through
>> uhd_images_downloader.py but it gave this error:
>> ----------------------------------------------------------------------------------
>> Traceback (most recent call last):
>>? ? File "uhd_images_downloader.py", line 47, in <module>
>>? ? ? u = urllib2.urlopen(images_src)
>>? ? File "/usr/lib/python2.7/urllib2.py", line 126, in urlopen
>>? ? ? return _opener.open(url, data, timeout)
>>? ? File "/usr/lib/python2.7/urllib2.py", line 383, in open
>>? ? ? protocol = req.get_type()
>>? ? File "/usr/lib/python2.7/urllib2.py", line 245, in get_type
>>? ? ? raise ValueError, "unknown url type: %s" % self.__original
>> ValueError: unknown url type: @UHD_IMAGES_DOWNLOAD_SRC@
>
> @UHD_IMAGES_DOWNLOAD_SRC@ gets replaced by the build system. You cannot
> run it from the source tree. It must be the file installed to <install
> path>/share/uhd/utils
>
> Please, let me know if that isnt the case. ie, the installed script gave
> you that error.
>
>> ----------------------------------------------------------------------------------
>> I then manually downloaded several firmware/fpga images but after burning
>> them on the N210 I get the following error when I run uhd_usrp_probe:
>>
>> ----------------------------------------------------------------------------------
>> -- Opening a USRP2/N-Series device...
>> Error: RuntimeError:
>> Please update the firmware and FPGA images for your device.
>> See the application notes for USRP2/N-Series for instructions.
>> Expected protocol compatibility number [7 to 10], but got 11:
>> The firmware build is not compatible with the host code build.
>> ----------------------------------------------------------------------------------
>>
>
> This means the installed library is actually the one out of date. Is it
> possible you have either an old copy or multiple installs? like in /usr
> and /usr/local?
>
> Typically, compatible firmware and images come with the binary
> installers.
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki#Installation-Instructions
>
> Or, if you install from source, they can be downloaded like so:
> http://code.ettus.com/redmine/ettus/projects/uhd/wiki/UHD_Build#Firmware-and-FPGA-images
>
> Thanks,
> -Josh
>
>
>
> ------------------------------
>
> Message: 3
> Date: Sun, 1 Jul 2012 23:34:36 -0700
> From: "Armand Sperduti" <[email protected]>
> To: <[email protected]>
> Subject: [USRP-users] ExtIO / UHD compatibility
> Message-ID: <[email protected]>
> Content-Type: text/plain;? ? charset="us-ascii"
>
> Hello,
>
> I'm new to the USRP world.
>
> I have a NI-2920 with N210 FW 12.2 and FPGA 10.0 loaded on it. I've
> currently have uhd_003_004_002-177 unstable_Win64 loaded.
> Computer is an I7 running Windows 7 professional 64 bit.
> As a simple test of the system (and to have something to play with) I'm
> trying to get HDSDR 2.14 running with it.
> usd_usrp_probe runs fine, but I'm getting an ExtIO error: Expected protocol
> compatibility number [7 to 11], but got 12.
> I'm guessing this means the firmware in the SDR is too new for the current
> version of ExtIO.
>
> I've tried a number of different images for the radio (and read many pages
> of archives and web sites) but I haven't a solution.
> Has anyone been able to make this combination work?
>
> Thanks,
> Armand Sperduti
>
>
>
>
>
>
> ------------------------------
>
> Message: 4
> Date: Mon, 2 Jul 2012 07:09:27 -0400
> From: Dean Ferraro <[email protected]>
> To: Armand Sperduti <[email protected]>
> Cc: "<[email protected]>" <[email protected]>
> Subject: Re: [USRP-users] ExtIO / UHD compatibility
> Message-ID: <[email protected]>
> Content-Type: text/plain;? ? charset=us-ascii
>
>
> For me 32 bit and anything other than the 003.004.x code branch. The latest
> version of code I could get working was 32 bit 003.003.002. There is now a
> knowledge base article on using HDSDR. They mention having success with
> 003.004 code but I experienced otherwise.
>
> If I remember correctly any uhd.dll that I tried failed to work other than
> the version installed in the local folder with the ExtIO dll.
>
> -Dean
>
>
> On Jul 2, 2012, at 2:34 AM, "Armand Sperduti" <[email protected]> wrote:
>
>> Hello,
>>
>> I'm new to the USRP world.
>>
>> I have a NI-2920 with N210 FW 12.2 and FPGA 10.0 loaded on it. I've
>> currently have uhd_003_004_002-177 unstable_Win64 loaded.
>> Computer is an I7 running Windows 7 professional 64 bit.
>> As a simple test of the system (and to have something to play with) I'm
>> trying to get HDSDR 2.14 running with it.
>> usd_usrp_probe runs fine, but I'm getting an ExtIO error: Expected protocol
>> compatibility number [7 to 11], but got 12.
>> I'm guessing this means the firmware in the SDR is too new for the current
>> version of ExtIO.
>>
>> I've tried a number of different images for the radio (and read many pages
>> of archives and web sites) but I haven't a solution.
>> Has anyone been able to make this combination work?
>>
>> Thanks,
>> Armand Sperduti
>>
>>
>>
>>
>> _______________________________________________
>> USRP-users mailing list
>> [email protected]
>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
>
> ------------------------------
>
> Message: 5
> Date: Mon, 2 Jul 2012 13:18:11 +0200
> From: "Simon HB9DRV" <[email protected]>
> To: "'Dean Ferraro'" <[email protected]>,? ? "'Armand Sperduti'"
>? ???<[email protected]>
> Cc: [email protected]
> Subject: Re: [USRP-users] ExtIO / UHD compatibility
> Message-ID: <[email protected]>
> Content-Type: text/plain;? ? charset="US-ASCII"
>
> FWIW here's a screenshot of my code running a N210 with 5MHz bandwidth.
>
> http://www.dit-dit-dit.com/Blog/tabid/88/post/5-mhz/Default.aspx
>
> This software may be available late August.
>
> Simon Brown, HB9DRV
> http://dit-dit-dit.com
>
> You are standing at the end of a road before a small brick building. Around
> you is a forest.
> A small stream flows out of the building and down a gully. The sunspot count
> is 285.
>
>
> -----Original Message-----
> From: [email protected]
> [mailto:[email protected]] On Behalf Of Dean Ferraro
>
> For me 32 bit and anything other than the 003.004.x code branch. The latest
> version of code I could get working was 32 bit 003.003.002. There is now a
> knowledge base article on using HDSDR. They mention having success with
> 003.004 code but I experienced otherwise.
>
>
>
>
> ------------------------------
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> End of USRP-users Digest, Vol 23, Issue 2
> *****************************************
>
>
>
> _______________________________________________
> USRP-users mailing list
> [email protected]
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
------------------------------
Message: 3
Date: Wed, 04 Jul 2012 14:51:11 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Fwd: tunnel.py doesn't receive packages when
??? transmit and receive frequencies are different
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/04/2012 07:39 AM, Weixian Zhou wrote:
> Hi Josh,
> 1) Since the TX and RX of XCVR2450 shared a common LO, how to explain why
> my two PC both received packages for the following settings:
>? ? PC1: *./tunnel.py --tx-freq=2.51G --rx-freq=2.512G *
>? ? PC2: *./tunnel.py --tx-freq=2.512G --rx-freq=2.51G*
I think the better question is, does the application work better when
you take shared LO into consideration?
If you really want to investigate, it would be helpful to know what the
LO and RX and TX DSP frequencies are all tuned to after initialization.
> 2) About the tunning: Which file am I gonna start modifying? tune_request_t
> is a c++ file data structure, am I gonna modify c++ file or python script?
>
tune request is also usable in python. The USRP source and sink blocks
in GRC have some documentation/examples on this as well.
Pass a tune_request object into set_center_freq call for the USRP source
or sink object.
-josh
> ---------- Forwarded message ----------
> From: Josh Blum <[email protected]>
> Date: Fri, Jun 29, 2012 at 6:00 PM
> Subject: Re: [USRP-users] tunnel.py doesn't receive packages when transmit
> and receive frequencies are different
> To: [email protected]
>
>
>
>
> On 06/29/2012 02:58 PM, Li Sun wrote:
>> But can we set one daughter board's RX and TX at different frequency, e.g.
>> RX at 2.412GHz, TX at 2.432GHz ?
>>
>
> Yes, it is possible to have two different center frequencies for
> XCVR2450 RX and TX. The only requirement is that the RF frontend is
> tuned to the same frequency for TX and RX. However, the DSPs can be used
> to shift the signal digitally as long as you remain with the bandwidth
> of the daughterboard.
>
> So, to so this: You can use the tune_request_t to ask for a desired
> center frequency, but enforce a specific RF frequency.
> 1) create a tune request with the desired center frequency
> 2) set rf_freq to the desired LO frequency
> 3) set rf_freq_policy to MANUAL.
>
> Note: tunnel.py does not have a command line option for this level of
> control. So you will need to modify the gnuradio example to implement this.
>
> Some doxygen here for tune request:
> http://files.ettus.com/uhd_docs/doxygen/html/structuhd_1_1tune__request__t.html
>
> -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: 4
Date: Thu, 5 Jul 2012 08:42:15 +0300
From: Birhane Alemayoh <[email protected]>
To: John Malsbury <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Frequency Hopping
Message-ID:
??? <capf4mozeqe2zu_mrwhsmftnsaq5gwfnhhdaepe1sg+qny2h...@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"
Dear John,
I am using DBSRX2 draughtboards with N200, and I want to implement
frequency hopping. The dwell time for my application is is 4.615ms(GSM
system).
I could n't get the specification of the DBRX2 draughtboards that specifies
the tuning latency. is it possible to achieve this frequency hopping from
the host PC or without modifying the FPGA firmware?
Thank you!!
On Tue, Jul 3, 2012 at 7:34 PM, John Malsbury <[email protected]>wrote:
> **
> Peter,
>
> We have timed transactions in UHD now, so if you schedule the frequency
> changes and streaming commands enough in advance, you can hop
> deterministically and not have to worry about OS scheduling and Ethernet
> latency.? Lock time on the SBX is on the order of 200 us.
>
> Example of timed commands here:
> http://files.ettus.com/uhd_docs/manual/html/sync.html
>
> Also, not sure what daughterboard you're using, but most are limited to 40
> MHz BW, so doing this in the FPGA without PLL retuning may not be viable.
>
> -John
>
>
>
> On 07/03/2012 09:24 AM, Knee, Peter A wrote:
>
>? All,****
>
> ** **
>
> I am attempting to implement a frequency hopper using my USRP N210.? The
> total bandwidth of the signal to be transmitted is 50 MHz, but the total
> data bandwidth on each frequency is much, much less.? Thus, to avoid having
> to stream 50 MSPS, we?d like to generate the signal at baseband and use the
> FPGA to digitally convert the signal to the correct frequency.? The issue I
> believe is how quickly we need to change frequencies.? The dwell time for
> each frequency channel is on the order of 2 ms.? From what I?ve read, the
> tuning time for the SBX daughterboard is .6 ms, but this does not include
> other issues such as OS scheduling and Ethernet transit.? ****
>
> ** **
>
> I have consulted the archives on the timed commands feature to implement
> frequency hopping but if I?m understanding the tuning times correctly,
> retuning the DSP device doesn?t seem to be an option.? Is this correct?? If
> not, does anyone have any examples of how to schedule the pattern and
> implement using the UHD?****
>
> ** **
>
> Our other option is to modify the firmware to contain a frequency table so
> that when I packetize the data for Ethernet transit, I can extract the
> desired frequency and use the table to tune the FPGA.? This is obviously
> the least desirable option as I don?t have much experience with FPGA
> programming.? ****
>
> ** **
>
> If anyone has any other hints or tips they would be much appreciated.****
>
> ** **
>
> Thanks,****
>
> Peter Knee****
>
>
> _______________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120705/b3a946d2/attachment-0001.html>
------------------------------
_______________________________________________
USRP-users mailing list
[email protected]
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
End of USRP-users Digest, Vol 23, Issue 5
*****************************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120705/1f26e0e6/attachment-0001.html>
------------------------------
Message: 6
Date: Fri, 6 Jul 2012 15:57:49 +0200
From: Juan Manuel Parro <[email protected]>
To: [email protected]
Subject: [USRP-users] Timeout while streaming N210+DBSRX2 at 50Msps
Message-ID:
<cagd2_u-i4as2syw_ulavkmn71ifubqdsxhpu8_+lcrb9vva...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Dear All,
We are trying to store data with a decimation factor of 2 but,
depending on the duration of the capture, we succeed or not. If we
save 100ms of data the result is ok, but for larger durations (e.g.
10s), sometimes, we get the following error: Timeout while
streaming.
We are saving the samples in a RAM disk with enough memory for 2GB of
data. We also use a format of samples over the wire of 8bit/samp.
Does this error mean that we are losing samples in the reception?
Thanks in advance
--
Juan M Parro Jim?nez
Telf. +34 93 586 8009
Universitat Autonoma de Barcelona (UAB)
Spain
------------------------------
Message: 7
Date: Fri, 06 Jul 2012 08:15:59 -0700
From: Josh Blum <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Timeout while streaming N210+DBSRX2 at
50Msps
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1
On 07/06/2012 06:57 AM, Juan Manuel Parro wrote:
> Dear All,
>
> We are trying to store data with a decimation factor of 2 but,
> depending on the duration of the capture, we succeed or not. If we
> save 100ms of data the result is ok, but for larger durations (e.g.
> 10s), sometimes, we get the following error: Timeout while
> streaming.
I dont recognize the error. Is this gnuradio? a modified UHD example?
I think you are seeing the result of overflow:
http://files.ettus.com/uhd_docs/manual/html/general.html
You can increase the RX socket buffer to be very large. The kernel can
potentially buffer all the samples for you in RAM:
http://files.ettus.com/uhd_docs/manual/html/transport.html#resize-socket-buffers
-josh
> We are saving the samples in a RAM disk with enough memory for 2GB of
> data. We also use a format of samples over the wire of 8bit/samp.
> Does this error mean that we are losing samples in the reception?
>
> Thanks in advance
>
> --
> Juan M Parro Jim?nez
>
> Telf. +34 93 586 8009
> Universitat Autonoma de Barcelona (UAB)
> Spain
>
> _______________________________________________
> 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
End of USRP-users Digest, Vol 23, Issue 6
*****************************************
