Re: [Discuss-gnuradio] Booting Zynq/Gnuradio
HI Ivan, > I've been working through the wiki as well. In my setup I had to also > replace the FSBL with the default Xilinx one to get the system to boot > (ZC702 eval board). If you stop u-boot from autobooting you can go in and > change the environment variables (printenv, setenv) and when you have > everything setup you can 'saveenv' and the state will be saved to flash. > > Now the system boots smoothly. Since I had some issues with the booting > process I'm not sure if the system.bit file is loaded properly. To make > sure, I load the bit file using /dev/xdevcfg (have to mknod, convert .bit > to .bin, etc.). Then I insmod the user_peripheral.ko (had to copy it into > /lib/modules/ for insmod to find it). I was wondering how one would load a bit file after booting, so this definitely a good tip. I will try that out once I get a little further along. Meanwhile I'll figure out the right boot environment variables for my Zedboard next. Thanks, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Booting Zynq/Gnuradio
> On 08/20/2013 04:32 AM, Jan Schiefer wrote:
>>
>> Now, many many CPU cycles later, I am at the point of booting it. Well,
>> almost. What happens is that Das U-Boot is looking for an initial
>> ramdisk:
>>
>> U-Boot 2013.01 (Aug 17 2013 - 06:32:40)
>>
>> DRAM: 512 MiB
>> WARNING: Caches not enabled
>> MMC: zynq_sdhci: 0
>> SF: Detected S25FL256S with page size 64 KiB, total 32 MiB
>> In:serial
>> Out: serial
>> Err: serial
>> Net: Gem.e000b000
>> Hit any key to stop autoboot: 0
>> Copying Linux from SD to RAM...
>> Device: zynq_sdhci
>> Manufacturer ID: 1b
>> OEM: 534d
>> Name: 0
>> Tran Speed: 5000
>> Rd Block Len: 512
>> SD version 2.0
>> High Capacity: Yes
>> Capacity: 3.7 GiB
>> Bus Width: 4-bit
>> reading uImage
>> 2855496 bytes read in 415 ms (6.6 MiB/s)
>> reading devicetree.dtb
>> 21734 bytes read in 19 ms (1.1 MiB/s)
>> reading uramdisk.image.gz
>> ** Unable to read file uramdisk.image.gz **
>> zynq-uboot>
>>
>> Why? Because the environment says so:
>> sdboot=echo Copying Linux from SD to RAM... && mmcinfo && fatload mmc 0
>> 0x300 ${kernel_image} && fatload mmc 0 0x2A0 ${devicetree_image}
>> && fatload mmc 0 0x200 ${ramdisk_image} && bootm 0x300 -
>> 0x2A0
>>
>> That doesn't seem quite right, I am assuming this should use the rootfs
>> in
>> the rootfs partition, shouldn't it?
>>
>> So my question is, am I missing something, or is the zynq Wiki page
>> missing a little section on how to set up the U-Boot environment
>> variables
>> in the flash?
>
> I assume you figured out you need to modify the bootm command so it does
> not look for the ramdisk? The default config from Xilinx is somewhat
> obsessed with booting from a ramdisk :) I'm looking into some ways of
> modifying the bootloader behavior without rebuilding it all the time.
>
> What zynq hardware are you using?
>
> Philip
>
This is on a Zedboard. I did figure out that I need to change mboot
parameters, but I haven't studied the whole setup enough to know what all
else needs to change. So I thought I'd ask :-).
When you write about modifications, are you referring to more advanced
ways to load bitfiles rather than sticking them in the boot image?
Regards,
Jan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Booting Zynq/Gnuradio
Hi everybody,
I was thrilled to find Jonathon's writeup, and I have been trying to get
the same setup working here. Some things I learned along the way:
- OpenEmbedded is very very cool!
- bitbake doesn't work on eCryptfs file systems, as its path length
restrictions are not acceptable. One needs to build somewhere else (or at
least put the TMP and SSTATE-CACHE directories elsewhere).
- On my system (Ubuntu 12.04 64-bit), there was no binary called gmake,
which caused problems when generating the bit file with the Xilinx tool
chain. Solved this by linking /usr/bin/make to /usr/bin/gmake
Now, many many CPU cycles later, I am at the point of booting it. Well,
almost. What happens is that Das U-Boot is looking for an initial ramdisk:
U-Boot 2013.01 (Aug 17 2013 - 06:32:40)
DRAM: 512 MiB
WARNING: Caches not enabled
MMC: zynq_sdhci: 0
SF: Detected S25FL256S with page size 64 KiB, total 32 MiB
In:serial
Out: serial
Err: serial
Net: Gem.e000b000
Hit any key to stop autoboot: 0
Copying Linux from SD to RAM...
Device: zynq_sdhci
Manufacturer ID: 1b
OEM: 534d
Name: 0
Tran Speed: 5000
Rd Block Len: 512
SD version 2.0
High Capacity: Yes
Capacity: 3.7 GiB
Bus Width: 4-bit
reading uImage
2855496 bytes read in 415 ms (6.6 MiB/s)
reading devicetree.dtb
21734 bytes read in 19 ms (1.1 MiB/s)
reading uramdisk.image.gz
** Unable to read file uramdisk.image.gz **
zynq-uboot>
Why? Because the environment says so:
sdboot=echo Copying Linux from SD to RAM... && mmcinfo && fatload mmc 0
0x300 ${kernel_image} && fatload mmc 0 0x2A0 ${devicetree_image}
&& fatload mmc 0 0x200 ${ramdisk_image} && bootm 0x300 - 0x2A0
That doesn't seem quite right, I am assuming this should use the rootfs in
the rootfs partition, shouldn't it?
So my question is, am I missing something, or is the zynq Wiki page
missing a little section on how to set up the U-Boot environment variables
in the flash?
Again, thanks for the great work, this is exciting stuff!
Regards,
Jan, ac7td
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Building gnuradio on cygwin - wxPython issue
On 7/3/2010 6:13 AM, Don Ward wrote: Jan Schiefer wrote: I should know better, but I am nonetheless trying to build gnuradio on Windows XP/cygwin. I did follow the instructions on the wiki (including picking the exact versions), but I am getting stuck on building wxPython. When I try to do the python setup.py install WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0 BUILD_GIZMOS=0 UNICODE=0 step, I get the following error: function Traceback (most recent call last): File "setup.py", line 1034, in **other_kw File "/usr/lib/python2.6/distutils/core.py", line 152, in setup dist.run_commands() File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands self.run_command(cmd) ... File "/usr/lib/python2.6/distutils/ccompiler.py", line 769, in link_shared_object extra_preargs, extra_postargs, build_temp, target_lang) File "/usr/lib/python2.6/distutils/cygwinccompiler.py", line 189, in link libraries.extend(self.dll_libraries) TypeError: 'NoneType' object is not iterable The offending line 189 is a rather nondescript libraries.extend(self.dll_libraries) Has anybody who is more pythonic than me seen this before? My cygwin version is current as of last Wednesday, and the python version is 2.6.5 (no other python installations on the machine). My latest test install of Cygwin and GNU Radio (May 2010) used python 2.5.5. You could try going back to that version. I will try to look at it over the weekend and see if I can make it work with 2.6.5. While I try to keep GNU Radio running under Cygwin, every update to a Cygwin package or third-party library (such as wxPython) carries a significant risk of breakage. For "production" use of GNU Radio on Windows, I prefer to use MinGW and MSYS. The initial setup takes a little longer, but once you have a working system there is seldom a need to update anything but GNU Radio. -- Don W. Thanks Don, this is good advice, I have been hit by cygwin update-related breakages for other applications as well. I will try the MinGW/MSYS route instead and report back. Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Building gnuradio on cygwin - wxPython issue
Hi,
I should know better, but I am nonetheless trying to build gnuradio on
Windows XP/cygwin. I did follow the instructions on the wiki (including
picking the exact versions), but I am getting stuck on building wxPython.
When I try to do the
python setup.py install WXPORT=msw COMPILER=cygwin BUILD_GLCANVAS=0
BUILD_GIZMOS=0 UNICODE=0
step, I get the following error:
function
Traceback (most recent call last):
File "setup.py", line 1034, in
**other_kw
File "/usr/lib/python2.6/distutils/core.py", line 152, in setup
dist.run_commands()
File "/usr/lib/python2.6/distutils/dist.py", line 975, in run_commands
self.run_command(cmd)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/usr/lib/python2.6/distutils/command/install.py", line 577, in run
self.run_command('build')
File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/usr/lib/python2.6/distutils/command/build.py", line 134, in run
self.run_command(cmd_name)
File "/usr/lib/python2.6/distutils/cmd.py", line 333, in run_command
self.distribution.run_command(command)
File "/usr/lib/python2.6/distutils/dist.py", line 995, in run_command
cmd_obj.run()
File "/usr/lib/python2.6/distutils/command/build_ext.py", line 340, in run
self.build_extensions()
File "/usr/lib/python2.6/distutils/command/build_ext.py", line 449, in
build_extensions
self.build_extension(ext)
File "/usr/lib/python2.6/distutils/command/build_ext.py", line 531, in
build_extension
target_lang=language)
File "/usr/lib/python2.6/distutils/ccompiler.py", line 769, in
link_shared_object
extra_preargs, extra_postargs, build_temp, target_lang)
File "/usr/lib/python2.6/distutils/cygwinccompiler.py", line 189, in link
libraries.extend(self.dll_libraries)
TypeError: 'NoneType' object is not iterable
The offending line 189 is a rather nondescript
libraries.extend(self.dll_libraries)
Has anybody who is more pythonic than me seen this before? My cygwin
version is current as of last Wednesday, and the python version is 2.6.5
(no other python installations on the machine).
Thanks for any insights,
Jan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] build error on OS X 10.4: ld: multiple definitions of symbol _posix_memalign
Alexander List wrote: Is anyone else using OS X and succeeds to build gnuradio 3.2 without issues? A little while ago, I built 3.2 RC2 on a Macbook Pro running 10.4.11 and didn't encounter any problems (other than Macports installing all sorts of extra stuff if you don't set the swig install options right). gnuradio built and installed fine from svn. Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.2 Release Candidate 2 available for testing
> I can't replicate your results here on an Ubuntu 9.04 machine. > > There is only one actual assertDoubleEquals function in libcppunit, > and it takes all five arguments. The macro > CPPUNIT_ASSERT_DOUBLES_EQUAL that takes three arguments supplies the > other two as defaults. This has been the case on the default > installation of libcppunit for Ubuntu 8.04, 8.10, and 9.04. I'm > trying to figure out how your libgnuradio-core-qa.so came to have a > dynamic link to a version of the function with only four arguments. > > Has this specific source code tree been compiled before under a > different environment? Can you do a 'make distclean' and try again > (from the ./bootstrap step)? I was working from the tarball, so this was a completely new source tree. However, I think I found the culprit after some more digging. There was an older version of cppunit hiding in /usr/local/lib (wasn't installed through the package manager, so it escaped my attention for a while). The build is still underway, but I am pretty sure this is the root cause. Sorry about the false alarm! Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.2 Release Candidate 2 available for testing
Johnathan Corgan wrote: GNU Radio 3.2 release candidate 2 is now available for download and testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.2rc2.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.2rc2.tar.gz [etc] My 3.2-rc2 build fails with the following error: Making all in tests make[4]: Entering directory `/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/tests' /bin/bash ../../../libtool --tag=CXX --mode=link g++ -g -O2 -g -O2 -pthread -pthread -Wall -Woverloaded-virtual -o test_all test_all.o ../../../gnuradio-core/src/lib/libgnuradio-core-qa.la /home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/lib/libgnuradio-core.la libtool: link: g++ -g -O2 -g -O2 -pthread -pthread -Wall -Woverloaded-virtual -o .libs/test_all test_all.o ../../../gnuradio-core/src/lib/.libs/libgnuradio-core-qa.so -L/usr/lib /usr/lib/libcppunit.so -ldl /home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/lib/.libs/libgnuradio-core.so /home/jan/gr-build/gnuradio-3.2rc2/omnithread/.libs/libgromnithread.so /home/jan/gr-build/gnuradio-3.2rc2/gruel/src/lib/.libs/libgruel.so -lboost_thread-gcc43-mt-1_35 -lrt /usr/lib/libfftw3f.so -lgsl -lgslcblas -pthread ../../../gnuradio-core/src/lib/.libs/libgnuradio-core-qa.so: undefined reference to `CppUnit::assertDoubleEquals(double, double, double, CppUnit::SourceLine)' collect2: ld returned 1 exit status make[4]: *** [test_all] Error 1 make[4]: Leaving directory `/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src/tests' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core/src' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/jan/gr-build/gnuradio-3.2rc2/gnuradio-core' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/jan/gr-build/gnuradio-3.2rc2' make: *** [all] Error 2 This is on Ubuntu 9.04, following the instructions on the wiki (http://gnuradio.org/trac/wiki/UbuntuInstall). cppunit is 1.12.1-1 as installed from the Ubuntu repositories. Some output from nm: j...@ubuntu:~$ nm --demangle /usr/lib/libcppunit.a | grep assertDoubleEquals 0030 T CppUnit::assertDoubleEquals(double, double, double, CppUnit::SourceLine, std::string const&) So there seeems to be an extra parameter in the version of assertDoubleEquals that I have. According to cppunit documentation, there are macros with and without the extra parameter (which is a user-supplied message in case of error). Thanks, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] any recommendation? debug tools and IDE on cygwin
From some sessions I attended at Eclipecon, it seems that cygwin support for Eclipse CDT is indeed limited, and that isn't likely to change. I did some JNI work with it and it mostly worked for me, but the indexer seems to have a hard time with the cygdrive paths. Writing your own Makefiles definitely helps. If you are considering Eclipse, you do want to build with mingw instead. I haven't tried this with gnuradio, so I don't know what is involved, but I seem to recall reading that it is possible. This idea definitely has potential as Eclipse has pretty reasonable Python support, too. It may be easier to start playing with this on Linux though, to avoid having to solve too many problems at once. Just my -17dB$, Jan Bob wrote: guys, I just got GR installed on cygwin. It runs. But don't know what debugging tools and IDE that I can use to play with it. Eclipse for windows seems not support cygwin. I couldn't run debugging or any other code navigation function. do you have any suggestions and recommendations on cygwin debugging tools and IDE? really appreciate it!! Bob Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ 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] Information on ticket:181 and invitation to help (long)
$ python Python 2.4.4 (#1, Nov 1 2007, 23:42:22) [GCC 4.1.2 (Gentoo 4.1.2)] on linux2 Type "help", "copyright", "credits" or "license" for more information. >>> from gnuradio import gr >>> gr.firdes.hilbert(0) terminate called after throwing an instance of 'std::out_of_range' what(): Hilbert: Must have odd number of taps Aborted $ g++ --version g++ (GCC) 4.1.2 (Gentoo 4.1.2) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ swig -version SWIG Version 1.3.31 Compiled with x86_64-pc-linux-gnu-g++ [x86_64-pc-linux-gnu] Please see http://www.swig.org for reporting bugs and further information $ svn info Path: . URL: http://gnuradio.org/svn/gnuradio/branches/releases/3.1 Repository Root: http://gnuradio.org/svn Repository UUID: 221aa14e-8319-0410-a670-987f0aec2ac5 Revision: 7023 Node Kind: directory Schedule: normal Last Changed Author: jcorgan Last Changed Rev: 6822 Last Changed Date: 2007-11-05 17:02:31 -0800 (Mon, 05 Nov 2007) $ uname -a Linux localhost 2.6.22-gentoo-r9 #1 SMP Sun Nov 25 22:16:51 PST 2007 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Release 3.1.0rc0 now available; New Debian package repository
Oh, and one more question: I noticed a new dependency on numpy. I have lost track of this issue, is Numeric now no longer required? Thanks, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio Release 3.1.0rc0 now available; New Debian package repository
rc0 passes make distcheck here: Linux localhost 2.6.19-gentoo-r5 #1 SMP Tue Feb 27 21:16:23 PST 2007 x86_64 Intel(R) Core(TM)2 CPU 6600 @ 2.40GHz GenuineIntel GNU/Linux Revalidated that ticket 169 is fixed, passes.. I tried the usrp_wfm_rcv.py as a quick sanity check an that works fine, too. Are there any more recommendations as fas as "system test" goes? Is usrp_wfm_rcv.py a good one to use, or are there examples that exercise more of the system? Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Capturing 12-bit data at 10MHz sample clock?
This may be a dumb question, but suppose I changed the USRP ADC clock to 10MHz. Would there be a way to get 12-bit integer data across the USB, using usrp_rx_cfile.py or something similar? This would result in a manageable USB transfer rate of 30MB/s and line up pretty well with the bandwidth of the TVRX tuner. From poking around, it appears to me that the data transfer across the USB is either 2 * 8 bits/sample or 2 * 16. 2 * 12 should be easy enough to disentangle? Just curious, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on US digital cable ...
Vijay Ramasami wrote: On 8/17/07, Jan Schiefer <[EMAIL PROTECTED]> wrote: Vijay Ramasami wrote: Thanks for the information David. I will look up ITU-J.83B ... Do you happen to have any captured QAM cable data (or any website that lists the data) ? I wanted to see if I can put together a software demod for digital cable ... On 8/13/07, David I. Emery <[EMAIL PROTECTED]> wrote: On Mon, Aug 13, 2007 at 10:52:54AM -0400, Vijay Ramasami wrote: Hi, I have a couple of questions: 1. Does the US digital cable system follow the DVB-C standard (or one of its annexes) ? Is there any information (website) on the typical symbol rates, bandwidths (I am guessing approx 6 MHz), used ? There is a Cablelabs spec that defines what is used. The ETSI standards (ITU-T J.83B) also define the particular parameters as well. I can look up detailed references if needed... The are actually only two standard modulations in wide use 64QAM with a particular set of parameters that yields a 30 Mb/s signal with a 5.056941 Msym/symbol rate and a 256QAM signal which yields a 38.9 Mb/s signal with a symbol rate of 5.360537 Msym/s Both signals are 6 MHz wide as US CATV is universally 6 MHz channel based. 2. Has anyone successfully captured (preferably unencrypted) digital QAM transmissions using the USRP ? If so, can you please send me a link to the data ? Given that the symbol rates are in the range of 5-6 Ms/s, it must be possible to use 16 MHz sampling frequency to demodulate the signals. I have used a number of purpose built demods, but not yet tried a USRP solution. Some of the cable transport streams have open channels, but you will find most are encrypted except the local OTA HD signals and a few freebie promos. It is also possible to MODULATE QAM cable standard signals, something that gets more useful every month as more QAM/ATSC tuners are shipped for cable ready setups with CableCards rather than set top boxes. This of course allows direct input of MPEG transport streams into the digital domain of LCD/plasma panels with no analog step... -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." If you can't find any, let me know and I might be able to help. I have access to 2 QAM-64 channels and 15 or so QAM256 channels, some HD, all unencrypted. I probably have some encrypted ones too, but I don't know how many, as they are encrypted... If you can write a little capture program, I can try to hook up the USRP to the cable jack and see whether I can capture something. Problem is, I don't have a TVRX (yet), but this that may be a good excuse to order one. :-). Provided the phase response of the TVRX is sufficiently flat for this kind of signal. Anybody have a guess? Cheers, Jan Hi Jan, I would highly appreciate it if you can capture a few QAM-64 snapshots. I was able to successfully demodulate signals captured from a QAM modulator, but I don't have access to a real-world cable source. I guess the python script "usrp_rx_cfile.py" (in the examples directory) can be used to capture samples. We need at least 16 MHz sampling frequency for symbol timing recovery to work properly. Thanks, Vijay. Hi Vijay, sorry this is taking so long, but I think I have what you need now. With a 16MHz sampling frequency you get only 8 bits of resolution, so I was a little skeptical as to whether this would be sufficient. I played around with a 10 second QAM64 snapshot (640MB, stored as 16-bit signed ints, which gzips down to around 270MB). I put a chunk of this data into the Agilent 89600 Vector Signal Analyzer software, and with equalization turned on, the constellation actually looks pretty reasonable. So what I captured must not be complete garbage :-). Let me know if you still need this and I find a shady spot on the web to put it. Or if you'd rather have something shorter, or stored as floats, let me know. Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on US digital cable ...
Vijay, I would highly appreciate it if you can capture a few QAM-64 snapshots. I was able to successfully demodulate signals captured from a QAM modulator, but I don't have access to a real-world cable source. I guess the python script "usrp_rx_cfile.py" (in the examples directory) can be used to capture samples. We need at least 16 MHz sampling frequency for symbol timing recovery to work properly. My TVRX is on a UPS truck somewhere. As soon as it arrives, I'll give it a shot. Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Questions on US digital cable ...
Vijay Ramasami wrote: Thanks for the information David. I will look up ITU-J.83B ... Do you happen to have any captured QAM cable data (or any website that lists the data) ? I wanted to see if I can put together a software demod for digital cable ... On 8/13/07, David I. Emery <[EMAIL PROTECTED]> wrote: On Mon, Aug 13, 2007 at 10:52:54AM -0400, Vijay Ramasami wrote: Hi, I have a couple of questions: 1. Does the US digital cable system follow the DVB-C standard (or one of its annexes) ? Is there any information (website) on the typical symbol rates, bandwidths (I am guessing approx 6 MHz), used ? There is a Cablelabs spec that defines what is used. The ETSI standards (ITU-T J.83B) also define the particular parameters as well. I can look up detailed references if needed... The are actually only two standard modulations in wide use 64QAM with a particular set of parameters that yields a 30 Mb/s signal with a 5.056941 Msym/symbol rate and a 256QAM signal which yields a 38.9 Mb/s signal with a symbol rate of 5.360537 Msym/s Both signals are 6 MHz wide as US CATV is universally 6 MHz channel based. 2. Has anyone successfully captured (preferably unencrypted) digital QAM transmissions using the USRP ? If so, can you please send me a link to the data ? Given that the symbol rates are in the range of 5-6 Ms/s, it must be possible to use 16 MHz sampling frequency to demodulate the signals. I have used a number of purpose built demods, but not yet tried a USRP solution. Some of the cable transport streams have open channels, but you will find most are encrypted except the local OTA HD signals and a few freebie promos. It is also possible to MODULATE QAM cable standard signals, something that gets more useful every month as more QAM/ATSC tuners are shipped for cable ready setups with CableCards rather than set top boxes. This of course allows direct input of MPEG transport streams into the digital domain of LCD/plasma panels with no analog step... -- Dave Emery N1PRE/AE, [EMAIL PROTECTED] DIE Consulting, Weston, Mass 02493 "An empty zombie mind with a forlorn barely readable weatherbeaten 'For Rent' sign still vainly flapping outside on the weed encrusted pole - in celebration of what could have been, but wasn't and is not to be now either." If you can't find any, let me know and I might be able to help. I have access to 2 QAM-64 channels and 15 or so QAM256 channels, some HD, all unencrypted. I probably have some encrypted ones too, but I don't know how many, as they are encrypted... If you can write a little capture program, I can try to hook up the USRP to the cable jack and see whether I can capture something. Problem is, I don't have a TVRX (yet), but this that may be a good excuse to order one. :-). Provided the phase response of the TVRX is sufficiently flat for this kind of signal. Anybody have a guess? Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Multiple C files required by single C++ block.How to build?
Finally: “make clean”, “make” and “make check”.
This results in:
ImportError:
/home/jonas/gnuradio/gr-howto-write-a-block-3.0.2/src/lib/.libs/_howto.so:
undefined symbol: _Z10jonas_testv
What you need to do is to surround the declaration of jonas_testv() with
en extern "C" {} declaration. If you don't do this, then the linker is
looking for the "mangled name" , which is C++'s way to embed type
declarations in a function name. If the function is declared in the .h
as extern "C", it will just expect the function name with an underscore
in front of it, just like C does.
Cheers,
Jan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] XCode / SDCC Intel-Mac issue
Michael, thank you for doing an excellent piece of detective work to get to the source of this issue! Well done! I'll be at ND for "The Game" next weekend, and if you happen to go there too, I'd like to buy you a hot dog! I have another surprising data point to add to this whole thing: I just updated all the darwinports stuff on my wife's Macbook Pro. I rebuilt the world, and guess what, the USRP code builds and runs just fine on that machine with SDCC 2.6! This is with XCode 2.2.1. I seem to have gotten the lucky release. Maybe not all the 2.2.1s are the same (different gcc builds or something)? Mine came from the DVD in the box. Anyway, thanks for all the time you sank into this. At least now everybody should be able to build a working USRP image on any of the Intel Macs, and that's what matters. Cheers, Jan Michael Dickens wrote: I made enough progress on this issue to know there is a problem, but that it's beyond what I can investigate further until I have more time. What I'm doing instead is making the compiled and ready to install SDCC 2.4 for Intel-Darwin available for anyone to download and install. That way folks can keep using GNU Radio from the current SVN repository, and at some time in the future maybe SDCC will get fixed, or Apple's GCC will get fixed, or whatever the problem(s) is(are) will get fixed. While XCode certainly seems suspicious, and most fingers point to it being the issue, some fingers don't point there (they just don't point, since those data points don't fit into any pattern I've tested). I've updated the "MacInstall" Wiki page with this info < http://gnuradio.org/trac/wiki/MacInstall >. I'm also updating my install guide with the same info. I would certainly appreciate knowing that this work around does really work for (some, all, many) Intel-Mac users. I know that it works for me. - MLD ___ 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] The Mystery Deepens: GNU Radio on Intel-Mac
Thanks Michael, I am still on XCode 2.3 and will now definitely refrain from upgrading, for now. I can probably be talked into deliberately breaking my working MBP install by upgrading for testing purposes. Cheers, Jan Michael Dickens wrote: * I can easily show on our brand new 20" Intel-iMac that a "recent" (Wednesday) SVN checkout of GNU Radio will compile, check, and install, but USB transport doesn't work. On a similarly equipped PPC-Mac, USB transport does function (albeit slowly in comparison, maybe 1/2 the speed, w/ the Intel-iMac maxing out at 32 M-Bytes/s - which is good news for those moving to Intel-Macs). * I can also show on the same computer that a compile on a MacBook Pro (MBP) dated (checked out on) July 13 does allow for USB transport. * GNU Radio uses dynamic libraries, and one of those is LIBUSB (for the USB transport), and the installed version of LIBUSB was just performed this week from version 0.1.12 - the same as what's installed on the MBP. * By changing a link in /usr from "local_old" (for the MBP compile from July 13) to "local_new" to the compile I did this week, the USB transport will either work or not (respectively). The "facts" thus far lead (past tense) me to believe that it was a change in GNU Radio's software. * I then retrieved an archive of the actual source code for the "local_old" install from the MBP and dropped it onto the Intel-iMac. I then made everything anew from that codebase (from July 13, which worked before) ... and ... drum roll please it DID NOT work! This now leads me to believe it was the change in XCode from 2.3 to 2.4 (released August 11, which would be about the time folk started noticing oddness). Since 2.3 is compatible with the Intel-Mac's, I will revert the install back to 2.3 to check out this theory (likely early next week). Yet even more as testing goes further. - MLD ___ 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] RDS
Great pointer! Here is the posting: http://www.archivum.info/discuss-gnuradio@gnu.org/2006-02/msg00018.html This would be great to build on. Cheers, Jan Matt Ettus wrote: I seem to recall someone writing a gr-rds module a while ago. You might check the mailing list archives. I would love to have this feature in gnuradio. Please let me know if you need any help. Matt Jan Schiefer wrote: Hi Erlend, I think you should be able to see the subcarrier with the USRP. The injection level of the RDS signal is typically around 1.5 to 2%, this is substantially less than the pilot, which is typically around 9%, but it should still be visible. Make sure you have a good signal without too much multipath. Also, you want to double-check whether the station you are looking at is indeed carrying RDS (not sure whether everybody does in Norway). If you end up writing a decoder, please drop me a line. The American version of RDS, called RBDS, is (of course) slightly different. I'd be interested in helping to making sure that it will work on both sides of the Atlantic. Cheers, Jan Erlend Barstad Strand wrote: Hi I am trying to extend the usrp_wfm_rcv_pll.py by reading the RDS subcarrier, however I have a problem observing the subcarrier at all. I have connected a file_sink to the fm_demod in order to see the spectrum in Matlab. In the spectrum I can observe the L+R, L-R and pilot tone, but no RDS subcarrier at 57kHz. Have anyone successfully seen this channel on broadcast FM? Is it possible that the RDS subcarrier doesnt have enough power to be oberved with the USRP board? best regards erlend ___ 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 mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Anyone using an Intel-Mac Mini?
Which version of XCode should I try this with? Does it matter? Jam Michael Dickens wrote: For anyone with a Intel-Mac (MacBook Pro or Mac Mini) which is "known" to be working with the USRP hardware: If you update to the latest SVN of GR, does: usrp/host/apps: test_usrp_standard_rx and test_usrp_standard_tx still work? You might want to backup your various install-locations first (e.g. /opt, /usr/local). On a (friend's) MBP, the latest SVN -does not work- any longer. Reverting back to a version from July 13 does work. Both use LIBUSB 0.1.12 ... so maybe I was barking up the wrong tree. Next on the agenda: look at what's changed in the USRP since then. - MLD ___ 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] RDS
Hi Erlend, I think you should be able to see the subcarrier with the USRP. The injection level of the RDS signal is typically around 1.5 to 2%, this is substantially less than the pilot, which is typically around 9%, but it should still be visible. Make sure you have a good signal without too much multipath. Also, you want to double-check whether the station you are looking at is indeed carrying RDS (not sure whether everybody does in Norway). If you end up writing a decoder, please drop me a line. The American version of RDS, called RBDS, is (of course) slightly different. I'd be interested in helping to making sure that it will work on both sides of the Atlantic. Cheers, Jan Erlend Barstad Strand wrote: Hi I am trying to extend the usrp_wfm_rcv_pll.py by reading the RDS subcarrier, however I have a problem observing the subcarrier at all. I have connected a file_sink to the fm_demod in order to see the spectrum in Matlab. In the spectrum I can observe the L+R, L-R and pilot tone, but no RDS subcarrier at 57kHz. Have anyone successfully seen this channel on broadcast FM? Is it possible that the RDS subcarrier doesnt have enough power to be oberved with the USRP board? best regards erlend ___ 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] gnuradio-core fails to make on an Intel MacBook Pro using XCode 2.4?
Which version of gcc comes with Xcode 2.4? Can't find anything in the release notes. As of 3341, gnuradio-core does compile on OSX /Intel with Xcode 2.2.1, (gcc 4.0.1), I have never tried it with anything newer. Cheers, Jan Michael Dickens wrote: I'd already tracked it down to the file Eric mentions, so it's good to have commonality here. I'll have access to a MacBook Pro (in person, even, every so often) next Wednesday, and will spend some time debugging this issue at that time unless someone else has figured it out by then. Since gnuradio-core did compile on an Intel-Mac once upon a time, there has to be something in the way Apple is handling the __ELF__ directive Eric has some good suggestions on how to proceed ... we'll get to the bottom of this sooner or later. - MLD The fix needs to go in gnuradio-core/src/lib/filters/assembly.h On the macbook it's executing the !__ELF__ branch. I suspect that there's some Mach magic required here. Looking at some compiler generated assember and checking the predefined preprocessor defines should lead to enlightenment. Be sure to leave the old default branch -- I think it handled COFF or a.out -- and add a new check for whatever's right for OS/X. Eric ___ 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] No audio on os x reading .dat files
I just tried this with rev 3340 on an Intel Mac, and I hear the guy talking. This would confirm the endianness theory. Cheers, Jan Eric Blossom wrote: On Tue, Aug 15, 2006 at 05:52:50PM +0200, Josh Jennings wrote: Hi Michael, Having thought about this a little more, I don't think this problem is limited to the osx-audio. I have tried this also on my osx: 1) convert a complex dat file to a num file for gnuplot 2) plot the num file in gnuplot On os x I get zeros for all the converted points from the dat file, therefore something seems corrupted. When I do the same on my linux, I get a good set of converted complex points in my num file and it shows up correctly in gnuplot. Here is a list of the files and commands I use for listening to audio and converting the dat file: It's probably an "endianness problem". The dat file is native binary on whatever machine it was written on. Most likely x86, thus little-endian. The PPC macs are big-endian. Thus the problem. Anybody know if the intel macs are big or little endian? Eric ___ 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] How does 'make check' find its dependencies?
Michael, thanks for your insights! The solution that Jonathan proposed addresses this very issue and works fine. I have annotated bug #26 with the other locations that need the DYLD_LIBRARY_PATH set while the tests are being run. This lets the make check pass on OSX, too. So I don't need you need to do anything further, as far as this is concerned, other than maybe testing it on your system, so we have the PPC version of OSX covered. Thanks, Jan Michael Dickens wrote: I'm still compiling the new SNV stuff, for the purposes of debugging the install procedure & updating my install guide ... I don't have commit access yet as far as I know, so I can't change anything if I do find issues. OSX libraries are created with a specific directory location as an attribute. So not only does the library have to be in the correct place (the attribute location), but if it's a non-standard location then the environment variable "DYLD_LIBRARY_PATH " must be set with that path in mind (as well as other paths, potentially, to get the load path correct). Setting this variable will -really- screw things up, so don't do it on a global basis. OTOH, for a local check, it is possible to create libraries with a local (tmp) path in mind, set the DYLD_LIBRARY_PATH to point to that location, then do the "check" part of "make check". I don't know if GNU Radio does all this stuff or not. Last time I remember, "make check" failed under OSX for just this reason ... the dyld's couldn't be found. If nobody else has a fix for this issue, then I'll add it to my queue ... at a low priority for now since it's simple enough to "make install" then "make check" instead of the reverse. - MLD On Aug 10, 2006, at 3:45 AM, Jan Schiefer wrote: I am wondering: in 'make check', given that the libraries haven't actually been installed, which piece of magic allows python to resolve its imports? I am trying to get the new SVN build working on OSX, but I get stranded in the "make check" for gr-audio-osx. If somebody could tell me how the imports are supposed to work, I can probably figure it out. This was filed as defect #26. I am really surprised that I got this far. Great work, guys! ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Make -j should now be working
I am still seeing occasional, semi-random build failures, although it mostly appears to work. This is on a dual-core Intel Mac with -j 3. I haven't run enough of them to spot a pattern, but sometimes the make fails and sometimes the make check. With all due respect, I don't think the current approach of recursive makefiles is going to get us to a point where you can get a consistent and repeatable build with arbitrary numbers of processors or build machines (in the case of a distributed build), with multiple developers, over long periods of time. It is really really hard to do this without the top-level make being aware of all the dependencies throughout the whole code base. It is so easy to subtly break a build by introducing a dependency in a lower-level Makefile that the top-level make isn't aware of. Then multi-process builds will sometimes fail and sometimes succeed, depending on the execution order, which is completely arbitrary. Spotting and debugging the resulting inconsistencies is usually pretty painful, as most of you will know. I know I might be starting a holy war here, but I believe that a better way to do this reliably is for the top-level Makefile to include the lower-level ones, which just state the dependencies for the particular module. All the actual work is controlled by a single instance of make, which has the whole picture of the dependencies and can schedule accordingly. That doesn't preclude building individual modules, as they can be stated as sub-targets and built individually. A reference to the landmark paper "Recursive make considered harmful" may be in order (http://www.pcug.org.au/~millerp/rmch/recu-make-cons-harm.html). This is almost 10 years old, but still well worth reading. I just wondered whether this was on anybody else's radar. Cheers, Jan Johnathan Corgan wrote: Ticket #13 was reporting failure with parallel makes. Invoking (after bootstrap & configure) make with the -j option causes it to run as many instances in parallel as possible, dependencies allowing, in order to take advantage of multiple processors or cores, or to have a second instance run while the first was waiting for I/O, etc. Normally you put -j2 or -j3 to limit the maximum, as beyond that there is little benefit. This was failing in gnuradio-core, but was fixed back in r3222. Those of you tracking the new svn trunk--could you test this and confirm? Incidentally, make -j doesn't break anything, and at one point had 1100 processes running in parallel to build various parts of the whole tree. So when we get to 1024 core processors, we know we'll be able to take advantage of them. :-) -Johnathan ___ 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] How does 'make check' find its dependencies?
I am wondering: in 'make check', given that the libraries haven't actually been installed, which piece of magic allows python to resolve its imports? I am trying to get the new SVN build working on OSX, but I get stranded in the "make check" for gr-audio-osx. If somebody could tell me how the imports are supposed to work, I can probably figure it out. This was filed as defect #26. I am really surprised that I got this far. Great work, guys! Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with USB on OSX?
Hi Thomas, after loading the firmware, this is what it looks like: --- USB High-Speed Bus: Host Controller Location: Built In USB Host Controller Driver: AppleUSBEHCI PCI Device ID:0x27cc PCI Revision ID: 0x0002 PCI Vendor ID:0x8086 Bus Number: 0xfd USRP Rev 2: Version: 1.02 Bus Power (mA): 500 Speed:Up to 480 Mb/sec Manufacturer: Free Software Folks Product ID: 0x0002 Serial Number: Vendor ID:0xfffe Built-in iSight: Version: 1.55 Bus Power (mA): 500 Speed:Up to 480 Mb/sec Manufacturer: Micron Product ID: 0x8501 Vendor ID:0x05ac (Apple Computer, Inc.) --- Pretty similar, I'd say, apart from the USRP. No "vendor specific" anymore. Try the following: After downloading the firmware to the USRP, disconnect the USB. Hit Refresh on System Profiler - USRP should be gone. Plug USB back in, hit Refresh again. See whether it still says "vendor specific" or "USRP Rev whatever". This would be similar to your Ubuntu experiment, but make sure that the OSX firmware download does the right thing. Alternatively, try things in the opposite order: Run firmware download on OSX, boot into Ubuntu and look with lsusb (or whatever tool) what ID string you get out of the USRP. Also, you were asking about XCode versions. I am running XCode 2.2.1 (from the DVD that came with the MacBook Pro). As for other version info, the darwinports stuff is all up-to-date, apart from libtool 1.5.20_0 < 1.5.22_0 . There is no specific reason for this other than lazyness. Don't know about you, but I find the XCode version thing suspicious. What have other people reported? Has anybody got it working with XCode 2.3 on PowerPC? Cheers, Jan > Hi Jan, > > Once you programmed the USRP, what do you see as a Name in the System > Profiler? Do you see "Vendor Specific" or something else? Also, what > is the USB information on the MacBook Pro when you click on the top > most element where the USRP is connected to in the System Profiler? > Mine looks like this: > > USB High-Speed Bus: > > Host Controller Location: Built In USB > Host Controller Driver: AppleUSBEHCI > PCI Device ID: 0x27cc > PCI Revision ID:0x0002 > PCI Vendor ID: 0x8086 > Bus Number: 0xfd > > Vendor-Specific: > > Version:0.04 > Bus Power (mA): 500 > Speed: Up to 480 Mb/sec > Product ID: 0x0002 > Vendor ID: 0xfffe > > Built-in iSight: > > Version:1.55 > Bus Power (mA): 500 > Speed: Up to 480 Mb/sec > Manufacturer: Micron > Product ID: 0x8501 > Vendor ID: 0x05ac (Apple Computer, Inc.) > > > Thomas > > At least, that gives me some hope > > On 8/1/06, Jan Schiefer <[EMAIL PROTECTED]> wrote: >> Hi Thomas, >> >> I am afraid I don't have any of those boards. I just have the Basic >> [TR]X. I guess we can still compare logs with only the USRP and no TX/RX >> boards. Provided that we know where to look (which I don't). But maybe >> Michael will have some ideas. >> >> Cheers, >> Jan >> >> Thomas Schmid wrote: >> > I forgot to mention that I have the RFX400 and RFX2400 daughterboards. >> > I also tried the same thing with both daughterboards removed with the >> > same result. Unfortunately I don't have the BasicRX/TX with me and can >> > not test it. Do you have one of the RFX400 or 2400 with which you >> > could test? >> > >> > Thomas >> > >> > On 7/30/06, Thomas Schmid <[EMAIL PROTECTED]> wrote: >> >> Hi Jan, >> >> >> >> I have two USRPs to test with, one a Rev 3 and one a Rev 4.1. Both >> >> have the same behavior, except that one shows version 0.04 and the >> >> other 0.02 when I first plug them in (in the system profiler). Then, >> I >> >> run test_usrp_standard_tx, the firmware uploads, i.e. the LEDs start >> >> to blink slower, but the system profiler still shows the old values, >> >> i.e., they stay at "Vendor-specific". >> >> >> >> I will try to see if I can enable some more debug information. >> >> >> >> Thomas >> >> >> >> On 7/29/06, Jan Schiefer <[EMAIL PROTECTED]> wrote: >> >> > Hi Thomas, >> >> > >> >> > I am using gnuradio+USRP on a MacBook Pro under 10.4.7, this setup >> >> > should be very similar to yours.I have a version 3b USRP, with a >> >> BasicRX >> >> > and a BasicTX board. >> >>
Re: [Discuss-gnuradio] Problem with USB on OSX?
Isn't the way this works that the USRP disconnects/reconnects after the firmware download? Maybe the Mac misses that somehow? What happens if after loading the firmware you unplug and reconnect the USB? Cheers, Jan Thomas Schmid wrote: Hi Jan, I have two USRPs to test with, one a Rev 3 and one a Rev 4.1. Both have the same behavior, except that one shows version 0.04 and the other 0.02 when I first plug them in (in the system profiler). Then, I run test_usrp_standard_tx, the firmware uploads, i.e. the LEDs start to blink slower, but the system profiler still shows the old values, i.e., they stay at "Vendor-specific". I will try to see if I can enable some more debug information. Thomas On 7/29/06, Jan Schiefer <[EMAIL PROTECTED]> wrote: Hi Thomas, I am using gnuradio+USRP on a MacBook Pro under 10.4.7, this setup should be very similar to yours.I have a version 3b USRP, with a BasicRX and a BasicTX board. Have you checked out http://comsec.com/wiki?UsrpInstall ? When I plug the USRP in my system, before it loads any firmware (i.e. before I run any usrp-related program), I see the following in the System profiler (Apple logo/About This Mac, click More Info... , Hardware/USB, USB High-Speed Bus/Vendor-specific Version 0.02, etc etc Product ID 0x0002, Vendor ID 0xfffe. After running test_usrp_standard_tx, this information changes From "Vendor-specific" to "USRP Rev 2", the version changes to 1.02 and there is a "serial number" string of all zeroes. Does yours show the same information in the System Profiler? Also, what does it say if you go to the usrp directory and run a "svn up"? Mine says "At revision 832." Cheers, Jan Thomas Schmid wrote: > I just installed gnuradio on my macbook and I wanted to test the usrp > but got the same error as Sam: > > @ enter_search > 802_15_4_pkt: waiting for packet > usrp_basic_rx: failed to start end point streaming > > Next I tried to use the benchmark_usb.py file and I got this error: > Testing 2MB/sec... usrp_open_interface:usb_claim_interface: failed > interface 1 > usb_claim_interface: couldn't claim interface > usrp_basic_tx: can't open tx interface > Traceback (most recent call last): > File "./benchmark_usb.py", line 106, in ? >main () > File "./benchmark_usb.py", line 96, in main >ok = run_test (rate, verbose) > File "./benchmark_usb.py", line 63, in run_test >usrp_tx = usrp.sink_s (0, tx_interp) > File "/usr/local/lib/python2.4/site-packages/gnuradio/usrp.py", line > 230, in __init__ >fpga_filename, firmware_filename) > File "/usr/local/lib/python2.4/site-packages/gnuradio/usrp1.py", > line 932, in sink_s >return _usrp1.sink_s(*args) > RuntimeError: can't open usrp1 > > > Interestingly, the firmware is uploaded successfully, i.e., the led > first blinks fast, then slower, and then I get the error. > > Any ideas on what might be wrong? > > Thomas > > > On 7/27/06, Michael Klass <[EMAIL PROTECTED]> wrote: >> Thanks for the reply Jon. I'm quite sure that it has USB 2.0 ports, >> though. >> >> >> >> On 7/26/06, Jonathan Jacky <[EMAIL PROTECTED] > wrote: >> > >> > I'm using OS X. I've never seen this "failed to start end point >> > streaming" message. I've not used the flex 400 boards, only the >> Basic >> > RX/TX and LFRX/TX. Are you sure your Mac has USB 2.0 ports? Until >> > fairly recently (late 2003 or early 2004), Macs came with USB 1.1 >> ports. >> > >> > There is more information about this 1.1 vs 2.0 business, and how >> to use >> > the Mac System Profiler to check that OS X recognizes the USRP, at >> > >> > >> http://staff.washington.edu/~jon/gr-osx/gr-osx-usrp.html#using >> > >> > Jon Jacky >> > >> > >> > ___ >> > 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 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] Problem with USB on OSX?
Michael Dickens wrote:
I can tell you from the print-out that the issue is part of LIBUSB
("usb_claim_interface") which is used by the USRP, and not the USRP's
FUSB code for Darwin. Maybe there are patches for 0.1.12 for Intel
which are needed? Any other Intel-mac users see this?
Works fine here (on MacBook Pro). I am also using libusb 0.1.12.
Is there any other debug/syslog output that would be useful to debug
this? I don't have the same TX/RX boards as Thomas, but if we both pull
those boards and compare debug output, this should be easy to figure
out. Just need to know where to look.
Cheers,
Jan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Intel Mac GNU Radio Install Update Soon
Thomas Schmid wrote: A quick note of caution: I found out that sometimes compiling with -j2 gets errors, then restarting the process without -j2 compiles without any errors. I assume that it is some dependency problems because one of the processes did not finish yet. "This should never happen", but frequently does. The whole point of makefiles is to figure out dependencies and "do stuff". If you know what depends on what, figuring out what can be done in parallel is a trivial task. If that breaks the makefile, there is probably some assumption about build order coded into the makefile. If you care about what you are building, this is probably worth tracking down. Just like running your multi-threaded application for the first time on a multi-processor box. If it breaks in new and interesting ways, there's something you forgot :-). Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problem with USB on OSX?
Hi Thomas, I am using gnuradio+USRP on a MacBook Pro under 10.4.7, this setup should be very similar to yours.I have a version 3b USRP, with a BasicRX and a BasicTX board. Have you checked out http://comsec.com/wiki?UsrpInstall ? When I plug the USRP in my system, before it loads any firmware (i.e. before I run any usrp-related program), I see the following in the System profiler (Apple logo/About This Mac, click More Info... , Hardware/USB, USB High-Speed Bus/Vendor-specific Version 0.02, etc etc Product ID 0x0002, Vendor ID 0xfffe. After running test_usrp_standard_tx, this information changes From "Vendor-specific" to "USRP Rev 2", the version changes to 1.02 and there is a "serial number" string of all zeroes. Does yours show the same information in the System Profiler? Also, what does it say if you go to the usrp directory and run a "svn up"? Mine says "At revision 832." Cheers, Jan Thomas Schmid wrote: I just installed gnuradio on my macbook and I wanted to test the usrp but got the same error as Sam: @ enter_search 802_15_4_pkt: waiting for packet usrp_basic_rx: failed to start end point streaming Next I tried to use the benchmark_usb.py file and I got this error: Testing 2MB/sec... usrp_open_interface:usb_claim_interface: failed interface 1 usb_claim_interface: couldn't claim interface usrp_basic_tx: can't open tx interface Traceback (most recent call last): File "./benchmark_usb.py", line 106, in ? main () File "./benchmark_usb.py", line 96, in main ok = run_test (rate, verbose) File "./benchmark_usb.py", line 63, in run_test usrp_tx = usrp.sink_s (0, tx_interp) File "/usr/local/lib/python2.4/site-packages/gnuradio/usrp.py", line 230, in __init__ fpga_filename, firmware_filename) File "/usr/local/lib/python2.4/site-packages/gnuradio/usrp1.py", line 932, in sink_s return _usrp1.sink_s(*args) RuntimeError: can't open usrp1 Interestingly, the firmware is uploaded successfully, i.e., the led first blinks fast, then slower, and then I get the error. Any ideas on what might be wrong? Thomas On 7/27/06, Michael Klass <[EMAIL PROTECTED]> wrote: Thanks for the reply Jon. I'm quite sure that it has USB 2.0 ports, though. On 7/26/06, Jonathan Jacky <[EMAIL PROTECTED] > wrote: > > I'm using OS X. I've never seen this "failed to start end point > streaming" message. I've not used the flex 400 boards, only the Basic > RX/TX and LFRX/TX. Are you sure your Mac has USB 2.0 ports? Until > fairly recently (late 2003 or early 2004), Macs came with USB 1.1 ports. > > There is more information about this 1.1 vs 2.0 business, and how to use > the Mac System Profiler to check that OS X recognizes the USRP, at > > http://staff.washington.edu/~jon/gr-osx/gr-osx-usrp.html#using > > Jon Jacky > > > ___ > 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 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] Secret documentation and Python 2.4
Hi Eric, This particular nugget of info is secreted in gnuradio-core/README ;) I had long given up on README files, as I found them to mostly contain trivial stuff. Maybe it is time to revise that policy :-). Seems like this thing is a little underdocumented. How can we help? would be most welcome. Part of the problem you're seeing is that folks have generated documentation outside of the project (no problem with that), however, since it's not in our repository, we can't edit it to make corrections, extensions, etc. Besides Naveens's, we've got the same problem with Dawei Shen's tutorial. Any chance that the authors of this external documentation might be talked into contributing it to the docs module? Let me ramble a bit about the potential "customers" for more documentation. Gnu Radio is really a great technology and significantly lowers the barrier to entry to playing with SDR. However, the learning curve is still pretty steep. Particularly as not everybody has the knowledge or patience to resolve all the build dependencies, or the money to buy an USRP. I am thinking of e.g. some hams that may have a Windows PC, a little dusty programming knowledge but some exposure to DSP concepts and plenty of motivation. The kind of motivation that you get from reading the "Exploring GNU Radio" article. But there is a big gap to "How to write a block". We are still very much in early-adopter land here, and getting more people playing with this stuff would make a big difference. So if there was this hypothetical binary distribution, I think it might look like this: - gnuradio-core and audio-support in binary form, to be installed on top of an existing Python install - Optional USRP support - A few How-Tos: Getting started (mini-Python primer, mini-SDR primer, Running your first example program, Catalog of the existing examples, Audio experiments involving your favorite MP3, Radio experiments with downloadable waveform snippets, etc) - An easy ordering option for USRPs :-) - Commented/documented examples - The secret gnuradio-core library docs as HTML (or CHM on Windows) Basically, documentation for anything that you can do without a C++ compiler, with a focus on How-Tos, examples and ideas for experiments. Does this make sense? Or am I barking up the wrong tree here? If so, any other ideas on where to focus? Also, does this hypothetical binary distribution exist, or is somebody maybe working on it? I haven't used docbook, but it doesn't exactly look like rocket science. Any recommendations on authoring tools? (Please, let the answer not be "Emacs, of course!"). Vex looked pretty promising, OpenOffice didn't seem to offer much support. Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Secret documentation and Python 2.4
Hi there, I must be missing something - recently I saw a note here on this list about --enable-doxygen to autogenerate documentation for gnuradio-core. Very nice! It would be very useful if this kind of information was on the wiki. Is there some other "official" information repository? I wonder what other nuggets of information I am missing out on. On a vaguely related note, I came across an installation guide for gnuradio (http://www.eecis.udel.edu/~manicka/Research/GnuRadio_InstallationNotes.pdf), which claims that as of gnuradio 2.8, python 2.4 was required. Is that the true? Seems like this thing is a little underdocumented. How can we help? Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Quick Change to fusb_darwin
Michael Dickens wrote: ps> Has anyone successfully gotten GNURadio (and thus background libraries and includes) to install and execute on an Intel-Mac? It was good to see the note about ".align 4" versus ".align 16", so I know that folks are making progress. I hope to have access (remotely, without USRP hardware) to an Intel-Mac soon and will start working my way through the process. I will update my install guide (2) with advice once I get it working, but I certainly welcome advice from others who have already done this or are in the process of doing it. I am almost there and I'll send you my notes once I am a little further with the USRP. I tried a few examples without the USRP, and everything I tried showed signs of life. I am still working on the USRP part, and it is looking promising. As soon as I can pry the machine out of my wife's hands, I'll continue my quest. The prerequisites weren't hard, the process I used for the wxPython libraries is somewhat questionable, but it appears to work. fftw-3-single didn't build from darwinports, and that's because the Portfile enables Altivec. Once I changed that, it built fine. Then there's the alignment issue in gnuradio-core, but that's pretty much all I had to do so far. One question, do you have a pointer to a concise description of the USB problems? I'll be happy to test your fix for applicability to the Intel Macs. Cheers, Jan ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
