Re: [Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS

[Berndt Josef Wulf]

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 /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] Problems building GNURadio on Ubuntu 12.04LTS

[Berndt Josef Wulf]

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

[Discuss-gnuradio] Problems building GNURadio on Ubuntu 12.04LTS

[Berndt Josef Wulf]

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

[Discuss-gnuradio] Error on reconnecting to TCP port

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] Ultimate SDR system ??

[Berndt Josef Wulf]

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
 &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] USRP FX2 24MHz crystal

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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?

[Berndt Josef Wulf]

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

AW: [Discuss-gnuradio] Dead USRP box?

[Berndt Josef Wulf]

G'day Bob,
 
yes, the LED is blinking. I'm pretty sure its the USB interface that
died inside the chip. I just can't explain why as all I did was to
power-up the unit after a few month being left switched-off.
 
Power supply voltage and current draw all look fine. Will keep you
posted once I changed-over the FX2 chip.
 
Seasons Greetings,
 
Berndt

-Ursprüngliche Nachricht-
Von: discuss-gnuradio-bounces+wulf=ping.net...@gnu.org
[mailto:discuss-gnuradio-bounces+wulf=ping.net...@gnu.org] Im Auftrag
von Bob Cameron
Gesendet: Monday, 22 December 2008 11:29 AM
An: discuss-gnuradio@gnu.org
Betreff: Re: [Discuss-gnuradio] Dead USRP box?


Hi Berndt

Have you heard this happening on more than just our boards? Weird!

I assume you have the same blinking LED so this excludes the EEPROM load
from the problem? I use to work on some Alcatel data radios with the
Altera chips and we had EEPROM failures every now and then.

I have emailed Matt in case he offers a repair service. If not I might
just wait till you have repaired yours. 

Cheers Bob

Berndt Josef Wulf wrote: 

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:

  


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Dead USRP box?

[Berndt Josef Wulf]

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?

[Berndt Josef Wulf]

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] Faulty USRP microprocessor?

[Berndt Josef Wulf]

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

[Discuss-gnuradio] Faulty USRP microprocessor?

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] URSP/Gnuradio for amateur radio usage

[Berndt Josef Wulf]

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=get&search=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

[Berndt Josef Wulf]

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/tun character device, and the associated tun 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 tun 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=51 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

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] GRC: 'Utils' not defined

[Berndt Josef Wulf]

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

[Discuss-gnuradio] GRC: 'Utils' not defined

[Berndt Josef Wulf]

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] Important: New trunk dependency: GSL

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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 3.1.2rc0 tarballs available for testing

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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 Companion (GRC) 0.69 experience

[Berndt Josef Wulf]

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] Re: Gnu Radio Companion (GRC) 0.69 experience

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] Gnu Radio Companion (GRC) 0.69 experience

[Berndt Josef Wulf]

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] GNU Radio release 3.1.1 available - upgrade recommended

[Berndt Josef Wulf]

On Tuesday 06 November 2007 12:39:33 Johnathan Corgan wrote:
> GNU Radio 3.1.1 has been released and is available at:
>
> ftp://ftp.gnu.org/gnu/gnuradio/gnuradio-3.1.1.tar.gz
> ftp://ftp.gnu.org/gnu/gnuradio/gr-howto-write-a-block-3.1.1.tar.gz
>
> This is an important bug fix release that clears up some longstanding
> issues in the USRP FPGA code and some recent regressions in the GNU
> Radio examples.  It is recommended that you upgrade to this version if
> you are tracking the stable releases. (These changes are also in the
> GNU Radio unstable development branch.)
>
> For Subversion based users, you may update your repository to obtain
> the latest changes.
>
> The full release log may be found at:
>
> http://gnuradio.org/trac/wiki/Release3.1Branch
>
> Updates to binary packages will follow shortly.

G'day,

On NetBSD the following error occurs with:

checking boost/shared_ptr.hpp usability... yes
checking boost/shared_ptr.hpp presence... yes
checking for boost/shared_ptr.hpp... yes
checking for svn... /usr/pkg/bin/svn
Shared object "libaprutil-0.so.0" not found
Shared object "libaprutil-0.so.0" not found
Component omnithread passed configuration checks, but not building.
Component gnuradio-core requires omnithread, which is not being built.
configure: error: Component gnuradio-core has errors, stopping.
*** Error code 1

