Re: [Discuss-gnuradio] GRC selector audio sink error
On Thu, Jan 6, 2011 at 6:51 AM, Phelps Williams wrote: > I put together a simple example of a selector which is controlled by a > variable chooser to toggle between two different frequencies. These two > frequencies are dumped to an audio sink. This example works fine (and I > hear the default tone) until the selector input index is changed at which > point the following error is observed: > audio_alsa_sink[hw:0,0]: snd_pcm_hw_params failed: File descriptor in bad > state > terminate called after throwing an instance of 'std::runtime_error' > what(): check topology failed on audio_alsa_sink(1) using ninputs=1, > noutputs=0 > Does anybody have an idea what is going on here? Hi Phelps, This should be fixed in the git repository since Dec 2010. For the longer answer with explanation, patch, etc. see the mailing list from nov/dec last year. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Highest Datarates with GNURadio
On Tue, Jan 4, 2011 at 6:48 PM, wrote: > > Hi All, > > I started working with GNURadio a few months ago as a platform for use with > a Visual Light Communication front end. I've had some good success with the > basic benchmark testing and implementation of a few basic tests with GRC, > but I'm curious as to what datarates have been achieved within the GNURadio > community. > > As of now, I've been able to reach rates of 4Mb/s with GMSK and BPSK > modulation and I'm pretty sure I've reached the limits of what my PC's can > handle in real time (I seem to be getting errors occurring mostly from > system overruns). I haven't gone into testing with the OFDM blocks or > higher order modulation schemes, but I wanted to see what type of rates I > should expect. That sounds about right. The data rates are limited by the bandwidth you can pull in from the front end (USRP in this case) and the speed of your computer. So your computer's hardware plays a big role if you're looking for comparisons. As a note, as we start to integrate VOLK functions into GNU Radio blocks, we should see an increase in performance and therefore an increase in the possible datarates. Tom > I'm using the system mostly as a testbed for the time being, so my thought > is to do the signal processing offline (to / from a file) and have the > transmission simply sending and receiving from a file. If anyone has > suggestions or examples of how to do this it would be greatly appreciated. > > > Thanks in advance for any thoughts, > > Michael Rahaim > Graduate Research Assistant > Smart Lighting Engineering Research Center > Boston University > mrah...@bu.edu > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] QA tests for FIR filters
On Wed, Jan 5, 2011 at 11:25 AM, Philip Balister wrote: > I'm adding a armv7 NEON implementation to gnuradio. I've got the basic code > in place and am testing the qa code before starting the asm work. I'm seeing > failures from the test_filter program, but it is not clear exactly what the > problem is. Is there a way to have the test program let me know what test > fails? I displayed some intermediate results and didn't see anything super > obvious. > > Here is what I see: > > r...@usrp-e1xx:~/gnuradio# ./gnuradio-core/src/tests/test_filter > . [generic] [armv7_a] > . [generic] [armv7_a] > . [generic] > . [generic] > . [generic] > . [generic] [armv7_a]F.>>> gr_fir_fff: using armv7_a > .>>> gr_fir_ccf: using armv7_a > ... > > r...@usrp-e1xx:~/gnuradio# > > Philip When the tests are run, a directory called .unittests/ is created that contains an XML output file with the information about which tests passed and which failed. If you've run tests_filter by hand, the file you're looking for is .unittests/gnuradio_core_filter.xml. By default, when you run "make check," the test_all program is run, which creates .unittests/gnuradio_core_all.xml. These unit test output files are created if you're working on master or next. Of course, it'll help if you do a pull from whichever branch you're on (next, I'm assuming) because I just uploaded a fix for a copy-and-paste error in the test_filter code that produced the wrong file name :) Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Stow and make install (DESTDIR)
Hello!
I tried to install GNU Radio with GNU Stow. I'd like to have several
versions of GNU Radio that I can switch betwenn without rebuild. Stow
seems to help much in that scenario. And it does a clean uninstall even
if the build tree has changed since build.
How install does _not_ work:
The Stow manual recommends[1]:
6.1.2 Other FSF software
The Free Software Foundation, the organization behind the GNU project,
has been unifying the build procedure for its tools for some time.
Thanks to its tools `autoconf' and `automake', most packages now respond
well to these simple steps, with no other intervention necessary:
./configure options
make
make install prefix=/usr/local/stow/package
Hopefully, these tools can evolve to be aware of Stow-managed packages,
such that providing an option to `configure' can allow `make' and `make
install' steps to work correctly without needing to "fool" the build
process.
Unfortnately libtool does not like this way of installing:
$ make install prefix=/usr/local/stow/package
[...]
test -z "/usr/local/stow/packag/lib" || /bin/mkdir -p
"/usr/local/stow/packag/lib"
/bin/bash ../../../libtool --mode=install /usr/bin/install -c
libgnuradio-core.la '/usr/local/stow/packag/lib'
libtool: install: error: cannot install `libgnuradio-core.la' to a
directory not ending in /usr/local/lib
[...]
How install _does_ work:
You rather need to install with DESTDIR[2]:
# full version
STOWDIR=/usr/local/stow
PACKAGE=gnuradio
VERSION=3.3git
PREFIX=/usr/local
./configure --prefix=${PREFIX}
make
sudo make install DESTDIR=${STOWDIR}/${PACKAGE}-${VERSION}
stow -d ${STOWDIR} -t / ${PACKAGE}-${VERSION}
Note: make install with DESTDIR installs everything with DESTDIR
prepended. If PREFIX=/usr/local/, and DESTDIR=/usr/local/stow/package,
files will end up under /usr/local/stow/package/usr/local/. Stow just
moves files out of DESTDIR to the target directory. This is why the
target has to be /-
If you install to the standard paths, this can be simplified to
# simple version
PACKAGE=gnuradio
VERSION=3.3
./configure
make
sudo make install DESTDIR=/usr/local/stow/${PACKAGE}-${VERSION}
sudo stow -d /usr/local -t / ${PACKAGE}-${VERSION}
If you get conflicts you probably have an old package version installed.
You need to uninstall first.
Uninstall:
==
List your stow packages:
STOWDIR=/usr/local/stow
ls $STOWDIR
The name of the directory is the name of the package.
Unstow the currently installed version:
sudo stow -d $STOWDIR -t/ -D package
[1] http://www.gnu.org/software/stow/manual.html#SEC8
[2] http://www.gnu.org/prep/standards/standards.html#DESTDIR
I hope this information can help others manage their GNU Radio
installations.
Regards
Patrick
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Stow and make install (DESTDIR)
On Thu, Jan 6, 2011 at 1:51 PM, Patrick Strasser
wrote:
> Hello!
>
> I tried to install GNU Radio with GNU Stow. I'd like to have several
> versions of GNU Radio that I can switch betwenn without rebuild. Stow
> seems to help much in that scenario. And it does a clean uninstall even
> if the build tree has changed since build.
>
> How install does _not_ work:
>
>
> The Stow manual recommends[1]:
>
> 6.1.2 Other FSF software
>
> The Free Software Foundation, the organization behind the GNU project,
> has been unifying the build procedure for its tools for some time.
> Thanks to its tools `autoconf' and `automake', most packages now respond
> well to these simple steps, with no other intervention necessary:
>
> ./configure options
> make
> make install prefix=/usr/local/stow/package
>
> Hopefully, these tools can evolve to be aware of Stow-managed packages,
> such that providing an option to `configure' can allow `make' and `make
> install' steps to work correctly without needing to "fool" the build
> process.
>
>
> Unfortnately libtool does not like this way of installing:
> $ make install prefix=/usr/local/stow/package
> [...]
> test -z "/usr/local/stow/packag/lib" || /bin/mkdir -p
> "/usr/local/stow/packag/lib"
> /bin/bash ../../../libtool --mode=install /usr/bin/install -c
> libgnuradio-core.la '/usr/local/stow/packag/lib'
> libtool: install: error: cannot install `libgnuradio-core.la' to a
> directory not ending in /usr/local/lib
> [...]
>
> How install _does_ work:
>
>
> You rather need to install with DESTDIR[2]:
>
> # full version
> STOWDIR=/usr/local/stow
> PACKAGE=gnuradio
> VERSION=3.3git
> PREFIX=/usr/local
> ./configure --prefix=${PREFIX}
> make
> sudo make install DESTDIR=${STOWDIR}/${PACKAGE}-${VERSION}
> stow -d ${STOWDIR} -t / ${PACKAGE}-${VERSION}
>
> Note: make install with DESTDIR installs everything with DESTDIR
> prepended. If PREFIX=/usr/local/, and DESTDIR=/usr/local/stow/package,
> files will end up under /usr/local/stow/package/usr/local/. Stow just
> moves files out of DESTDIR to the target directory. This is why the
> target has to be /-
>
> If you install to the standard paths, this can be simplified to
>
> # simple version
> PACKAGE=gnuradio
> VERSION=3.3
> ./configure
> make
> sudo make install DESTDIR=/usr/local/stow/${PACKAGE}-${VERSION}
> sudo stow -d /usr/local -t / ${PACKAGE}-${VERSION}
>
> If you get conflicts you probably have an old package version installed.
> You need to uninstall first.
>
> Uninstall:
> ==
>
> List your stow packages:
>
> STOWDIR=/usr/local/stow
> ls $STOWDIR
>
> The name of the directory is the name of the package.
>
> Unstow the currently installed version:
>
> sudo stow -d $STOWDIR -t/ -D package
>
> [1] http://www.gnu.org/software/stow/manual.html#SEC8
> [2] http://www.gnu.org/prep/standards/standards.html#DESTDIR
>
>
> I hope this information can help others manage their GNU Radio
> installations.
>
> Regards
>
> Patrick
Patrick,
Thanks for the info!
Tom
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Stow and make install (DESTDIR)
Hi Patrick,
I manage multiple versions of GNU Radio manually by simply installing
each under its own prefix and having a symbolic link "current" point
to whichever version I want to use. It is really easy:
1. Update local repository using "git pull"
2. Get unique version for the snapshot "git describe --abbrev=8"
This gives something like v3.3.1git-817-g66768f6e
3. Build and install GNU Radio using
--prefix=/opt/gnuradio/v3.3.1git-817-g66768f6e
4. In /opt/gnuradio create a symlink pointing to the new version "ln
-s v3.3.1git-817-g66768f6e current"
I have my environment set up to include the stuff in /opt/gnuradio/current:
export PATH=$PATH:/opt/gnuradio/current/bin
export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio/current/lib
export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio/current/lib/pkgconfig
export PYTHONPATH=$PYTHONPATH:/opt/gnuradio/current/lib/python2.6/site-packages
This way I can switch between versions by moving the symlink.
Removing an old version is done by deleting the whole folder
/opt/gnuradio/XYZ and does not rely on "make uninstall"
One could do the same with UHD. Until now I have simply installed it
in the same folder as GNU Radio.
This method also works with other software, even those that come as
binary only as long as they can be installed under custom prefix.
Alex
On Thu, Jan 6, 2011 at 7:51 PM, Patrick Strasser
wrote:
> Hello!
>
> I tried to install GNU Radio with GNU Stow. I'd like to have several
> versions of GNU Radio that I can switch betwenn without rebuild. Stow
> seems to help much in that scenario. And it does a clean uninstall even
> if the build tree has changed since build.
>
> How install does _not_ work:
>
>
> The Stow manual recommends[1]:
>
> 6.1.2 Other FSF software
>
> The Free Software Foundation, the organization behind the GNU project,
> has been unifying the build procedure for its tools for some time.
> Thanks to its tools `autoconf' and `automake', most packages now respond
> well to these simple steps, with no other intervention necessary:
>
> ./configure options
> make
> make install prefix=/usr/local/stow/package
>
> Hopefully, these tools can evolve to be aware of Stow-managed packages,
> such that providing an option to `configure' can allow `make' and `make
> install' steps to work correctly without needing to "fool" the build
> process.
>
>
> Unfortnately libtool does not like this way of installing:
> $ make install prefix=/usr/local/stow/package
> [...]
> test -z "/usr/local/stow/packag/lib" || /bin/mkdir -p
> "/usr/local/stow/packag/lib"
> /bin/bash ../../../libtool --mode=install /usr/bin/install -c
> libgnuradio-core.la '/usr/local/stow/packag/lib'
> libtool: install: error: cannot install `libgnuradio-core.la' to a
> directory not ending in /usr/local/lib
> [...]
>
> How install _does_ work:
>
>
> You rather need to install with DESTDIR[2]:
>
> # full version
> STOWDIR=/usr/local/stow
> PACKAGE=gnuradio
> VERSION=3.3git
> PREFIX=/usr/local
> ./configure --prefix=${PREFIX}
> make
> sudo make install DESTDIR=${STOWDIR}/${PACKAGE}-${VERSION}
> stow -d ${STOWDIR} -t / ${PACKAGE}-${VERSION}
>
> Note: make install with DESTDIR installs everything with DESTDIR
> prepended. If PREFIX=/usr/local/, and DESTDIR=/usr/local/stow/package,
> files will end up under /usr/local/stow/package/usr/local/. Stow just
> moves files out of DESTDIR to the target directory. This is why the
> target has to be /-
>
> If you install to the standard paths, this can be simplified to
>
> # simple version
> PACKAGE=gnuradio
> VERSION=3.3
> ./configure
> make
> sudo make install DESTDIR=/usr/local/stow/${PACKAGE}-${VERSION}
> sudo stow -d /usr/local -t / ${PACKAGE}-${VERSION}
>
> If you get conflicts you probably have an old package version installed.
> You need to uninstall first.
>
> Uninstall:
> ==
>
> List your stow packages:
>
> STOWDIR=/usr/local/stow
> ls $STOWDIR
>
> The name of the directory is the name of the package.
>
> Unstow the currently installed version:
>
> sudo stow -d $STOWDIR -t/ -D package
>
> [1] http://www.gnu.org/software/stow/manual.html#SEC8
> [2] http://www.gnu.org/prep/standards/standards.html#DESTDIR
>
>
> I hope this information can help others manage their GNU Radio
> installations.
>
> Regards
>
> Patrick
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: GNU Stow and make install (DESTDIR)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 schrieb Alexandru Csete on 2011-01-06 21:09: > Hi Patrick, > > I manage multiple versions of GNU Radio manually by simply installing > each under its own prefix and having a symbolic link "current" point > to whichever version I want to use. It is really easy: > > 1. Update local repository using "git pull" > 2. Get unique version for the snapshot "git describe --abbrev=8" > This gives something like v3.3.1git-817-g66768f6e That was the part I missed until now. Thanks! > 3. Build and install GNU Radio using > --prefix=/opt/gnuradio/v3.3.1git-817-g66768f6e > 4. In /opt/gnuradio create a symlink pointing to the new version "ln > -s v3.3.1git-817-g66768f6e current" > > I have my environment set up to include the stuff in /opt/gnuradio/current: > > export PATH=$PATH:/opt/gnuradio/current/bin > export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:/opt/gnuradio/current/lib > export PKG_CONFIG_PATH=$PKG_CONFIG_PATH:/opt/gnuradio/current/lib/pkgconfig > export > PYTHONPATH=$PYTHONPATH:/opt/gnuradio/current/lib/python2.6/site-packages I could not get all the paths right, and I like things in /opt less than in /usr/local as you have to care yourself to get it known to the rest of the system. But in the end its a matter of taste. Regards Patrick -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.10 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk0mKYsACgkQ/G6gHctkMa8VOgCcC7KCkmqLWWsatJzeVH3x0ODc mTEAoKLRcTEiTmBIpLNnLQdSe7C/B5JN =WepS -END PGP SIGNATURE- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to make 8 bits sample works
On Thu, 2011-01-06 at 15:08 +0800, James Jordan wrote: > Hi all, I want to let my application work on 8 bit sample mode. > I have test and checked that 8 bit resolution sample can meet my > application's accurate need. > I test my application that run it on 16 bit sample and shift the read > data right 8 bits then shift left 8 bits. My application works fine. > But when I let my application work on 8 bit sample mode, my > application can not work, I wonder the logic that usrp hardware > produce 8 bit sampled data. What does the received 8-bit data look like? How is the received 8-bit data different from the 8-bit data you have generated from 16-bit data? --n > > Thanks! > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Question about the HBF in the DDC
The passband of the HBF scales with your data rate. The bandwidth is about 70% of the data rate. Matt On 01/05/2011 08:03 AM, peng senl wrote: Hello, I have another question about the bandwidth of the HBF. For a wide band incoming signal, let's say 20MHz, can we still use this HBF to filter for this incoming signal, as the pass band of the HBF is only 0.6MHz. --- On Tue, 1/4/11, Tom Rondeau wrote: From: Tom Rondeau Subject: Re: [Discuss-gnuradio] Question about the HBF in the DDC To: "peng senl" Cc: discuss-gnuradio@gnu.org Date: Tuesday, January 4, 2011, 8:31 PM On Tue, Jan 4, 2011 at 1:13 PM, peng senl wrote: Hello, I get a question about the half band filter in the DDC. I found that the LO (local oscillator) in my daughter board is set at 0.2MHz less than the carrier center frequency, which means that the IF of the output signal is center at 0.2 MHz. I am assuming the NCO in the FPGA is generating a sinusoid at 0.2MHz to mix the IF signal to base band. Then we would get a ase band signal and a high order frequency part at 0.4MHz. But the half band filter after the CIC filter has a pass band of 0.6MHz from the reference materials what I have read. This means that the high order part won't be filtered by the HBF. It's generating a _complex_ sinusoid. It's not modulating the signal like an analog LO but performing complex multiplication. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: GNU Stow and make install (DESTDIR)
On Thu, Jan 6, 2011 at 9:44 PM, Patrick Strasser wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > schrieb Alexandru Csete on 2011-01-06 21:09: >> Hi Patrick, >> >> I manage multiple versions of GNU Radio manually by simply installing >> each under its own prefix and having a symbolic link "current" point >> to whichever version I want to use. It is really easy: >> >> 1. Update local repository using "git pull" >> 2. Get unique version for the snapshot "git describe --abbrev=8" >> This gives something like v3.3.1git-817-g66768f6e > > That was the part I missed until now. Thanks! I learned that trick from the GNU Radio build scripts. The version string is also displayed in the beginning of the configure step but it scrolls away very quickly. Alex ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP1 Clock drift
Hi Guys, I ran Kalibrate against my pair of USRP1's using GSM900 towers (around 940MHz) and found my first unit to me 5kHz off and the second was 13kHz off. Is this within limits for the built in oscillator? I have been using them to transmit P25 frames around 435Mhz and found that my commercial P25 radios will not decode anything coming from the second USRP. The first USRP works OK. I have swapped around all daughterboards between both USRPs and the only common factor is the second USRP motherboard so I am sure its due to the clock in that unit. Perhaps clocktamer or a secondhand GPSDO is needed for my Tx applications. Cheers, Matt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Clock drift
On Fri, 2011-01-07 at 10:01 +1100, Matt Robert wrote: > Hi Guys, > > I ran Kalibrate against my pair of USRP1's using GSM900 towers (around > 940MHz) and found my first unit to me 5kHz off and the second was 13kHz off. > > Is this within limits for the built in oscillator? I have been using > them to transmit P25 frames around 435Mhz and found that my commercial > P25 radios will not decode anything coming from the second USRP. The > first USRP works OK. I have swapped around all daughterboards between > both USRPs and the only common factor is the second USRP motherboard so > I am sure its due to the clock in that unit. > This is within spec. It doesn't tend to drift that much so if you characterize how far it's off it'll stay reasonably constant (to a few ppm) unless temperature changes drastically. > Perhaps clocktamer or a secondhand GPSDO is needed for my Tx applications. You will need an oscillator with a ~64MHz output to run the USRP1. There is no 10MHz reference input on USRP1. I used a GPSDO and a homebrew PLL based around an Si570 VCXO to keep mine synchronized, but it wasn't a quick hack. Unfortunately there don't seem to be many 64MHz TCXOs in a reasonable form factor out there. --n > > Cheers, > Matt > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Channel estimate block
2011/1/5 intermilan : > > > > hi all: > Is there any block about the channel estimate? If there is a channel > estimate block ,please tell me the exactly position(under which folder). > Thank you ! Not really. You might find something useful out of the cma_equalizer_cc (in filter) or the lms_dfe_cc (in general). Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USRP1 Clock drift
Hi Matt; Is it possible to include in your application a monitor which would receive a transmission which you could use as a reference in order to correct your transmitter's local oscillator? It seems to me that this would be a better solution to your problem than modifying the hardware in order to inject an external clock. On Fri, 7 Jan 2011, Matt Robert wrote: > Hi Guys, > > I ran Kalibrate against my pair of USRP1's using GSM900 towers (around > 940MHz) and found my first unit to me 5kHz off and the second was 13kHz off. > > Is this within limits for the built in oscillator? I have been using > them to transmit P25 frames around 435Mhz and found that my commercial > P25 radios will not decode anything coming from the second USRP. The > first USRP works OK. I have swapped around all daughterboards between > both USRPs and the only common factor is the second USRP motherboard so > I am sure its due to the clock in that unit. > > Perhaps clocktamer or a secondhand GPSDO is needed for my Tx applications. > > Cheers, > Matt > Cheers -- Peter F Bradshaw: http://www.exadios.com (public keys avaliable there). Personal site: http://personal.exadios.com "I love truth, and the way the government still uses it occasionally to keep us guessing." - Sam Kekovich. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] how to make 8 bits sample works
I have fix the problem which is my application bug. On Fri, Jan 7, 2011 at 4:55 AM, Nick Foster wrote: > On Thu, 2011-01-06 at 15:08 +0800, James Jordan wrote: > > Hi all, I want to let my application work on 8 bit sample mode. > > I have test and checked that 8 bit resolution sample can meet my > > application's accurate need. > > I test my application that run it on 16 bit sample and shift the read > > data right 8 bits then shift left 8 bits. My application works fine. > > But when I let my application work on 8 bit sample mode, my > > application can not work, I wonder the logic that usrp hardware > > produce 8 bit sampled data. > > What does the received 8-bit data look like? How is the received 8-bit > data different from the 8-bit data you have generated from 16-bit data? > > --n > > > > > Thanks! > > ___ > > Discuss-gnuradio mailing list > > Discuss-gnuradio@gnu.org > > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
