Re: [Discuss-gnuradio] u2_flash_tool : Can not find the command

2010-03-05 Thread Andy_Long

Hi, Johnathan, John, Matt and Josh

Thank you all for the help! The problem was solved!:)

When I am using the SD card via a USB adapter, it shows the name dev/sd1.
By using this name, it gives me the same results as before. 

However, the USRP works well by using the name mmcblk0 . :)

Another thing is that actually the terminal shows the name mmcblk1 when I
inserted SD cards as soon as I took them from the package without any extra
operation for partition. 

regards,
Andy 

-- 
View this message in context: 
http://old.nabble.com/u2_flash_tool-%3A---Can-not-find-the-command-tp27760919p27791386.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] benchmark_rx.py with std_4rx_0tx.rbf

2010-03-05 Thread Christian Rohlfing
The script benchmark_rx.py (located in gnuradio-examples/python/digital)
doesn't run with the FPGA-file std_4rx_0tx.rbf. Is there any explanation
for this problem?

On the TX-side, I'm running benchmark_tx.py with the standard rbf-file
std_2rxhb_2tx.rbf. (Testing benchmark_rx.py with the standard rbf-file
on the RX-side works properly.)

My setup (both RX and TX):
GNU Radio (commit hash 3.3git-647-geb6ff48d, fetched 03.04.2010) running
on Ubuntu 8.10
USRP1 (RFX2400 daughterboard, omnidirectional antenna)





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


Re: [Discuss-gnuradio] Transmit legit, become a ham

2010-03-05 Thread John Gilmore
 Nothing forces you to interact with other ham radio operators. You can
 happily work in isolation communicating among your own stations if you
 wish.

Unless you need to do frequency coordination, which you usually do.
Then you have to deal with the oldest, gnarliest hams around, the ones
who 50 years ago got access to mountaintop towers and have been squatting
on them ever since, like trolls under bridges.

 However, ham-land contains a ready pool of technically inclined
 people, most of whom are interested in but not well informed about
 subjects like software defined radio and Free Software.

I got a ham Tech license in the 1970-80's and it was one of the more
disappointing experiences in my life.  What a culture clash!  The ham
fraternity was filled with people who spent all their time
chit-chatting on their handheld radios about their personal lives, but
who knew and cared very little about radio technology or computers.
(Nowadays everyone has cellphones, but in those days they were the
only ones who could communicate mobile.)  They fought uselessly over
stupid little status things like how short or long your callsign was.
I soldered together a 1200 bps packet radio interface board, ran
BBS's, evolved protocol software, and taught classes on digital radio
communication protocols to the interested part of the local Bay Area
ham community (led by Hank Magnuski, KA6M).  The almost universal
attitude among the hams who I met was We got here first, we own these
frequencies, don't you put any funny computer stuff on 'em because
that will just attract more of the public to horn in on our monopoly.
They actively threatened to turn me in to the FCC for any real or
imagined violation of the incredibly picky rules, like letting someone
else log in over my radio modem (carrying third party traffic).
Really friendly folks.

I decided to retire my ham license until a large number of the
existing hams died off (many were middle aged or older).  Perhaps now
the worst jerks have cleared the ranks, and some more welcoming people
are hams; I don't know.  I moved my digital radio experiments to the
unlicensed bands, ignored the hams, and have been much happier ever
since.  I think the hams are still doing 1200 bps FSK, while the
unlicensed folks have evolved to 108,000,000 bps WiFi.  There must be
tens of thousands of hams nationwide.  There are tens of thousands of
WiFi nodes in San Francisco alone -- and no crazy restrictions about
not using encryption, not letting other people use your radio, etc.

John




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


Re: [Discuss-gnuradio] benchmark_rx.py with std_4rx_0tx.rbf

2010-03-05 Thread Eric Blossom
On Fri, Mar 05, 2010 at 11:27:00AM +0100, Christian Rohlfing wrote:
 The script benchmark_rx.py (located in gnuradio-examples/python/digital)
 doesn't run with the FPGA-file std_4rx_0tx.rbf. Is there any explanation
 for this problem?
 
 On the TX-side, I'm running benchmark_tx.py with the standard rbf-file
 std_2rxhb_2tx.rbf. (Testing benchmark_rx.py with the standard rbf-file
 on the RX-side works properly.)
 
 My setup (both RX and TX):
 GNU Radio (commit hash 3.3git-647-geb6ff48d, fetched 03.04.2010) running
 on Ubuntu 8.10
 USRP1 (RFX2400 daughterboard, omnidirectional antenna)

Just to rule out a problem, are you trying to run both Tx and Rx
concurrently using a single USRP1 connected to a single computer?  
If so, you need to specify the same .rbf file for both the Tx and Rx
sides, otherwise the last one opened stomps on the first one opened
when it reloads the FPGA with the other .rbf image.

Eric


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


Re: [Discuss-gnuradio] Quadrature direct-conversion receiver design

2010-03-05 Thread Matt Ettus

On 03/04/2010 06:24 PM, Marcus D. Leech wrote:

OK, so this probably seems like a fundamental sort of question, but I've
noticed that there seem to be
   a couple of different places on the net describing quadrature receiver
toplogies, and I want to know something
   fairly simple.

For a direct-conversion quadrature receiver, must you phase split *BOTH*
the RF and LO inputs to the
   mixers?  That is, do you need a 90 degree hybrid on both the RF and LO
ports?





The way I think of it is that you need quadrature on 2 of the 3 ports -- 
 The way we use this on USRPs is that the RF is split but not phase 
shifted, the LO is phase shifted, and you get the 2nd phase shift by 
using I and Q samples.


In what amateurs call phasing receivers, instead of using I and Q 
sampling, you phase shift one channel using analog components and then 
add that to the other channel.


In both cases you could do the phase shift on the RF instead of the LO, 
but that is usually harder to do cleanly.


Matt


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


Re: [Discuss-gnuradio] Quadrature direct-conversion receiver design

2010-03-05 Thread Ken N9VV

F.Y.I.
http://www.norcalqrp.org/files/Tayloe_mixer_x3a.pdf
original Tayloe pdf about QSD
Ken N9VV

On 3/5/2010 6:08 AM, Matt Ettus wrote:

For a direct-conversion quadrature receiver, must you phase split *BOTH*
the RF and LO inputs to the
mixers? That is, do you need a 90 degree hybrid on both the RF and LO
ports?



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


Re: [Discuss-gnuradio] Building GNU Radio on the Beagle board

2010-03-05 Thread halidziya yerebakan
Hi;

My project changed but at the end
*I get the image* , problem is my University's firewall they are allowing
only a few ports because of that I download from another location.

Thanks

On Tue, Feb 16, 2010 at 7:36 PM, Philip Balister phi...@balister.orgwrote:

 On 02/16/2010 07:15 AM, George Nychis wrote:

 I believe you're failing the human checker ;)

 Philip is trying to tell you to e-mail him for the files.


 He did email. Maybe I have him a bad link. Since I am traveling atm, here
 is the link:

 http://balister.dyndns.org:8008/~balister/gnuradio-image.tar.gzhttp://balister.dyndns.org:8008/%7Ebalister/gnuradio-image.tar.gz

 If your firewall is restrictive, the port may be the problem. Let me know,
 and I can move it to my website for a bit.

 Philip




 - George


 On Tue, Feb 16, 2010 at 1:27 AM, halidziya yerebakanhalidz...@gmail.com
 wrote:

  Hi;


 Sorry again but link is not working. I am unable to download it. Is it
 problem because of your ADSL ?

 You have a web site but may be openning project in Sourceforge.net can be
 usesful.

 Thanks


 On Mon, Feb 8, 2010 at 11:34 PM, Philip Balisterphi...@balister.org
 wrote:

  On 02/08/2010 04:29 PM, yerebakan wrote:

  Hi;

  Sorry , but I am unable to reach get the files from  GNU radio
 sdk
 from philip at ...  (in given adress) is it http adress or do we have
 to
 request by mail ?


 Ask by email :) This is a very preliminary image atm, as you can tell
 from
 my notes. The process is working for me though and I would appreciate
 some
 testing.

 I'll send you the link in a minute, it is on my DSL line, so the
 download
 speed is not great.

 Philip



  Thanks

 On Wed, Feb 3, 2010 at 8:25 PM, Philip Balisterphi...@balister.org
  wrote:

   From time to time people ask about building GNU Radio for the

 Beagleboard.
 In an attempt to make it easier for more people to work on this, I
 posted
 some notes at:

 http://www.opensdr.com/node/17

 describing how to build GNU Radio on the Beagleboard (obviously
 building
 it
 cross is much faster, but you need to be aware of some tricky bits). I
 know
 this is all a bit vague, but hopefully someone finds it useful :)

 If you have Beagle specific questions, please ask those on the
 appropriate
 list/irc channel. I'll be glad to respond to GNU Radio specific issues
 here.

 Philip


 ___
 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




 Halid Ziya Yerebakan

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






