Friday, December 31, 2010

Re: [Discuss-gnuradio] ICOM 706 MKIIG as input to GNURadio

On 12/31/2010 02:24 PM, Brad Hein wrote:
>
> I'm looking for a way to tap into the unmodulated signal in my ICOM
> 706 MKIIG (I don't have a SDR BUT I do have a sound card, and lots of
> ham equipment :) ).
>
> Referring to the product service manual[1], I have found the "product
> detector" signal before it reaches the AF stages.
>
> Also it appears (hoping I'm wrong) that the second IF runs at about
> 9Mhz. So does that mean that I need to down-convert the signal from
> 9Mhz, to something the soundcard can handle?
>
> Or is there a better place to tap the IQ signal coming from the VDO...?
>
> Anybody else had any success in tapping the IQ in a receiver and
> feeding that into GNURadio?
>
>
> 73
> K1GTO
> BH
>
Pulling off a signal from the 2nd IF would likely be doable. But you'll
need to convert it to quadrature baseband somehow.

Most "traditional" receivers *do not* have a quadrature architecture.

You might look into getting something like a "SoftRock 40" and modifying
it to produce a quadrature conversion to baseband from
9MHz, instead of the nominal 7.1MHz that the "Softrock 40" is
designed for. I think the "SoftRock" series uses a Tayloe
detector, whose crystal clock runs at 4X the nominal conversion
frequency.

If you can identify the point in the receiver where the 9MHz IF is at
roughly 50Ohms impedance, it should be quite straightforward.


--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] USRP N210 10MHz reference input

Thanks Josh - knowing what to look for helped - as does my using the right
file =) Just confirmed operation by gently phase modulating my reference
clock from a signal generator with a CW RF input - the sample phases follow
as they should.
R.


Josh Blum-3 wrote:
>
>
>> The problem is this: the 'Ref Clock' switch in the 'UHD Single USRP
>> Source'
>> doesn't appear to function. Switching it to External does seem to do
>> anything. The GRC code is the same no matter whether I set the ref clock
>> to
>> int or ext (I checked the python code with diff).
>>
>
> Works for me, here is my diff when i switch the ref to External and
> click generate:
>
>> io_type=uhd.io_type_t.COMPLEX_FLOAT32,
>> num_channels=1,
>> )
>> + _clk_cfg = uhd.clock_config_t()
>> + _clk_cfg.ref_source = uhd.clock_config_t.REF_SMA
>> + _clk_cfg.pps_source = uhd.clock_config_t.PPS_SMA
>> + _clk_cfg.pps_polarity = uhd.clock_config_t.PPS_POS
>> + self.uhd_single_usrp_source_0.set_clock_config(_clk_cfg);
>> self.uhd_single_usrp_source_0.set_samp_rate(samp_rate)
>> self.uhd_single_usrp_source_0.set_center_freq(rx_freq, 0)
>> self.uhd_single_usrp_source_0.set_gain(0, 0)
>
> -Josh
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

--
View this message in context: http://old.nabble.com/USRP-N210-10MHz-reference-input-tp30564787p30564992.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

[Discuss-gnuradio] ICOM 706 MKIIG as input to GNURadio


I'm looking for a way to tap into the unmodulated signal in my ICOM 706 MKIIG (I don't have a SDR BUT I do have a sound card, and lots of ham equipment :) ).

Referring to the product service manual[1], I have found the "product detector" signal before it reaches the AF stages.

Also it appears (hoping I'm wrong) that the second IF runs at about 9Mhz. So does that mean that I need to down-convert the signal from 9Mhz, to something the soundcard can handle?

Or is there a better place to tap the IQ signal coming from the VDO...?

Anybody else had any success in tapping the IQ in a receiver and feeding that into GNURadio?


73
K1GTO
BH


References
[1] http://www.rigpix.com/icom/ic706mkiig.htm

Re: [Discuss-gnuradio] gnuradio on virtual linux?

Hi Ali,

I managed to get a N210 running on a virtual Ubuntu 10.04 on a Windows 7
laptop with VirtualBox. The N210 was connected via a bridged connection to
the GbE port. Can't comment on the merits of various VMs but can confirm
that it is workable - at least for for sample rates <2Mbps.

R.


alirazib wrote:
>
> Hi all,
>
> I have managed to install gnuradio 3.3.0 on my Windows machine with
> Cygwin, although some of the components like gr-usrp2, usrp2, grc, wxgui
> etc. could not be installed. Then I needed to install drivers for USRP2.
> The apparent complexity involved in installing UHD drivers on Windows is
> actually making me rethink. I am thinking of installing a virtual linux
> environment (like, Portable Ubuntu, Microsoft Virtual PC or VMWire) on my
> Windows OS and then trying out the gnuradio and USRP2 packages designed
> for Ubuntu. Could anyone suggest me if that would be a good idea? If so,
> then which virtual machine should I choose?
>
> Thanks,
> Ali
>
>

--
View this message in context: http://old.nabble.com/gnuradio-on-virtual-linux--tp30525694p30564932.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] USRP N210 10MHz reference input

> The problem is this: the 'Ref Clock' switch in the 'UHD Single USRP Source'
> doesn't appear to function. Switching it to External does seem to do
> anything. The GRC code is the same no matter whether I set the ref clock to
> int or ext (I checked the python code with diff).
>

Works for me, here is my diff when i switch the ref to External and
click generate:

> io_type=uhd.io_type_t.COMPLEX_FLOAT32,
> num_channels=1,
> )
> + _clk_cfg = uhd.clock_config_t()
> + _clk_cfg.ref_source = uhd.clock_config_t.REF_SMA
> + _clk_cfg.pps_source = uhd.clock_config_t.PPS_SMA
> + _clk_cfg.pps_polarity = uhd.clock_config_t.PPS_POS
> + self.uhd_single_usrp_source_0.set_clock_config(_clk_cfg);
> self.uhd_single_usrp_source_0.set_samp_rate(samp_rate)
> self.uhd_single_usrp_source_0.set_center_freq(rx_freq, 0)
> self.uhd_single_usrp_source_0.set_gain(0, 0)

-Josh

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

[Discuss-gnuradio] USRP N210 10MHz reference input

Greetings, first post so please be gentle..

I have managed to build the UHD driver and gnuradio
(v3.3.1git-380-ged78ba5d) etc under Ubuntu 10.04. Running from the
gnuradio-companion it all works exactly as expected ie I can demodulate
broadcast FM OK and device streams reliably up to sample rates of 20Msps
fine.

I'm trying to get my shiny N210 to accept a 10MHz reference and 1PPS (from a
Trimble Mini-Thunderbolt GPSDO).
The problem is this: the 'Ref Clock' switch in the 'UHD Single USRP Source'
doesn't appear to function. Switching it to External does seem to do
anything. The GRC code is the same no matter whether I set the ref clock to
int or ext (I checked the python code with diff).

The 1PPS input seems to be working OK - tested 'test_pps_input' from UHD -
passes with GPS connected and fails when I remove the 1PPS. The 10MHz input
is the right level ~10dBm. I'm guessing this is a software problem and not a
hardware one (this is a software radio right? :) )

Anyone got any ideas? Thanks in advance,

Rob.


--
View this message in context: http://old.nabble.com/USRP-N210-10MHz-reference-input-tp30564787p30564787.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

Re: [Discuss-gnuradio] Gnuradio website

On Fri, Dec 31, 2010 at 8:28 AM, Philip Balister <philip@balister.org> wrote:
> gnuradio.org is down, can someone kick it ...
>
> Philip


It has been kicked.

Tom

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

[Discuss-gnuradio] Gnuradio website

gnuradio.org is down, can someone kick it ...

Philip

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

[Discuss-gnuradio] SSB/AM driver amp for LFTX / BasicTX ?

Hi,

I am a ham, and software engineer, not a lot of electronics experience.
Can anybody recommend a commercial product, or simple circuit , or further information for taking whatever LFTX
(using USRP) puts out (1mw I guess ?) to at least 1W level (to later be fed into a linear amp like Tokyo Hy Power HL45B for SSB operating).

Thank you,

Adi

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

Re: [Discuss-gnuradio] cannot detect USRP2 on ubuntu 9.10 whatsoever...various solutions adopted...

