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: Timeout while streaming N210+DBSRX2 at 50Msps
(Juan Manuel Parro)
2. Re: USRP-users Digest, Vol 23, Issue 5 (Ben Hilburn)
3. Re: Timeout while streaming N210+DBSRX2 at 50Msps (Ben Hilburn)
4. Digital filters inside the FPGA (MOISES NAVARRO)
----------------------------------------------------------------------
Message: 1
Date: Fri, 6 Jul 2012 18:41:23 +0200
From: Juan Manuel Parro <[email protected]>
To: [email protected]
Subject: Re: [USRP-users] Timeout while streaming N210+DBSRX2 at
50Msps
Message-ID:
<cagd2_u-5tosmo9qqi6c6wmwwba42jw+2gfsaw+hj+-vu_qe...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1
Juan M:
We are using the version of UHD 003.004.001 and the samples and
captured using the rx_samples_to_file.exe file under Windows 7. We
already changed the registry FastSendDatagramThreshold, as recommended
in:
http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx#appendix_e
The overflow issue was the first I thought but I don?t see the
classical 0's on the screen...
We will try with with a larger rx socket buffer and let you know the results
Josh said:
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
On Fri, Jul 6, 2012 at 3:57 PM, Juan Manuel Parro
<[email protected]> 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.
> 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
--
Juan Manuel Parro Jim?nez
------------------------------
Message: 2
Date: Fri, 6 Jul 2012 10:41:31 -0700
From: Ben Hilburn <[email protected]>
To: Farrukh Aziz <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] USRP-users Digest, Vol 23, Issue 5
Message-ID:
<caoevzkjaazlvaumanwk_zkjnrky9emnlkm8rmfok+qodupz...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Farrukh -
You must have the libraries that you need installed when you compile GNU
Radio. Otherwise, GNURadio will not build the components that depend on
those packages. You need to install the necessary packages, re-compile and
then re-install.
If the above paragraph confused you, then the easiest solution is probably
just uninstalling and re-installing once you have the
necessary prerequisites installed.
Cheers,
Ben
----------------------------
Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, LLC<http://www.ettus.com/>
| USRP <http://goo.gl/Ixjhh>
On Thu, Jul 5, 2012 at 2:52 PM, Farrukh Aziz <[email protected]> wrote:
> 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]<http://mc/[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]<http://mc/[email protected]>
>
> You can reach the person managing the list at
>
> [email protected]<http://mc/[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] <http://mc/[email protected]>>
> To:
> [email protected]<http://mc/[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]<http://mc/[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] <http://mc/[email protected]>>
> To:
> [email protected]<http://mc/[email protected]>
> Subject: Re: [USRP-users] USRP-users Digest, Vol 23, Issue 2
> Message-ID:
> <[email protected]<http://mc/[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]<http://mc/[email protected]><
> [email protected]<http://mc/[email protected]>>
> wrote:
> >
> > From:
> > [email protected]<http://mc/[email protected]><
> [email protected]<http://mc/[email protected]>
> >
> > Subject: USRP-users Digest, Vol 23, Issue 2
> > To:
> > [email protected]<http://mc/[email protected]>
> > Received: Monday, 2 July, 2012, 9:00 PM
> >
> > Send USRP-users mailing list submissions to
> >
> > [email protected]<http://mc/[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]<http://mc/[email protected]>
> >
> > You can reach the person managing the list at
> >
> > [email protected]<http://mc/[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]<http://mc/[email protected]>
> >
> > To: USRP user forum
> > <[email protected]<http://mc/[email protected]>
> >
> > Subject: [USRP-users] Updating compatible UHD and firmware
> > Message-ID:
> >
> > <[email protected]<http://mc/compose?to=1341182159.72962.yahoomailclas...@web161301.mail.bf1.yahoo.com>
> >
> > 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] <http://mc/[email protected]>>
> > To:
> > [email protected]<http://mc/[email protected]>
> > Subject: Re: [USRP-users] Updating compatible UHD and firmware
> > Message-ID:
> > <[email protected]<http://mc/[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]<http://mc/[email protected]>
> >
> > To:
> > <[email protected]<http://mc/[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]<http://mc/[email protected]>
> >
> > To: Armand Sperduti
> > <[email protected]<http://mc/[email protected]>
> >
> > Cc:
> > "<[email protected]<http://mc/[email protected]>>"
> <[email protected]<http://mc/[email protected]>
> >
> > Subject: Re: [USRP-users] ExtIO / UHD compatibility
> > Message-ID:
> > <[email protected]<http://mc/[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]<http://mc/[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://mc/[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]<http://mc/[email protected]>
> >
> > To: "'Dean Ferraro'"
> > <[email protected]<http://mc/[email protected]>>,
> "'Armand Sperduti'"
> > <[email protected] <http://mc/[email protected]>>
> > Cc:
> > [email protected]<http://mc/[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]<http://mc/[email protected]>
> > [mailto:[email protected]<http://mc/[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://mc/[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://mc/[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] <http://mc/[email protected]>>
> To:
> [email protected]<http://mc/[email protected]>
> Subject: Re: [USRP-users] Fwd: tunnel.py doesn't receive packages when
> transmit and receive frequencies are different
> Message-ID:
> <[email protected]<http://mc/[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] <http://mc/[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]<http://mc/[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://mc/[email protected]>
> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]<http://mc/[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]<http://mc/[email protected]>
> >
> To: John Malsbury
> <[email protected]<http://mc/[email protected]>
> >
> Cc:
> [email protected]<http://mc/[email protected]>
> Subject: Re: [USRP-users] Frequency Hopping
> Message-ID:
>
> <capf4mozeqe2zu_mrwhsmftnsaq5gwfnhhdaepe1sg+qny2h...@mail.gmail.com<http://mc/[email protected]>
> >
> 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]<http://mc/[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://mc/[email protected]>
> ://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
> >
> >
> >
> > _______________________________________________
> > USRP-users mailing list
> > [email protected]<http://mc/[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://mc/[email protected]>
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
>
> End of USRP-users Digest, Vol 23, Issue 5
> *****************************************
>
>
> _______________________________________________
> 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/20120706/54b05ba2/attachment-0001.html>
------------------------------
Message: 3
Date: Fri, 6 Jul 2012 10:42:52 -0700
From: Ben Hilburn <[email protected]>
To: Juan Manuel Parro <[email protected]>
Cc: [email protected]
Subject: Re: [USRP-users] Timeout while streaming N210+DBSRX2 at
50Msps
Message-ID:
<caoevzkj-eqvs0f+-6mba7ksqiyge-bn-fzqv_x4hma0k2gm...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Juan -
It's possible for overflows to occur without the infamous 'O's appearing on
the screen. If you are having strange issues like the ones you are
describing, generally over/under flows are a good first bet.
Cheers,
Ben
----------------------------
Ben Hilburn <http://goo.gl/5DdZ3> @ Ettus Research, LLC<http://www.ettus.com/>
| USRP <http://goo.gl/Ixjhh>
On Fri, Jul 6, 2012 at 9:41 AM, Juan Manuel Parro <[email protected]>wrote:
> Juan M:
> We are using the version of UHD 003.004.001 and the samples and
> captured using the rx_samples_to_file.exe file under Windows 7. We
> already changed the registry FastSendDatagramThreshold, as recommended
> in:
> http://www.microsoft.com/windows/windowsmedia/howto/articles/optimize_web.aspx#appendix_e
>
> The overflow issue was the first I thought but I don?t see the
> classical 0's on the screen...
> We will try with with a larger rx socket buffer and let you know the
> results
>
> Josh said:
> 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
>
> On Fri, Jul 6, 2012 at 3:57 PM, Juan Manuel Parro
> <[email protected]> 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.
> > 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
>
>
>
> --
> Juan Manuel Parro Jim?nez
>
> _______________________________________________
> 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/20120706/d92717ab/attachment-0001.html>
------------------------------
Message: 4
Date: Fri, 6 Jul 2012 20:12:32 +0200
From: MOISES NAVARRO <[email protected]>
To: [email protected]
Subject: [USRP-users] Digital filters inside the FPGA
Message-ID:
<cafmaxz_oue0aggcahkjbj0n59elfpn-7kr0bpozth8bsmla...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"
Dear all,
We are using a USRP N210 with UHD. We are collecting data with a decimated
factor equal to 2, so the sampling frequency is 50Mps. The results are
quite good!
But now, we dont want any digital filtering. I Think that, in the FPGA the
signals are filtered with a half band filter, isn't it? (@ 50Msps)
We want to keep the the same sampling frequency, but with any digital
filtering.
Is that possible? Can we made a "small modification" in the FPGA code in
order to avoid the digital filters? or any idea?
I know that, if we reduce the sampling frequency we could have aliasing...
We can manage this effect without any digital filter :)
Many thanks in advance for your help
Mois?s Navarro
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.ettus.com/pipermail/usrp-users_lists.ettus.com/attachments/20120706/eb59f22a/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 7
*****************************************