Can someone tell me more about libaprutil? Is this a new dependency? I didn't 
see it on previous versions.

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"

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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 /share/examples/gnuradio, but it appears to have changed to 
/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

Re: [Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing

[Berndt Josef Wulf]

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

[Discuss-gnuradio] gnuradio-core/src/lib/runtime/gr_runtime.i missing

[Berndt Josef Wulf]

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] Reorganization of gnuradio-examples in trunk r6279

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] am_rcv and remote audio

[Berndt Josef Wulf]

On Saturday 01 September 2007 09:54:20 [EMAIL PROTECTED] wrote:
> Hello all,
>
> 1. I find that in the code am_rcv.py, if you comment out the line
> "src.set_pga(0,20)", the quality of the sound is improved ALOT.

I guess it depends how strong the station is that you're trying to receive.

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

[Berndt Josef Wulf]

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] missing module usrpm

[Berndt Josef Wulf]

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

[Discuss-gnuradio] gnuradio-3.0.4 available via pkgsrc

[Berndt Josef Wulf]

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] Which swig and boost versions?

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] Efficient notch filters

[Berndt Josef Wulf]

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] Next release?

[Berndt Josef Wulf]

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?

[Berndt Josef Wulf]

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 
 #include 

 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 
+#elif HAVE_SYS_BSWAP_H
+#include 
 #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] SSB Modulator

[Berndt Josef Wulf]

G'day,

I've found various implementations of SSB demodulators but no modulators? Has 
anyone written or seen an implementation of a SSB modulator?

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Discuss-gnuradio] svn-4661: gr-qtgui not building on NetBSD

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] Release candidate 3.0.3rc2 available for testing

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Discuss-gnuradio] calling python from C/C++

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] Release candidate 3.0.3rc1 available for testing

[Berndt Josef Wulf]

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

[Discuss-gnuradio] usrp_spectrum_sense.py: object has no attribute 'bin_statistics_f

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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!

[Berndt Josef Wulf]

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!

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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 "", 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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

Re: [Discuss-gnuradio] APT signals

[Berndt Josef Wulf]

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)
-Nnumber 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] APT signals

[Berndt Josef Wulf]

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 ?

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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] NetBSD

[Berndt Josef Wulf]

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] audio sampling rate problem after Ubuntu 6.06 downgrade...

[Berndt Josef Wulf]

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] Scanning/Detecting Wifi

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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()

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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

[Berndt Josef Wulf]

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] gr-howto-write-a-block

[Berndt Josef Wulf]

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] --disable-all-components --enable-gr-usrp doesn't built

[Berndt Josef Wulf]

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] gnuradio-core and usrp documentation

[Berndt Josef Wulf]

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] gnuradio module version assignments

[Berndt Josef Wulf]

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] README.hacking missing

[Berndt Josef Wulf]

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] README.hacking missing

[Berndt Josef Wulf]

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] Release 3.0.1 Unofficial Tarballs

[Berndt Josef Wulf]

G'day Johnathan,

Ok, they are forming part of the distribution, but I've never seen and 
obviously never missed them until now.

I didn't create a pkgsrc distribution for version 3.0 since it had other 
problems that needed to be overcome and my working schedule was very tight at 
that time. Hence I'm pretty keen to see this through the door as its been 
awhile since pkgsrc was updated.

I now see that these files are in the SVN repository. Not sure how to deal 
with this as such. Perhaps skip 3.0.1 and release 3.0.2 as the next official 
release?

cheerio Berndt

On Thursday 09 November 2006 17:38, you wrote:
> On Thu, 2006-11-09 at 18:03 +1030, Berndt Josef Wulf wrote:
> > It appars that those ending with _vXX are nolonger part of the
> > distribution and may be a leftover from earlier distribution - old
> > skeletons? :-)
>
> Actually, those ending in vXX are part of the source tree and are
> supposed to be in the distribution tarball.  The bug is not referring to
> them in one particular place in the Makefile.am so they get included.
>
> I am the guilty party here--I added those 'vector' operations to the
> tree as one of the first contributions I ever made to GNU Radio, and
> clearly didn't know what I was doing.  It's a wonder Eric lets me near
> the tree sometimes :-)
>
> But--did pkgsrc ever work for you, say, in the release 3.0 tarballs?
> This bug has been there since the CVS days.
>
> Anyway, it's easy to fix, but we've got to huddle and figure out what it
> means as far as the release goes.  Unfortunately, we already tagged
> 3.0.1 in the repository off the release branch.  We could delete that
> tag, and re-tag the release branch after checking in that fix.  It would
> (almost) be as if this broken 3.0.1 never existed.
>
> Some would call this cheating, others would call it clever.


