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
*****************************************