-- 
Saygılar;
Halid Ziya Yerebakan
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations

2010-03-05 Thread Mattias Kjellsson
Mattias Kjellsson wrote:
 Tom Rondeau wrote:
   
 On Thu, Mar 4, 2010 at 2:13 PM, Mattias Kjellsson m...@kth.se wrote:
   
 
 Tom Rondeau wrote:
 
   
 On Thu, Mar 4, 2010 at 11:38 AM, Mattias Kjellsson m...@kth.se wrote:

   
 
 Tom Rondeau wrote:

 
   
 On Thu, Mar 4, 2010 at 10:28 AM, Mattias Kjellsson m...@kth.se wrote:


   
 
 Eric Blossom wrote:


 
   
 I assume that you mean 1 byte per symbol.
 I suggest that you create *_ci and *_ii versions that handle 32-bits.

 Eric


   
 
 You are correct, one byte per symbol. Or one symbol per byte, whichever
 way one wants to look at it.
 To clarify what the custom block does is that it takes K bytes with 1
 significant bit (in lsb, from a glfsr or similar) and turns it into 1
 byte with K significant bits. Then it's just to feed these new, packed
 (is this the word for it?), bytes into the chunks_to_symbols_bc- block,
 producing one symbol for every byte.

 Is this really stupid, or has it just not been done yet? I assume that
 there are more people working with more signal- points than two in their
 constellations. But at the same time it seems like I'm wasting a lot of
 resources on copying bytes with only two or three (qpsk, qam16)
 significant bits in them...


 //Mattias


 
   
 Have you looked at
 gnuradio-core/src/python/gnuradio/blks2impl/dqpsk.py (and qam8, qam16,
 qam64, and qam256.py)? They handle the modulation and demodulation
 parts of the TX and RX. We don't have a good synchronization scheme,
 but I think these do what you want.

 Tom


   
 
 I know of them, and have looked at them, but nothing more. Since I don't
 speak python very well, I try to do everything in c++.

 I have tried to use pilots mixed in every few data- symbols and
 compensate the data- symbols using these known symbols. I'm getting kind
 of good results, although I think the custom early/late gate sampler I
 wrote has a settling time way to long  (between 900 and 3000 symbols
 depending on which constants I put in). I'll try to rewrite the MM-
 sync- block to utilize the slicer_45deg(), and see what results I get
 with that. From what I can tell from the paper pointed to by the header-
 file, the optimized MM- loop should be able to handle at least QPSK,
 and have a way shorter settling time than 900 symbols.

 I think the pilot- compensation code should still work and compensate
 any screw to the constellation.

 I'm getting all exited just writing about it ;) I'll let you know how it
 goes.
 //Mattias

 
   
 Matt and I wrote a resampler based on polyphase filterbanks a few
 months ago. It's called gr_pfb_clock_sync_xxf (in the filter
 directory). It works really well for any PAM signal (we've tested it
 with PSK and QAMs successfully). You can see how its used in the new
 dbpsk2.py and dqpsk2.py files.

 Tom

   
 
 I will have a look, I haven't had the instant success I was hoping for
 with the MM- loop as I hoped... It might have something to do with the
 parameters, but I doubt it, since I see the constellation alright, but
 it still demodulates the symbols into bits incorrectly, ie. the loops
 have locked on a rotated constellation, and/or the compensation with the
 pilot- symbols doesn't do the trick/ is done incorrectly. Maybe if I
 stop and think about it some more. But that'll be tomorrow, since it is
 way past office hours here.

 Mattias
 
   
 Yes, at this point, the constellation is locked, but it's just locked
 with any 90 degree phase ambiguity (or 180 if bpsk). None of the sync
 loops understand this, so you'll probably have to map the symbols for
 the given rotation to the correct (transmitted) rotation.

 Tom
   
 
 I have now read the code, and tried it out a bit.

 A thing, just code- wise, I saw and wanted to ask about:
 Lines 49 and 57 in gr_pbf_clock_sync_ccf.cc,
 iosig is a std::vector from line 49, is there a reason that on line 57,
 there is a 4 instead of iosig.size() ?
 Or are these numbers just coincidently the same?

 Also I got this error:
 pilot_reveiver: ./gr_buffer.h:123: unsigned int
 gr_buffer::index_add(unsigned int, unsigned int): Assertion `s 
 d_bufsize' failed.
 Aborted

 Which is new to me... I have isolated it to the the gr_pbf_sync_ccf-
 block. Since I don't see the error if I don't connect this block.

 This is how I create the block:
 d_symbol_extractor = gr_make_pfb_clock_sync_ccf (d_sps, 0.1, tr_taps,
 nfilts, nfilts/2, 0.1); where,
 d_sps = 8
 tr_taps = gr_firdes::root_raised_cosine(nfilts, nfilts, 1.0/d_sps, 0.5,
 ntaps);
 nfilts = 32;
 ntaps = 11*(d_sps+nfilts);

 By looking at the error outputs, outputs[1-3] I get 9 points of data
 (samples_per_symbol + 1) out of  gr_pfb_stync_block::work() by the looks
 of them it seems like it is some sort of transitioning going on on the
 first and third output, and a swinging output 

Re: [Discuss-gnuradio] Transmit legit, become a ham

2010-03-05 Thread Kelly Martin

John Gilmore wrote:

Unless you need to do frequency coordination, which you usually do.
Then you have to deal with the oldest, gnarliest hams around, the ones
who 50 years ago got access to mountaintop towers and have been squatting
on them ever since, like trolls under bridges.
  
Frequency coordination is voluntary in the amateur radio service.  
Unless you plan to operate in a band that is already packed with 
repeaters, you can, in most places, ignore frequency coordination; 
typically the local coordination body (if it functions at all, which is 
by no means a guarantee) has designated some range of frequencies as 
open use and you can just use those frequencies.  And very few areas 
have meaningful coordination for the bands above 900 MHz; even if there 
is coordination in place for 33cm and up, odds are nobody will notice if 
you ignore it.


Amateur radio frequency coordinators tend to be tinplated dictators with 
delusion of godhood.  They also do not have the blessing of the FCC that 
they like to pretend they do, and furthermore their legal authority is 
entirely limited to repeaters (which they'd know if they had actually 
read the regulations that apply to them, which is unlikely).


Things have changed since the 70s; a lot of the twerps you dealt with 
have died off by now.


Kelly


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


[Discuss-gnuradio] GNU Radio and OS Dev Forums

2010-03-05 Thread Jamil Ben Alluch
Hello,

My name is Jamil Ben Alluch and I've recently finished setting up a website
dedicated to providing Open Source projects with user based support, in
other words message boards.

I've already set a Forum on our page dedicated to GNU Radio that users may
use or link to at their discretion. I am offering a free of charge service
to the Open Source community, so it will be bear no cost to the project or
the users.
My goal is to offer free access to information for both users and project
managers alike, as a my contribution to the projects that I've chosen to
link to.
I want to give the ability to  users to communicate with people
knowledgeable in multiple Open Source development projects in order to allow
them to combine various development toolkits at once, something for which
help is often hard to find in a single place.
I am however still in the process of building my user base and ironing out
some details on both the website and forums.

The GNU Radio forum address on OS Dev Forums is:
http://gnuradio.osdevforums.com. This address will link directly to the
forum dedicated to GNU Radio.

Our forums page is http://forums.osdevforums.com and our main site is
http://www.osdevforums.com; All these links are easily accessible from the
main page.

Let me know If you have any questions, comments or suggestions.

Thank you for your time and attention.

Sincerely,

--
Jamil Ben Alluch Ben Amar
OS Dev Forums Founder
http://www.osdevforums.com
ja...@osdevforums.com
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio


Re: [Discuss-gnuradio] Transmit legit, become a ham

2010-03-05 Thread Gregory Maxwell
On Fri, Mar 5, 2010 at 6:22 AM, John Gilmore g...@toad.com wrote:
 Nothing forces you to interact with other ham radio operators. You can
 happily work in isolation communicating among your own stations if you
 wish.

 Unless you need to do frequency coordination, which you usually do.
 Then you have to deal with the oldest, gnarliest hams around, the ones
 who 50 years ago got access to mountaintop towers and have been squatting
 on them ever since, like trolls under bridges.

Mostly echoing what Kelly said...  Operating in the DC suburbs I've
never had need to coordinate, there is always plenty of inactive space
on the 23cm band.  Though perhaps in California (where there is a lot
of 23cm activity, as I understand it) experiences may differ.  Some of
the amateur allocations overlap ISM allocations, so even the worst
spectrum dictator would have little hope of micromanaging that.

I suppose its a little different if you're looking to run something
like a persistent packet BBS.

 I got a ham Tech license in the 1970-80's and it was one of the more
 disappointing experiences in my life.  What a culture clash!  The ham
 fraternity was filled with people who spent all their time
 chit-chatting on their handheld radios about their personal lives, but
 who knew and cared very little about radio technology or computers.
 (Nowadays everyone has cellphones, but in those days they were the
 only ones who could communicate mobile.)

In my direct experience this has changed (Although I've only been
licensed a couple of years, I've owned a radio for a decade and seen
the decline and shift away).  Between the internet, pervasive cell
phones, SMS, and such people that simply want to chat have moved on to
mediums which better support technophobes.  Certainly they still
exist, but today in most areas the bigger problem is under utilization
of the allocations (especially the UHF/SHF ones) and the related fear
that the allocations will be taken away.

[snip]
 since.  I think the hams are still doing 1200 bps FSK, while the
 unlicensed folks have evolved to 108,000,000 bps WiFi.

At lower frequencies the latest fads involve low speed very
narrow-band efficient modulations such as PSK-31, and other low speed
fancy forward error corrected protocols which operate at near the
information theoretic limit like JT65B.  At higher frequencies D-STAR
is becoming popular in some areas, and D-STAR depends on a
proprietary, patent encumbered, and trade-secret speech codec.

Of course, there are people running multimegabit and even WiFi systems
operated under part 97 (e.g. switched into ham bands, or on the
overlapping ISM segments but with the ham emission restrictions rather
than the part 15)

 There must be
 tens of thousands of hams nationwide.  There are tens of thousands of
 WiFi nodes in San Francisco alone -- and no crazy restrictions about
 not using encryption, not letting other people use your radio, etc.

There are about 700k licensees.  Who knows about how many are actually
active, or even living. I could only assume that it would be
significantly less than half.

Of course, 99.999% of your WiFi nodes are just some Apple controlled
appliances with users who even more are blissfully ignorant of how the
technology works.  It's great for facilitating communication, but the
bulk of it isn't facilitating advancement of the art of radio
engineering.   Because the technology encourages ignorant usage any
effort to build more intelligent infrastructure (meshes and such) has
to contend with the interference from those tens of thousands of nodes
with little to no hope for relief.

It's a bit bogus to compare the lack of restrictions on ISM with the
restrictions on ham radio. If your ISM radiated power is high enough
to have any real range on your uncertified equipment, you're in clear
violation of the FCC regulations.

I suppose you could argue that enforcement is much more likely in the
ham bands, and I suppose that may be true but I don't think it's fair
or accurate to say that the restrictions are worse.

The content, crypto, and usage restrictions are silly on ham radio,
especially when compared with how people are using part 15 devices. I
think the goals for spectrum management could be better achieved
through other means. But getting the rules changed would require
having new blood around to petition the FCC to change the rules.



Cheers,


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


[Discuss-gnuradio] GNU radio in college courses

2010-03-05 Thread Sam Keene
Hello,

I'm considering using GNU radio for an upcoming elective course I'll be 
offering in software defined radio. I'm looking for suggestions for textbooks, 
course material, etc. I'd also be interested in hearing about anyone experience 
good or bad who may have done this before.

thanks,

-Sam Keene
Assistant Professor
The Cooper Union


  


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


Re: [Discuss-gnuradio] GNU radio in college courses

2010-03-05 Thread Johnathan Corgan
On Fri, Mar 5, 2010 at 13:01, Sam Keene samke...@yahoo.com wrote:

 I'm considering using GNU radio for an upcoming elective course I'll be 
 offering in software defined radio. I'm looking for suggestions for 
 textbooks, course material, etc. I'd also be interested in hearing about 
 anyone experience good or bad who may have done this before.

Dr. Sharlene Katz of California State University Northridge has done
something similar, and presented on SDR in Education at the last SDR
Forum in December.  It would be a good place to start.

Johnathan


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


[Discuss-gnuradio] IT++ functions

2010-03-05 Thread Pradyumna Desale
Hi All,

I wanted to use some of the communication related signal processing
functions in gnuradio. Has anyone done something on these lines before?
Please let me know.

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


[Discuss-gnuradio] Failed to set center frequency (USRP2)

2010-03-05 Thread senlin peng
Hi all,

I have a problem with the USRP2 board when working with the DBSRX
daughter board.  I am using the 
usrp2_rx_cfile.py file to collect some data with center frequency
around 1.5GHz which is within the range of this daughter board, but it
fails. The USRP2 works  with the RFX 1800 board with this frequency.
So I am confusing. Does anyone know the reason?

-- 
Best Regards!


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


Re: [Discuss-gnuradio] Problem installing new module

2010-03-05 Thread Sagar Kapare
The exact same code works on two other machines, both running OSX 10.5. The
sink is a locally created modules, so it is entirely possible that there is
something missing in the instantiation that is being caught on only on my
machine and not at others (for what reason I cannot fathom).

As an aside, another thing that might be helpful is that my python
installation is partially broken: I have to move the installed .so .la files
(as well as the python files) ouput from a make install from the
/usr/local/lib onto the python script directory (as found during the
configure step)
/opt/local/Library/Frameworks/Python.framework/Versions/2.6/lib/python2.6/site-packages.

On Mon, Mar 1, 2010 at 7:39 AM, Johnathan Corgan 
jcor...@corganenterprises.com wrote:

 On Mon, Mar 1, 2010 at 00:41, Sagar Kapare writetosag...@gmail.com
 wrote:

  RuntimeError: unable to resolve input endpoint sink_ff(0):0

 The runtime doesn't like a reference you are passing to a 'connect'
 call.  Check what you are putting in the connect call that you are
 wiring to 'sink_ff' input 0.  It should be a properly instantiated gr
 block or hierarchical block.

 Johnathan

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


Re: [Discuss-gnuradio] IT++ functions

2010-03-05 Thread Per Zetterberg

Pradyumna Desale wrote:

Hi All,

I wanted to use some of the communication related signal processing 
functions in gnuradio. Has anyone done something on these lines 
before? Please let me know.


Thank you!
Pradyumna


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

We have been planning to do this all the time but no progress yet :-(




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


Re: [Discuss-gnuradio] IT++ functions

2010-03-05 Thread Pradyumna Desale
Hey Per,

Thanks for replying! I wanted to start by incorporating channel models
(channel.h if you are familiar with IT++) and was wondering if just writing
a wrapper function in swig would do the necessary work for us or we have to
make some specific changes to incorporate those codes in gnuradio framework.
Any thoughts?

For starters I am going to write a wrapping function for
set_channel_profile() in channel.h (line no. 676) and another wrapper for
virtual void generate (int no_samples, cvec output)=0

I was wondering if I should follow the guidelines of how to write a signal
processing block or there is another method? I am not superbly confident
with swig and it will be awesome to have someone to bounce ideas off of. Let
me know.

Cheers!
--
Pradyumna

On Fri, Mar 5, 2010 at 5:38 PM, Per Zetterberg per.zetterb...@ee.kth.sewrote:

 Pradyumna Desale wrote:

 Hi All,

 I wanted to use some of the communication related signal processing
 functions in gnuradio. Has anyone done something on these lines before?
 Please let me know.

 Thank you!
 Pradyumna
 

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


 We have been planning to do this all the time but no progress yet :-(




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


Re: [Discuss-gnuradio] usrp2_wfm_rcv.py

2010-03-05 Thread Mike
Hi Johnathan,

Have you had any luck with this issue?  The same is happening on my FLEX2400
with USRP2.

Here is the full error message:

./usrp2_wfm_rcv.py -f 2.4G
Using RX d'board 0x0007
This daughterboard does not cover the required frequency range
for this application.  Please use a BasicRX or TVRX daughterboard.
Press ENTER to continue anyway, or Ctrl-C to exit.
 gr_fir_ccf: using SSE
 gr_fir_fff: using SSE
Traceback (most recent call last):
  File ./usrp2_wfm_rcv.py, line 287, in module
app = stdgui2.stdapp (wfm_rx_block, USRP2 WFM RX)
  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 7935, in __init__
self._BootstrapApp()
  File /usr/lib/python2.6/dist-packages/wx-2.8-gtk2-unicode/wx/_core.py,
line 7509, 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 ./usrp2_wfm_rcv.py, line 116, in __init__
self._build_gui(vbox, usrp_rate, demod_rate, audio_rate)
  File ./usrp2_wfm_rcv.py, line 199, in _build_gui
callback=self.set_gain)
  File /usr/local/lib/python2.6/dist-packages/gnuradio/wxgui/form.py, line
225, in __init__
nsteps = int((self.max-self.min)/self.step_size)
ZeroDivisionError: float division


Cheers,

Mike


On 11 December 2008 17:05, Johnathan Corgan
jcor...@corganenterprises.comwrote:

 On Wed, Dec 10, 2008 at 4:02 PM, Catalin Lacatus
 claca...@us.toyota-itc.com wrote:

  For the first time I was using USRP2 with BasicRX.
  Also, I did some tests for different frequencies and gains with Basic RX
 and
  RFX2400. I got the same error

 This appears to be a bug in usrp2_wfm_rx.py, dealing with setting up
 the gain slider control in the GUI.  I understand why this is
 happening with the BasicRX or LFRX, but not yet with the RFX2400.
 I'll look into this further soon.

 -Johnathan


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

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


Re: [Discuss-gnuradio] gr_unpack_k_bits_bb, its inverse, and higher order constellations

2010-03-05 Thread Eric Blossom
On Fri, Mar 05, 2010 at 04:26:34PM +0100, Mattias Kjellsson wrote:
 Mattias Kjellsson wrote:
  Tom Rondeau wrote:

 Sorry, I just saw that I wrote the last message off- list.
 
 Anyway, I have searched some more in the causes of this error. I took
 the easy way out and looked in gr_buffer.h at line 127. and Changed this:
 Approximately around lines 115-130 in gr_buffer.h
 unsigned index_add (unsigned a, unsigned b){
 unsigned s = a + b;
 /*if (s = d_bufsize)
s -= d_bufsize;*/
 while(s=d_bufsize){
 s-=d_bufsize;
 }
 assert (s  d_bufsize);
 return s;
 }
 
 I assume this is not the way to do this, but it gets rid of the error-
 message... But since I have changed in the library to make this specific
 block not produce an error... It just seems like doing things backwards.
 But then again, this code- change assures that sd_bufsize, but is it
 always correct to do this? I guess not, but I'm not sure.

index_add is correct as originally written.

I suspect that pfb_clock_sync_ccf has a problem in it.

It looks like it only works if the number of output streams is 1 or 4,
but not 2 or 3.  It needs to override check_topology to enforce this.

The two occurences of:

if(output_items.size()  2) {
  ...
}

should probably be changed to: if (output_items.size() == 4)

It also looks like it's leaking d_diff_filters (should delete in the
destructor).

Eric


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


[Discuss-gnuradio] trellis encoder and OFDM modulator

2010-03-05 Thread Veljko Pejovic
Hi,

I tried to use trellis_encoder from trellis package to perform
convolution coding before sending the message to the OFDM modulator.
However, ofdm_mod has zero input signature, and relies on send_pkt()
which calls ofdm_packet_utils.make_packet() and then puts the message
in the queue at gr.ofdm_mapper_bcv. Since the chain basically starts
with ofdm_mod I don't see the way to connect the trellis_encoder
before the signal is already modulated. In ftw80211 project they
modify ofdm_packet_utils and write their own convolution coding
method, I could do the same, but then I would miss all the benefits of
this nice trellis package.

Interestingly, the other modulation blocks such as dbpsk or d8psk have
different input signatures, and I would put the trellis_encoder
between the gr.message_source and modulator in pkt.py. Is there a way
to seamlessly introduce trellis_encoder in the flow graph with an OFDM
modulator? Am I missing something here?


Thanks,


Veljko


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