On 12/31/2010 01:34 AM, Nick Foster wrote:
> Verify that the ethernet card (and cable) work with another device such
> as a network switch. The USRP2 should work with any gigabit Ethernet
> card supported in Linux.
>
> --n
>
> On Thu, 2010-12-30 at 20:23 +0800, yyl wrote:
>> On 12/22/2010 02:10 AM, Nick Foster wrote:
>>> If the ethtool output you provided is with the USRP2 plugged in and
>>> turned on, then your ethernet card isn't detecting a link. If another
>>> computer works fine with that same USRP2, I suspect the ethernet cable
>>> or your ethernet card as the culprit. You might also try:
>>>
>>> sudo ifconfig eth0 up
>>>
>>> and see if that affects the result of your ethtool output.
>>>
>>> --n
>>>
>>> On Tue, 2010-12-21 at 11:34 +0800, yulong yang wrote:
>>>> Hi all,
>>>>
>>>> I am new to gnuradio and stuck with the usrp2 connection for several
>>>> days... I looked up tens of search results but no solution yet.
>>>> Therefore I post my problem and hope someone could give me a hand:
>>>>
>>>> I am running gnu radio 3.2.2 on ubuntu9.10, and I think gnuradio works
>>>> fine because dial_tone.py and grc all could be launched correctly.
>>>> However, when I plug in USRP2, problems happen:
>>>>
>>>> if I typed in "sudo find_usrps" it says: No USRP2 found.
>>>>
>>>> if I typed "sudo find_usrps -e eth0" it also says No USRP2 found.
>>>> (eth0 is what I get when typing in ifconfig)
>>>>
>>>> if I typed in "sudo usrp2_fft.py" t says:
>>>>
>>>> Traceback (most recent call last):
>>>> File "/usr/local/bin/usrp2_fft.py", line 273, in<module>
>>>> main ()
>>>> File "/usr/local/bin/usrp2_fft.py", line 269, in main
>>>> app = stdgui2.stdapp(app_top_block, "USRP2 FFT", nstatus=1)
>>>> File
>>>> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
>>>> line 36, in __init__
>>>> wx.App.__init__ (self, redirect=False)
>>>> File
>>>> "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
>>>> line 7978, in __init__
>>>> self._BootstrapApp()
>>>> File
>>>> "/usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py",
>>>> line 7552, in _BootstrapApp
>>>> return _core_.PyApp__BootstrapApp(*args, **kwargs)
>>>> File
>>>> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
>>>> line 39, in OnInit
>>>> frame = stdframe (self.top_block_maker, self.title, self._nstatus)
>>>> File
>>>> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
>>>> line 60, in __init__
>>>> self.panel = stdpanel (self, self, top_block_maker)
>>>> File
>>>> "/usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/stdgui2.py",
>>>> line 81, in __init__
>>>> self.top_block = top_block_maker (frame, self, vbox, sys.argv)
>>>> File "/usr/local/bin/usrp2_fft.py", line 70, in __init__
>>>> self.u = usrp2.source_32fc(options.interface, options.mac_addr)
>>>> File "/usr/local/lib/python2.6/dist-packages/gnuradio/usrp2.py",
>>>> line 644, in source_32fc
>>>> return _usrp2.source_32fc(*args, **kwargs)
>>>> RuntimeError: No USRPs found on interface eth0
>>>>
>>>>
>>>> What exactly the problem is?
>>>> TO note:
>>>> 1. python is fine. I ran following process and it did not say error:
>>>> Python 2.6.4 (r264:75706, Dec 7 2009, 18:45:15)
>>>> [GCC 4.4.1] on linux2
>>>> Type "help", "copyright", "credits" or "license" for more
>>>> information.
>>>> >>> from gnuradio import gr
>>>> >>> from gnuradio import usrp
>>>> >>> from gnuradio import audio
>>>> >>> from gnuradio import usrp2
>>>> >>> exit()
>>>>
>>>> 2. could it be the firmware in usrp2? I saw some threads discussing
>>>> firmware in SD card. But it seems to run process like usrp2_fft.py
>>>> dose not need any firmware.
>>>>
>>>> 3. my usrp2 runs fine. I checked it with another computer which could
>>>> launch usrp_fft.py correctly. Also, when I power on usrp2, all 6
>>>> lights flah and then D and F remain on.
>>>>
>>>> 4. my ethernet card should be fine. it is gigabit. here is what it
>>>> says when I type in "sudo ethtool eth0":
>>>>
>>>> Settings for eth0:
>>>> Supported ports: [ TP ]
>>>> Supported link modes: 10baseT/Half 10baseT/Full
>>>> 100baseT/Half 100baseT/Full
>>>> 1000baseT/Full
>>>> Supports auto-negotiation: Yes
>>>> Advertised link modes: 10baseT/Half 10baseT/Full
>>>> 100baseT/Half 100baseT/Full
>>>> 1000baseT/Full
>>>> Advertised auto-negotiation: Yes
>>>> Speed: Unknown!
>>>> Duplex: Unknown! (255)
>>>> Port: Twisted Pair
>>>> PHYAD: 1
>>>> Transceiver: internal
>>>> Auto-negotiation: on
>>>> Supports Wake-on: pumbag
>>>> Wake-on: g
>>>> Current message level: 0x00000001 (1)
>>>> Link detected: no
>>>>
>>>>
>>>> I am really confused and find no solution on my own. Any suggestion
>>>> would be greatly appreciated. I will wait online and provide any
>>>> additional information if you need.
>>>> _______________________________________________
>>>> Discuss-gnuradio mailing list
>>>> Discuss-gnuradio@gnu.org
>>>> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>> sorry for the late response, I have been working on ubuntu for several
>> days. Thank you for your reply. I just tried this command and nothing
>> happened, I got the same result as previous.
>> Could the ethernet card be too new for usrp2 to recognize? I am confused
>> because I have done every step mentioned in build guide and ran grc well.
>

I find that the usrp2 could be found when I run wireshark. I searched
this question and found a thread talking about that maybe the broadcast
and multi-cast function of my ethernet card are closed by default, when
wireshark is running it opens them(they say it is under the promiscuous
mode) so usrp2 could be detected and ran files like usrp2_fft.py
successfully.

I am out of lab for now but I will return 2 days later and test the
ethernet card.

Thank you for your quick reply and happy new year in advance:)

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

Thursday, December 30, 2010

[Discuss-gnuradio] [UHD] Time delay does not work


Hello,

I am sending 802.11 packet using "tx_waveforms"
I have modified the code to read samples from a file.
The file is 2560000 samples for 1000 802.11 packets.
When I give 0 sec delay, gnuradio transmits packets and I have receive the packets from my laptop in monitor mode.
But if I give any delay, the packet seems not transmitted nor delayed.


------------------------------------------------------------------------------------------------------------------------------------
root@node1-2:~/git/uhd/host/build/examples# ./tx_waveforms --args addr=192.168.10.2 --freq 2427e6 --nsamps 2560001 --txrate 20e6 --gain 15 --secs 2

linux; GNU C++ version 4.4.1; Boost_103800; UHD_0001.20101229023217.253ac61


Creating the usrp device with: addr=192.168.10.2...
Current recv sock buff size: 50000000 bytes
Using Device: Single USRP:
  Device: USRP2/N Series device
  Mboard: USRP2-REV3 mboard
  RX DSP: USRP2-REV3 ddc0
  RX Channel: 0
    RX Dboard: USRP2-REV3 dboard (rx unit)
    RX Subdev: XCVR2450 (0x0061)
  TX DSP: USRP2-REV3 duc0
  TX Channel: 0
    TX Dboard: USRP2-REV3 dboard (tx unit)
    TX Subdev: XCVR2450 (0x0060)

Setting TX Rate: 20.000000 Msps...
Actual TX Rate: 20.000000 Msps...
Setting device timestamp to 0...
Read data to send from file: in.dat
Number of samples in file: 2560001

Sent 257382 samples

Done!




--
From: Sangho Oh
Voice mail: (609) 759-1552




--
From: Sangho Oh
Voice mail: (609) 759-1552

Re: [Discuss-gnuradio] Followup: M-Audio Revolution 7.1 as audio source at 192KHz: Fedora 14/Alsa/ICE1724 driver

On 12/30/2010 07:52 PM, Rafael Diniz wrote:
> Have you tried the OSS driver, using the 4front drivers?
>
> Best regards,
> Rafael Diniz
I dug deeper, and the card apparently only supports 96KHz on the input
side. I haven't used the
card in a few years, so my recollection of its input-side rate must be
wrong.

--
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] Followup: M-Audio Revolution 7.1 as audio source at 192KHz: Fedora 14/Alsa/ICE1724 driver

Have you tried the OSS driver, using the 4front drivers?

Best regards,
Rafael Diniz

> I'd noticed a problem with running the M-Audio Revolution 7.1 sound card
> at 192KHz as a source in Gnu Radio -- the spectrum was
> all "funny", with the spectrum getting "reflected" about 48KHz,
> almost as if the actual sample rate on the card wasn't correct, and
> perhaps set to 96KHz instead of the expected 192KHz.
>
> To eliminate Gnu Radio as a cause, I used "arecord" with the correct
> parameters to record a 20-second chunk of audio from the card,
> then used Gnu Radio to plot the spectrum. Sure enough, the spectrum
> is still not correct, so I suspect this is a driver issue.
>
> I *know* that I used to be able to use this card at 192KHz several years
> ago, and the card advertises 192KHz sampling as a feature.
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org
>
>
>
> _______________________________________________
> 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] two pfb channelizer questions

Have been playing with the channelizer and it's amazing! To re-raise an old point: IMHO, By all means, the hARRIS (lowercase "h" notation) should be kept, IMHO.

1. Sorry if this has been previously asked but I wasn't able to find it - say we want to channelize a swath but we're only interested in a few of the channels and we want to ignore the rest (e.g., say we care about only 5 of 100 available channels, but there are gaps between the "interesting" ones)...

In this example would it be necessary to connect up the remaining 95 "uninteresting" channels to the null_sink ?

2. This is perhaps more of a pfb question - our app uses gr.firdes.root_raised_cosine() which has the published restriction that "symbol rate must be a factor of sample rate" so that if the desired signal doesn't have this property it must be resampled (such as using the pfb arb resampler). Question is whether there exists some "magic pfb" method of performing the root-cosine filtering operation directly, without needing a resamp. Probably pie in the sky, but was just curious...

Best Regards

Max


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

Re: [Discuss-gnuradio] Followup: M-Audio Revolution 7.1 as audio source at 192KHz: Fedora 14/Alsa/ICE1724 driver

On 12/30/2010 03:31 PM, Marcus D. Leech wrote:
> I'd noticed a problem with running the M-Audio Revolution 7.1 sound
> card at 192KHz as a source in Gnu Radio -- the spectrum was
> all "funny", with the spectrum getting "reflected" about 48KHz,
> almost as if the actual sample rate on the card wasn't correct, and
> perhaps set to 96KHz instead of the expected 192KHz.
>
> To eliminate Gnu Radio as a cause, I used "arecord" with the correct
> parameters to record a 20-second chunk of audio from the card,
> then used Gnu Radio to plot the spectrum. Sure enough, the spectrum
> is still not correct, so I suspect this is a driver issue.
>
> I *know* that I used to be able to use this card at 192KHz several
> years ago, and the card advertises 192KHz sampling as a feature.
>
Yet another follow-up.

It turns out that despite what the hardware reports, the ADC on the
Revolution 7.1 only runs at 96KHz, and the controller apparently does
some kind of half-assed upsampling. Gack!

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] output 0 is not connected internally



On Thu, Dec 30, 2010 at 4:44 PM, Josh Blum <josh@joshknows.com> wrote:

>>
>> [root@gto ~]# gnuradio-companion
>> Traceback (most recent call last):
>>   File "/usr/local/bin/gnuradio-companion", line 45, in <module>
>>     """%gr.version()
>> AttributeError: 'module' object has no attribute 'version'
>>
>>

it looks like its importing from an older install of gnuradio that didnt
have the gr_constants* stuff. Make sure to clean out old gnuradio
installs tarballs, rpms, etc...



Aha -  you're right!

$ echo $PYTHONPATH
/usr/lib/python2.7/site-packages/mpich2

So after I set the PYTHONPATH to the one in /usr/local/lib... specified by Marcus, ***gnuradio-companion started up for the first time! ***

And you are correct - I did in fact have an old gnuradio RPM hanging around out there (it was a dependency of some other AX.25 stuff I was using so I thought I could get away with "overwriting it" with the compiled version of gnuradio, but I was wrong.).


Here's what I've learned from this experience

#1 - It is possible to run gnuradio + grc on Fedora 14
#2 - Install all development packages required to make the build process successful (if unsuccesful then it's due to missing dependency package)
#3 - Install gnuradio + grc from git source (as specified on gnuradio wiki page "BuildGuide".
#4 - Make sure that PYTHONPATH=/usr/local/lib/
python2.7/site-packages. If not, then there is another instance of something (gnuradio?) conflicting with the newly built one.
#5 -  The gnuradio and grc which currently ship with Fedora 14 are outdated, and seem to be broken/misconfigured (they don't work out of hte box).
 




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

RE: Re: [Discuss-gnuradio] import qtgui error

Ally,

Do you have PyQwt (http:// http://pyqwt.sourceforge.net/) installed ?

Mike

-----Original Message-----
From: discuss-gnuradio-bounces+dr=drelectro.com@gnu.org [mailto:discuss-gnuradio-bounces+dr=drelectro.com@gnu.org] On Behalf Of Tom Rondeau
Sent: Friday, 24 December 2010 9:11 AM
To: lishan_wh
Cc: discuss-gnuradio@gnu.org
Subject: Re: Re: [Discuss-gnuradio] import qtgui error

On Wed, Dec 22, 2010 at 7:13 PM, lishan_wh <lishan_wh@126.com> wrote:
> Tom,
> I use Ubuntu 9.04 and QWT-5.0.2.
> Thank you!
> Ally


Strange, I'm able to run this example on an Ubuntu 8.04 running
QWT-5.0.2, QT 4.3.4, and GNU Radio v. 3.3.0.

Are you sure you don't have multiple installations of QT4, QWT, or GNU
Radio anywhere?

Tom

> At 2010-12-22 22:55:41,"Tom Rondeau" <trondeau1122@gmail.com> wrote:
>>2010/12/22 lishan_wh <lishan_wh@126.com>:
>>> I tried the code of 'Tutorial - Using the QT GUI Blocks in GNU Radio', but
>>> error occurred.
>>>
>>> Traceback (most recent call last):
>>> File "qt_basics.py", line 4, in <module>
>>> from gnuradio.qtgui import qtgui
>>> File
>>> "/opt/gnuradio/3.3.0/lib/python2.6/site-packages/gnuradio/qtgui/qtgui.py",
>>> line 6, in <module>
>>> import _qtgui
>>> ImportError: /opt/gnuradio/3.3.0/lib/libgnuradio-qtgui-3.3.0.so.0: undefined
>>> symbol: _ZN9QwtPicker5resetEv
>>>
>>> Who can tell me what is the problem? Thank you!
>>
>>What version of QWT are you using? What's your OS?
>>
>>Tom
>
>

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


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

Re: [Discuss-gnuradio] output 0 is not connected internally

>>
>> [root@gto ~]# gnuradio-companion
>> Traceback (most recent call last):
>> File "/usr/local/bin/gnuradio-companion", line 45, in <module>
>> """%gr.version()
>> AttributeError: 'module' object has no attribute 'version'
>>
>>

it looks like its importing from an older install of gnuradio that didnt
have the gr_constants* stuff. Make sure to clean out old gnuradio
installs tarballs, rpms, etc...

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

Re: [Discuss-gnuradio] output 0 is not connected internally

On 12/30/2010 04:09 PM, Brad Hein wrote:


On Thu, Dec 30, 2010 at 2:05 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 12/30/2010 01:51 PM, Brad Hein wrote:


Thank you both for your suggestions,

I'll go ahead and carefully follow the instructions on the gnuradio wiki page "FedoraInstall" under "gnuradio from tarball".

BH

Do it from the GIT source.  It's almost always stable enough to use.


Compilation from GIT source was successful. I ran make install, and ran gnuradio-companion, and it's now producing the error shown below, which I am investigating...

Marcus - Any chance you could send me the output from an "rpm -qa" on your box, so I can compare packages? I'm wondering what could be different between your Fedora14 (which as you say, works) , and mine, which has so many problems...


[root@gto ~]# gnuradio-companion
Traceback (most recent call last):
  File "/usr/local/bin/gnuradio-companion", line 45, in <module>
    """%gr.version()
AttributeError: 'module' object has no attribute 'version'


That's almost certainly because your PYTHONPATH is either not set, or set to the wrong thing.

Under F14, on a 32-bit machine, it should be:

PYTHONPATH=/usr/local/lib/python2.7/site-packages

Also make sure that /usr/local/lib is in your ld.so cache





--  Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org 

Re: [Discuss-gnuradio] output 0 is not connected internally



On Thu, Dec 30, 2010 at 2:05 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
On 12/30/2010 01:51 PM, Brad Hein wrote:


Thank you both for your suggestions,

I'll go ahead and carefully follow the instructions on the gnuradio wiki page "FedoraInstall" under "gnuradio from tarball".

BH

Do it from the GIT source.  It's almost always stable enough to use.


Compilation from GIT source was successful. I ran make install, and ran gnuradio-companion, and it's now producing the error shown below, which I am investigating...

Marcus - Any chance you could send me the output from an "rpm -qa" on your box, so I can compare packages? I'm wondering what could be different between your Fedora14 (which as you say, works) , and mine, which has so many problems...


[root@gto ~]# gnuradio-companion
Traceback (most recent call last):
  File "/usr/local/bin/gnuradio-companion", line 45, in <module>
    """%gr.version()
AttributeError: 'module' object has no attribute 'version'






 

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org



[Discuss-gnuradio] Followup: M-Audio Revolution 7.1 as audio source at 192KHz: Fedora 14/Alsa/ICE1724 driver

I'd noticed a problem with running the M-Audio Revolution 7.1 sound card
at 192KHz as a source in Gnu Radio -- the spectrum was
all "funny", with the spectrum getting "reflected" about 48KHz,
almost as if the actual sample rate on the card wasn't correct, and
perhaps set to 96KHz instead of the expected 192KHz.

To eliminate Gnu Radio as a cause, I used "arecord" with the correct
parameters to record a 20-second chunk of audio from the card,
then used Gnu Radio to plot the spectrum. Sure enough, the spectrum
is still not correct, so I suspect this is a driver issue.

I *know* that I used to be able to use this card at 192KHz several years
ago, and the card advertises 192KHz sampling as a feature.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] output 0 is not connected internally

On 12/30/2010 01:51 PM, Brad Hein wrote:
>
>
> Thank you both for your suggestions,
>
> I'll go ahead and carefully follow the instructions on the gnuradio
> wiki page "FedoraInstall" under "gnuradio from tarball".
>
> BH
>
Do it from the GIT source. It's almost always stable enough to use.

--
Marcus Leech
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
http://www.sbrac.org

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

Re: [Discuss-gnuradio] output 0 is not connected internally

On Thu, Dec 30, 2010 at 1:26 PM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Thu, Dec 30, 2010 at 12:48 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
> On 12/30/2010 12:39 PM, George S. Williams wrote:
>
> On 12/30/2010 12:16 PM, Brad Hein wrote:
>
> Unfortunately the compile failed - I ran into compile errors with things in
> the usrp2 and gr-usrp2 directories, so I removed them from the Makefile and
> the compile eventually went through... But make install didn't seem to
> install any new grc binaries. I made sure to run configure with --with-grc,
> so I don't think it's being skipped.
>
> Is anybody else out there working on getting gnuradio working in Fedora14
> who would like to join forces?
>
> I've been running Gnu Radio on F14 for quite some time.
>
> Following the instructions in the build guide, make sure you have the
> pre-reqs, and you should be good to go.
>
> http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide
>
> If you go the UHD route (which I recommend), you'll need to set
> PKG_CONFIG_PATH to point at /usr/local/lib/pkgconfig before doing the
>   configure and make steps for gnu radio.
>


Thank you both for your suggestions,

I'll go ahead and carefully follow the instructions on the gnuradio wiki page "FedoraInstall" under "gnuradio from tarball".

BH

 
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org


Brad,
Follow what Marcus said. I just wanted to chime in and say that you
shouldn't ever need to do anything with the Makefiles. If a component
fails in configure, make will not try to build it. If you need to, you
can explicitly remove a component with ./configure
--disable-<component-name>.

Tom

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

Re: [Discuss-gnuradio] output 0 is not connected internally

On Thu, Dec 30, 2010 at 12:48 PM, Marcus D. Leech <mleech@ripnet.com> wrote:
> On 12/30/2010 12:39 PM, George S. Williams wrote:
>
> On 12/30/2010 12:16 PM, Brad Hein wrote:
>
> Unfortunately the compile failed - I ran into compile errors with things in
> the usrp2 and gr-usrp2 directories, so I removed them from the Makefile and
> the compile eventually went through... But make install didn't seem to
> install any new grc binaries. I made sure to run configure with --with-grc,
> so I don't think it's being skipped.
>
> Is anybody else out there working on getting gnuradio working in Fedora14
> who would like to join forces?
>
> I've been running Gnu Radio on F14 for quite some time.
>
> Following the instructions in the build guide, make sure you have the
> pre-reqs, and you should be good to go.
>
> http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide
>
> If you go the UHD route (which I recommend), you'll need to set
> PKG_CONFIG_PATH to point at /usr/local/lib/pkgconfig before doing the
>   configure and make steps for gnu radio.
>
>
>
> --
> Marcus Leech
> Principal Investigator
> Shirleys Bay Radio Astronomy Consortium
> http://www.sbrac.org


Brad,
Follow what Marcus said. I just wanted to chime in and say that you
shouldn't ever need to do anything with the Makefiles. If a component
fails in configure, make will not try to build it. If you need to, you
can explicitly remove a component with ./configure
--disable-<component-name>.

Tom

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

Re: [Discuss-gnuradio] output 0 is not connected internally

On 12/30/2010 12:39 PM, George S. Williams wrote:
On 12/30/2010 12:16 PM, Brad Hein wrote:


Unfortunately the compile failed - I ran into compile errors with things in the usrp2 and gr-usrp2 directories, so I removed them from the Makefile and the compile eventually went through... But make install didn't seem to install any new grc binaries. I made sure to run configure with --with-grc, so I don't think it's being skipped.

Is anybody else out there working on getting gnuradio working in Fedora14 who would like to join forces?

I've been running Gnu Radio on F14 for quite some time.

Following the instructions in the build guide, make sure you have the pre-reqs, and you should be good to go.

http://gnuradio.org/redmine/wiki/gnuradio/BuildGuide

If you go the UHD route (which I recommend), you'll need to set PKG_CONFIG_PATH to point at /usr/local/lib/pkgconfig before doing the
  configure and make steps for gnu radio.



--  Marcus Leech Principal Investigator Shirleys Bay Radio Astronomy Consortium http://www.sbrac.org 

Re: [Discuss-gnuradio] output 0 is not connected internally

On 12/30/2010 12:16 PM, Brad Hein wrote:


Unfortunately the compile failed - I ran into compile errors with things in the usrp2 and gr-usrp2 directories, so I removed them from the Makefile and the compile eventually went through... But make install didn't seem to install any new grc binaries. I made sure to run configure with --with-grc, so I don't think it's being skipped.

Is anybody else out there working on getting gnuradio working in Fedora14 who would like to join forces?

My next step is to install Ubuntu (not to use, but as a reference), which is what I saw a user in a youtube video using to demonstrate a touch tones app. I'll try and transplant grc to Fedora, or at least compare the two configurations to hopefully expose a difference in the python files so I can get it working.

 

 
Tom


grc is now called gnuradio-companion

For me it's at-   /usr/local/bin/gnuradio-companion

I spent a week trying to figure it out...

HTH,
George

Re: [Discuss-gnuradio] why there is a requirement of adc_model.v in usrp2 ?

On Wed, 2010-12-29 at 21:06 -0800, anirudh2059. wrote:
> Hi,
>
> I am working on my college project (usrp2). I am trying to analyze some of
> the FPGA codes and I came across a code for adc i.e. adc_model.v . (
> /usrp2/models). My question is if I am using an external ADC (LTC 2284) then
> why is it required to design a model for adc?
>
> pls note:- I am a new bee in usrp2. Sorry for posting such a silly question
> :confused:

nick@crapshoot:~/ettus/fpga$ grep "adc_model" * -r
usrp2/models/adc_model.v:module adc_model
usrp2/models/adc_model.v:endmodule // adc_model
usrp2/top/single_u2_sim/single_u2_sim.v: adc_model adc_model

It's only instantiated in single_u2_sim. It's not used in the USRP2
FPGA.


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

Re: [Discuss-gnuradio] output 0 is not connected internally



On Thu, Dec 30, 2010 at 11:12 AM, Brad Hein <linuxbrad@gmail.com> wrote:

On Thu, Dec 30, 2010 at 10:26 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Wed, Dec 29, 2010 at 10:57 PM, Brad Hein <linuxbrad@gmail.com> wrote:
>
> I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386
> computers. I've tried two now, and I'm plagued with the same problems - they
> just won't execute.
>
> I suspect there's a problem which went undetected, maybe a python file
> version mismatch or some other inconsistency. I'm trying hard to isolate the
> source of the problem.
>
> I also wrote a very basic grc which consisted of a sound source and attached
> it to different sinks (audio sync / waterfall sink / scope sink) - each
> producing the same error shown below, when executed.
>
> I'm trying different things, but any input would be greatly appreciated =)

Looking at your version information below, you're running a very old
version of the GNU Radio Companion (grc 0.70). You'll need to update
it, which I think will solve your problem. I actually don't know if we
have a newer package of GRC out there, so you might have to
compile/install it yourself (Josh, let me know if I'm wrong about
this).



Thank you for pointing that out! I went ahead and obtained gnuradio 3.3.0 (sourcecode) and I'm setting up my "faster" Fedora PC to compile it.

If this works, I suppose I should share the procedure with Fedora so they can make the necessary changes to the F14 repo so that others can have a working configuration without the need for compiling.




Unfortunately the compile failed - I ran into compile errors with things in the usrp2 and gr-usrp2 directories, so I removed them from the Makefile and the compile eventually went through... But make install didn't seem to install any new grc binaries. I made sure to run configure with --with-grc, so I don't think it's being skipped.

Is anybody else out there working on getting gnuradio working in Fedora14 who would like to join forces?

My next step is to install Ubuntu (not to use, but as a reference), which is what I saw a user in a youtube video using to demonstrate a touch tones app. I'll try and transplant grc to Fedora, or at least compare the two configurations to hopefully expose a difference in the python files so I can get it working.

 

 
Tom