___
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

[Berndt Josef Wulf]

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] Release 3.0.1 Unofficial Tarballs

[Berndt Josef Wulf]

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] Q from a novice user in Japan

[Berndt Josef Wulf]

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] All new packetradio 1200 and 9600 G3RUH with Muller and Mueller block

[Berndt Josef Wulf]

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] All new packetradio 1200 and 9600 G3RUH with Muller and Mueller block

[Berndt Josef Wulf]

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
>

Re: [Discuss-gnuradio] All new packetradio 1200 and 9600 G3RUH with Muller and Mueller block

[Berndt Josef Wulf]

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 packet whose CRC
> check failed. When CRC check for a packet is ok, the framer prints the CRC
> value to standard output and returns the packet to python, whose function
> printpacket prints it in a readable format.
>
> 1200tx.py
> usage: 1200tx.py [options]
>
> options:
> -h, --help show this help message and exit
> -f FREQ, --freq=FREQ set frequency to FREQ
> -m MESSAGE, --message=MESSAGE
> message to send
> -c CALL, --mycall=CALL
> source callsign
> -t CALL, --tocall=CALL
> recipient callsign
> -v CALL, --via=CALL digipeater callsign
> -d, --do-logging enable logging on datafiles
> -s, --use-datafile use usrp.dat (256kbps) as output
>
> This program transmit a message from a source callsign to a dest callsign
> via a digipeater. It is made to work with a basic TX board (the only tx
> board I have), therefore it uses the repetition of spectrum of a sampled
> signal to go to VHF. I guess the code can be easily adapted for more
> serious transmit boards.
>
> 9600rx.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 packet whose CRC
> check failed. When CRC check for a packet is ok, the framer prints the CRC
> value to standard output and returns the packet to python, whose function
> printpacket prints it in a readable format.
>
> 9600tx.py
> usage: 9600tx.py [options]
>
> options:
> -h, --help show this help message and exit
> -f FREQ, --freq=FREQ set frequency to FREQ
> -m MESSAGE, --message=MESSAGE
> message to send
> -c CALL, --mycall=CALL
> source callsign
> -t CALL, --tocall=CALL
> recipient callsign
> -v CALL, --via=CALL digipeater callsign
> -d, --do-logging enable logging on datafiles
> -s, --use-datafile use usrp.dat (256kbps) as output
>
> This program transmit a message from a source callsign to a dest callsign
> via a digipeater. It is made to work with a basic TX board (the only tx
> board I have), therefore it uses the repetition of spectrum of a sampled
> signal to go to VHF

Re: [Discuss-gnuradio] Call for testing release 3.0.1

[Berndt Josef Wulf]

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 "?

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] Suggestion for improvement on USRP

[Berndt Josef Wulf]

On Sunday 29 October 2006 00:00, hanwen wrote:
> Hi, all,
>
> Having enjoyed GNU Radio for several months, I've got two ideas to make
> improvement on USRP.
> As I know, making daughterboard synchronized to the mother boards and the
> synchronization of several motherboard will need a little modification to
> the boards. That is to change the locations of some resistors and
> capacitors.
> In the further revison of USRP, I think it's better to place some jumpers
> on boards for setting clock ralations between the boards. That'll be much
> more convenient.
>
> Another suggestion is that USB 2.0 is not fast enough for some application.
> Maybe in the future, It can be replaced by faster interface such as
> Gigabits Ethernet, 1394 or even PCI iterface.

Just another note to fill the wish list:

Place LED's at the edge of the board where they can be observed easily. The 
current design hides the LED's below the daughter boards and are hard to 
observe.

cheerio Berndt


___
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

[Berndt Josef Wulf]

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] Test reports needed for release 3.0rc1 tarball

