[Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS
G'day, I've downloaded today's sources and tried to build GNURadio on Ubuntu 12.04LTS when I hit the following problem: [ 85%] Built target pygen_gr_trellis_src_examples_python_cef97 [ 85%] Building CXX object gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o In file included from /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_usrp_source.h:25:0, from /home/berndt/gnuradio/gnuradio/gr-uhd/lib/gr_uhd_usrp_source.cc:22: /home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_api.h:25:26: fatal error: uhd/config.hpp: No such file or directory compilation terminated. Searching the source tree, there indeed is no config.hpp. Is this file generated during the configuration process? 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS
On Sun, 2012-09-30 at 17:43 -0700, Josh Blum wrote:
On 09/30/2012 05:39 PM, Berndt Josef Wulf wrote:
G'day,
I've downloaded today's sources and tried to build GNURadio on Ubuntu
12.04LTS when I hit the following problem:
[ 85%] Built target pygen_gr_trellis_src_examples_python_cef97
[ 85%] Building CXX object
gr-uhd/lib/CMakeFiles/gnuradio-uhd.dir/gr_uhd_usrp_source.cc.o
In file included
from
/home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_usrp_source.h:25:0,
from /home/berndt/gnuradio/gnuradio/gr-uhd/lib/gr_uhd_usrp_source.cc:22:
/home/berndt/gnuradio/gnuradio/gr-uhd/include/gr_uhd_api.h:25:26: fatal
error: uhd/config.hpp: No such file or directory
compilation terminated.
Searching the source tree, there indeed is no config.hpp. Is this file
generated during the configuration process?
I wonder how gnuradio got configured with uhd support? Thats actually
the one file the FindUHD.cmake looks for to confirm the header location:
FIND_PATH(
UHD_INCLUDE_DIRS
NAMES uhd/config.hpp
HINTS $ENV{UHD_DIR}/include
${PC_UHD_INCLUDEDIR}
PATHS /usr/local/include
/usr/include
)
Thats just the first header it encounters. Theres probably some
installation issue. Can you post the ls install prefix/include/uhd/*
I didn't have uhd installed and hence /usr/{local,}/include/uhd don't
exist.
Having said this, I had an older version installed, 3.5.2 if my memory
serves me correctly, which was de-installed prior to updating and
building the current source tree.
73, Berndt
VK5ABN
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS
On Mon, 2012-10-01 at 10:36 +0930, Berndt Josef Wulf wrote:
On Sun, 2012-09-30 at 17:43 -0700, Josh Blum wrote:
I wonder how gnuradio got configured with uhd support? Thats actually
the one file the FindUHD.cmake looks for to confirm the header location:
FIND_PATH(
UHD_INCLUDE_DIRS
NAMES uhd/config.hpp
HINTS $ENV{UHD_DIR}/include
${PC_UHD_INCLUDEDIR}
PATHS /usr/local/include
/usr/include
)
Thats just the first header it encounters. Theres probably some
installation issue. Can you post the ls install prefix/include/uhd/*
I didn't have uhd installed and hence /usr/{local,}/include/uhd don't
exist.
Having said this, I had an older version installed, 3.5.2 if my memory
serves me correctly, which was de-installed prior to updating and
building the current source tree.
I've installed UHD and gnuradio builds fine.
Many thanks for your help and pointing me into the right direction.
73, Berndt
VK5ABN
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ultimate SDR system ??
G'day William, FYI: About a week ago, I was facing the same situation and decided to purchase a Dell Studio XPS 1645 laptop. The major factors for my decision were 1.) Onsite warranty repair 2.) Better screen resolution 1080p (1920x1080) 3.) Free inclusion of a blue-ray player (special) 4.) Being a happy Dell user for the past 10 years 5.) Price was AUS$1887.20, including a 10% membership discount Spec: I7-720QM, 6Gb RAM, 1Gb ATI HD 4670, Blue-Ray, Win7 Pro I've justed visited Dell USA and noticed their prices are substantially higher for some reason. I waited until a favorable configuration was on offer, in this case the inclusion of a blue-ray player. cheerio Berndt On 26/04/10 William Pretty Security Inc wrote: Hi All; Found this little baby on Tiger Direct: http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=57 05306 http://www.tigerdirect.ca/applications/SearchTools/item-details.asp?EdpNo=5 705306CatId=4938 CatId=4938 Hp Pavilion Intel i7-720QM processor, 6GB of DDR3 RAM What do you think ?? Bill ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Error on reconnecting to TCP port
G'day, I've created a simple application in GRC using a TCP source in server mode. When started, it excepts connections on the allocated port for the first time. However, after statefully disconnecting from the port, any further attempts to make a new connection with the server application fail - connection refused. Is this the expected behavior? I was assuming that it will accept new connections after disconnecting from the previous session. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP FX2 24MHz crystal
G'day, The FX2 chip has issues and this time I suspect a faulty crystal. I would like to replace it before going any further. The current crystal is a ECSD240E, but I can't find any information on it. Does anyone know the part number for a replacement crystal and a possible source? Thanks, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] (old) USRP schematics
G'day, can someone point me to the schematics of the old USRP in PDF or PS format? I had a browse in usrp-hw couldn't identify anything useful in there. Thanks, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Faulty USRP microprocessor?
G'day, I'm glad to inform that replacing the FX2 chip resolved the problem and the USRP appears to be fully operational, e.g. usrp_benchmark and usrp_wfm work out of the box. I since tried to connect the board using a USB2.0 cable of 5m in length and can't establish communication with it. The cable length is within the USB2.0 specifications. It may just be a poor quality or bad cable, but would like to hear if anyone else has been successful in using a long USB cable. Using an oscilloscope, I can see a pulse train of about 0.5Vpp with channel A (D+) and channel B (D-) at the USRP connector. Does this sound right? cheerio Berndt On Thursday 13 November 2008 08:49:40 Berndt Josef Wulf wrote: G'day, I haven't made any progress in finding a solution to my problem. A direct email to Matt (Ettus) explaining my predicament didn't receive a reply. It was hoped that the manufacturer of the USRP would provide some after sale techmical support for their products. The USRP is no longer communicating when it was powered up after being in storage for the past 6 month. As mentioned in my previous email, see below, my suspect is the co-processor that hosts the USB interface, although I can't be sure. Perhaps someone on this list knows a procedure that would lead to an accurate diagnosis. At this stage I'm contemplating to replace the processor. What needs to be considered prior to replacing this processor, e.g. does it need to be flashed? I'm also looking for a supplier for this chip. Any help is very much appreciated. 73, Berndt VK5ABN On Tuesday 04 November 2008 22:28:38 Berndt Josef Wulf wrote: G'day, today I discovered that my USRP appears to have a problem. The USRP device is nolonger detected when connected to a PC (i386) running WinXP, Linux or NetBSD. I tried different systems and cables to no avail. This is with GNU-Radio current, but also tried with the last stable release. Power supply rail measures 3.3V after the regulator and the LED is fast flashing, which normally would indicate that the processor is running, but firmware hasn't been loaded. Signal lines from processor pins to connector/cable have continuity. I'm now suspecting the USB interface on the microprocessor chip. Has anyone had similar experience and what was the solution to your problem? If so, what was your solution? I really would hate the idea of having to replace the microprocessor because of lack of spares and in particular its package size. Any help is very much appreciated. 73, Berndt VK5ABN ___ 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] Dead USRP box?
G'day Bob, this is exactly what happened to my USRP board. The board seems operational except it won't communicate. I've ordered the FX2 chip from DigiKey as I believe it to be faulty. Digikey actually managed to sent me the wrong part, a RAM chip, inside an otherwise correctly labled package. The hopefully correct part is on its way, so it shouldn't be long until we know if it fixed the problem. It just begs the question, what causes this chip to fail? As described by Bob, it was left off for several month and failed on subsequent power up. Seasons Greetings, cheerio Berndt On Sunday 21 December 2008 12:48:40 Bob Cameron wrote: Hi All I purchased a USRP some time ago, had it working and then left it for a while. I suspect that the USB port has been zapped. Question. Is it safe to assume that there should be some kind of response in /var/log/messages on connection of the USB cable? I have tried the usual switching of ports and cables, pulling daughterboards, the LED is blinking and the 24MHz oscillator can be heard on the nearby HF radio. I can no doubt tackle the debugging by looking up the chip specs. Any start point ideas would be welcome though. Cheers Bob VK2YQA ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Faulty USRP microprocessor?
G'day, I haven't made any progress in finding a solution to my problem. A direct email to Matt (Ettus) explaining my predicament didn't receive a reply. It was hoped that the manufacturer of the USRP would provide some after sale techmical support for their products. The USRP is no longer communicating when it was powered up after being in storage for the past 6 month. As mentioned in my previous email, see below, my suspect is the co-processor that hosts the USB interface, although I can't be sure. Perhaps someone on this list knows a procedure that would lead to an accurate diagnosis. At this stage I'm contemplating to replace the processor. What needs to be considered prior to replacing this processor, e.g. does it need to be flashed? I'm also looking for a supplier for this chip. Any help is very much appreciated. 73, Berndt VK5ABN On Tuesday 04 November 2008 22:28:38 Berndt Josef Wulf wrote: G'day, today I discovered that my USRP appears to have a problem. The USRP device is nolonger detected when connected to a PC (i386) running WinXP, Linux or NetBSD. I tried different systems and cables to no avail. This is with GNU-Radio current, but also tried with the last stable release. Power supply rail measures 3.3V after the regulator and the LED is fast flashing, which normally would indicate that the processor is running, but firmware hasn't been loaded. Signal lines from processor pins to connector/cable have continuity. I'm now suspecting the USB interface on the microprocessor chip. Has anyone had similar experience and what was the solution to your problem? If so, what was your solution? I really would hate the idea of having to replace the microprocessor because of lack of spares and in particular its package size. Any help is very much appreciated. 73, Berndt VK5ABN ___ 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] Faulty USRP microprocessor?
On Thursday 13 November 2008 09:12:37 Matt Ettus wrote: Berndt Josef Wulf wrote: G'day, I haven't made any progress in finding a solution to my problem. A direct email to Matt (Ettus) explaining my predicament didn't receive a reply. It was hoped that the manufacturer of the USRP would provide some after sale techmical support for their products. Berndt, I am sorry to have not gotten back to you, but I get over 300 non-spam emails per day, many with technical questions, and it can be hard to wade through them. I try to go through the backlog at least once a week. The USRP is no longer communicating when it was powered up after being in storage for the past 6 month. As mentioned in my previous email, see below, my suspect is the co-processor that hosts the USB interface, although I can't be sure. Perhaps someone on this list knows a procedure that would lead to an accurate diagnosis. It sounds like the transceiver circuitry on the FX2 has gone bad, but the processor is still running. This the most common failure mechanism we see. We have static protection diodes on the recent boards, but it does not seem to change things. The best course of action is to replace the FX2 chip. We do not see this failure often, but when it does, it is often when used with cheap aftermarket power supplies for the laptop, or with a nonstandard USRP power supply. At this stage I'm contemplating to replace the processor. What needs to be considered prior to replacing this processor, e.g. does it need to be flashed? I'm also looking for a supplier for this chip. They do not need to be flashed. You should be able to get the chip from Digikey or any other Cypress dealer. The exact part number is CY7C68013A-100AC. They are about $15 in small quantities. Matt G'day Matt, many thanks for your reply. You're confirming my suspicions and I'm now confident in tackling this problem head0on by replacing the FX2. Hope to be back on-the-air with USRP and GNU-Radio soon. 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] URSP/Gnuradio for amateur radio usage
Nice gadget, but prices are insane. cheerio Berndt On Thursday 30 October 2008 08:53:27 Robert Tiller wrote: And do not forget the new QS1 http://www.philcovington.com/QuickSilver/ On Tue, Oct 28, 2008 at 1:09 PM, rafael2k [EMAIL PROTECTED] wrote: thats true Chris, Thanks for the information. but none runs gnuradio, usually PowerSDR is used. bye, rafael diniz Em Monday 27 October 2008, Chris Albertson escreveu: On Mon, Oct 27, 2008 at 8:36 PM, rafael2k [EMAIL PROTECTED] wrote: There are others SDR radios out there that were made for amateurs, like Flex5000, softrock and others, but they all use a stereo sound cable connected to the PC soundcard as interface (at most 96kHZ and 20kHz bandwidth), ..., ursp is much more powerfull. There are exceptions to your they all use a stereo sound cable rule. One that you might want to look at is here http://hpsdr.org/ There are several sub projects within HPSDR. Look at both of these: http://hpsdr.org/mercury.html http://hpsdr.org/penelope.html -- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+- Ciência da Computação @ Unicamp Rádio Muda, radiolivre.org, TV Piolho, tvlivre.org, www.midiaindependente.org Chave PGP: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x2FF86098 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -+-+-+- ___ 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] TunTap device problem in GRC
On Saturday 18 October 2008 13:49:23 Ed Criscuolo wrote:
Josh Blum wrote:
I pasted the relevant code below so we can reference its mystery hex
number.
The tun tap block in grc takes code from the tun tap example to open a
tun tap file descriptor. The file descriptor is fed into a file
descriptor source and sink. From the outside of the tun tap block, we
see the input to the file descriptor sink and the output of the file
descriptor source.
GRC will try to exec ifconfig on the tun tap device name, if an ip
address is specified. You can manually run ifconfig as well. I dont
think this is the problem.
Should this work in linux? Maybe.
Looks like it should. Yet, when I run it in linux, the tun0 network
device gets created without the IP address, but manually running
the same ifconfig command works. At least as far as asigning the
address.
Should this work in mac os? Possibilities are even worse: those hard
coded hex values, they probably have header file constants that change
numeric value from linux to freebsd.
Quite likely. In addition, I've found that the tun/tap driver works
differently on OSX. In Linux, there's a master tun device called
/dev/net/tun. Opening this returns a unique fd and creates both the
/dev/tunx character device, and the associated tunx network device.
In the Mac OSX tun/tap driver, there is no master /dev/net/tun device.
Instead, the driver precreates all the character devices from /dev/tun0
thru /dev/tun15. You have to open the specific one to get the associated
net device created.
In addition, the ifconfig command works differently on OSX than
on Linux. The OSX tunx network devices are created as
point-to-point devices, and the OSX ifconfig command REQUIRES
the IP address of the far side of the link. And the syntax is
different. Linux uses the keyword pointopoint, while OSX
just uses two addresses, eg - ifconfig tun0 10.0.0.1 10.0.0.2.
Looks like we either need an abstraction layer, or something
that converts the OSX semantics to the Linux API.
OSX and NetBSD seem to be very similar in behaviour see below:
barossa: {10} ifconfig tun0 create
barossa: {11} ifconfig tun0 10.0.0.1 10.0.0.2
barossa: {12} ifconfig tun0
tun0: flags=51UP,POINTOPOINT,RUNNING mtu 1500
inet 10.0.0.1 - 10.0.0.2 netmask 0xff00
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] software defined antenna
On Saturday 11 October 2008 09:14:48 Steve Totaro wrote: On Fri, Oct 10, 2008 at 4:20 PM, John Ackermann N8UR [EMAIL PROTECTED] wrote: rhubbell wrote: Hi all, After being on-frequency here for a little while I can see that the range of experience/expertise is wide. Which is great. I'm curious if any long-timers have begun to look at software defined antennas? Or is there any effort at all anywhere in the public domain? I guess military and universities don't really count for public as much as they once did, but I'd guess they're working toward SDA also. I'm not sure just what you mean by software defined antenna but Vic Kean, K1LT, has been using an array of short vertical antennas fed to multiple ADCs and phased in software to receive on the 160M amateur band. I don't have URLs handy, but I know he's made some postings about his work. Searching for K1LT and SDR would be a good start. John I could see a software controlled antennae, using software to control reed switches and servos, but not a strictly software defined antennae, more like a robotic antennae that could be populated with standard or predefined settings for the antennae configuration, as well as manual control. I have a software controlled wifi antennae on my chimney, the software just controls a servo for direction. I have this guy, which kicks butt and has come down in price quite a bit http://cgi.ebay.com/WiFi-USB-24-dBi-YAGI-ANTENNA-2-4GHz-ULTRA-LONG-RANGE_W0 QQitemZ270284630828QQihZ017QQcategoryZ86720QQssPageNameZWDVWQQrdZ1QQcmdZView Item Haven't used it in ice/snow but i assume that will be a problem and require some kind of covering to keep the elements that stick off, jerking the servo takes care of water build up from rain that can and does degrade wifi signals. Systems such as an over-the-horizon radar, such as the Jindalee project in Australia, are possibly as close as it gets to be a SDA. It involves a little more than just an antenna rotator controller... 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GRC: 'Utils' not defined
G'day, Its been a while since I last used GRC and a lot has changed since then. I've built and installed GNU-Radio after merging GRC. I can run the sample and also create new circuits, but when load older GRC files I'm getting the following error: Loading: /home/wulf/dsp/ssb.grc.xml Parser Error: global name 'Utils' is not defined Failue I can't find any reference to 'Utils' in any of these files and failed to find any reference to a possible solution using Google. Can someone push me in the right direction? Many thanks in advance, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC: 'Utils' not defined
G'day Josh, thanks, this fixed the problem. I can now load and convert the old applications. cheerio Berndt On Monday 15 September 2008 03:01:04 Josh Blum wrote: There is a conversion script that is supposed to automatically convert older grc.xml files. Anyway, when I was reorganizing grc I forgot to update an import statement in the converter. Its fixed now. -Josh Berndt Josef Wulf wrote: G'day, Its been a while since I last used GRC and a lot has changed since then. I've built and installed GNU-Radio after merging GRC. I can run the sample and also create new circuits, but when load older GRC files I'm getting the following error: Loading: /home/wulf/dsp/ssb.grc.xml Parser Error: global name 'Utils' is not defined Failue I can't find any reference to 'Utils' in any of these files and failed to find any reference to a possible solution using Google. Can someone push me in the right direction? Many thanks in advance, cheerio Berndt ___ 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] Important: New trunk dependency: GSL
On Thursday 11 September 2008 21:28:53 Greg Troxel wrote: I'll be adding the GNU Scientific Library (GSL) as a new dependency on the trunk. GSL is a huge numerical library that's been under active development for more than 10 years: http://www.gnu.org/software/gsl FYI this is in pkgsrc as math/gsl and it's at 1.11. G'day Greg, FYI: GNU Radio currently won't built on pkgsrc as the versions of boost, wxGTK and py-wxWindows are too old. It also lacks py-gsl. 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 8-ary FSK modulator/demodulator and golay encoder/decoder
G'day, does GNU Radio have an implementation for a 8-ary FSK modulator/demodulator and the golay encoder/decoder or can someone point me to a good source describing the implementation of such? Many thanks in advance, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.2rc0 tarballs available for testing
On Thursday 13 March 2008 05:27:30 Johnathan Corgan wrote: GNU Radio release 3.1.2rc0 tarballs are now available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.1.2rc0.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.1. 2rc0.tar.gz Release 3.1.2rc0 is a pre-release for testing purposes, and incorporates all known bug fixes from the development trunk. In addition, new features and functions that don't (or shouldn't) impact existing user code have been included: http://gnuradio.org/trac/wiki/Release3.1Branch Instructions for installation may be found at: http://gnuradio.org/trac/wiki/BuildGuide Source code-based installation of GNU Radio requires ensuring the build prerequisites are installed on your system, followed by the traditional 'configure' and 'make' process. See the OS specific instructions at the above wiki page to accomplish this. Doesn't build using the pkgsrc framework failing as shown below: checking boost/shared_ptr.hpp presence... yes checking for boost/shared_ptr.hpp... yes checking for svn... /usr/pkg/bin/svn svn: '.' is not a working copy svn: '.' is not a working copy Not building component omnithread. Component gnuradio-core requires omnithread, which is not being built or specified via pre-installed files. Needless to say, svn is installed and accessable. No idea about omnithread. Any suggestions appreciated. Systeminfo: NetBSD 4.99.51 (GENERIC) 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.2rc0 tarballs available for testing
On Saturday 15 March 2008 23:16:21 Johnathan Corgan wrote: On 3/15/08, Berndt Josef Wulf [EMAIL PROTECTED] wrote: Doesn't build using the pkgsrc framework failing as shown below: checking boost/shared_ptr.hpp presence... yes checking for boost/shared_ptr.hpp... yes checking for svn... /usr/pkg/bin/svn svn: '.' is not a working copy svn: '.' is not a working copy Not building component omnithread. Component gnuradio-core requires omnithread, which is not being built or specified via pre-installed files. Needless to say, svn is installed and accessable. No idea about omnithread. Any suggestions appreciated. The svn comment is harmless; it's a side effect of using a tarball instead of an svn checked out source tree. It looks like your ./configure line in pkgsrc doesn't have the omnithread module specified. That would be done with '--enable-omnithread' if you are including it in the build, or using the new '--with-omnithread' syntax if you are referring an already installed instance of libgromnithread. hmm, I've used the --enable-omnithread option. I don't know of any package that would provide me with the libgromnithread library. Will investigate this further, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.1.2rc0 tarballs available for testing
On Saturday 15 March 2008 23:44:43 Berndt Josef Wulf wrote: On Saturday 15 March 2008 23:16:21 Johnathan Corgan wrote: On 3/15/08, Berndt Josef Wulf [EMAIL PROTECTED] wrote: Doesn't build using the pkgsrc framework failing as shown below: checking boost/shared_ptr.hpp presence... yes checking for boost/shared_ptr.hpp... yes checking for svn... /usr/pkg/bin/svn svn: '.' is not a working copy svn: '.' is not a working copy Not building component omnithread. Component gnuradio-core requires omnithread, which is not being built or specified via pre-installed files. Needless to say, svn is installed and accessable. No idea about omnithread. Any suggestions appreciated. The svn comment is harmless; it's a side effect of using a tarball instead of an svn checked out source tree. It looks like your ./configure line in pkgsrc doesn't have the omnithread module specified. That would be done with '--enable-omnithread' if you are including it in the build, or using the new '--with-omnithread' syntax if you are referring an already installed instance of libgromnithread. hmm, I've used the --enable-omnithread option. I don't know of any package that would provide me with the libgromnithread library. BTW: Which package does provide libgromnithread? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
G'day, Still crashes here with the following error messages: No module named serial in RS232 Source! - continuing... No module named serial in RS232 Sink! - continuing... Removing empty category Custom... Verbose: Traceback (most recent call last): File /home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py, line 248, in ? exit(0) TypeError: 'str' object is not callable Done The program 'Editor.py' received an X Window System error. This probably reflects a bug in the program. The error was 'BadLength (poly request too large or internal Xlib length erro'. (Details: serial 10975 error_code 16 request_code 151 minor_code 23) (Note to programmers: normally, X errors are reported asynchronously; that is, you will receive the error a while after causing it. To debug your program, run it with the --sync command line option to change this behavior. You can then get a meaningful backtrace from your debugger if you break on the gdk_x_error() function.) cheerio Berndt On Saturday 19 January 2008 05:38:46 Josh Blum wrote: The error seems to come from gtk.main and not from the GRC source itself. Perhaps this is the result of a race condition (in grc) between the the main thread and the thread waiting on the flow graph to finish. -By clicking the kill button, the waiting thread finishes by calling the very same method that handles the kill button press. Perhaps in all the ruckus, some gtk functions get called by 2 threads at once, and eventually gtk gets upset and dies/crashes... I committed a fix for this in the GRC trunk. Can somebody with this issue try out the trunk fix and let me know? -Josh Ed Criscuolo wrote: I've seen this exact same behavior for some time. I'm currently running the latest GnuRadio release and GRC 0.69 on Mac OSX 10.4.11 @(^.^)@ Ed Achilleas Anastasopoulos wrote: I would like to thank again Josh for the wonderfull job on GRC: I am now using it regularly for my classroom demonstrations on analog/digital communications. I have noticed (it has been more than 6 months since the last time I used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). In fact, 8 out of 10 times that I stop a running graph (usually with 4-5 graphical sinks running) either by closing the graph window or by pressing the stop button on the graphical editor of GRC, it closes the entire GRC editor... Can someone confirm this behavior? Thanks Achilleas ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience
On Fri, 18 Jan 2008 03:09:29 am Achilleas Anastasopoulos wrote: I would like to thank again Josh for the wonderfull job on GRC: I am now using it regularly for my classroom demonstrations on analog/digital communications. I have noticed (it has been more than 6 months since the last time I used it) that 0.69 version crashes a lot with my fedora 7 (64 bit). In fact, 8 out of 10 times that I stop a running graph (usually with 4-5 graphical sinks running) either by closing the graph window or by pressing the stop button on the graphical editor of GRC, it closes the entire GRC editor... Can someone confirm this behavior? Thanks Achilleas PS: I have to add one more item on my wish list for 0.70 :-) In the open file and save file dialog boxes, make open and save the default action when pressing enter, so you wont have to press the button with the mouse... G'day, I can confirm your observation. This is exactly my experience here too. I'm running NetBSD-i386-current 4.99.42. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Re: Gnu Radio Companion (GRC) 0.69 experience
On Friday 18 January 2008 09:20:55 Steve Bunch wrote:
On Jan 17, 2008, at 3:35 PM, Steve Bunch wrote:
I tried grc on a Fedora Core 6 installation, Python 2.4, and see
this crash (sometimes, maybe even usually) when the graph has been
edited. I don't think it ever crashed on a run where the graph
hadn't been changed.
Josh,
Followup: retrying grc on Fedora 8 (Python 2.5), Core 2 quad, 32-bit,
recent installation of GNURadio 3.1svn, grc from svn current, I have
no crashes observed in dozens of edits and reruns of a previously-
often-failing graph.
G'day,
I've rebuilt and installed GNU Radio svn-7461 as of today on a system running
python-2.4.4 and swig-1.3.31. It still crashes when started and stopped a few
times, three times in this particular case, with message shown below. This
was using example noisy_sinusoid.grc.xml application provided by the GRC
package. This is reproducable at will. Note the TypeError: 'str' object is
not callable and the message just prior to the coredump.
barossa: {18} ./Editor.py ../examples/noisy_sinusoid.grc.xml
No module named serial in RS232 Source! - continuing...
No module named serial in RS232 Sink! - continuing...
Removing empty category Custom...
Welcome to GRC 0.69
Loading: ../examples/noisy_sinusoid.grc.xml
Done
Showing: /home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml
Executing: /home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml
No module named serial in RS232 Source! - continuing...
No module named serial in RS232 Sink! - continuing...
Removing empty category Custom...
Verbose:
Traceback (most recent call last):
File /home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py, line 248,
in ?
exit(0)
TypeError: 'str' object is not callable
Done
Executing: /home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml
No module named serial in RS232 Source! - continuing...
No module named serial in RS232 Sink! - continuing...
Removing empty category Custom...
Verbose:
Traceback (most recent call last):
File /home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py, line 248,
in ?
exit(0)
TypeError: 'str' object is not callable
Done
Executing: /home/wulf/projects/gnuradio/grc/examples/noisy_sinusoid.grc.xml
No module named serial in RS232 Source! - continuing...
No module named serial in RS232 Sink! - continuing...
Removing empty category Custom...
Verbose:
Traceback (most recent call last):
File /home/wulf/projects/gnuradio/grc/src/ExecFlowGraphGUI.py, line 248,
in ?
exit(0)
TypeError: 'str' object is not callable
/home/wulf/projects/gnuradio/grc/src/ActionHandler.py:68: GtkWarning: Invalid
text buffer iterator: either the iterator is uninitialized, or the
characters/pixbufs/widgets in the buffer have been modified since the
iterator was created.
You must use marks, character numbers, or line numbers to preserve a position
across buffer modifications.
You can apply tags and insert marks without invalidating your iterators,
but any mutation that affects 'indexable' buffer contents (contents that can
be referred to by character offset)
will invalidate all outstanding iterators
gtk.main()
Segmentation fault (core dumped)
barossa: {19}
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Undefined PLT symbol Pa_IsStreamActive
G'day, make check fails in gr-audio-portaudio with the following error: File ./qa_portaudio.py, line 24, in ? import audio_portaudio File /home/wulf/projects/gnuradio/gnuradio/gr-audio-portaudio/src/audio_portaudio.py, line 6, in ? import _audio_portaudio ImportError: /home/wulf/projects/gnuradio/gnuradio/gr-audio-portaudio/src/.libs/_audio_portaudio.so: Undefined PLT symbol Pa_IsStreamActive (symnum = 31) FAIL: run_tests Has anyone seen this? What is the required revision for portaudio. pkgsrc currently uses portaudio-18.1 which may be a little out-of-date. Thanks for your help, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Major trunk repository update in r6466
GOn Wednesday 19 September 2007 04:29:29 Johnathan Corgan wrote: The GNU Radio trunk repository has been updated with the following changes: * Final gr.top_block and gr.hier_block2 implementation inside gnuradio-core/src/lib/runtime * Implementation of gr.hier_block2 versions of all the old-style blocks in blks. These live in blks2. * Addition of gr.hier_block2 based versions of gr-wxgui blocks * Conversion of all the example code in gnuradio-examples to use this new code * Conversion of all the gr-utils scripts to use the new code The OFDM examples and related hierarchical blocks have not yet been converted. Code in the rest of the tree that is outside the core and example components has also not yet been converted. This has been done in a way that preserves all the existing functionality; you have to try in order to end up using the new style stuff. So existing, unchanged user code *should* not be affected. Release 3.1 will be the stable release that introduces this new code, and will also be the series that allows you to continue to use the old code. In release 3.2, we will be removing the old-style gr.flow_graph and gr.hier_block implementation, so you'll need to have ported your own code by then. Until we have a porting guide written, your best place to understand the changes is to peruse the examples and blks2impl directories. For users who already have a copy of the trunk checked out, compiled, and installed, it is *required* that you do: $ sudo make uninstall $ make distclean $ svn up ...then build from scratch. There have been directory and filename changes; without uninstalling and cleaning first, you will get a mix old and new on your system. This merge is the last remaining major update to the trunk before release 3.1. Please help to stabilize it by reporting bugs (and I'm sure there will be many) on the list or in Trac. G'day, It built and seems to run fine on NetBSD-i386. Is there a way of telling the install process where to install the example files? I would expect it to be in prefix/share/examples/gnuradio, but it appears to have changed to prefix/share/gnuradio/examples. Also, where do the pmt-serial-tags.scm and pmt-serialize.scm files fit in? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing
G'day, building current source results in an error due to missing file gr_runtime.i. It appears runtime.i was renamed to gr_runtime.i which was missed in the trunk. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing
On Tuesday 11 September 2007 06:11:20 you wrote: Berndt Josef Wulf wrote: G'day, building current source results in an error due to missing file gr_runtime.i. It appears runtime.i was renamed to gr_runtime.i which was missed in the trunk. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio See Johnathan's email of 8/27/2007 11:50 AM PDT: One of the changes is that there are no longer any gr_runtime.* files as this class has been removed from the code as part of an API change. However, due to the somewhat broken way we handle SWIG dependencies, a reference to gr_runtime.i remains in the machine generated dependency files (gnuradio-core/src/lib/swig/*.d). This will cause an *already compiled* local copy of the trunk to fail compilation once it is updated with the latest repository revision. It will *not* affect any freshly checked out copies. If you run into this issue, you can either: 1) Edit gnuradio-core/src/lib/swig/*.d and manually remove the line that references gr_runtime.i in each one, -OR- 2) Delete gnuradio-core/src/lib/swig/*.d and then run ./config.status from the top-level directory, -OR- 3) Check out a fresh copy of the trunk and rebuild (simple but overkill.) Patches welcome from anyone who has a better way of automating tracking of SWIG dependencies that doesn't create the above issue when a dependent file is removed. -Dan Looks like I didn't read all the mail on this list. Thought that make distclean should do the trick. Rebuilt again and all is fine now. Thanks cheerio Berndt --- ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reorganization of gnuradio-examples in trunk r6279
On Wednesday 05 September 2007 04:03:23 Johnathan Corgan wrote: Berndt Josef Wulf wrote: Can we also add a switch that enables building individual modules outside the source tree the way it was prior to GNU-Radio 3.0.2? The way it was prior to 3.0.2 (or maybe it was 3.0.3) was broken. The 'make check' process could fail because of linkage outside the tree vs. inside during a build. That's why I suggested a configure argument switch, which is disabled by default. It would make life lot easier for package builder, well at least for those that do not want to build monolithic packages. Its easy to implement and has no impact on current methodology whatsoever, as it would require a conscious decision in getting this wrong! This will allow building packages as individual modules. I understand the benefit this would have; we will at least reexamine it after the 3.1 release, but no promises. You make my request sound like a complex issue similar to that of an API change. It merely adds another configure option, which only requires a couple of minor changes in the configure script and Makefile.common file. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Reorganization of gnuradio-examples in trunk r6279
On Tuesday 04 September 2007 12:39:00 Johnathan Corgan wrote: All, As of revision 6279 of the GNU Radio trunk software, the gnuradio-examples hierarchy has undergone some reorganization. First, a new top-level component has been created, 'gr-utils', to hold many of the commonly used USRP scripts that aren't really examples, but rather utilities. These now get installed onto the system path so they can be conveniently run from anywhere: usrp_benchmark_usb.py:Test USB--USRP throughput performance usrp_fft.py: Plot FFT, waterfall, or scope of USRP Rx usrp_oscope.py: Plot scope of USRP Rx with extra options usrp_print_db.py: Prints list of installed USRP daughterboards usrp_rx_cfile.py: Record raw USRP Rx data to a file usrp_rx_nogui.py: Receive common analog mods (AM, FM, WFM) usrp_siggen.py: Generate USRP Tx signals usrp_test_counting.py:Test USRP firmware/USB path integrity usrp_test_loop.py: Test USRP digital loopback capability usrp_test_loop_lfsr.py: Test USRP digital loopback (alternate) This component is dependent on having gnuradio-core, gr-usrp, and gr-wxgui also configured for build; this is the default. The gnuradio-examples component itself now installs its various sub-directories into $(prefix)/share/gnuradio/examples/..., so you don't need to keep the source tree lying around to view or run the examples. This allows individual gnuradio-components to install examples into this hierarchy. So the channel-coding examples have been moved into gr-trellis, and only install if gr-trellis itself is being installed. Likewise, the ATSC examples now install onto the system from gr-atsc. Some of the cruft has been deleted or moved into 'limbo' in the repository, and don't get installed. These changes hopefully improve the usability of the GNU Radio distribution. Can we also add a switch that enables building individual modules outside the source tree the way it was prior to GNU-Radio 3.0.2? This will allow building packages as individual modules. The pkgsrc framework keeps track of the dependencies and enables users to pick and choose modules for installation pulling in dependencies as required. The pkgsrc modules are currently patched to facilitate this behaviour. The pkgsrc sources and the corresponding patches can be found on: http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/ham/ I've made mentioning of this many times before but sofare haven't received a reponse nor seen any action. Just let me know if there is any hope to see this implemented. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Eight-core SPARC MCU record
G'day, May be this is of interest to some! http://www.electronicstalk.com/news/sun/sun102.html cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio-3.0.4 available via pkgsrc
G'day, I've just committed gnuradio-3.0.4 into the pkgsrc tree which should become availabe shortly. It may be of interest to some of you to know that GNU Radio was successfully built on hardware platforms such as Alpha, I386, SPARC64, SPARC and X86_64. The NetBSD Packages Collection (pkgsrc) is a framework for building third-party software on NetBSD and other UNIX-like systems, currently containing over 6400 packages. It is used to enable freely available software to be configured and built easily on supported platforms. For more info visit http://www.netbsd.org/docs/software/packages.html. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] missing module usrpm
G'day,
I'm going through the example applications and whilst most work fine, some did
return the following messages and failing to execute:
barossa: {17} ./usrp_wfm_rcv_nogui.py -f 100.3
Traceback (most recent call last):
File ./usrp_wfm_rcv_nogui.py, line 9, in ?
from usrpm import usrp_dbid
ImportError: No module named usrpm
I can't remember seeing this module in previous releases, nor did I see this
error message. Did I miss an options needed for this module to build? I
suspect it to be part of gr-usrp. Where and how is it created? grep'ing
through the source tree I only found references to usrpm but failed to find
the location where it is defined.
Thanks in advance,
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Efficient notch filters
On Tuesday 31 July 2007 08:29:32 Johnathan Corgan wrote: Marcus Leech wrote: Is there a way to produce an efficient notch filter with the bandpass filter designer in Gnu Radio? You can subtract the output of a linear phase bandpass filter from the original signal, as long as the original signal has been delayed by the same number of taps as the filter before the subtraction. I use the band_reject filter option see below: elif options.filter_type == nf: coeffs = gr.firdes.band_reject( 1.0, sample_rate, frequency - (bandwidth/2), frequency + (bandwidth/2), 50, gr.firdes.WIN_HANN) For more info consult the documentation, cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Which swig and boost versions?
G'day, which versions of swig and boost are required for 3.0.4 and beyond? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Next release?
G'day, when can we expect a new release? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] typeo in usrp_bytesex.h?
G'day,
build of svn revision 5249 fails with following error message:
[...]
/bin/ksh ../../../../libtool --tag=CXX --mode=compile
g++ -DHAVE_CONFIG_H -I. -I../../../.. -DOMNITHREAD_POSIX=1
-I../../../../omnithread -I../../../../pmt/src/lib -I../../../../mblock/src/lib
-I../../../../usrp/host/lib/legacy -I../../../../usrp/host/lib/inband
-I../../../../usrp/firmware/include -I/usr/pkg/include -I/usr/pkg/include -g
-O2 -Wall -Woverloaded-virtual -pthread -MT
usrp_server.lo -MD -MP -MF .deps/usrp_server.Tpo -c -o usrp_server.lo
usrp_server.cc
g++ -DHAVE_CONFIG_H -I. -I../../../.. -DOMNITHREAD_POSIX=1
-I../../../../omnithread -I../../../../pmt/src/lib -I../../../../mblock/src/lib
-I../../../../usrp/host/lib/legacy -I../../../../usrp/host/lib/inband
-I../../../../usrp/firmware/include -I/usr/pkg/include -I/usr/pkg/include -g
-O2 -Wall -Woverloaded-virtual -pthread -MT
usrp_server.lo -MD -MP -MF .deps/usrp_server.Tpo -c
usrp_server.cc -fPIC -DPIC -o .libs/usrp_server.o
../../../../usrp/host/lib/legacy/usrp_bytesex.h:43: error: expected `)'
before '(' token
usrp_server.cc: In member function 'virtual void
usrp_server::handle_message(mb_message_sptr)':
[...]
This appears to be due to a typo in usrp_bytesex.h in line 43 where the
declaration of bswap32 should be bswap_32?
NetBSD does support byte-order swapping functions see excerpt of relevant man
page below. The GNU Radio configure script checks for byteswap.h to determine
support for these functions. NetBSD declares these functions in sys/bswap.h
and an appropriate fix would be to modify config/grc_usrp.m4 and
usrp/host/lib/legacy/usrp_bytesex.h, see attached diff files.
The source tree built and installed fine after implementing changes described
above. make check fails with errors in mblock module. I will have to
investigate this further.
sysinfo: NetBSD-i386 4.99.17, gnuradio svn revision 4259
cheerio Berndt
man 3 bswap
--- 8 ---
NAME
bswap16, bswap32, bswap64 -- byte-order swapping functions
LIBRARY
Standard C Library (libc, -lc)
SYNOPSIS
#include sys/types.h
#include machine/bswap.h
uint16_t
bswap16(uint16_t);
uint32_t
bswap32(uint32_t);
uint64_t
bswap64(uint64_t);
--- 8 ---
--- grc_usrp.m4.orig 2007-05-06 10:47:05.0 +0930
+++ grc_usrp.m4 2007-05-06 10:58:54.0 +0930
@@ -51,7 +51,7 @@
# These checks don't fail
AC_C_BIGENDIAN
-AC_CHECK_HEADERS([byteswap.h linux/compiler.h])
+AC_CHECK_HEADERS([byteswap.h sys/bswap.h linux/compiler.h])
AC_CHECK_FUNCS([getrusage sched_setscheduler])
AC_CHECK_FUNCS([sigaction snprintf])
--- usrp_bytesex.h.orig 2007-05-06 10:28:04.0 +0930
+++ usrp_bytesex.h 2007-05-06 11:10:55.0 +0930
@@ -32,6 +32,8 @@
#ifdef HAVE_BYTESWAP_H
#include byteswap.h
+#elif HAVE_SYS_BSWAP_H
+#include sys/bswap.h
#else
static inline unsigned short int
bswap_16 (unsigned short int x)
@@ -40,7 +42,7 @@
}
static inline unsigned int
-bswap32 (unsigned int x)
+bswap_32 (unsigned int x)
{
return x) 0xff00) 24) | (((x) 0x00ff) 8) \
| (((x) 0xff00) 8) | (((x) 0x00ff) 24));
*
The following GNU Radio components have been successfully configured:
config
omnithread
gnuradio-core
pmt
mblock
usrp
gr-usrp
gr-audio-jack
gr-audio-oss
gr-audio-portaudio
gr-atsc
gr-cvsd-vocoder
gr-gsm-fr-vocoder
gr-pager
gr-radio-astronomy
gr-trellis
gr-video-sdl
gr-qtgui
gr-wxgui
gr-sounder
gnuradio-examples
You my now run the make command to build these components.
*
The following components were skipped either because you asked not
to build them or they didn't pass configuration checks:
gr-audio-alsa
gr-audio-osx
gr-audio-windows
gr-comedi
These components will not be built.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] svn-4661: gr-qtgui not building on NetBSD
G'day,
configure detects qt3 but fails to find qwt-5.0.1 and hence won't build
gr-qtqui. It appears that the configure script uses the pkg-config utility to
retrieve metainformation about installed libraries. However, qwt does not
install a pkg-config metadata file. Does qwt install a pkg-config metadata
file on Linux?
The qwt files are currently installed in ${PREFIX}/{include/qwt,lib} and the
plugin in ${QTDIR}/plugin/designer.
gr-qtgui built fine after manually creating a pkg-config metadata file for
qwt. I believe that I shouldn't need to do this.
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing
On Wednesday 28 February 2007 13:19:12 you wrote: Berndt Josef Wulf wrote: I beg to differ. It worked within the pkgsrc environment and only broke in recent RC2. Yes, it appears this was accidentally working before, as we were allowing the system library paths to be included when building inside the tree. Now that we've cleaned things up, we'll need to come up with a different way for this to succeed. By my recollection it was the intent of having these switches to enable developers to select and build individual modules. Greg Troxel has an idea (posted earlier) to address this; unfortunately, it's too large of a change to make it into the stable branch until we get thorough testing on the trunk. So release 3.03 will work as-is. In this case I will base the pkgsrc collection on RC1 for now, which I have ready for commit. It would be nice to see a solution for future releases. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] svn-4661: gr-qtgui not building on NetBSD
On Wednesday 28 February 2007 13:24:19 you wrote: Berndt Josef Wulf wrote: configure detects qt3 but fails to find qwt-5.0.1 and hence won't build gr-qtqui. It appears that the configure script uses the pkg-config utility to retrieve metainformation about installed libraries. However, qwt does not install a pkg-config metadata file. Does qwt install a pkg-config metadata file on Linux? No. First, the new gr-qtgui component is a work-in-progress, so it doesn't do anything much useful yet (other than in a very specific test scenario used last week during the OFDM bash). The configure script is incomplete. The group was using a manually created qwt.pc file as a substitute to fishing this out autotools macros. Bob McGwier will be updating the .m4 file to work without the .pc file, and then it should start working on several platforms. gr-qtgui built fine after manually creating a pkg-config metadata file for qwt. I believe that I shouldn't need to do this. Correct, see above. Sorry, I didn't realise that gr-qtgui wasn't ready for public release yet. It caught my attention as I've been writing some widgets using pyqt. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing
G'day, latest release candidate breaks when compiling individual packages. This is due to intree dependencies that are nolonger satisfied under the following condition, e.g.: ./configure --prefix=/usr/pkg --disable-all-components --enable-gr-audio-oss resulting in: gmake[4]: Entering directory `/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src' gmake[4]: *** No rule to make target `../../gnuradio-core/src/lib/libgnuradio-core.la', needed by `_audio_oss.la'. Stop. gmake[4]: Leaving directory `/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src' gmake[3]: *** [all] Error 2 gmake[3]: Leaving directory `/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/src' gmake[2]: *** [all-recursive] Error 1 gmake[2]: Leaving directory `/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss' gmake[1]: *** [all-recursive] Error 1 gmake[1]: Leaving directory `/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2' gmake: *** [all] Error 2 *** Error code 2 With this in place, pkgsrc will nolonger be able to build individual packages for each module as in the past. cheerio Berndt On Tuesday 27 February 2007 09:31:04 Johnathan Corgan wrote: All, GNU Radio release candidate 3.0.3rc2 is available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.0.3rc2.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.0.3rc2.tar.g z This is a bug fix and very minor enhancement release to the existing 3.0 stable branch. All relevant issues that have been corrected on the main development trunk have been back-ported. Details on the changes since release 3.0.3rc1 are listed here: http://gnuradio.org/trac/wiki/Release3.0Branch As usual, please report any problems via the Trac ticket system, using the 'guest' account with password 'gnuradio': http://gnuradio.org/trac/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing
My guess is that one could make it a special case of disable-all-components --enable- when building a specific component. pkgsrc builds packages in a sandbox filesystem containing all package dependencies hence it was never an issue. cheerio Berndt On Tuesday 27 February 2007 10:57:54 you wrote: Do the packages install the .la file? Perhaps some sort of conditional that uses in-tree for configured component and in-$libdir for unconfigured components would be the right thing. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing
On Tuesday 27 February 2007 12:31:13 you wrote: On Tue, Feb 27, 2007 at 11:39:36AM +1030, Berndt Josef Wulf wrote: G'day, latest release candidate breaks when compiling individual packages. This is due to intree dependencies that are nolonger satisfied under the following condition, e.g.: ./configure --prefix=/usr/pkg --disable-all-components --enable-gr-audio-oss resulting in: gmake[4]: Entering directory `/usr/pkgsrc/ham/gnuradio-audio-oss/work/gnuradio-3.0.3rc2/gr-audio-oss/s rc' gmake[4]: *** No rule to make target `../../gnuradio-core/src/lib/libgnuradio-core.la', needed by `_audio_oss.la'. Stop. FYI, this isn't new behavior. It's been like this (or should have been like this) since the build system overhaul. I understand your desire to build individual pieces, but that hasn't been coded up yet. Eric I beg to differ. It worked within the pkgsrc environment and only broke in recent RC2. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] calling python from C/C++
G'day, where can I find a simple working example that demonstrates how to create and call a python function from C/C++? I've written an eventhandler for the powermate device in C++ and want to call the relevant python eventhandlers. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
G'day,
I've successfully built and tested gnuradio-3.0.3rc1 with pkgsrc see below:
barossa: {376} make install
=== Checking for vulnerabilities in gnuradio-3.0.3rc1
=== Installing for gnuradio-3.0.3rc1
= Automatic manual page handling
= Registering installation for gnuradio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-jack-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-oss-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-audio-portaudio-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-core-docs-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-examples-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-gsm-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-howto-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-radio-astronomy-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-trellis-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-video-sdl-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package gnuradio-wxgui-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-3.0.3rc1
gnuradio-3.0.3rc1 requires installed package usrp-docs-3.0.3rc1
barossa: {377}
BTW: Is there any particular reason why gr-howto-write-a-block is standalone
and not part of the gnuradio distribution? Seems odd
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] usrp_spectrum_sense.py: object has no attribute 'bin_statistics_f
G'day,
Is usrp_spectrum_sense.py suppose to work with 3.0.3RC1?
It's failing with -
Using RX d'board A: TV Rx
Traceback (most recent call last):
File ./usrp_spectrum_sense.py, line 236, in ?
fg = my_graph()
File ./usrp_spectrum_sense.py, line 169, in __init__
stats = gr.bin_statistics_f(self.fft_size, self.msgq,
AttributeError: 'module' object has no attribute 'bin_statistics_f'
barossa: {15} vi usrp_spectrum_sense.py
I suspect that it isn't part of this release yet.
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
On Thursday 22 February 2007 15:18, Eric Blossom wrote: On Thu, Feb 22, 2007 at 02:43:09PM +1030, Berndt Josef Wulf wrote: G'day, RC1 built fine, but I'm seeing a number of these errors during gmake check. == ERROR: test_fff_002 (__main__.test_fft_filter) -- Traceback (most recent call last): File ./qa_fft_filter.py, line 191, in test_fff_002 self.fg.run() File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr /flow_graph.py, line 112, in run self.start () File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr /flow_graph.py, line 93, in start self.scheduler.start () File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr /scheduler.py, line 57, in start thread.start() File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr /gr_threading_24.py, line 420, in start _start_new_thread(self.__bootstrap, ()) error: can't start new thread Not sure about those... Sounds like you are running out of some system resource. another issue already highlighted by Greg Toxel is Testing gr_vmcircbuf_sysv_shm_factory... gr_vmcircbuf_sysv_shm: shmat (1): Too many open files gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument ... gr_vmcircbuf_sysv_shm_factory: Doesn't work Testing gr_vmcircbuf_mmap_shm_open_factory... Those aren't (hard) failures. They just indicate that under stress testing your shm* stuff won't work. Greg posted a note to the list a while ago about how to bum p up the default number of shm segments available. When shm* doesn't work, we use other techniques such as shm_open or mmap'ing a tmp file. Will install and test RC1 later tonight. Thanks, Eric Greg's suggestion of bumping the values for shmmni and shmseg helped to solve the shmat(1) related matter. shmget(1) still fails with invalid argument when the second parameter of shmget evaluates to 8396800 - e.g. shmget(IPC_PRIVATE=0, size=8396800, pagesize=4096) No luck with thread related errors. It may be due to recent changes we had in the NetBSD source tree. Running the usual suspects from gnuradio-examples appear to be fine. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing
G'day, RC1 built fine, but I'm seeing a number of these errors during gmake check. == ERROR: test_fff_002 (__main__.test_fft_filter) -- Traceback (most recent call last): File ./qa_fft_filter.py, line 191, in test_fff_002 self.fg.run() File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py, line 112, in run self.start () File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/flow_graph.py, line 93, in start self.scheduler.start () File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/scheduler.py, line 57, in start thread.start() File /usr/src/gnuradio/gnuradio-3.0.3rc1/gnuradio-core/src/python/gnuradio/gr/gr_threading_24.py, line 420, in start _start_new_thread(self.__bootstrap, ()) error: can't start new thread another issue already highlighted by Greg Toxel is Testing gr_vmcircbuf_sysv_shm_factory... gr_vmcircbuf_sysv_shm: shmat (1): Too many open files gr_vmcircbuf_sysv_shm: shmget (1): Invalid argument ... gr_vmcircbuf_sysv_shm_factory: Doesn't work Testing gr_vmcircbuf_mmap_shm_open_factory... Will install and test RC1 later tonight. cheerio Berndt On Thursday 22 February 2007 03:58, Johnathan Corgan wrote: All, GNU Radio release candidate 3.0.3rc1 is available for testing: http://gnuradio.org/releases/gnuradio/gnuradio-3.0.3rc1.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.0.3rc1.tar.g z This is a bug fix and very minor enhancement release to the existing 3.0 stable branch. All relevant issues that have been corrected on the main development trunk have been back-ported. Details on the changes since release 3.0.2 are listed here: http://gnuradio.org/trac/wiki/Release3.0Branch Unfortunately, this release candidate does not include a fix for ticket:39 (/lib vs /lib64 issues on Fedora Core 5 and 6). Those developers who are affected by this issue and can perform testing of potential fixes should contact Eric Blossom. As usual, please report any problems via the Trac ticket system, using the 'guest' account with password 'gnuradio': http://gnuradio.org/trac/ ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GRC version 0.60
On Saturday 10 February 2007 04:25, Hans Glitsch wrote: Hi Josh, This is really nice. A great interface. The only problem is that it doesn't have some of the blocks I am using. :( Feature request: rational_resampler and freq_xlating_fir_filter Hallo Hans, the frequency translating fir filter is supported. Just select the low/high/bandpass filters, double click on the box and select the desired filter type from the drop-down menu, e.g. Xlating FIR: Complex-Complex cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FYI: svn-current build problem
G'day, I'm currently seeing this when attempting to compile svn-current revision 4315. g++ -DHAVE_CONFIG_H -I. -I../../../.. -I../../../../gnuradio-core/src/lib/runtime -I../../../../gnuradio-core/src/lib/general -I../../../../gnuradio-core/src/lib/general -I../../../../gnuradio-core/src/lib/gengen -I../../../../gnuradio-core/src/lib/gengen -I../../../../gnuradio-core/src/lib/filter -I../../../../gnuradio-core/src/lib/filter -I../../../../gnuradio-core/src/lib/reed-solomon -I../../../../gnuradio-core/src/lib/io -I../../../../gnuradio-core/src/lib/g72x -I../../../../gnuradio-core/src/lib/omnithread -I../../../../gnuradio-core/src/lib/swig -I../../../../gnuradio-core/src/lib/swig -I/usr/pkg/include -I/usr/pkg/include/python2.4 -I. -I/usr/pkg/include -g1 -O1 -Wall -Woverloaded-virtual -pthread -MT _gnuradio_swig_py_io_la-gnuradio_swig_py_io.lo -MD -MP -MF .deps/_gnuradio_swig_py_io_la-gnuradio_swig_py_io.Tpo -c gnuradio_swig_py_io.cc -fPIC -DPIC -o .libs/_gnuradio_swig_py_io_la-gnuradio_swig_py_io.o ../../../../config.h: In function 'double exp10(double)': ../../../../config.h:417: error: redefinition of 'double exp10(double)' ../../../../config.h:417: error: 'double exp10(double)' previously defined here ../../../../config.h: In function 'double exp10(double)': ../../../../config.h:417: error: redefinition of 'double exp10(double)' ../../../../config.h:417: error: 'double exp10(double)' previously defined here ../../../../gnuradio-core/src/lib/io/gr_udp_source.cc: In member function 'virtual int gr_udp_source::work(int, gr_vector_const_void_star, gr_vector_void_star)': ../../../../gnuradio-core/src/lib/io/gr_udp_source.cc:139: warning: comparison between signed and unsigned integer expressions gmake[6]: *** [_gnuradio_swig_py_io_la-gnuradio_swig_py_io.lo] Error 1 gmake[6]: Leaving directory `/home/wulf/projects/gnuradio/gnuradio/gnuradio-core/src/lib/swig' gmake[5]: *** [all] Error 2 gmake[5]: Leaving directory `/home/wulf/projects/gnuradio/gnuradio/gnuradio-core/src/lib/swig' I haven't had a chance to further investigate this as I'm preparing to go interstate. AFAIK, libm doesn't support exp10() on NetBSD and hence it shouldn't be defined. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG compilation speedup!
On Saturday 13 January 2007 15:05, Eric Blossom wrote:
I've just checked code into the trunk that speeds up compilation of
the swig generated code, as well as reducing the number of
dependencies for each piece.
-r4255 refactors gnuradio_swig_python.{cc,py} into 5 separate .so's
These correspond to the runtime, general, filter and io directories,
and also includes a new directory, gengen. gengen contains that part
of general that was machine generated. This split is arbitrary, but
was useful for getting size of the swig generated glue code for
general down to about 2MB.
In addition, the swig glue is now compiled with -g1 -O1 instead of
-g -O2. With this change all the swig code now compiles in about 60%
of the time that it used to take.
Packagers, please note that there are now 5 SWIG generated .so's and
.py's in gnuradio-core that replace the previous 1
(gnuradio_swig_python.{so,py})
What are the issues with the compile time? This topic came up previously in
discussions which determined that documentation will nolonger be generated by
default due to build time.
I can't see the point for doing so. I don't care if its takes me 15 minutes or
30 minutes to compile all GNU Radio.
Compilation time saved will now be spend waiting for the download?
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Heard FM on the basic RX hooray!
On Saturday 06 January 2007 05:05, M. Ranganathan wrote: After some (perhaps needless) struggle I am happy to report I finally got to listen to some FM stations using the basic Rx. Some tips for the wary newcomer: 1. Dont try to build wxPython. It requires an act of God to get all the pieces together to make that happen. Instead install from the binary that you can get from wxPython.org. Unless you use pkgsrc in which case you just type make install in meta-pkgs/gnuradio. pkgsrc will build and install gnuradio including documentation, examples and all missing dependencies... :-) 2. You are best off inserting a wire into the connector for the Antenna. Radio shack does not cary a suitable antenna that fits into the connector. Get a SMA to BNC or SMA to N adapter which are available from Farnell, RS or much cheaper on Ebay! It makes life so much easier! I've installed the USRP and all accessories inside a 19 rackmount enclosure. 3. You dont need anything more than a long wire as an RF Front End to just fiddle around and get some FM reception. Yep, that how I started. However, a low noise broadband amplifier will bring very subtle improvements. I have a RFA-403 low noise broadband amplifier (0.01-2.0GHz) that is used as a LNA and exciter amplifier. Its low cost (29,90 EUR), easy to build kit available from http://www.funkamateur.de So it actually works! That was the point of the exercise. I have the worlds most expensive FM radio finally (for the quality of sound I get from it anyway -- no this is not a complaint). I will now proceed to figure out the various pieces that make this all work. Now that you've got this far, I'm sure there are many other applications for you to explore and enjoy. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] graphical interface for gnu radio
On Monday 01 January 2007 18:30, Josh Blum wrote:
I have been working on a graphical interface for gnu radio. I was
wondering if there are any gnu radio enthusiasts willing to check out my
program and give me some feed back. I call it gnu radio companion or
GRC. Here is the link http://www.joshknows.com/?key=grc
Interesting, but doesn't run on a NetBSD-4.99.5 system see below:
barossa: {72} ./Main.py
app init
python: Error detected by libpthread: Unlocking unlocked mutex.
Detected by file /usr/src/lib/libpthread/pthread_mutex.c, line 363,
function pthread_mutex_unlock.
See pthread(3) for information.
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] problem with just checked out and recompiled gnuradio
On Tuesday 19 December 2006 23:42, Greg Troxel wrote:
I probably didn't rebuild all since swig upgrade to 1.3.31.
I suppose the Makefile.am's need to have a dependency on the swig
executable :-) (I know, ENOPATCH...)
I got a different error, so I did make distclean and a full rebuild.
Now I get this, which I'll look into when I get a chance.
gdt 199 /usr/adroit/lib/python2.4/site-packages/gnuradio python
Python 2.4.3 (#1, Jul 11 2006, 02:04:00)
[GCC 3.3.3 (NetBSD nb3 20040520)] on netbsd3
Type help, copyright, credits or license for more information.
from gnuradio import _audio_oss
Traceback (most recent call last):
File stdin, line 1, in ?
ImportError:
/usr/adroit/lib/python2.4/site-packages/gnuradio/_audio_oss.so:
Undefined PLT symbol _ZN14gr_basic_block11basic_blockEv (symnum =
81)
FYI:
Works fine here on NetBSD-4.99.5, swig-1.3.31 and gcc-4.2.1:
barossa: {48} python
Python 2.4.3 (#1, Aug 20 2006, 03:28:21)
[GCC 4.1.2 20060628 prerelease (NetBSD nb2 20060711)] on netbsd4
Type help, copyright, credits or license for more information.
from gnuradio import _audio_oss
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] USRP sample rate
G'day, I'm toying with the idea of using an external programmable clock for the USRP. Is there a way of setting the USRP sample rate without needing to build custom firmware? If not, would it be doable? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] PlayStation 3
You can get them on Ebay for around AU$1000 which is about US$750 or thereabouts with 27m to go. http://cgi.ebay.com.au/Sony-PS3-60GB-Playstation-3-PS-3-3-game-2-controller_W0QQitemZ250060054687QQihZ015QQcategoryZ11328QQrdZ1QQcmdZViewItem cheerio Berndt On Tuesday 12 December 2006 13:42, Eric A. Cottrell wrote: Robert McGwier wrote: Now if we can only get our hands on one or more of these PS3's. If you want to get a real laugh, search for PS3 using froogle and look at all of the listings in the thousands of dollars. MADNESS. Anyway, now that we have very good information, I have placed my pre-order with Yellow Dog Linux FROM Yellow Dog Linux for $100. This is a nonrefundable deposit. If you do this, it comes preloaded with YDL, running when it shows up, and the delta price between PS3 and PS3+YDL is less than them individually. Bob Hello, Not to mention the violence associated with just owning or wanting to own the PS3. March/April time frame seems like a long time to wait for a device released in November. Might as well buy one at Dayton. Pre-Christmas shopping for hot items is insane madness. There may be some hope in January to get one. My company has given me Boxing Day off as a bonus. I am going to hang around and see if I can pick up a PS3 after the user has fallen into The Uncanny Valley. :) What is the street price for a PS3? I read somewhere that there is $800 worth of hardware in the box. Does that make it a $1200 to $1600 toy? Isn't USB getting too slow for input with this type of box? How am I going to decode and display two HDTV signals at the same time? 73 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] APT signals
G'day, I managed to capture the spectrum emitted by NOAA-12 for its entire pass; not quite sure anymore which one it was. Using a Diamond D130 discone antenna and a low noise broadband power amplifier (10-2000MHz, g=20dB, nf=3.5, po=+20dbm!!!) the signal was recorded utilizing the usrp_rx_cfile.py python script, a gain of 100, and decimation of 250 centered on 137.5MHz. It produced a very large file -rw-r--r-- 1 root wheel 1117519872 Dec 9 20:01 noaa-12.dat This a little more than 1GB and 419MB zipped. Do we have a place were it can be uploaded for other list members that are interested? My bandwidth isn't large enough to offer it to public from here. I was surprised how loud the signal was, considering the equipment used here, and how well the TVRX card performed. Now I'm really looking forward to shooting the big birds = geostationary satellites. BTW: Do we have an AFC block to compensate for doublershift or is this something we still need to implement? I looked through the documentation but failed to find anything there. cheerio Berndt On Saturday 09 December 2006 16:52, Berndt Josef Wulf wrote: G'day, I'm looking for raw data. Don't you use the usrp_rx_cfile.py script to capture frequency spectrum? e.g.: ./usrp_rx_cfile.py -d 32 -f 137.5M You may need to play with the options -R, -g, -N (subdev, gain and number of samples) depending on your setup where -R [A|B] site where the tvrx is plugged in -g 0..115 gain (default is mid-point @ 58) -N positive int number of samples (e.g samplerate * record time in sec) I usually have to specify the frequency and the decimation. I want to write my own decoder and an image sink to ultimately display the pictures received and hence audio files want do the trick. cheerio Berndt On Saturday 09 December 2006 14:29, Bill Tracey wrote: Berndt, I can grab some APT audio with a USRP and Bob McGwier's rx apt code. Or are you looking for the raw data coming off the TVRF -- could probably do that as well but will need some pointers as to how to grab the raw sample off the TVRF card -- suppose one just takes the rxapt python code and hacks it to dump to a file sink? I've also got a Hamtronics R139 I can grab audio from -- although it's gotten a bit deaf of late. Pics from it can be seen @: http://oddjob.yi.org:/wxpics/index.html Regards, Bill At 10:44 PM 12/8/2006, you wrote: G'day, Ok, let's try it this way: Is there someone with the equipment and time to record APT signals transmitted by NOAA satellites in the 137MHz band? Alternatively, geostationary weather satellites transmit WEFAX pictures at around 1691MHz (Hey, were are the guys that tuned into GPS spectrum which is right next door... :-) I want to demodulate the AM/FM 2400Hz sub-carrier signal and display the image. Currently I'm not in the position to capture the spectrum myself due to lack of equipment but this is about to change. I can provide info on satellite passes and frequencies for your location. cheerio Berndt On Wednesday 06 December 2006 14:20, Berndt Josef Wulf wrote: G'day, Has anyone sampled NOAA or METEOR signals in the 137MHz spectrum which they wouldn't mind sharing the spectrum data file(s)? ___ 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] APT signals
G'day, Ok, let's try it this way: Is there someone with the equipment and time to record APT signals transmitted by NOAA satellites in the 137MHz band? Alternatively, geostationary weather satellites transmit WEFAX pictures at around 1691MHz (Hey, were are the guys that tuned into GPS spectrum which is right next door... :-) I want to demodulate the AM/FM 2400Hz sub-carrier signal and display the image. Currently I'm not in the position to capture the spectrum myself due to lack of equipment but this is about to change. I can provide info on satellite passes and frequencies for your location. cheerio Berndt On Wednesday 06 December 2006 14:20, Berndt Josef Wulf wrote: G'day, Has anyone sampled NOAA or METEOR signals in the 137MHz spectrum which they wouldn't mind sharing the spectrum data file(s)? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] APT signals
G'day, I'm looking for raw data. Don't you use the usrp_rx_cfile.py script to capture frequency spectrum? e.g.: ./usrp_rx_cfile.py -d 32 -f 137.5M You may need to play with the options -R, -g, -N (subdev, gain and number of samples) depending on your setup where -R [A|B]site where the tvrx is plugged in -g 0..115 gain (default is mid-point @ 58) -N positive int number of samples (e.g samplerate * record time in sec) I usually have to specify the frequency and the decimation. I want to write my own decoder and an image sink to ultimately display the pictures received and hence audio files want do the trick. cheerio Berndt On Saturday 09 December 2006 14:29, Bill Tracey wrote: Berndt, I can grab some APT audio with a USRP and Bob McGwier's rx apt code.Or are you looking for the raw data coming off the TVRF -- could probably do that as well but will need some pointers as to how to grab the raw sample off the TVRF card -- suppose one just takes the rxapt python code and hacks it to dump to a file sink? I've also got a Hamtronics R139 I can grab audio from -- although it's gotten a bit deaf of late. Pics from it can be seen @: http://oddjob.yi.org:/wxpics/index.html Regards, Bill At 10:44 PM 12/8/2006, you wrote: G'day, Ok, let's try it this way: Is there someone with the equipment and time to record APT signals transmitted by NOAA satellites in the 137MHz band? Alternatively, geostationary weather satellites transmit WEFAX pictures at around 1691MHz (Hey, were are the guys that tuned into GPS spectrum which is right next door... :-) I want to demodulate the AM/FM 2400Hz sub-carrier signal and display the image. Currently I'm not in the position to capture the spectrum myself due to lack of equipment but this is about to change. I can provide info on satellite passes and frequencies for your location. cheerio Berndt On Wednesday 06 December 2006 14:20, Berndt Josef Wulf wrote: G'day, Has anyone sampled NOAA or METEOR signals in the 137MHz spectrum which they wouldn't mind sharing the spectrum data file(s)? ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Attenuators ?
On Friday 08 December 2006 08:40, Shravan Rayanchu wrote: Hello everyone, I want to be able to capture RF data from one wireless card using gnuradio without any external interference. I was thinking of using an attenuator (with SMA or BNC connectors) one end of which I can connect to a wireless card and the other end to gnuradio board. I have some PCMCIA wireless cards which have the BNC-F interface. Two questions: 1. What is the minimum attenuation required so that I dont end up frying the boards? You should be save by inserting 40db attentuation. 2. I would like to have the attenuation to be tunable. Do you know of any tunable attenuators (preferably low cost) which fit my requirements? Have a look on ebay. There are plenty of adjustable (not frequency tunable) attentuators and fixed attentuators for sale. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gEDA PCB can't read usrp-hw/rfx/pcb/*pcb layouts
G'day, which program was used to generate the usrp-hw/rfx/pcb/*pcb layout files? The gEDA PCB layout program returns illegal file format, however, it reads the basic RX/TX daughter boards. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] 137MHz NOAA and METEOR signals
G'day, Has anyone sampled NOAA or METEOR signals in the 137MHz spectrum which they wouldn't mind sharing the spectrum data file(s)? Thanks, 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] audio sampling rate problem after Ubuntu 6.06 downgrade...
On Sunday 03 December 2006 06:26, Dave hartzell wrote: After a failed attempt to upgrade to Ubuntu 6.10, I reformatted and re-installed 6.06. I had heard of problems to 6.10 (broken X), but didn't listen I'm back to normal (at least with Gnu Radio) and now I'm having an audio card sample rate problem that was NOT there with my initial install of 6.06. This can be fixed with the -O plughw:0,0 runtime CLI option, but anyone have any clues as to why this is required now? No hardware was changed in the install process...maybe I should upgrade from the on-board sound... G'day, You may want to create a directory such as mkdir ~/.gnuradio Then create a file called config.conf containing your default settings (below are those of mine): [audio] audio_module = audio_oss [audio_oss] default_input_device = /dev/audio default_output_device = /dev/audio latency = 0.005 This should do the trick. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD
On Sunday 03 December 2006 07:42, Jordan Hayes wrote: Everytime I run a (v3.0.2) gnuradio program (on NetBSD 3.1), I get the following message: usb_control_msg failed: error sending control message: Input/output error It doesn't seem to stop the program from running, but it's a little annoying. Anyone know what it means? This was raised previously in following thread http://www.nabble.com/USRP-on-NetBSD-p1964955.html No fix has surfaced since then. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Scanning/Detecting Wifi
G'day Greg, I've updated pkgsrc/ham/gnuradio-core to 3.0.2nb1. It fixes a bug that I encountered in gr.firdes.band_reject() function. At least it returns the expected result :-) cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] SWIG 1.3.31 now required on the trunk
On Friday 01 December 2006 09:31, Eric Blossom wrote: We've decided to require SWIG 1.3.31 to compile the trunk. We try to avoid upping the mininum rev level of any our dependencies, but this one's required for proper support of SWIG directors. I believe that it also brings in support for Python 2.5, but I haven't tested that yet. Sorry for any inconvenience this may bring. The good news is that if your distribution doesn't yet package SWIG 1.3.31, SWIG is very easy to build from source. It's the normal ./configure make sudo make install dance. Is this version backward compatible, e.g. will built the older versions? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] FYI: Core 2 Duo CPU SBC
Found this new product very interesting for embedded applications: http://www.commell.com.tw/News/News/News_20061120_LS-371.htm cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Q from a novice user in Japan
G'day,
I've also built epydoc 3.0alpha3 and tried to generate documentation run it
against ${PYSITELIB}/gnuradio. It produced a lot of documentation but it
failed prior to finishing. There were a lot of warnings and the process
failed in wxgui.
If someone was successful in completing the conversion, perhaps it may be a
good idea to make the documentation available as a package. I certainly would
appreciate it.
Thanks,
cheerio Berndt
On Tuesday 28 November 2006 04:01, Mamoru Yamamoto wrote:
Dear Colleagues,
Yesterday I re-installed the epydoc from the subversion
repository of epydoc, and tried formatting the GNUradio
python libraries. epydoc version would be 3.0, I suppose.
The result was much better than before. Though I met
some errors, I could generate useful HTMLs with which I can
browse python functions. Thanks for Eric's suggestion.
I also learned that after import any module in python,
we can show its help information by typing help(module).
Sorry I am too ignorant to this software package.
Regards,
Mamoru Yamamoto [EMAIL PROTECTED]
Eric,
Thank you for your answer.
For our applicaion 150MHz and 400MHz receivers must synchronize
very precisely. I cannot use TV RX for this reason. Is the
frequency 150MHz too high for Basic RX board? We may need
to add more amplifiers between the antenna and the USRP.
Thank you very much for the information of epydoc.
I installed ver 2.1 from yum (Fedore Core 4), and run it.
But as other E-mail says, I got many errors. It created
some results, but I do not know if they are very useful
or not... Should I use Ver 3.0 of the epidoc?
Regards,
Mamoru Yamamoto
On Thu, Nov 09, 2006 at 03:30:28AM +0900, Mamoru Yamamoto wrote:
Dear GNUradio experts,
I am very new to GNUradio. I am in Kyoto University, Japan studying
ionosphere by using radar and other techniques. I am interested
in developing a 150/400MHz beacon receiver with GNUradio + USRP.
Now I have a USRP base board + Basic RX + Flex 400 for this purpose.
OK.
A TV RX daughterboard might be a better choice for the 150 MHz beacon.
I have some questions.
--- How I can get information on Python functions?
Documents generated by doxygen explain only
C++ part of the software. (Am I correct?)
To know Python functions, do I need to read through
codes? I would like to know if there is a list
or man-pages of such Python functions. My application
may not require any new C++ coding.
You could run epydoc on the python code in and under gnuradio-
core/src/python.
Most of the code has epydoc doc strings.
--- I learned GNUradio and USRP from network very much.
Thank you very much. But informations are very much
scattered. Don't you have a plan of GNUradio (plus USRP) book?
We've thought about it. Thanks for the words of encouragement.
Thanks for your help. Regards,
Mamoru Yamamoto [EMAIL PROTECTED]
You're welcome.
Eric
Mamoru Yamamoto [EMAIL PROTECTED]
___
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] grc_gr_wxgui.m4 fix
G'day Folks,
please find patch below that fixes above config file for pkgsrc and should
continue to work for all other platforms.
cheerio Berndt
--- grc_gr_wxgui.m4.orig2006-11-24 22:56:31.0 +1030
+++ grc_gr_wxgui.m4 2006-11-24 22:56:54.0 +1030
@@ -26,9 +26,7 @@
gr-wxgui/src/python/Makefile \
])
-# FIXME: this breaks pkgsrc by calling python without a version number
-# gdt--patch welcome :-)
-if python -c 'import wx'; then
+if ${PYTHON} -c 'import wx'; then
passed=yes
else
passed=no
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr.firdes.band_reject()
G'day, I have a problem using the above function. My assumption is that band_reject means the rejection of a portion of a spectrum as used in notch filters. The following filter design does not show up the expected notch in the spectrum. To the contrary, the spectrum shows a slight increase of the noise contents at 1000Hz. sample_rate = 48000 frequency = 1000 bandwidth = 100 coeffs = gr.firdes.band_reject( 1.0, sample_rate, frequency - (bandwidth/2), frequency + (bandwidth/2), 50, gr.firdes.WIN_HANN) filter = gr.fir_filter_fcc(1, coeffs) The band/low/high pass filters work as expected. I use gr.noise_source and fft_sink to verify the design. What am I doing wrong? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] GNU Radio Wikis
G'day, where did the old GNU Radio Wiki go? I'm looking for the pages containing information on user applications, sample data files, howto files etc. I can't find them on www.gnuradio.org/trac/wiki anymore. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD Package Collection for GNU Radio 3.0.2
G'day, For those running NetBSD, I've updated the NetBSD Packages Collection to accommodate the release of GNU Radio 3.0.2. GNU Radio is split into modular packages, see below, giving users maximum control over the installation process. Those that are lazy may issue make install inside the meta-pkgs/gnuradio directory which will build and install all GNU Radio modules including any missing dependencies. Meta-Package: = gnuradio-3.0.2 New Package: gnuradio-core-docs-3.0.2 gnuradio-audio-jack-3.0.2 gnuradio-audio-portaudio-3.0.2 gnuradio-video-sdl-3.0.2 gnuradio-trellis-3.0.2 gnuradio-radio-astronomy-3.0.2 usrp-docs-3.0.2 Updated Packages: gnuradio-core-3.0.2 gnuradio-audio-oss-3.0.2 gnuradio-gsm-3.0.2 gnuradio-usrp-3.0.2 gnuradio-wxgui-3.0.2 gnuradio-examples-3.0.2 gnuradio-howto-3.0.2 usrp-3.0.2 Visit http://www.netbsd.org/Documentation/software/packages.html for more information about the NetBSD Packages Collection. Note: NetBSD Packages Collection supports many other platforms including Linux, FreeBSD, Solaris, OS/X and many more - see below http://www.netbsd.org/Documentation/software/packages.html#platforms Enjoy, 73, Berndt VK5ABN ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Ettus Research announcements Nov 2006
I think that the compulsory addition of a housing will deter many people on low budget from purchasing a USRP. It has become a pricy commodity. Just my opinion, cheerio Berndt On Monday 13 November 2006 07:13, Matt Ettus wrote: USRP Update, Nov 12th, 2006 In this issue -- 1 USRP-announce Mailing List 2 Enclosure [Finally] Available! 3 SDR06 Conference == Mailing List Changes - There is a new USRP-announce mailing list. This list will only be used for announcements, about once or twice a month, and users cannot post to it. It will only be used for announcements about the USRP family of products. If interested, you can subscribe to it here: http://aeinet.com/mailman/listinfo/usrp-announce USRP Enclosure Now Available! - We are pleased to announce the availability of the new USRP Enclosure. This oft-requested item is made out of black anodized aluminum, and includes a fan and 2 RF cables. The enclosure, which measures 8.25 by 6.5 by 2 (210mm by 167mm by 54mm) has front-panel cutouts for the power, USB, and 5 SMA bulkhead connectors. The enclosure comes with 2 SMA cables, male on one side to connect to daughterboards inside the box, and female bulkhead to mount to the box on the other side. More cables are available for those needing more than 2 RF connections to the outside of the box. The only restriction the enclosure places on usage is that only one TVRX board may be used at a time. Other daughterboards are not affected. Going forward, all USRPs ordered will come with the enclosure, fan, 2 cables, and appropriate hardware. The price of the USRP has been adjusted to reflect this. For those who already own USRPs, you can purchase the enclosure/fan/cables/hardware package separately for $125. Pictures of the enclosure are here: http://gnuradio.org/enclosure.jpg http://gnuradio.org/enclosure_open.jpg === SDR06 Conference and Trade Show --- Ettus Research will have a booth (#207) at the SDR06 conference and trade show happening this week in Orlando, from Monday through Thursday. There will be live demos of the USRP in action. We look forward to meeting those of you who are attending. If you'd like to arrange a meeting outside of the tradeshow, you can do so by email ([EMAIL PROTECTED]) or in person at the booth. More info on the show can be found here: http://sdrforum.org/pages/sdr06/forumMeeting_sdr06_main.asp === Thanks for your time, Matt Ettus ___ 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] --disable-all-components --enable-gr-usrp doesn't built
G'day, ./configure --sysconfdir=/usr/pkg/share/examples --disable-all-components --without-libintl-prefix --prefix=/usr/pkg --host=i386--netbsdelf --mandi r=/usr/pkg/man doesn't build due to usrp not being build. To reproduce, on a system with the usrp-module already installed, install a fresh tarball and try to build gr-usrp only. The following comment was found inside the configure script: # Don't do gr-usrp if usrp skipped # There *has* to be a better way to check if a value is in a string I consider this to be a bug since configure should check for availability of the usrp-module system wide and not just inside the tarball package. I successfully built gr-usrp after bypassing this limitation. Whilst most users will build usrp and gr-usrp together, IMHO, a fix is desirable in order to be consistent and enable modular packaging of gnuradio. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gr-howto-write-a-block
G'day, are there any compelling reasons why this module isn't part of the main tree like the other modules? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio-core and usrp documentation
G'day,
do gnuradio-core and usrp now install their docs into a common directory such
as ${prefix}/share/doc/gnuradio-${VERSION} ?
If so, there will be conflicts for filenames that exist for both packages,
e.g. README, index.html etc.
Prior to the mega tarball, documentation was installed into seperate
directories - see below
${prefix}/share/doc/gnuradio-${VERSION}
${prefix}/share/doc/usrp-${VERSION}
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] README.hacking missing
G'day, FYI: The inofficial release installs ChangeLog, README and attempts to install README.hacking, which doesn't exist in the tarball. It also crjeates an empty directory share/doc/gnuradio/html BTW: Is there any point at all to install these files if a user decided to disable the creation of all other documents (e.g those created by doxygen, latex and friends)? Just curious. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] README.hacking missing
G'day,
Below is a partial log documenting the installation of the files in question:
gmake[3]: Entering directory
`/usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/doc'
mkdir -p html
gmake[4]: Entering directory
`/usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/doc'
gmake[4]: Nothing to be done for `install-exec-am'.
/usr/bin/install -d /usr/pkg/share/doc/gnuradio-3.0.1
/usr/bin/install -c -o root -g wheel -m
444 ../../README /usr/pkg/share/doc/gnuradio-3.0.1
/usr/bin/install -c -o root -g wheel -m
444 ../../README.hacking /usr/pkg/share/doc/gnuradio-3.0.1
install: ../../README.hacking: stat: No such file or directory
/usr/bin/install -c -o root -g wheel -m
444 ../../ChangeLog /usr/pkg/share/doc/gnuradio-3.0.1
cp -r html /usr/pkg/share/doc/gnuradio-3.0.1
gmake[4]: Leaving directory
`/usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/doc'
g
The Makefile does make reference to it:
barossa: {100} grep README.hacking gnuradio-core/doc/*
gnuradio-core/doc/Makefile.am: @for i in $(top_srcdir)/README
$(top_srcdir)/README.hacking $(top_srcdir)/ChangeLog; do \
gnuradio-core/doc/Makefile.am: @for i in README README.hacking ChangeLog; do
\
gnuradio-core/doc/Makefile.in: @for i in $(top_srcdir)/README
$(top_srcdir)/README.hacking $(top_srcdir)/ChangeLog; do \
gnuradio-core/doc/Makefile.in: @for i in README README.hacking ChangeLog; do
\
gnuradio-core/doc/Makefile defines the following after running configure:
gnuradio-core/doc/Makefile:
install-data-local:
$(mkinstalldirs) $(DESTDIR)$(docdir)
@for i in $(top_srcdir)/README $(top_srcdir)/README.hacking
$(top_srcdir)/ChangeLog; do \
echo $(INSTALL_DATA) $$i $(DESTDIR)$(docdir); \
$(INSTALL_DATA) $$i $(DESTDIR)$(docdir); \
done
cp -r html $(DESTDIR)$(docdir)
[...]
It isn't related to pkgsrc other then it wasn't noted by anyone. I'm aware of
it now since the pkgsrc framework provides a mechanism that is used to
deinstall packages. It will issue warnings on attempts of
installing/deinstalling files that don't exist.
The creation and installation of documentation created by doxygen and tools
that depend on it is disabled by default (--enable-doxygen=no). I don't
believe that a user choosing not to install gnuradio documentation cares much
about the README* and ChangeLog files, especially since these are more
relevant to the decision making processes prior to the installation.
IMHO, it his doesn't need to be fixed prior to the current release if it is
too much of a pain to do since it won't have any impact on the performance of
GNU Radio and it has been like this for possibly a long time.
FYI: A installation log for gnuradio-core can be found on:
ftp://ftp.netbsd.org/pub/NetBSD/misc/wulf/gnuradio-core.log
cheerio Berndt
On Friday 10 November 2006 02:00, Johnathan Corgan wrote:
On Thu, 2006-11-09 at 23:52 +1030, Berndt Josef Wulf wrote:
FYI: The inofficial release installs ChangeLog, README and attempts to
install README.hacking, which doesn't exist in the tarball.
Is this while using pkgsrc? You're correct, the README.hacking in the
root of the tree is not put into the release tarball, and the Makefile's
don't reference it, so I'm not sure what would be trying to install it.
BTW: Is there any point at all to install these files if a user decided
to disable the creation of all other documents (e.g those created by
doxygen, latex and friends)?
Which specific files are you referring to here?
Nothing like cutting a release to bring out the post-release bugs...
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] gnuradio module version assignments
G'day, As GNU Radio now ships in a mega-tarball, which version numbers are assigned to the individual modules? Are they pulled inline with the version number of the release, e.g. gr-audio-oss-3.0.1? cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Q from a novice user in Japan
On Thursday 09 November 2006 05:31, Eric Blossom wrote: --- How I can get information on Python functions? Documents generated by doxygen explain only C++ part of the software. (Am I correct?) To know Python functions, do I need to read through codes? I would like to know if there is a list or man-pages of such Python functions. My application may not require any new C++ coding. You could run epydoc on the python code in and under gnuradio-core/src/python. Most of the code has epydoc doc strings. Tried that. Running epydocs' last stable (2.1) release didn't produce anything useful. It complaint about improper paragraph indentation for most of the files. Haven't tried their developement version - yet. cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release 3.0.1 Unofficial Tarballs
I've tried this version in pkgsrc and I'm getting the following error: gmake[5]: Entering directory `/usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/lib/general' PYTHONPATH=../../../../gnuradio-core/src/python srcdir=. ./generate_all.py Traceback (most recent call last): File ./generate_all.py, line 33, in ? generate_all () File ./generate_all.py, line 28, in generate_all generate_common.generate () File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/lib/general/generate_common.py, line 82, in generate expand_h_cc_i (r, s) File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/lib/general/generate_common.py, line 68, in expand_h_cc_i expand_template (d, root + '.h.t') File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/python/build_utils.py, line 55, in expand_template template = open_src (template_filename, 'r') File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/python/build_utils.py, line 106, in open_src return open (os.path.join (srcdir, name), mode) IOError: [Errno 2] No such file or directory: './gr_add_vXX.h.t' gmake[5]: *** [gr_add_cc.h] Error 1 The configuration string is shown ./configure --enable-doxygen --enable-dot --enable-html-docs --sysconfdir=/usr/pkg/share/examples --disable-all-components --enable-gnuradio-core --without-libintl-prefix --prefix=/usr/pkg --host=i386--netbsdelf --mandir=/usr/pkg/man builds fine outside pkgsrc (1st pass) but fails in pkgsrc. The same behavior is observed after gmake clean and building a second time (2nd pass). Are these old skeletons of previous versions? What's gives? cheerio Berndt On Thursday 09 November 2006 02:38, Johnathan Corgan wrote: Unofficial tarballs for GNU Radio release 3.0.1 are available at: http://gnuradio.org/releases/gnuradio/gnuradio-3.0.1.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.0.1.tar.gz The release history and changes are available at: http://gnuradio.org/trac/wiki/Release3.0Branch Build instructions for GNU Radio 3.0 are at: http://gnuradio.org/trac/wiki/BuildGuide You may customize your configuration options according to: http://gnuradio.org/trac/wiki/BuildConfiguration Many thanks to those who tested the svn repository and release candidate. These tarballs will be uploaded to the GNU Project, signed, and made available on the official download mirrors in the next few days. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Release 3.0.1 Unofficial Tarballs
G'day, ok, the problems appears to be that pkgsrc touches some files in the gnuradio-core/src/lib/general directory triggering the execution of the generate_all.py script which imports generate_common.py. generate_common.py contains a list of files reg_roots = [ 'gr_add_const_XX', 'gr_multiply_const_XX', 'gr_add_XX', 'gr_sub_XX', 'gr_multiply_XX', 'gr_divide_XX', 'gr_mute_XX', 'gr_add_vXX', 'gr_multiply_vXX', 'gr_add_const_vXX', 'gr_multiply_const_vXX' ] It appars that those ending with _vXX are nolonger part of the distribution and may be a leftover from earlier distribution - old skeletons? :-) generate_all is also executed after a gmake clean since it removes several files that are supplied in the tarball, which need to be regenerated, causing the same problem. I removed the files ending in _vXX from the list in generate_common.py and successfully built the distribution. Can someone in the know verify this? Can we get it fixed for the official release tarball? Thanks in advance, cheerio Berndt On Thursday 09 November 2006 17:00, Berndt Josef Wulf wrote: I've tried this version in pkgsrc and I'm getting the following error: gmake[5]: Entering directory `/usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/lib/ge neral' PYTHONPATH=../../../../gnuradio-core/src/python srcdir=. ./generate_all.py Traceback (most recent call last): File ./generate_all.py, line 33, in ? generate_all () File ./generate_all.py, line 28, in generate_all generate_common.generate () File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/lib/ge neral/generate_common.py, line 82, in generate expand_h_cc_i (r, s) File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/lib/ge neral/generate_common.py, line 68, in expand_h_cc_i expand_template (d, root + '.h.t') File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/python /build_utils.py, line 55, in expand_template template = open_src (template_filename, 'r') File /usr/pkgsrc/ham/gnuradio-core/work/gnuradio-3.0.1/gnuradio-core/src/python /build_utils.py, line 106, in open_src return open (os.path.join (srcdir, name), mode) IOError: [Errno 2] No such file or directory: './gr_add_vXX.h.t' gmake[5]: *** [gr_add_cc.h] Error 1 The configuration string is shown ./configure --enable-doxygen --enable-dot --enable-html-docs --sysconfdir=/usr/pkg/share/examples --disable-all-components --enable-gnuradio-core --without-libintl-prefix --prefix=/usr/pkg --host=i386--netbsdelf --mandir=/usr/pkg/man builds fine outside pkgsrc (1st pass) but fails in pkgsrc. The same behavior is observed after gmake clean and building a second time (2nd pass). Are these old skeletons of previous versions? What's gives? cheerio Berndt On Thursday 09 November 2006 02:38, Johnathan Corgan wrote: Unofficial tarballs for GNU Radio release 3.0.1 are available at: http://gnuradio.org/releases/gnuradio/gnuradio-3.0.1.tar.gz http://gnuradio.org/releases/gnuradio/gr-howto-write-a-block-3.0.1.tar.gz The release history and changes are available at: http://gnuradio.org/trac/wiki/Release3.0Branch Build instructions for GNU Radio 3.0 are at: http://gnuradio.org/trac/wiki/BuildGuide You may customize your configuration options according to: http://gnuradio.org/trac/wiki/BuildConfiguration Many thanks to those who tested the svn repository and release candidate. These tarballs will be uploaded to the GNU Project, signed, and made available on the official download mirrors in the next few days. ___ 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] All new packetradio 1200 and 9600 G3RUH with Muller and Mueller block
Hi Matteo,
the following versions are used:
NetBSD-4.99.3
gnuradio-current (3 November 2006)
python-2.4
wxGTK-2.6.3
boost-1.33.1
swig-1.3.29
cheerio Berndt
On Sunday 05 November 2006 19:18, Matteo Campanella wrote:
This looks like a tougher thing to be solved... never seen an error like
that, it seems to be a swig problem. The make check does not do
anything, that's why it works ok. Which gnuradio version are you using,
and which swig is on your system?
I am on a fedora core 5 and gnuradio is version 3, while swig used is
swig-1.3.24-2.2.1
ciao
Matteo iz2eeq
On Sun, 2006-11-05 at 11:36 +1030, Berndt Josef Wulf wrote:
G'day,
I followed your lead and downloaded it again and it compiled and
installed fine. I run the following tests:
barossa: {31} ./1200tx.py -c VK5ABN -s
gr_fir_fff: using SSE
gr_fir_ccf: using SSE
which create the expected usrp.data file
barossa: {33} ll usrp.dat
-rw-r--r-- 1 root wheel 3688112 Nov 5 11:21 usrp.dat
However, execution of 100rx.py produced the following result
barossa: {34} ./1200rx.py -s
gr_fir_ccf: using SSE
gr_fir_fff: using SSE
Traceback (most recent call last):
File ./1200rx.py, line 157, in ?
main()
File ./1200rx.py, line 131, in main
sink = packetradio.hdlc_framer(pktq,0)
File /usr/pkg/lib/python2.4/site-packages/gnuradio/packetradio.py,
line 316, in hdlc_framer
return _packetradio.hdlc_framer(*args)
TypeError: argument number 1: a 'gr_msg_queue_sptr *' is
expected, 'PySwigObject(û4û)' is received
Make check in gr-packetradio looks ok
gmake[3]: Entering directory `/tmp/gr-packetradio/src/python'
--
Ran 2 tests in 0.000s
OK
PASS: run_tests
==
All 1 tests passed
==
Any ideas?
cheerio Berndt
On Sunday 05 November 2006 07:45, Matteo Campanella wrote:
Hello, that sounds really strange. In order to be sure everything is at
the right place, I downloaded the tgz myself and recompiled, and
everything is ok. I did:
make clean
./bootstrap
./configure --prefix=/usr/local/gr --enable-maintainer-mode
make
make install
the file packetradio.i is there, in gr-packetradio/src/lib, as you can
see yourself.
let me know if you get any progress on this.
best regards
Matteo iz2eeq
I get some warning on deferencing type-punned... but I always got
them anyway. I can get the compiled library installed.
On Sun, 2006-11-05 at 07:53 +1030, Berndt Josef Wulf wrote:
G'day,
Is it possible that the src directory is missing in the
gr-packetradio package or am I missing something?
barossa: {34} ./configure --prefix=/usr/pkg
configure: error: cannot find sources (src/lib/packetradio.i) in . or
..
cheerio Berndt
On Saturday 04 November 2006 22:16, Matteo Campanella wrote:
I've finally reviewed all the material and converted the old code
to make it more user friendly as well as to make use of the great
blocks GNURADIO offers. I am talking about the Mueller and Muller
clock recovery and sampler. Now both 1200 and 9600 python code
works, both for transmit and receive. I have isolated the framer
functionality in a block, gr_framer, that takes care of HDLC and
G3RUH LFSR
scrambling/descrambling. This block uses the message queue model to
return the packets back to the python code. Full option parser
support has been added to the python code, so that usrp parameters
and message to transmit can be passed to the programs via command
line. A description od the python programs follows. For those
interested, they can be downloaded at
http://digilander.iol.it/iz2eeq/gnuradio.html. Feedbacks and
evolutions are welcome.
Matteo, iz2eeq
1200rx.py
usage: 1200rx.py [options]
options:
-h, --help show this help message and exit
-R RX_SUBDEV_SPEC, --rx-subdev-spec=RX_SUBDEV_SPEC
select USRP Rx side A or B (default=A)
-f FREQ, --freq=FREQ set frequency to FREQ
-g GAIN, --gain=GAIN set gain in dB (default is midpoint)
-d, --do-logging enable logging on datafiles
-s, --use-datafile use usrp.dat (256kbps) as input
This program receives packets and show them on terminal in this
form: X
CRC C75F C75F
= Sat Nov 4 11:21:50 2006
fm IZ2EEQ-7 to SXQT16-0 via RELAY-0,WIDE7-7 UIv pid=F0
'+4il .K\
=
XXX
CRC 34EC 34EC
= Sat Nov 4 11:27:42 2006
fm IK1ZNW-6 to I2ODL-6 via IK2NHL-4 I45^ pid=F0
PC19^0^IK5PWJ-6^0^5452^1^IZ5FSA-6^0^5452^0^IK2XDE-6^0^5432^0^IK5ZUK
-6^0 ^545 2^1^I5UXJ-2^0^5451^1^IR1BI-6^0^5451^1^IR8AW-6^0^5452^H2^
=
he Xs are returned by the framer and indicate a candidate
Re: [Discuss-gnuradio] All new packetradio 1200 and 9600 G3RUH with Muller and Mueller block
G'day,
I've got it to work after completely deleting and rebuilding all of gnuradio
and the packetradio code.
barossa: {84} ./9600tx.py -s -c vk5abn -m hello world, it works!
gr_fir_fff: using SSE
barossa: {85} ./9600rx.py -s
gr_fir_ccf: using SSE
gr_fir_fff: using SSE
CRC 988A 988A
= Mon Nov 6 11:49:39 2006
fm vk5abn-0 to CQ-0 via RELAY-0 UI pid=F0
hello world, it works!
=
Will try this code in realtime once back home.
Sorry for the false alarm and thanks to Matteo for his work.
cheerio Berndt
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Call for testing release 3.0.1
G'day,
Will we see a release candidate tarball before the final release? It was the
tarballed version that caused me grieve last time.
SVN based source built, checked, installed and runs fine on
NetBSD-4.99.3-i386. I couldn't test usrp code since I'm away from home in
Beijing at the moment.
Noted: gr-gsm-vocoder doesn't appear to execute any test code
barossa: {25} make check
Making check in src
Making check in lib
make check-recursive
Making check in gsm
Making check in .
Making check in python
make check-TESTS
--
Ran 0 tests in 0.000s
OK
PASS: run_tests
==
All 1 tests passed
==
BTW: Is it now save to use make -j n?
cheerio Berndt
On Saturday 04 November 2006 11:52, Johnathan Corgan wrote:
All,
The GNU Radio release 3.0 branch has accumulated a few bug fixes and
updates over the last several weeks since the 3.0 tarballs went out.
None of these have been serious, and the rate of new bugs has dropped to
nearly zero.
The latest of these updates has been to fix the build issue with
automake 1.10.0. Since that is now the default for Cygwin and Gentoo,
it will likely be the version shipping with other distributions or
systems soon. So, at this point we'd like to cut a 3.0.1 cumulative bug
fix release.
I've created a Wiki page with the details of what's changed since
release 3.0:
http://gnuradio.org/trac/wiki/Release3.0Branch
To summarize here:
* Updated AUTHORS file (r3740, r3750)
* Changed line ending style on config/*.m4 (r3751, r3776, ticket:88)
* Improved gr-video-sdl configuration error message (r3752, ticket:84)
* Fixed 'make clean' breakage using BSD make (r3753, ticket:87)
* Fixed non-portable constructs in build (r3775, r3839, r3840)
* Remove bashisms in build system (r3797, r3838)
* Updated gr-how-to-write-a-block README (r3841)
* Improved error message on size mismatch in fg.connect (r3849)
* Eliminate compiler warnings (r3854)
* Fix for systems missing include/linux/compiler.h (r3914)
* Fix for working with automake = 1.10.0 (r3923, ticket:92)
What we'd like is for people to test this in all the usual ways before
we cut tarballs. You can point your svn client at:
http://gnuradio.org/svn/gnuradio/branches/releases/3.0
(This is not the same as the tagged 3.0 release, but rather is the part
of the repository we've been accumulating the bug fixes into.)
If you find an issue, please file a bug on the Trac system at:
http://gnuradio.org/trac
...by logging in as username 'guest' and password 'gnuradio' (without
quotes.)
Thanks!
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] GNU Radio 3.0 Release Candidate 3 available for testing
make -j 2 failed last time I tried. Also, make clean fails in gr-trellis/doc due to missing $(RM) variable. Haven't tried the actual release. cheerio Berndt On Saturday 07 October 2006 01:44, Greg Troxel wrote: http://gnuradio.org/releases/gnuradio/gnuradio-3.0rc3.tar.gz On NetBSD/i386 current from 2006-08-02, when configured as: LDFLAGS=-L/usr/pkg/lib -R/usr/pkg/lib -L/usr/adroit/lib -R/usr/adroit/lib CPPFLAGS=-I/usr/pkg/include -I/usr/adroit/include ./configure --prefix=/usr/adroit a 'make' succeeded, as did 'sudo make install' 'make check' failed with the gr_vmcircbuf_mmap_tmpfile_factory ending up with malloc corruption. This seems similar to the problem in svn head that I mailed you about recently. I haven't tried make -j or running this - I did this on a xen domU w/o USB. The modules that were enabled and disabled follow: * The following GNU Radio components have been successfully configured: config gnuradio-core gnuradio-examples usrp gr-usrp gr-audio-oss gr-gsm-fr-vocoder gr-radio-astronomy gr-trellis gr-video-sdl gr-wxgui You my now run the make command to build these components. * The following components were skipped either because you asked not to build them or they didn't pass configuration checks: gr-audio-alsa gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows These components will not be built. Greg Troxel [EMAIL PROTECTED] ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] to prevent mental damages, avoid dB's.
It don't see how this makes the calculation of RF power any easier, to the contrary it confuses the issue. cheerio Berndt On Thursday 28 September 2006 17:50, John Gilmore wrote: transmit power converted to dBm (1 dBm == 1 mW) minus the attenuator loss = output power in dBm. E.g. 100 mW - 20dBm 20dBm - 15 db att = 5 dBm 5 dBm - 3.2 mW Actually, I think 0 dBm = 1 mW. dB's are a royal pain in the butt. They eluded me for years because they required a lot of rote memorization and made no sense. For those of us not pickled in radio-speak from an early age, but who know basic algebra, there's a simple way to deal. Ignore deciBels. Use Bels. Bels are easy and obvious. They're a straight logarithmic scale in Base 10. 100 mW is 2 Bm. 10 mW is 1 Bm. 1 mW is 0 Bm. 0.1 mW is -1 Bm. DeciBels are just tenths of a bel. So if you shift the decimal point one place, you're suddenly calculating in an easy to use notation. Here's the above calculation in Bels: 100 mW - 2 Bm 2 Bm - 1.5 B att = 0.5 Bm 0.5 Bm - 10 to the 0.5 power - the square root of 10 - about 3.2 mW See, now you not only know the answer, but you know WHY 5dBm is 3.2 mW. Why the EE universe settled on doing everything in tenths of a logarithmic unit is way beyond me. It's as if every carpenter figured every length in deciInches or decimeters, even if inches, kilometers or meters would be the more straightforward unit. How often do you calculate in decivolts, deciwatts, or decimeters per second per second? The rumor is that decibels were invented because somebody at Bell Labs couldn't cope with decimal points or negative numbers, in the days when equipment wasn't capable of dealing with large orders of magnitude (e.g. the painful-to-someone 0.3 Bel became the friendly-to-someone 3 deciBel). Of course, now that people regularly see 5 to 10 orders of magnitude (5 to 10 Bels) (50 to 100 deciBels) (factors of 1 to 10 billion) in ratios, such as in radar, digital signal processing, or fiber optics, the deci has just become a hindrance. You can do your part to clear up this idiocy by using Bels in most places where the lemmings use deciBels. You may actually get them to think (briefly). John PS: Don't even get me started about why dBm's aren't referenced to watts rather than milliwatts! Since a milli is 1/1000th and that's just 3 orders of magnitude, referencing to ordinary watts would merely involve subtracting 3 or 30 from the number, e.g. 40 dBm = 4 Bm = 1 BW = 10 dBW. It reminds me of how we're still calculating speeds in 5280-foot units per 3600-second units rather than in some sane system using basic decimal units. Actually using BW notation in your thinking and writing may overload lemming brains, though. ___ 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] to prevent mental damages, avoid dB's.
I guess this is the difference big between RF engineers and academics - applied versus theory. Spreadsheets can help in doing conversion/calculations but doesn't stop people from using these values out of context as for this you need to know what you're doing. BTW: I do these calculations in my head - pretty much primary school stuff really. cheerio Berndt On Friday 29 September 2006 11:33, Brian Padalino wrote: You could open Google Spreadsheets in the web browser you've probably already got open. Not only that, but you can share it with your buddies for collaborative editing so everyone can use it! Or you could just write a bc script to to handle it. That uses much less memory, I am sure. Or we could ask Google to build it into their calculator function so you can just type 200 dB in mW and it would do the conversion for you! I wasn't trying to be a jerk, but I have noticed that spreadsheets are much better at converting data to a visual format as well as extending a dataset you might be building and doing some visual interpretations. There's always more than one way to skin a cat, as GNURadio is all about. On 9/28/06, Daniel O'Connor [EMAIL PROTECTED] wrote: On Friday 29 September 2006 10:13, Brian Padalino wrote: A spreadsheet could work just the same without all the Tcl/Tk silliness or input verification problems. Yeah, a spreadsheet, so lightweight compared to a memory hungry Tcl/Tk application. 12623 radar 1 1030 11972K 6068K select 0:00 3.97% wish8.4 12643 darius6 200 120M 72048K kserel 0:07 0.00% soffice.bin *cough* Not sure what you mean about input verification. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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] to prevent mental damages, avoid dB's.
On Friday 29 September 2006 12:03, Daniel O'Connor wrote: On Friday 29 September 2006 11:49, Berndt Josef Wulf wrote: BTW: I do these calculations in my head - pretty much primary school stuff really. Yeah, depends what level of accuracy you need though :) How accurate do you need it... :-) cheerio Berndt ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Recommended PC?
On Saturday 19 August 2006 09:27, Bob Collins wrote: I am just starting out with Gnu Radio and want to purchase and/or build a PC that will cause me the fewest extraneous problems. I figure that those of you using Gnu Radio may have opinions on the matter but I was unable to find anything in the archives. For the RF-IF, I plan on getting Matt Ettus's USRP. (By the way, I design with FPGAs.) Now for the questions: 1) Laptop or Desktop: I would prefer to use a laptop but not if it adds to the pain. A Dell Inspiron 9400 laptop with a 2GHz Centrino Duo which works fine here. cheerio Berndt pgp9OJ0RnbdAq.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Re: Ticket #12 - libossaudio link issue on NetBSD
On Sunday 06 August 2006 03:52, Johnathan Corgan wrote:
Berndt:
A trial fix for this issue is at:
http://gnuradio.utah.edu/svn/gnuradio/branches/developers/jcorgan/ticket-12
Could you please check this out into a fresh directory and test? I've
disabled all the components except gnuradio-core and gr-audio-oss.
I created an autoconf macro to test for the ossaudio library when the
target machine is NetBSD, otherwise is tests for sys/soundcard.h like
the current method. The Makefile.am will link in the ossaudio library
where needed if found.
-Johnathan
Thanks, but bad news: it still doesn't work.
barossa: {4} ldd /usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so
/usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so:
-lm.0 = /usr/lib/libm387.so.0
-lm.0 = /usr/lib/libm.so.0
-lfftw3f.3 = /usr/pkg/lib/libfftw3f.so.3
-lstdc++.5 = /usr/lib/libstdc++.so.5
-lgcc_s.1 = /usr/lib/libgcc_s.so.1
-lgnuradio-core.0 = /usr/pkg/lib/libgnuradio-core.so.0
libossaudio isn't linked in compared to the version that works
/usr/pkg/lib/python2.4/site-packages/gnuradio/_audio_oss.so:
-lossaudio.0 = /usr/lib/libossaudio.so.0
-lm.0 = /usr/lib/libm387.so.0
-lm.0 = /usr/lib/libm.so.0
-lfftw3f.3 = /usr/pkg/lib/libfftw3f.so.3
-lstdc++.5 = /usr/lib/libstdc++.so.5
-lgcc_s.1 = /usr/lib/libgcc_s.so.1
-lgnuradio-core.0 = /usr/pkg/lib/libgnuradio-core.so.0
configure detects the libossaudio library but OSS_LIBS doesn't substitute it
into gr-audio-oss/src/Makefile
cheerio Berndt
pgpO9cw9HZ5NF.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] New source code repository!
On Saturday 05 August 2006 03:36, Eric Blossom wrote:
Hi Everyone,
I'm pleased to announce that we have combined all the source
code repositories in to a new unified subversion system!
In addition we are running Trac, http://gnuradio.utah.edu/trac,
which provides a unified bug-tracker, wiki and subversion code
browser.
We've also restructured the entire build process in a way that removes
the need for things like ./checkout, ./for-all-dirs and ./buildit
Johnathan Corgan will be following up with details on the new build
system. We think you'll like it. There are bound to be a few rough
spots at first, so please bear with us, and let us know what's not
working ;)
I'd like to thank the following people and organizations for making this
possible:
Matt Ettus for bugging me non-stop about Trac, and insisting that we
make GNU Radio easier to build.
Jay Lepreau and the folks at the University of Utah's Flux Research
Group for providing expertise, the machine, net connection and
industrial strength archiving. For those of you unfamiliar with
Flux and the Emulab - Network Emulation Testbed, take a look at
http://www.emulab.net. Their main networking testbed has about 300
machines in a cluster. What's particularly interesting from the GNU
Radio point of view, is that they currently have about 20 machines
scattered about with USRP's attached. The USRP's have RFX-900
daughterboards, and best of all, these machines can be used by _you_
to perform wireless networking experiments.
For information on Emulab, take a look their web site. If you're
interested in running wireless experiments on the testbed, there's
already a GNU Radio project registered. Talk to me and I can add
you to the project.
Finally, I want to thank Johnathan Corgan for kicking some serious
ass making this all happen. Johnathan has been handling the sys
admin on the new machine, and is to blame for the restructuring of
the build system ;)
For those of you who just want to dive in: create a new directory
and cd into it, then execute these commands:
$ svn co http://gnuradio.utah.edu/svn/gnuradio/trunk gnuradio
$ cd gnuradio
$ ./bootstrap
$ ./configure
$ make make check
$ sudo make install
Regarding trac, we've got the bug tracker initialized, please feel
free to create tickets (bug reports / enhancement requests).
We still need to port the old usemod wiki pages to trac. Any
volunteers? It's pretty straight-forward, and I can provide details.
There is a bulk load command line tool to get them in. Also, we
still need to create a guest account on the wiki to let folks edit.
The plan is to use CAPTCHAs (visual Turing tests) and let anonymous
folks edit, but that code's not in yet.
Committers, we'll need to set you up to be able to write to svn. The
backend is using WebDAV with htdigest authentication. We're lacking a
good GUI to do this now, so here's how it's going to work. Send me a
pgp/gpg encrypted message with your preferred user name and a decent
password. (My keys are here http://comsec.com/pgp-keys.txt)
When we run out of things to do, we'll fix this problem, but for now,
we'll go with this. If anybody can point us to code that already
handles this (in less than 2000 lines of code), please do.
Also, if you're not familiar with subversion -- particularly the best
practices for branching and merging, and the recommended format of
commit messages on merges -- please take a look at the docs:
http://subversion.tigris.org.
The repo is laid out like this:
gnuradio/trunk/{gnuradio-core,gnuradio-examples,usrp,gr-usrp,...}
gnuradio/tags
gnuradio/branches
gnuradio/branches/developers/{eb,jcorgan,...}
gnuradio/trunk corresponds to CVS head. Please ensure that this code
always builds. If you're working on a non-trivial change, it's a good
idea to create a new branch using svn copy, do the work on the branch,
and then merge it into trunk when it's stable.
If any of you have uncommitted code in a cvs checkout, please generate
a diff against cvs HEAD (or use the tag SECOND_MIGRATION_2006_08_04)
and apply the diffs to svn.
That's it for now. Look for Johnathan's detailed note a bit later.
Best wishes,
Eric
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
G'day,
build fails with doxygen and dot options enabled
mkdir -p html
/usr/pkg/bin/doxygen
Error: tag INPUT: input source `../../src/lib' does not exist
gmake[1]: *** [html/index.html] Error 1
gmake[1]: Leaving directory
`/home/wulf/projects/gnuradio/gnuradio/gnuradio-core/doc'
gmake: *** [all-recursive] Error 1
In gr-radar the build fails due to
time_series.cc:37
if ((d_fd = open(d_filename.c_str(), O_RDONLY | O_LARGEFILE, 0660)) == -1){
NetBSD's open() function doesn't support the O_LARGEFILE flag. I guess all
Re: [Discuss-gnuradio] New source code repository!
On Saturday 05 August 2006 12:44, Eric Blossom wrote: Berndt, I think I've fixed these (not the doxygen stuff) in trunk. Can you please update and re-test? You'll need ./bootstrap ./configure since there were some configure.ac changes. Thanks! Eric It builds and installs fine, however there seems to be a problem with the audio support which doesn't seem to pickup that we need to link agains the libossaudio library. I had to manually add -lossaudio in the Makefile of gr-audio-oss/src/Makefile. Will have a look at this tonight. BTW: all tests pass on make check in the top directory... :-) Find below is the configuration for NetBSD *** The following GNU Radio components have been successfully configured: config gnuradio-core gnuradio-examples usrp gr-usrp gr-audio-oss gr-atsc gr-error-correcting-codes gr-gsm-fr-vocoder gr-radar gr-radio-astronomy pmt gr-video-sdl gr-wxgui However, the following components did not configure successfully due to missing dependencies: gr-audio-alsa gr-audio-jack gr-audio-osx gr-audio-portaudio gr-audio-windows gr-comedi cheerio Berndt pgpjX254x9T5q.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USRP USB changes committed to master repository
On Wednesday 26 July 2006 22:22, Greg Troxel wrote:
On Monday I committed the changes to ugen(4) that Joanne previously
described on the list to the master NetBSD repository. The option is
enabled in GENERIC and GENERIC_LAPTOP on i386 and GENERIC on amd64,
and is described in the ugen(4) man page.
Updating to the latest -current should be sufficient to get these
changes. Berndt Josef Wulf reports that they work for him when using
the fusb code, available at
http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/radio_test/usb/
I am interested in reports of how well this works on both i386 and
amd64.
It's pretty clear that getting pipelining closer to the hardware is
needed - this is being pushed upstream since it works and gets ~80% of
the likely speed gain.
[...]
G'day,
for those interested here are a few results from the tests conducted on a Dell
Inspiron 9400 Centrino Duo @ 2GHz/1GB running NetBSD-3.99.21:
barossa: {29} ./test_usrp_standard_rx
xfered 1.34e+08 bytes in 4.2 seconds. 3.197e+07 bytes/sec. cpu time =
0.04173
noverruns = 41
barossa: {30} ./test_usrp_standard_tx
...
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in 4.64 seconds. 2.894e+07 bytes/sec. cpu time = 0.491
41 underruns
barossa: {33} ./benchmark_usb.py
Testing 2MB/sec... usb_control_msg failed: error sending control message:
Input/output error
uUusb_throughput = 2M
ntotal= 100
nright= 947559
runlength = 0
delta = 100
FAILED
Testing 4MB/sec... usb_control_msg failed: error sending control message:
Input/output error
uUusb_throughput = 4M
ntotal= 200
nright= 1997896
runlength = 1997896
delta = 2104
OK
Testing 8MB/sec... usb_control_msg failed: error sending control message:
Input/output error
usb_throughput = 8M
ntotal= 400
nright= 3999286
runlength = 3999286
delta = 714
OK
Testing 16MB/sec... usb_control_msg failed: error sending control message:
Input/output error
usb_throughput = 16M
ntotal= 800
nright= 7997737
runlength = 7997737
delta = 2263
OK
Testing 32MB/sec... usb_control_msg failed: error sending control message:
Input/output error
usb_throughput = 32M
ntotal= 1600
nright= 15999303
runlength = 15999303
delta = 697
OK
Max USB/USRP throughput = 32MB/sec
Interestingly, the 2MB/sec test fails although the faster speeds are ok.
cheerio Berndt
pgpUl304aTUCV.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] NetBSD USRP USB changes committed to master repository
On Wednesday 26 July 2006 23:19, Greg Troxel wrote:
barossa: {29} ./test_usrp_standard_rx
xfered 1.34e+08 bytes in 4.2 seconds. 3.197e+07 bytes/sec. cpu time =
0.04173
noverruns = 41
barossa: {30} ./test_usrp_standard_tx
...
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in 4.64 seconds. 2.894e+07 bytes/sec. cpu time =
0.491 41 underruns
So this doesn't work. Could you try with decimation 10 (or 12, until
you get only a few underruns)?
Here are the values that stop producing overruns:
barossa: {101} ./test_usrp_standard_rx -D 10
xfered 1.34e+08 bytes in 5.24 seconds. 2.56e+07 bytes/sec. cpu time = 0.0399
noverruns = 0
barossa: {106} ./test_usrp_standard_tx -I 20
usb_control_msg failed: error sending control message: Input/output error
xfered 1.34e+08 bytes in 5.28 seconds. 2.542e+07 bytes/sec. cpu time = 0.492
0 underruns
cheerio Berndt
pgphobctz99PA.pgp
Description: PGP signature
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB throughput numbers for NetBSD (and Linux)
On Saturday 22 July 2006 23:56, Greg Troxel wrote: I'm sorry to say that I can't share the enthusiam as it didn't make much difference on a system using Centrino Duo system running with NetBSD-3.99.21. Does it require GNU Radio current? I'm currently running GNU Radio release 2.8 as found in the pkgsrc release! You need not only the patched NetBSD with the kernel option defined, but also the modified fusb code that Joanne pointed out recently (which enables read-ahead and write-behind). It lives here at the moment: https://acert.ir.bbn.com/projects/adroitgrdevel I can certainly believe that you'd get different results, but I would expect a big improvement. Thanks, I followed your instructions and now have stotter free sampling at max speed even with GUI's running concurrently AWESOME. cheerio Berndt pgpQ64GPEyIGt.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] USB throughput numbers for NetBSD (and Linux)
Hi, I'm sorry to say that I can't share the enthusiam as it didn't make much difference on a system using Centrino Duo system running with NetBSD-3.99.21. Does it require GNU Radio current? I'm currently running GNU Radio release 2.8 as found in the pkgsrc release! cheerio Berndt On Saturday 22 July 2006 15:26, Joanne M Mikkelson wrote: Hi, We collected some data comparing the USB throughput we're getting now on NetBSD against the throughput on Linux. For those who are interested in the current performance on NetBSD, I've included a summary. The full set of measurements taken (along with the summary) is available at: http://acert.ir.bbn.com/viewvc/adroitgrdevel/adroitgrdevel/radio_test/usb/t est-results?view=co Summary === The following USB throughput results were collected on two systems with the same hardware, running NetBSD-current with our ugen changes and SuSE Linux. The ugen changes allow specifying the length of the transfer to request from the host controller, and here the fusb_netbsd testing code was recompiled with the different sizes. The fusb_linux code uses 16k requests (and says that this is the largest request possible). In both cases the USRP library's default buffer size of 2 MB was used. The ugen driver could also be changed to avoid a copy to the buffer in the driver, and these tests investigate how much performance is improved in that case. For reference, here is how interpolation/decimation relates to the intended data rate: data rate | decimation | interpolation -- 16 MB/s 16 32 18.3 MB/s 14 28 21.3 MB/s 12 24 25.6 MB/s 10 20 32 MB/s 816 42.6 MB/s 612 benchmark_usb.py (bidirectional test) driver | xfer size | maximum (read+write) -- NetBSD 16k 32 MB/s Linux 16k 36.57 MB/s NetBSD 64k 32 MB/s (usually gets 36.57) NetBSD 128k32 MB/s NetBSD -copy 16k 32 MB/s NetBSD -copy 64k 42.6 MB/s NetBSD -copy 128k42.6 MB/s test_standard_usrp_rx driver | xfer size | maximum -- NetBSD 16k 21.3 Linux 16k 32 NetBSD 64k 25.6 NetBSD 128k21.3 NetBSD -copy 16k 25.6 NetBSD -copy 64k 25.6 NetBSD -copy 128k25.6 test_standard_usrp_tx driver | xfer size | maximum -- NetBSD 16k 21.3 Linux 16k 32 NetBSD 64k 25.6 NetBSD 128k21.3 NetBSD -copy 16k 21.3 NetBSD -copy 64k 25.6 NetBSD -copy 128k25.6 The Linux numbers suggest that there is about 36 MB/s bandwidth available total (maybe more but less than 42), and it must be divided between transmit and receive. So 32 can be done one-way, but as soon as one needs bidirectional traffic, neither direction can do 32. Probably the USRP could be set up to use, say, 25.6 and 8 between read and write instead of 16 and 16, but not 25.6 and 16. This follows fairly well from the implementation. On Linux, USRP reads and writes are all done via a generic request mechanism funneled through the control endpoint. So the sum of reads and writes in aggregate seems to be constrained by how fast data can be pushed through this system. With our NetBSD implementation, unless the transactions go in lock-step and thus one of read and write has to wait while the other's completion interrupt is being handled, read and write are handled independently all the way down until you get to the host controller driver. Therefore the bidirectional numbers are more related to the sum of the two unidirectional numbers, instead of bidirectional being essentially equal to unidirectional as we're seeing with Linux. The NetBSD numbers demonstrate that 128k transfers perform worse than 64k. As would be expected, 128k transfers aren't worse with the extra copy removed but they also aren't notably better. So while there is clearly too much cost copying 128k at a time vs. copying 64k, there is still a lot of cost that's not in the copy at all, because the numbers don't get vastly better when the copy is removed. The latter cost is what's preventing us from getting unidirectional rates comparable to Linux. Copying to/from user space is not showing to be the bottleneck; the kernel debug logs clearly show that user space consumes and writes faster than the bus in these tests. Choosing a Good Buffer Size === The previous results are all using a buffer size of 2 MB (which is 2 MB for each of read and write with fusb_netbsd). Also, all reads and writes from user space were 16k. The following tests indicated the read and write length does not
Re: [Discuss-gnuradio] NetBSD USB progress
This is much improved over ~4 MB/s but the next step is to work on optimizing what's needed to reach 32 MB/s reading or writing. If you're interested, the current driver work can be found at: http://acert.ir.bbn.com/cvs/?group=netbsd primarily in: http://acert.ir.bbn.com/viewvc/netbsd/netbsd/src/sys/dev/usb/ Is there a consolidated patch file that would make it easier to apply against the current NetBSD source tree? cheerio Berndt pgp62zeOKS7gc.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] NetBSD GNU Radio 2.8 packages
G'day, NetBSD users may be interested to learn that GNU Radio 2.8 modules are now available from the NetBSD Packages Collection (pkgsrc). I'm currently working on getting ham/gnuradio-audio-jack and ham/gnuradio-audio-portaudio. There are some issues that I need to resolve before they can be submitted. 73, Berndt VK5ABN pgpMrCTkVuKhO.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] make check in gr-atsc fails
G'day, Is make check in gr-atsc know to complete? It currently fails to complete with the following message. Making check in python make check-TESTS ... sched: gr_block atsc_viterbi_decoder (31) is requesting more input data than we can provide. ninput_items_required = 12 max_possible_items_available = 7 If this is a filter, consider reducing the number of taps. F == FAIL: test_loopback_003 (__main__.qa_atsc) -- Traceback (most recent call last): File ./qa_atsc.py, line 207, in test_loopback_003 self.assertEqual (expected_result, result_data) AssertionError: (71, 65, 38, 46, 28, 211, 28, 167, 63, 183, 65, 28, 239, 239, 22 6, 99, 85, 148, 139, 146, 28, 205, 9, 120, 44, 4, 200, 122, 9, 97, 122, 232, 45, 207, 16, 221, 21, 138, 45, 198, 48, 16, 94, 23, 254, 34, 245, 128, 39, 191, 67, [...] -- Ran 4 tests in 4.144s FAILED (failures=1) FAIL: run_tests === 1 of 1 tests failed === *** Error code 1 cheerio Berndt pgpgT3a2LmnMz.pgp Description: PGP signature ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