> The error shown when executed
> ===================================
>
> Executing: "/usr/share/grc/examples/audio/phone_tones.grc.xml"
>>>> Verbose:
> Traceback (most recent call last):
>   File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 231, in OnInit
>     self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first
> argument is the flow graph
>   File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 165, in __init__
>     self._start() #start the flow graph
>   File "/usr/share/grc/src/ExecFlowGraph.py", line 54, in _start
>     self.start()
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 97,
> in start
>     self._tb.start()
>   File
> "/usr/lib/python2.7/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
> line 1455, in start
>     return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self)
> RuntimeError: In hierarchical block scope throttle, output 0 is not
> connected internally
>
>>>> Done
>
>
> RPM Package list on Fedora14 notebook PC (basically identical to the other
> F14 PC)
> ===============================================================
>
> [root@Fedora14Laptop ~]# rpm -qa |egrep -i "gnuradio|grc|python"|sort
> abrt-addon-python-1.1.14-1.fc14.i686
> at-spi-python-1.32.0-2.fc14.i686
> audit-libs-python-2.0.4-4.fc14.i686
> cracklib-python-2.8.16-4.fc14.i686
> dbus-python-0.83.0-7.fc14.i686
> farsight2-python-0.0.21-2.fc14.i686
> gnome-python2-2.28.1-3.fc14.i686
> gnome-python2-applet-2.32.0-1.fc14.i686
> gnome-python2-bonobo-2.28.1-3.fc14.i686
> gnome-python2-canvas-2.28.1-3.fc14.i686
> gnome-python2-desktop-2.32.0-1.fc14.i686
> gnome-python2-extras-2.25.3-25.fc14.1.i686
> gnome-python2-gconf-2.28.1-3.fc14.i686
> gnome-python2-gnome-2.28.1-3.fc14.i686
> gnome-python2-gnomekeyring-2.32.0-1.fc14.i686
> gnome-python2-gnomevfs-2.28.1-3.fc14.i686
> gnome-python2-gtkhtml2-2.25.3-25.fc14.1.i686
> gnome-python2-libegg-2.25.3-25.fc14.1.i686
> gnome-python2-libwnck-2.32.0-1.fc14.i686
> gnuradio-3.2.2-7.fc14.i686
> grc-0.70-6.fc12.noarch
> gstreamer-python-0.10.19-1.fc14.i686
> libproxy-python-0.4.4-7.fc14.noarch
> libselinux-python-2.0.96-6.fc14.1.i686
> libsemanage-python-2.0.45-5.fc14.i686
> libuser-python-0.56.18-2.fc14.i686
> libxml2-python-2.7.7-2.fc14.i686
> newt-python-0.52.12-1.fc14.i686
> notify-python-0.1.1-15.fc14.i686
> policycoreutils-python-2.0.83-33.2.fc14.i686
> python-2.7-8.fc14.1.i686
> python-beaker-1.5.3-5.fc14.noarch
> python-BeautifulSoup-3.0.8.1-2.fc14.noarch
> python-boto-1.9b-3.fc14.noarch
> python-bugzilla-0.6.1-3.fc14.noarch
> python-crypto-2.3-2.fc14.1.i686
> python-cryptsetup-0.0.10-3.fc14.i686
> python-decorator-3.2.0-3.fc14.noarch
> python-deltarpm-3.6-0.2.20100708git.fc14.i686
> python-devel-2.7-8.fc14.1.i686
> python-ethtool-0.5-1.fc14.i686
> python-feedparser-4.1-12.fc14.noarch
> python-GnuPGInterface-0.3.2-7.fc14.noarch
> python-httplib2-0.6.0-3.fc14.noarch
> python-iniparse-0.4-2.fc14.noarch
> python-iwlib-0.1-3.fc14.i686
> python-libs-2.7-8.fc14.1.i686
> python-mako-0.3.4-2.fc14.noarch
> python-markupsafe-0.9.2-4.fc14.i686
> python-meh-0.10-2.fc14.noarch
> python-nose-0.11.3-5.fc14.noarch
> python-nss-0.9-9.fc14.i686
> python-paste-1.7.4-7.fc14.noarch
> python-pyblock-0.52-1.fc14.i686
> python-pycurl-7.19.0-7.fc14.i686
> python-setuptools-0.6.14-3.fc14.noarch
> python-simplejson-2.1.1-4.fc14.i686
> python-slip-0.2.13-1.fc14.noarch
> python-slip-dbus-0.2.13-1.fc14.noarch
> python-telepathy-0.15.18-1.fc14.noarch
> python-tempita-0.4-5.fc14.noarch
> python-urlgrabber-3.9.1-7.fc14.noarch
> python-virtkey-0.50-8.fc14.i686
> python-xlib-0.15-0.3.rc1.fc14.noarch
> rpm-python-4.8.1-5.fc14.i686
> setools-libs-python-3.3.7-8.fc14.i686
> wxPython-2.8.11.0-4.fc14.i686
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>


Re: [Discuss-gnuradio] output 0 is not connected internally

On Thu, Dec 30, 2010 at 11:12 AM, Brad Hein <linuxbrad@gmail.com> wrote:
>
> On Thu, Dec 30, 2010 at 10:26 AM, Tom Rondeau <trondeau1122@gmail.com>
> wrote:
>>
>> On Wed, Dec 29, 2010 at 10:57 PM, Brad Hein <linuxbrad@gmail.com> wrote:
>> >
>> > I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386
>> > computers. I've tried two now, and I'm plagued with the same problems -
>> > they
>> > just won't execute.
>> >
>> > I suspect there's a problem which went undetected, maybe a python file
>> > version mismatch or some other inconsistency. I'm trying hard to isolate
>> > the
>> > source of the problem.
>> >
>> > I also wrote a very basic grc which consisted of a sound source and
>> > attached
>> > it to different sinks (audio sync / waterfall sink / scope sink) - each
>> > producing the same error shown below, when executed.
>> >
>> > I'm trying different things, but any input would be greatly appreciated
>> > =)
>>
>> Looking at your version information below, you're running a very old
>> version of the GNU Radio Companion (grc 0.70). You'll need to update
>> it, which I think will solve your problem. I actually don't know if we
>> have a newer package of GRC out there, so you might have to
>> compile/install it yourself (Josh, let me know if I'm wrong about
>> this).
>>
>
>
> Thank you for pointing that out! I went ahead and obtained gnuradio 3.3.0
> (sourcecode) and I'm setting up my "faster" Fedora PC to compile it.
>
> If this works, I suppose I should share the procedure with Fedora so they
> can make the necessary changes to the F14 repo so that others can have a
> working configuration without the need for compiling.
>
> BH


There has been work on an RPM for Fedora 14, but the spec file doesn't
include GRC.

In general, though, we need to be better about keeping these guys up to date.

Thanks,
Tom

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

Re: [Discuss-gnuradio] output 0 is not connected internally


On Thu, Dec 30, 2010 at 10:26 AM, Tom Rondeau <trondeau1122@gmail.com> wrote:
On Wed, Dec 29, 2010 at 10:57 PM, Brad Hein <linuxbrad@gmail.com> wrote:
>
> I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386
> computers. I've tried two now, and I'm plagued with the same problems - they
> just won't execute.
>
> I suspect there's a problem which went undetected, maybe a python file
> version mismatch or some other inconsistency. I'm trying hard to isolate the
> source of the problem.
>
> I also wrote a very basic grc which consisted of a sound source and attached
> it to different sinks (audio sync / waterfall sink / scope sink) - each
> producing the same error shown below, when executed.
>
> I'm trying different things, but any input would be greatly appreciated =)

Looking at your version information below, you're running a very old
version of the GNU Radio Companion (grc 0.70). You'll need to update
it, which I think will solve your problem. I actually don't know if we
have a newer package of GRC out there, so you might have to
compile/install it yourself (Josh, let me know if I'm wrong about
this).



Thank you for pointing that out! I went ahead and obtained gnuradio 3.3.0 (sourcecode) and I'm setting up my "faster" Fedora PC to compile it.

If this works, I suppose I should share the procedure with Fedora so they can make the necessary changes to the F14 repo so that others can have a working configuration without the need for compiling.

BH

 
Tom



> The error shown when executed
> ===================================
>
> Executing: "/usr/share/grc/examples/audio/phone_tones.grc.xml"
>>>> Verbose:
> Traceback (most recent call last):
>   File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 231, in OnInit
>     self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first
> argument is the flow graph
>   File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 165, in __init__
>     self._start() #start the flow graph
>   File "/usr/share/grc/src/ExecFlowGraph.py", line 54, in _start
>     self.start()
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 97,
> in start
>     self._tb.start()
>   File
> "/usr/lib/python2.7/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
> line 1455, in start
>     return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self)
> RuntimeError: In hierarchical block scope throttle, output 0 is not
> connected internally
>
>>>> Done
>
>
> RPM Package list on Fedora14 notebook PC (basically identical to the other
> F14 PC)
> ===============================================================
>
> [root@Fedora14Laptop ~]# rpm -qa |egrep -i "gnuradio|grc|python"|sort
> abrt-addon-python-1.1.14-1.fc14.i686
> at-spi-python-1.32.0-2.fc14.i686
> audit-libs-python-2.0.4-4.fc14.i686
> cracklib-python-2.8.16-4.fc14.i686
> dbus-python-0.83.0-7.fc14.i686
> farsight2-python-0.0.21-2.fc14.i686
> gnome-python2-2.28.1-3.fc14.i686
> gnome-python2-applet-2.32.0-1.fc14.i686
> gnome-python2-bonobo-2.28.1-3.fc14.i686
> gnome-python2-canvas-2.28.1-3.fc14.i686
> gnome-python2-desktop-2.32.0-1.fc14.i686
> gnome-python2-extras-2.25.3-25.fc14.1.i686
> gnome-python2-gconf-2.28.1-3.fc14.i686
> gnome-python2-gnome-2.28.1-3.fc14.i686
> gnome-python2-gnomekeyring-2.32.0-1.fc14.i686
> gnome-python2-gnomevfs-2.28.1-3.fc14.i686
> gnome-python2-gtkhtml2-2.25.3-25.fc14.1.i686
> gnome-python2-libegg-2.25.3-25.fc14.1.i686
> gnome-python2-libwnck-2.32.0-1.fc14.i686
> gnuradio-3.2.2-7.fc14.i686
> grc-0.70-6.fc12.noarch
> gstreamer-python-0.10.19-1.fc14.i686
> libproxy-python-0.4.4-7.fc14.noarch
> libselinux-python-2.0.96-6.fc14.1.i686
> libsemanage-python-2.0.45-5.fc14.i686
> libuser-python-0.56.18-2.fc14.i686
> libxml2-python-2.7.7-2.fc14.i686
> newt-python-0.52.12-1.fc14.i686
> notify-python-0.1.1-15.fc14.i686
> policycoreutils-python-2.0.83-33.2.fc14.i686
> python-2.7-8.fc14.1.i686
> python-beaker-1.5.3-5.fc14.noarch
> python-BeautifulSoup-3.0.8.1-2.fc14.noarch
> python-boto-1.9b-3.fc14.noarch
> python-bugzilla-0.6.1-3.fc14.noarch
> python-crypto-2.3-2.fc14.1.i686
> python-cryptsetup-0.0.10-3.fc14.i686
> python-decorator-3.2.0-3.fc14.noarch
> python-deltarpm-3.6-0.2.20100708git.fc14.i686
> python-devel-2.7-8.fc14.1.i686
> python-ethtool-0.5-1.fc14.i686
> python-feedparser-4.1-12.fc14.noarch
> python-GnuPGInterface-0.3.2-7.fc14.noarch
> python-httplib2-0.6.0-3.fc14.noarch
> python-iniparse-0.4-2.fc14.noarch
> python-iwlib-0.1-3.fc14.i686
> python-libs-2.7-8.fc14.1.i686
> python-mako-0.3.4-2.fc14.noarch
> python-markupsafe-0.9.2-4.fc14.i686
> python-meh-0.10-2.fc14.noarch
> python-nose-0.11.3-5.fc14.noarch
> python-nss-0.9-9.fc14.i686
> python-paste-1.7.4-7.fc14.noarch
> python-pyblock-0.52-1.fc14.i686
> python-pycurl-7.19.0-7.fc14.i686
> python-setuptools-0.6.14-3.fc14.noarch
> python-simplejson-2.1.1-4.fc14.i686
> python-slip-0.2.13-1.fc14.noarch
> python-slip-dbus-0.2.13-1.fc14.noarch
> python-telepathy-0.15.18-1.fc14.noarch
> python-tempita-0.4-5.fc14.noarch
> python-urlgrabber-3.9.1-7.fc14.noarch
> python-virtkey-0.50-8.fc14.i686
> python-xlib-0.15-0.3.rc1.fc14.noarch
> rpm-python-4.8.1-5.fc14.i686
> setools-libs-python-3.3.7-8.fc14.i686
> wxPython-2.8.11.0-4.fc14.i686
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>

Re: [Discuss-gnuradio] DDC and Polyphase Channelizer

On Wed, Dec 29, 2010 at 4:32 AM, Jimmy Richardson <jmmrchrdsn@gmail.com> wrote:
> Hi, Tom:
>
> Please see my comments below.
>
> Thanks
>
> On 12/29/2010 12:58 AM, Tom Rondeau wrote:
>>
>> On Mon, Dec 27, 2010 at 3:48 AM, Jimmy Richardson<jmmrchrdsn@gmail.com>
>>  wrote:
>>>
>>> Hi,:
>>>
>>> I'm learning about polyphase channelizer, and I have been reading fred
>>> harris' paper "Digital Receivers and Transmitters Using Polyphase Filter
>>> Banks for Wireless Communications". I have also played with the Matlab
>>> programs at the end of the paper. What I'm trying to do next is to use
>>> GNURadio to do the channelization. I made two attempts, one uses
>>> freq_xlating_fir_filter_ccf to implement a DDC channelizer, another uses
>>> pfb_channelizer_ccf, running against the data in appendix III of harris'
>>> paper. I'm hoping the channelizer result from GNURadio code would match
>>> the
>>> result from Matlab, but I failed on both, I wonder if someone could help
>>> me
>>> spot the problem.
>>>
>>> 1. DDC Channelizer:
>>
>> Using the frequency xlating filters here is not recommended. You'll
>> need to use much longer filters than when using the channelizer. That
>
> Could you clarify? Does this mean I need to change the parameter to
> gr.firdes.low_pass, maybe reduce _cutoff_freq?


I was just saying that, in general, you'll be doing much more work
this way. But since you say later that you're only using this for
comparisons, then you already know that.


>> said, I'm not sure what would cause the problem you identified below.
>> In my opinion, it's not worth doing it this way.
>
> Ok, the reason I did this is because I want a way to verify the result from
> pfb channelizer is correct, since I'm not sure if I'm using it correctly.
>
>>
>>> 1.1 Code: The following is the core part of the code (input parsing and
>>> various other stuff are omitted), the value for the variables can be
>>> found
>>> in 1.2
>>>        self._filter_taps = gr.firdes.low_pass(1, self._input_rate,
>>> self._cutoff_freq, self._trans_width,
>>>
>>> window=gr.firdes.WIN_BLACKMAN_hARRIS)
>>>        print "Number of taps:   _filter_taps = ", len(self._filter_taps)
>>>
>>>        # Blocks
>>>        self.ddc_filter = list()
>>>        # i = 0 to M-1
>>>        for i in xrange(self._M):
>>>            offset = self._channel_bandwidth * (float(self._M)/2 - i)
>>>            print "Channel ", i, "'s offset (Hz): ", offset
>>>
>>>
>>>  self.ddc_filter.append(gr.freq_xlating_fir_filter_ccf(self._resampling_ratio,
>>>
>>>  self._filter_taps, offset, self._input_rate))
>>>            self.connect(self.head, self.ddc_filter[i],
>>> self.output_files[i])
>>>
>>> 1.2 Variable values:
>>> Input sampling freq (Hz):  _input_rate =  1120000000.0
>>> Resampling ratio:          _resampling_ratio =  28
>>> Output sampling freq (Hz): _output_rate =  40000000.0
>>> Transition width (Hz):     _trans_width =  2000000.0
>>> Number of channels:        _M =  40
>>> Number of samples:         _N =  11200
>>> Oversample rate:           _oversample_rate =  1.42857142857
>>> Channel bandwidth (HZ):    _channel_bandwidth =  28000000.0
>>> Cutoff freq (HZ):          _cutoff_freq =  13000000.0
>>> Number of taps:   _filter_taps =  561
>>> Channel  0 's offset (Hz):  560000000.0
>>> Channel  1 's offset (Hz):  532000000.0
>>> ...
>>> 1.3 Result: The result from GNURadio code is saved to output files, one
>>> for
>>> each channel. Then the results time-domain are plotted in Matlab (-10 to
>>> +10, time 1 to 200), and compared to the result plot from harris' code,
>>> they
>>> are similar, but not the same. Channel 0 to 5, 17, 18, 34 to 39 do not
>>> have
>>> any strong signal, this is reflected in both plots, channel 20's signal
>>> is
>>> exactly the same, but all other channels' plot are different.
>>>
>>> 2. Polyphase Channelizer:
>>> 2.1 Code:
>>>        self._filter_taps = gr.firdes.low_pass(1, self._input_rate,
>>> self._cutoff_freq, self._trans_width,
>>>
>>>  window=gr.firdes.WIN_BLACKMAN_hARRIS)
>>>        # Calculate the number of taps per channel for our own information
>>>        self._taps_per_channel = scipy.ceil(float(len(self._filter_taps))
>>> /
>>>  float(self._M))
>>>        print "Number of taps:   _filter_taps = ", len(self._filter_taps)
>>>        print "Taps per channel: _taps_per_channel = ",
>>> self._taps_per_channel
>>>
>>>        # Construct the channelizer filter
>>>        self.pfb = blks2.pfb_channelizer_ccf(self._M, self._filter_taps,
>>> self._oversample_rate)
>>>
>>>        # Connect the blocks
>>>        self.connect(self.head, self.pfb)
>>>        # i = 0 to M-1
>>>        for i in xrange(self._M):
>>>            self.connect((self.pfb, i), self.output_files[i])
>>>
>>> 2.2 Variable values:
>>> Input sampling freq (Hz):  _input_rate =  1120000000.0
>>> Resampling ratio:          _resampling_ratio =  28
>>> Output sampling freq (Hz): _output_rate =  40000000.0
>>> Transition width (Hz):     _trans_width =  2000000.0
>>> Number of channels:        _M =  40
>>> Number of samples:         _N =  11200
>>> Oversample rate:           _oversample_rate =  1.42857142857
>>> Channel bandwidth (HZ):    _channel_bandwidth =  28000000.0
>>> Cutoff freq (HZ):          _cutoff_freq =  13000000.0
>>> Number of taps:   _filter_taps =  561
>>> Taps per channel: _taps_per_channel =  15.0
>>>
>>> 2.3 Result: The GNURadio program failed with:
>>> "terminate called after throwing an instance of 'std::invalid_argument'
>>>  what():  gr_pfb_channelizer: oversample rate must be N/i for i in [1, N]
>>>
>>> This application has requested the Runtime to terminate it in an unusual
>>> way.
>>> Please contact the application's support team for more information."
>>>
>>> This doesn't seem to make sense, since in this case N = 40, oversample
>>> rate
>>> =1.42857142857, i = 28
>>>
>>> Thanks
>>
>> The "oversample_rate" is not exactly what you are specifying here. The
>> default behavior of this PFB channelizer implementation is to be
>> critically sampled; that is, the sample rate equals the bandwidth. For
>> many applications, you want to have the output sample rate be some
>> other rate, most notably, 2x the bandwidth. The oversample_rate allows
>> you to specify a number real number, but this cannot be an arbitrary
>> number in this case. Because of the way the samples are fed to the
>> filters, the oversample rate, O, has to be set such that the number of
>> filters, N, can be evenly divided by an integer to to get O; that is,
>> N/i = O for i in [1,N]. Take the example in in fred's paper where he
>> has 64 channels and a 1/48 resampling rate. So he's using a 48-to-1
>> downsampling in 64 channels, so his rate is 4/3, which means that the
>> output sampling rate is (4/3)*bw, where bw is the channel bandwidth.
>
> Sorry, false alarm here, it looks like a problem with MinGW's compiler, it
> didn't compile double comparison with 0.0 correctly or something. I tried
> the program under Ubuntu and the error disappeared. I think the number I
> used is the correct number since in my case N=40, i = 28, and O = N/i =
> 1.42857142857

Ok. I didn't calculate the number myself, just assumed it was wrong if
you were being given that error message :)

On a side note, I don't like that problem happening on MinGW.
Honestly, doing an == on floating point numbers isn't a good idea, so
I may need to rethink that check.

>> If you specified that the rate was 2.0, you would feed 32 of the 64
>> channels and have a sample rate that is twice the bandwidth. I notice
>> in the remarks in fred's paper that he's outputting the channels at 2
>> samples/symbol, so the oversample_rate here should be 2.
>
> I'm using fred's example in appendix III, not the 64 channels example. The
> comment summaries the example as below:

Yeah, I know. I was using fred's 64-channel example from the paper
because the numbers are easier to handle/explain.

> % receiver_40z is a demo of a 40 channel receiver, demodulating 30 channels,
> % of nominal symbol rate 20 MHz, separated by 28 MHz centers (1.4 times
> symbol rate)
> % input sample rate is 40*28 = 1120 MHz.
> % receiver performs a 40 point transform on the output of a 40-stage
> polyphase filter
> % the polyphase filter operates at input rate but outputs at 2
> samples/symbol or
> % 40 MHz. The resampling rate is 1120/40 = 28-to-1, thus output from
> 40-channels are
> % computed once for every 28 input samples. channelizer is not matched
> filter,
> % prototype filter is 10% wider than two sided bandwidth of input signal to
> accommodate
> % frequency uncertainty of separate channel centers.
>
>> I hope that makes sense and you can figure out from there what you
>> need to do to get it to work. I've worked with fred for a while now,
>> but I find his Matlab to be almost unreadable (I've told him this
>> before), so I can't quite tell you from a quick look over the code he
>> has in this paper what's really going on.
>
> I got passed the error, thanks, but still have problems with channelizer,
> see below...
>
>> Also, keep in mind that fred always develops he own filters straight
>> from the remez algorithm. If you are using gr.firdes.low_pass, you're
>> not going to get the same output filters. Closer would be to use the
>> blcks2.optfir.low_pass, which uses the PM algorithm (which in turn
>> uses Remez), but I couldn't give you the specs you need to build the
>> same _exact_ filter as in fred's paper. But you'll get close enough
>> that the basic shapes of the signals will be the same, if not every
>> point.
>
> Thanks for the suggestion, I modified filter statement to:
>
>        self._filter_taps = blks2.optfir.low_pass(1, self._input_rate,
>                                                  self._cutoff_freq -
> self._trans_width/2, self._cutoff_freq + self._trans_width/2,
>                                                  0.9, 60, 400)
>
> Note I have to use 400 as extra taps otherwise remez won't work (too many
> extremals -- cannot continue)

Hm, that looks wrong. You shouldn't need to use the extra taps input
just to get the algorithm to converge. It's really meant to be able to
give you minor control over the number of taps you use, specifically
if you need a filter with an even or odd number of taps. Using 400 is
way too many.

The real problem I think comes from your in-band ripple or 0.9. That's
a value in dB and specifies the magnitude of the peak-to-peak
fluctuations in the passband. I was able to use your settings above
but specified a ripple of 0.1, which produces a filter of 764 taps.


> I got the result, but still not the same as the one from Matlab:
> 1. The channels seem to be shifted by 20 then wrapped around, i.e. assuming
> channel # starts with 1, the pfb result's channel 1 seems to be matlab's
> channel 21, and channel 20 in pfb result seems to be matlab's channel 40,
> channel 21 in pfb result seems to be matlab's channel 1.
> 2. Assuming the channel shift/wrap is done, the time-domain plot still are
> not the same, pfb channel 1 (matlab's channel 21)'s plot seems to be the
> same, and no signal channels do fit, but other channels' plot are not the
> same (i.e. the situation is similar to my result of DDC).

This strikes me as a simple naming issue; which channel you decide is
0 versus N. The way that I have the output of the channelizer working,
channel 0 is the DC channel, channel 1 is the next one to the "right"
(the next one in moving in the positive frequency direction). Channel
floor(N/2) will either span the last part of the positive spectrum and
the first part of the negative spectrum (if N is even) or be the last
channel in the positive spectrum (if N is odd). Channel N-1 is
directly "left" of channel 0.

It's hard to know what you mean by the signals being "the same." Are
they completely different?

> Is this because the filter taps in GNURadio is different from Matlab? Is
> there a way I can create a filter in GNURadio from a list of numbers
> exported from Matlab?

It could be a filter issue. If you want to, generate you prototype
filter in Matlab, then you can just copy-and-paste those into your GNU
Radio program as a list and pass that to the pfb_channelizer.

Tom

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

Re: [Discuss-gnuradio] output 0 is not connected internally

On Wed, Dec 29, 2010 at 10:57 PM, Brad Hein <linuxbrad@gmail.com> wrote:
>
> I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386
> computers. I've tried two now, and I'm plagued with the same problems - they
> just won't execute.
>
> I suspect there's a problem which went undetected, maybe a python file
> version mismatch or some other inconsistency. I'm trying hard to isolate the
> source of the problem.
>
> I also wrote a very basic grc which consisted of a sound source and attached
> it to different sinks (audio sync / waterfall sink / scope sink) - each
> producing the same error shown below, when executed.
>
> I'm trying different things, but any input would be greatly appreciated =)

Looking at your version information below, you're running a very old
version of the GNU Radio Companion (grc 0.70). You'll need to update
it, which I think will solve your problem. I actually don't know if we
have a newer package of GRC out there, so you might have to
compile/install it yourself (Josh, let me know if I'm wrong about
this).

Tom

> The error shown when executed
> ===================================
>
> Executing: "/usr/share/grc/examples/audio/phone_tones.grc.xml"
>>>> Verbose:
> Traceback (most recent call last):
>   File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 231, in OnInit
>     self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first
> argument is the flow graph
>   File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 165, in __init__
>     self._start() #start the flow graph
>   File "/usr/share/grc/src/ExecFlowGraph.py", line 54, in _start
>     self.start()
>   File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 97,
> in start
>     self._tb.start()
>   File
> "/usr/lib/python2.7/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py",
> line 1455, in start
>     return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self)
> RuntimeError: In hierarchical block scope throttle, output 0 is not
> connected internally
>
>>>> Done
>
>
> RPM Package list on Fedora14 notebook PC (basically identical to the other
> F14 PC)
> ===============================================================
>
> [root@Fedora14Laptop ~]# rpm -qa |egrep -i "gnuradio|grc|python"|sort
> abrt-addon-python-1.1.14-1.fc14.i686
> at-spi-python-1.32.0-2.fc14.i686
> audit-libs-python-2.0.4-4.fc14.i686
> cracklib-python-2.8.16-4.fc14.i686
> dbus-python-0.83.0-7.fc14.i686
> farsight2-python-0.0.21-2.fc14.i686
> gnome-python2-2.28.1-3.fc14.i686
> gnome-python2-applet-2.32.0-1.fc14.i686
> gnome-python2-bonobo-2.28.1-3.fc14.i686
> gnome-python2-canvas-2.28.1-3.fc14.i686
> gnome-python2-desktop-2.32.0-1.fc14.i686
> gnome-python2-extras-2.25.3-25.fc14.1.i686
> gnome-python2-gconf-2.28.1-3.fc14.i686
> gnome-python2-gnome-2.28.1-3.fc14.i686
> gnome-python2-gnomekeyring-2.32.0-1.fc14.i686
> gnome-python2-gnomevfs-2.28.1-3.fc14.i686
> gnome-python2-gtkhtml2-2.25.3-25.fc14.1.i686
> gnome-python2-libegg-2.25.3-25.fc14.1.i686
> gnome-python2-libwnck-2.32.0-1.fc14.i686
> gnuradio-3.2.2-7.fc14.i686
> grc-0.70-6.fc12.noarch
> gstreamer-python-0.10.19-1.fc14.i686
> libproxy-python-0.4.4-7.fc14.noarch
> libselinux-python-2.0.96-6.fc14.1.i686
> libsemanage-python-2.0.45-5.fc14.i686
> libuser-python-0.56.18-2.fc14.i686
> libxml2-python-2.7.7-2.fc14.i686
> newt-python-0.52.12-1.fc14.i686
> notify-python-0.1.1-15.fc14.i686
> policycoreutils-python-2.0.83-33.2.fc14.i686
> python-2.7-8.fc14.1.i686
> python-beaker-1.5.3-5.fc14.noarch
> python-BeautifulSoup-3.0.8.1-2.fc14.noarch
> python-boto-1.9b-3.fc14.noarch
> python-bugzilla-0.6.1-3.fc14.noarch
> python-crypto-2.3-2.fc14.1.i686
> python-cryptsetup-0.0.10-3.fc14.i686
> python-decorator-3.2.0-3.fc14.noarch
> python-deltarpm-3.6-0.2.20100708git.fc14.i686
> python-devel-2.7-8.fc14.1.i686
> python-ethtool-0.5-1.fc14.i686
> python-feedparser-4.1-12.fc14.noarch
> python-GnuPGInterface-0.3.2-7.fc14.noarch
> python-httplib2-0.6.0-3.fc14.noarch
> python-iniparse-0.4-2.fc14.noarch
> python-iwlib-0.1-3.fc14.i686
> python-libs-2.7-8.fc14.1.i686
> python-mako-0.3.4-2.fc14.noarch
> python-markupsafe-0.9.2-4.fc14.i686
> python-meh-0.10-2.fc14.noarch
> python-nose-0.11.3-5.fc14.noarch
> python-nss-0.9-9.fc14.i686
> python-paste-1.7.4-7.fc14.noarch
> python-pyblock-0.52-1.fc14.i686
> python-pycurl-7.19.0-7.fc14.i686
> python-setuptools-0.6.14-3.fc14.noarch
> python-simplejson-2.1.1-4.fc14.i686
> python-slip-0.2.13-1.fc14.noarch
> python-slip-dbus-0.2.13-1.fc14.noarch
> python-telepathy-0.15.18-1.fc14.noarch
> python-tempita-0.4-5.fc14.noarch
> python-urlgrabber-3.9.1-7.fc14.noarch
> python-virtkey-0.50-8.fc14.i686
> python-xlib-0.15-0.3.rc1.fc14.noarch
> rpm-python-4.8.1-5.fc14.i686
> setools-libs-python-3.3.7-8.fc14.i686
> wxPython-2.8.11.0-4.fc14.i686
>
>
>
> _______________________________________________
> 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

Wednesday, December 29, 2010

[Discuss-gnuradio] why there is a requirement of adc_model.v in usrp2 ?

Hi,

I am working on my college project (usrp2). I am trying to analyze some of
the FPGA codes and I came across a code for adc i.e. adc_model.v . (
/usrp2/models). My question is if I am using an external ADC (LTC 2284) then
why is it required to design a model for adc?

pls note:- I am a new bee in usrp2. Sorry for posting such a silly question
:confused:
--
View this message in context: http://old.nabble.com/why-there-is-a-requirement-of-adc_model.v-in-usrp2---tp30555603p30555603.html
Sent from the GnuRadio mailing list archive at Nabble.com.


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

[Discuss-gnuradio] output 0 is not connected internally


I'm endeavouring to get gnuradio+grc working in Fedora 14 on my i386 computers. I've tried two now, and I'm plagued with the same problems - they just won't execute.

I suspect there's a problem which went undetected, maybe a python file version mismatch or some other inconsistency. I'm trying hard to isolate the source of the problem.

I also wrote a very basic grc which consisted of a sound source and attached it to different sinks (audio sync / waterfall sink / scope sink) - each producing the same error shown below, when executed.

I'm trying different things, but any input would be greatly appreciated =)


The error shown when executed
===================================

Executing: "/usr/share/grc/examples/audio/phone_tones.grc.xml"
>>> Verbose:   
Traceback (most recent call last):
  File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 231, in OnInit
    self.SetTopWindow(FlowGraphFrame(self.flow_graph_file_path))#first argument is the flow graph
  File "/usr/share/grc/src/ExecFlowGraphGUI.py", line 165, in __init__
    self._start() #start the flow graph
  File "/usr/share/grc/src/ExecFlowGraph.py", line 54, in _start
    self.start()
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/top_block.py", line 97, in start
    self._tb.start()
  File "/usr/lib/python2.7/site-packages/gnuradio/gr/gnuradio_swig_py_runtime.py", line 1455, in start
    return _gnuradio_swig_py_runtime.gr_top_block_sptr_start(self)
RuntimeError: In hierarchical block scope throttle, output 0 is not connected internally

>>> Done


RPM Package list on Fedora14 notebook PC (basically identical to the other F14 PC)
===============================================================

[root@Fedora14Laptop ~]# rpm -qa |egrep -i "gnuradio|grc|python"|sort
abrt-addon-python-1.1.14-1.fc14.i686
at-spi-python-1.32.0-2.fc14.i686
audit-libs-python-2.0.4-4.fc14.i686
cracklib-python-2.8.16-4.fc14.i686
dbus-python-0.83.0-7.fc14.i686
farsight2-python-0.0.21-2.fc14.i686
gnome-python2-2.28.1-3.fc14.i686
gnome-python2-applet-2.32.0-1.fc14.i686
gnome-python2-bonobo-2.28.1-3.fc14.i686
gnome-python2-canvas-2.28.1-3.fc14.i686
gnome-python2-desktop-2.32.0-1.fc14.i686
gnome-python2-extras-2.25.3-25.fc14.1.i686
gnome-python2-gconf-2.28.1-3.fc14.i686
gnome-python2-gnome-2.28.1-3.fc14.i686
gnome-python2-gnomekeyring-2.32.0-1.fc14.i686
gnome-python2-gnomevfs-2.28.1-3.fc14.i686
gnome-python2-gtkhtml2-2.25.3-25.fc14.1.i686
gnome-python2-libegg-2.25.3-25.fc14.1.i686
gnome-python2-libwnck-2.32.0-1.fc14.i686
gnuradio-3.2.2-7.fc14.i686
grc-0.70-6.fc12.noarch
gstreamer-python-0.10.19-1.fc14.i686
libproxy-python-0.4.4-7.fc14.noarch
libselinux-python-2.0.96-6.fc14.1.i686
libsemanage-python-2.0.45-5.fc14.i686
libuser-python-0.56.18-2.fc14.i686
libxml2-python-2.7.7-2.fc14.i686
newt-python-0.52.12-1.fc14.i686
notify-python-0.1.1-15.fc14.i686
policycoreutils-python-2.0.83-33.2.fc14.i686
python-2.7-8.fc14.1.i686
python-beaker-1.5.3-5.fc14.noarch
python-BeautifulSoup-3.0.8.1-2.fc14.noarch
python-boto-1.9b-3.fc14.noarch
python-bugzilla-0.6.1-3.fc14.noarch
python-crypto-2.3-2.fc14.1.i686
python-cryptsetup-0.0.10-3.fc14.i686
python-decorator-3.2.0-3.fc14.noarch
python-deltarpm-3.6-0.2.20100708git.fc14.i686
python-devel-2.7-8.fc14.1.i686
python-ethtool-0.5-1.fc14.i686
python-feedparser-4.1-12.fc14.noarch
python-GnuPGInterface-0.3.2-7.fc14.noarch
python-httplib2-0.6.0-3.fc14.noarch
python-iniparse-0.4-2.fc14.noarch
python-iwlib-0.1-3.fc14.i686
python-libs-2.7-8.fc14.1.i686
python-mako-0.3.4-2.fc14.noarch
python-markupsafe-0.9.2-4.fc14.i686
python-meh-0.10-2.fc14.noarch
python-nose-0.11.3-5.fc14.noarch
python-nss-0.9-9.fc14.i686
python-paste-1.7.4-7.fc14.noarch
python-pyblock-0.52-1.fc14.i686
python-pycurl-7.19.0-7.fc14.i686
python-setuptools-0.6.14-3.fc14.noarch
python-simplejson-2.1.1-4.fc14.i686
python-slip-0.2.13-1.fc14.noarch
python-slip-dbus-0.2.13-1.fc14.noarch
python-telepathy-0.15.18-1.fc14.noarch
python-tempita-0.4-5.fc14.noarch
python-urlgrabber-3.9.1-7.fc14.noarch
python-virtkey-0.50-8.fc14.i686
python-xlib-0.15-0.3.rc1.fc14.noarch
rpm-python-4.8.1-5.fc14.i686
setools-libs-python-3.3.7-8.fc14.i686
wxPython-2.8.11.0-4.fc14.i686


Re: [Discuss-gnuradio] USRP daughter-boards for 2.3-2.4, 2.5-2.7, 3.4-3.6 GHz

On Wed, Dec 29, 2010 at 10:53 AM, Alexander Chemeris
<alexander.chemeris@gmail.com> wrote:
> John,
>
> Does BURX work with UHD and USRP E100?

Alexander,
The BURX board doesn't currently have driver support for the UHD (and
thus, from what I understand, can't be used with the E100 either).
From a technical standpoint, we've been monitoring progress/changes
with the UHD, and it seems reasonably stable at this point. We can
revisit adding support in for the BURX board if there was interest in
this, and prioritize it accordingly.

--
John Orlando
CEO/System Architect
Epiq Solutions
www.epiq-solutions.com

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

[Discuss-gnuradio] Greeting and a question

Hi everyone,
I am a newcomer on this list and would like to first introduce myself.

I am a HW design engineer with over 20 years of experience in designing various electronic and systems including a working base station based on SW radio in 1999 with a team of engineers at Ericsson Radio Access in Sweden, a system that managed to support multiple mobiles systems including NMT, GSM, AMPS, DAMPS and DECT using a number of FPGAs and DSPs. My specialty is FPGA design and I would like to move some of the GNU radio blocks into an FPGA to make it possible to run the SW part on a low end processor such as ARM9 or similar.

After many years, I came back to into the field of working on a RBS design and found the wonderful project called Gnu Radio :)


Now, my questions, I wonder if anyone here has ever looked into using some old FPGA boards such Avnemt Memec Virtex-II pro board with P160 analog interface board together with Gnu Radio? The reason I am asking this is that I have a few of these boards from previous project and I believe they could be great HW for a quick start of the GR design with minimum amount of investment.

Thanks in advance and best regards,
Farhad Abdolian
Antibes, France