[Berndt Josef Wulf]

G'day,

3.0rc1 fails on NetBSD due to missing fusb_ra_wb.h:


gmake[5]: Entering directory `/tmp/gnuradio-3.0rc1/usrp/host/lib'
if /bin/ksh ../../../libtool --tag=CXX --mode=compile 
g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../usrp/host/lib 
-I../../../usrp/firmware/include  -I/usr/pkg/include  -I/usr/pkg/include -Wall 
-Woverloaded-virtual -pthread -MT 
fusb_ra_wb.lo -MD -MP -MF ".deps/fusb_ra_wb.Tpo" -c -o fusb_ra_wb.lo 
fusb_ra_wb.cc; \
then mv -f ".deps/fusb_ra_wb.Tpo" ".deps/fusb_ra_wb.Plo"; else 
rm -f ".deps/fusb_ra_wb.Tpo"; exit 1; fi
 
g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -I../../../usrp/host/lib 
-I../../../usrp/firmware/include -I/usr/pkg/include -I/usr/pkg/include -Wall 
-Woverloaded-virtual -pthread -MT 
fusb_ra_wb.lo -MD -MP -MF .deps/fusb_ra_wb.Tpo -c 
fusb_ra_wb.cc  -fPIC -DPIC -o .libs/fusb_ra_wb.o
fusb_ra_wb.cc:27:24: error: fusb_ra_wb.h: No such file or directory
fusb_ra_wb.cc:78: error: 'fusb_devhandle_ra_wb' has not been declared
fusb_ra_wb.cc:78: error: ISO C++ forbids declaration of 'fusb_devhandle_ra_wb' 
with no type
[...]


The patches that optimizes data bandwidth on USB interface hasn't made it into 
the trunk :(

cheerio Berndt

On Wednesday 04 October 2006 02:05, Johnathan Corgan wrote:
> This is just a reminder to the group that we have GNU Radio release
> 3.0rc1 available for testing:
>
> http://gnuradio.org/releases/gnuradio/gnuradio-3.0rc1.tar.gz
>
> There have been no reported problems so far, but it would also be
> helpful to get more "works for me" reports as well.  You can send a note
> to me or to the list.
>
> Once the tarball is unpacked, the only difference in build instructions
> between the tarball and building from SVN is that one does not need to
> run 'bootstrap' first.
>
> The release tarball does not include all the components that are
> available via SVN, as some are considered experimental, incomplete, or
> destined for a future 'contrib' tarball.  You can still obtain these via
> SVN.
>
> Johnathan Corgan, AE6HO
> [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

Re: [Discuss-gnuradio] Dawei Shen's tutorials

[Berndt Josef Wulf]

Document states the date of May 19, 2005. It doesn't appear to be up-to-date.

cheerio Berndt

On Friday 29 September 2006 14:21, Eric Blossom wrote:
> On Thu, Sep 28, 2006 at 01:26:18PM -0400, Lee Patton wrote:
> > The tutorials moved:
> > http://www.nd.edu/~jnl/sdr/docs/
>
> Unless they have recently been updated, they are getting to be quite
> out of date.  That is why we took the link down.
>
> Also, since they are not under our control, we have been unable to
> correct them.
>
> Eric
>
> > On Thu, 2006-09-28 at 12:16 -0500, TM Tiwari wrote:
> > > Hi Eric,
> > >
> > > I was serching for the tutorials but I could not find it. Can you
> > > please help me in this regard, because I am just about to start the
> > > GNU Radio project?
> > >
> > > Thank you
> > >
> > > Tarun
>
> ___
> 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.

[Berndt Josef Wulf]

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] to prevent mental damages, avoid dB's.

[Berndt Josef Wulf]

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.

[Berndt Josef Wulf]

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

[Discuss-gnuradio] Test: Ignore

[Berndt Josef Wulf]

Since your are reading this:

I'm not sure why gnu.org lists are still listed in several RBL databases. I'm 
subscribed to many mailing lists but gnuradio 
is the only one giving me grieve.  This situation exists for a long time now 
and I'm surprised that the responsible list maintainers seemingly don't care 
and get this sorted out for once and all! Personally, I couldn't sleep until 
this problem was fixed for once and all if this was my domain being 
blacklisted.

cheerio Berndt


___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio