Re: [Discuss-gnuradio] gr_vector_source_c.cc segmentation fault

[Eric Blossom]

On Thu, Mar 01, 2007 at 10:46:45PM -0500, Liu Xin wrote:
> Hello, All:
> 
> My program got Segmentation Fault. I used gdb to trace the process and got
> the following return:
> ===
> (gdb) continue
> Continuing.
> [New Thread -1223844944 (LWP 25403)]
> 
> Program received signal SIGSEGV, Segmentation fault.
> [Switching to Thread -1223844944 (LWP 25403)]
> 0xb7706c79 in gr_vector_source_c::work (this=0x82bf1c8,
> noutput_items=3968, [EMAIL PROTECTED],  [EMAIL PROTECTED])
> at gr_vector_source_c.cc:58
> 58optr[i] = d_data[offset++];
> Current language:  auto; currently c++
> (gdb)
> ==
> 
> 
> Could anyone give some clues what is wrong with the vector?
> Thanks a lot,
> Xin


What version of GNU Radio are you using?
Is it from a tarball or from svn?
What OS, version and distribution are you using?
What version of g++ are you using?


Eric


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

Re: [Discuss-gnuradio] InBand Signaling: Schedule

[Brian Padalino]

On 3/1/07, Thibaud Hottelier <[EMAIL PROTECTED]> wrote:

Hello,

We (George and me) have added a schedule page to the wiki :
http://gnuradio.org/trac/wiki/InBandSignalingSched

Could you please look it over, add anything missing and suggest
deadline. I can work on the FPGA, but I don't think I will be very
efficient. It would be great if you could suggest an entry point for
both of us.


The diagram should have the FPGA talking to both the AD9862 and the
daughterboard.  You can think of them on the same level since no real
communication is done digitally with the AD9862 - only the analog
signal really follows the chain as it is currently drawn.

As for entry points, I think writing small I2C and SPI modules that
can read and write the bus is a good start.  That should get you
familiar enough with an interface.

A top level design might be a good idea to look over and do a design
review.  Maybe map out what module names and interfaces are going to
connect to where.  Go over the use cases for how the packets are going
to be sent, processed, etc.

There is still a lot of planning to do before you shoudl really go
ahead and attack this problem.  You don't want your Verilog to become
spaghetti because it will just make it BIG.  Draw out your FSMs.  I
personally can't stand bubble charts and prefer ASM charts - but
either way, these sort of things should be planned out.

Here is a link on ASM charting:
   http://uhaweb.hartford.edu/jmhill/suppnotes/AsmChart/index.htm

I am sure there are others out there.

Moreover, unit testing your modules is a very good idea.  Get in the
habit of writing testbenches - they will always come in handy.

This should be plenty to keep you guys busy while Eric finishes
writing up the m-block stuff.  Go with his interface that he specified
and figure out what things have to happen to tune the daugherboards,
set the AD9862, etc.  Try to get down into the control of the entire
USRP.  What does the FX2 do?  What operations would have to happen in
a TDMA + FDMA sequence to make sure everything works properly?  What
does the tune() method do in Python for the daughterboards?

Good luck.


Thanks,
George and Thibaud


Brian


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

[Discuss-gnuradio] gr_vector_source_c.cc segmentation fault

[Liu Xin]

Hello, All:

My program got Segmentation Fault. I used gdb to trace the process and got
the following return:
===
(gdb) continue
Continuing.
[New Thread -1223844944 (LWP 25403)]

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223844944 (LWP 25403)]
0xb7706c79 in gr_vector_source_c::work (this=0x82bf1c8,
noutput_items=3968, [EMAIL PROTECTED],  [EMAIL PROTECTED])
at gr_vector_source_c.cc:58
58optr[i] = d_data[offset++];
Current language:  auto; currently c++
(gdb)
==


Could anyone give some clues what is wrong with the vector?
Thanks a lot,
Xin






The python program
=
#!/usr/bin/env python
from gnuradio import gr
from gnuradio import usrp
from gnuradio import eng_notation
import os
print 'Blocked waiting for GDB attach (pid = %d)' % (os.getpid(),)
raw_input ('Press Enter to continue: ')

def build_graph (carrier=2.462e9):

  interp = 16
  duc0 = 5e6   # IF frequency
  nchan = 1

  fg = gr.flow_graph ()

  dest = usrp.sink_c (0, interp, nchan)
  sample_rate = dest.dac_freq() / interp
  print "Sample rate = ", eng_notation.num_to_str (sample_rate)
  dest.set_tx_freq (0, duc0)
  dest.set_pga(0,20)

  max = (2**15)-1
  min = -max
  vector = []
  for i in range(40):
vector.append(complex(max,max))
vector.append(complex(max,min))
vector.append(complex(min,max))
vector.append(complex(min,min))
  for i in range(60):
vector.append(complex(0,0))

  src = gr.vector_source_c(vector,True)
  fg.connect (src, dest)

  dboard = usrp.selected_subdev(dest, (0,0))

  print "Signal will generated by :", dboard.side_and_name()

  rf = dest.tune(dboard._which, dboard, carrier)
  if rf:
print "Carrier :", eng_notation.num_to_str(rf.baseband_freq)
  else:
print "The range of the daugtherboard's frequency is :", \
eng_notation.num_to_str(dboard.freq_range()[0]), "-", \
eng_notation.num_to_str(dboard.freq_range()[1])
raise SystemExit

  return fg

if __name__ == '__main__':


  mygraph = build_graph ()
  mygraph.start ()
  raw_input ("Press Enter to quit : ")
  mygraph.stop ()




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

Re: [Discuss-gnuradio] mblock linking error

[Eric Blossom]

On Thu, Mar 01, 2007 at 06:27:54PM -0800, Johnathan Corgan wrote:
> Eric Blossom wrote:
> 
> >> Progress, I suppose :-)
> > 
> > Did you have GNU Radio stuff installed in /usr/local/lib when you ran
> > the test?
> > 
> > Also, we may need to run 
> > 
> >   # ldconfig
> > 
> > after editing /etc/ld.so.conf to update the dynamic loader's cache.
> 
> I just verified:
> 
> - no /usr/local/lib in ld.so.conf
> - no GNU Radio files in /usr/local/*
> - ldconfig was run
> 
> make, make check, and make distcheck passed.
> 
> The linker now puts the rpath /usr/local/lib argument.
> 
> Checking the created .so files inside the tree, the embedded RPATH
> values are the same as before, except they have /usr/local/lib appended
> to them.
> 
> So we're still not there yet.  Tim's fix was to add /usr/local/lib to
> his ld.so.conf.  My system doesn't need it.

Thanks for the info.  Strange...

Eric


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

Re: [Discuss-gnuradio] mblock linking error

[Johnathan Corgan]

Eric Blossom wrote:

>> Progress, I suppose :-)
> 
> Did you have GNU Radio stuff installed in /usr/local/lib when you ran
> the test?
> 
> Also, we may need to run 
> 
>   # ldconfig
> 
> after editing /etc/ld.so.conf to update the dynamic loader's cache.

I just verified:

- no /usr/local/lib in ld.so.conf
- no GNU Radio files in /usr/local/*
- ldconfig was run

make, make check, and make distcheck passed.

The linker now puts the rpath /usr/local/lib argument.

Checking the created .so files inside the tree, the embedded RPATH
values are the same as before, except they have /usr/local/lib appended
to them.

So we're still not there yet.  Tim's fix was to add /usr/local/lib to
his ld.so.conf.  My system doesn't need it.

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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

Re: [Discuss-gnuradio] USRP + case = electrical short??

[George Barrinuevo]

Hello,

I experienced a similar issue with my BasicRX and
other daughterboard.  Here is what I found.  When all
is working fine, the motherboards green LED blinks. 
Otherwise, it does not blink or come on when there is
a short.  When I loosened the nut/washer that holds
the SMA jumper cable to the case, the short went away.
 It appears that when this nut it tightened too much,
the locking washer will bite through the black pant on
the enclosure and make contact with the enclosure
metal which causes a short.  My solution was to loosen
this nut a bit.

A better solution is to find plastic thin washers and
use this instead of the locking washers supplied with
the enclosure.  However, I was not able to find a
plastic washer in the right size.  Someone on this
mailing list used a sheet protector with an
exacto-knife to cut out a shape of a washer.

Does anyone have a better/easier solution to this
problem?

Thanks,

--- "Weber, Michael J. (US SSA)"
<[EMAIL PROTECTED]> wrote:

> Hello,
> 
> I have a USRP with an RFX2400 mounted on the A side
> and a FLEX900
> mounted on the B side. Everything works great UNTIL
> I connect the SMA
> jumpers from a TX/RX port on either board to the
> case. When the
> connection between the TX/RX ground and the case is
> made, a short
> occurs, the regulator gets very hot, and the voltage
> at the input jack
> drops to about 2V. Of course I disconnected the
> power as soon as I
> discovered what was happening. The board seems happy
> out of the case, or
> even in the case if the antenna port jumpers are not
> installed. I have
> to other units just like this one running with no
> problems, though one
> of them has a FLEX400 instead of a FLEX900. 
> 
> So... any ideas where the short is? I inspected the
> case and USRP but
> didn't see anything telling, but there's a lot of
> tiny components and
> traces.
> 
> Help?
> 
> Thanks,
> Mike
> 
> -
> Mike Weber * 703-668-4516
> Network Engineer, BAE Systems 
> 
> 
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
>
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 


George Barrinuevo
[EMAIL PROTECTED]



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

[Discuss-gnuradio] USRP + case = electrical short??

[Weber, Michael J. (US SSA)]

Hello,

I have a USRP with an RFX2400 mounted on the A side and a FLEX900
mounted on the B side. Everything works great UNTIL I connect the SMA
jumpers from a TX/RX port on either board to the case. When the
connection between the TX/RX ground and the case is made, a short
occurs, the regulator gets very hot, and the voltage at the input jack
drops to about 2V. Of course I disconnected the power as soon as I
discovered what was happening. The board seems happy out of the case, or
even in the case if the antenna port jumpers are not installed. I have
to other units just like this one running with no problems, though one
of them has a FLEX400 instead of a FLEX900. 

So... any ideas where the short is? I inspected the case and USRP but
didn't see anything telling, but there's a lot of tiny components and
traces.

Help?

Thanks,
Mike

-
Mike Weber * 703-668-4516
Network Engineer, BAE Systems 


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

[Discuss-gnuradio] InBand Signaling: Schedule

[Thibaud Hottelier]

Hello,

We (George and me) have added a schedule page to the wiki :
http://gnuradio.org/trac/wiki/InBandSignalingSched

Could you please look it over, add anything missing and suggest
deadline. I can work on the FPGA, but I don't think I will be very
efficient. It would be great if you could suggest an entry point for
both of us.

Thanks,
George and Thibaud


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

Re: [Discuss-gnuradio] The shortest pulse length

[Eric Blossom]

On Thu, Mar 01, 2007 at 12:15:36PM -0500, David Scaperoth wrote:
> On 3/1/07, seph 004 <[EMAIL PROTECTED]> wrote:
> >
> > This is what I did:
> >
> >def build_graph ():
> >nchan = 1
> >interp = 512
> >duc0 = 0
> >duc1 = 0
> >fs = 250e3#2nd sample rate
> >between usb and dac
> >max_dev = 32e3  #1st sample rate divided
> >by 4 (1st = 2nd sample rate)
> >gain = 16e3
> >k = 2 * math.pi * max_dev / fs
> >vec1 = Numeric.arange (0.624, 0.656, 0.128)
> >vsource = gr.vector_source_f(vec1, False)
> >fmmod = gr.frequency_modulator_fc (k)
> >amp = gr.multiply_const_cc(gain)
> >
> >fg = gr.flow_graph ()
> >
> >u = usrp.sink_c (0, interp, nchan)
> >tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
> >m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
> >u.set_mux(m)
> >subdev = usrp.selected_subdev(u, tx_subdev_spec)
> >subdev.set_enable(True)
> >
> >sample_rate = u.dac_freq () / interp
> >u.set_tx_freq (0, duc0)
> >u.set_tx_freq (1, duc1)
> >
> 
> Are you trying to use one daughter boards(nchen=1)?   Why did you set duc0 =
> 0?   that means your  frequency will not be set at all.  You do not need to
> do set_tx_freq() twice if you are using one daughter board.  you only need :
> u.set_tx_freq (0, duc0) where duc0 is some frequency.  Also, if you are
> using the basic daughterboards, you need to make sure that you have the
> output connector connect to TXA not TXB (according to your tx_subdev_spec)
> 
> 
> Hope this helped.
> David

Lance, you really want to be using tune, not set_tx_freq.
tune knows about all the daughterboards and does the right thing to
split the work between the digital upconverter and the RF front end (if any).

Take a look at fm_tx4.py or fm_tx_2_daughterboards.py

Eric


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

Re: [Discuss-gnuradio] mblock linking error

[Eric Blossom]

On Thu, Mar 01, 2007 at 12:50:20PM -0500, Tim Meehan wrote:
> Eric,
> 
> When I added /usr/local/lib to ld.so.conf
> 
> The build was sucessful
> 
> Tim

Thanks.  That's good to know.  I don't think it should be necessary,
but it's better to know.

Eric


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

Re: [Discuss-gnuradio] mblock linking error

[Eric Blossom]

On Thu, Mar 01, 2007 at 10:06:46AM -0800, Johnathan Corgan wrote:
> Tim Meehan wrote:
> 
> > When I added /usr/local/lib to ld.so.conf
> > 
> > The build was sucessful
> 
> Great!
> 
> But--when I took out the /usr/local/lib from my ld.so.conf, it still
> compiled and linked okay, *and* it switched to using the rpath like your
> used to.
> 
> Progress, I suppose :-)

Did you have GNU Radio stuff installed in /usr/local/lib when you ran
the test?

Also, we may need to run 

  # ldconfig

after editing /etc/ld.so.conf to update the dynamic loader's cache.

Eric


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

Re: [Discuss-gnuradio] mblock linking error

[Johnathan Corgan]

Tim Meehan wrote:

> When I added /usr/local/lib to ld.so.conf
> 
> The build was sucessful

Great!

But--when I took out the /usr/local/lib from my ld.so.conf, it still
compiled and linked okay, *and* it switched to using the rpath like your
used to.

Progress, I suppose :-)

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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

Re: [Discuss-gnuradio] mblock linking error

[Tim Meehan]

Eric,

When I added /usr/local/lib to ld.so.conf

The build was sucessful

Tim

On 3/1/07, Eric Blossom <[EMAIL PROTECTED]> wrote:

On Thu, Mar 01, 2007 at 07:00:37AM -0800, Johnathan Corgan wrote:
> Tim Meehan wrote:
>
> > tim /etc/ld.so.conf
> >
> > /usr/X11R6/lib
> > /usr/lib/atlas
> >
> > /usr/lib/libc5-compat
> > /lib/libc5-compat
> > /usr/i486-linuxlibc1/lib
>
> Here is mine:
>
> /usr/local/lib
> /lib/i486-linux-gnu
> /usr/lib/i486-linux-gnu
> /usr/X11R6/lib
>
> I don't recall if the first line is something I added or if it is the
> stock configuration.
>
> > Some more possibly usefull infromation
> >
> > g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
> > test_mblock.o  -pthread ./.libs/libmblock-qa.so -Wl,--rpath
> > -Wl,/usr/local/lib
>
> On my Ubuntu 6.10 system:
>
> g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
> test_mblock.o  ./.libs/libmblock-qa.so


I recall something in a Debian or Ubuntu bug report about them
changing whether or not they use --rpath based on whether the
destination directory was listed in /etc/ld.so.conf.  It appears that
they are still doing this, and that this could account for the
difference in behavior.  (Seems a bit fragile...)

Tim and Johnathan, can you each perform another experiment for me?
First off do a "make uninstall" to ensure that the install path is
empty.

Then, Tim, please add /usr/local/bin to /etc/ld.so.conf and try

  ./bootstrap
  ./configure
  make
  make check

Johnathan, try the opposite: remove /usr/local/lib from /etc/ld.so.conf
then

  ./bootstrap
  ./configure
  make
  make check


Thanks for your assistance on this.  We may be honing in on the
fundamental libtool change that was made in Debian and/or Ubuntu.

Eric




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

Re: [Discuss-gnuradio] The shortest pulse length

[David Scaperoth]

On 3/1/07, seph 004 <[EMAIL PROTECTED]> wrote:


 This is what I did:

def build_graph ():
nchan = 1
interp = 512
duc0 = 0
duc1 = 0
fs = 250e3#2nd sample rate
between usb and dac
max_dev = 32e3  #1st sample rate divided
by 4 (1st = 2nd sample rate)
gain = 16e3
k = 2 * math.pi * max_dev / fs
vec1 = Numeric.arange (0.624, 0.656, 0.128)
vsource = gr.vector_source_f(vec1, False)
fmmod = gr.frequency_modulator_fc (k)
amp = gr.multiply_const_cc(gain)

fg = gr.flow_graph ()

u = usrp.sink_c (0, interp, nchan)
tx_subdev_spec = (1, 0) #usrp.pick_tx_subdevice(u)
m = usrp.determine_tx_mux_value(u, tx_subdev_spec)
u.set_mux(m)
subdev = usrp.selected_subdev(u, tx_subdev_spec)
subdev.set_enable(True)

sample_rate = u.dac_freq () / interp
u.set_tx_freq (0, duc0)
u.set_tx_freq (1, duc1)



Are you trying to use one daughter boards(nchen=1)?   Why did you set duc0 =
0?   that means your  frequency will not be set at all.  You do not need to
do set_tx_freq() twice if you are using one daughter board.  you only need :
u.set_tx_freq (0, duc0) where duc0 is some frequency.  Also, if you are
using the basic daughterboards, you need to make sure that you have the
output connector connect to TXA not TXB (according to your tx_subdev_spec)


Hope this helped.

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

Re: [Discuss-gnuradio] mblock linking error

[Tim Meehan]

Hi Johnathan

I think I am beginning to understand  now.  I am no expert with the gnu linker

when I run

$g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
test_mblock.o  -pthread ./.libs/libmblock-qa.so  .libs/libmblock.so
-Wl,--rpath -Wl,/usr/local/lib

I do not get an error

NOTE the addition of .libs/libmblock.so to the g++ line

Also if I run

$g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
test_mblock.o  -pthread ./.libs/libmblock-qa.so   -Wl

Note here I do not inlude .libs/libmblock.so but I remove the --rpath
-Wl,/usr/local/lib

I guess the `--rpath '  steps on whatever RPATH is in libmblock-qa.so


I have included the dumps you requested below.

I am rebuilding with /etc/ld.so.conf mod that Eric requested.

$ grep dependency libmblock-qa.la
dependency_libs='
/home/meehan/workspace/gnuradio/mblock/src/lib/libmblock.la
/home/meehan/workspace/gnuradio/omnithread/libgromnithread.la -lrt
/home/meehan/workspace/gnuradio/pmt/src/lib/libpmt.la
/usr/lib/gcc-lib/i486-linux/3.3.5/../../..//libcppunit.la -ldl '

$ objdump -x .libs/libmblock-qa.so | grep NEEDED
 NEEDED  libmblock.so
 NEEDED  libcppunit-1.10.so.0
 NEEDED  libdl.so.2
 NEEDED  libstdc++.so.5
 NEEDED  libm.so.6
 NEEDED  libc.so.6
 NEEDED  libgcc_s.so.1


$objdump -x .libs/libmblock-qa.so   | grep RPATH
 RPATH   /home/meehan/workspace/gnuradio/mblock/src/lib/.libs:/usr/local/lib

$ grep dependency libmblock.la
dependency_libs='
/home/meehan/workspace/gnuradio/omnithread/libgromnithread.la -lrt
/home/meehan/workspace/gnuradio/pmt/src/lib/libpmt.la  '

$ objdump -x .libs/libmblock.so | grep NEEDED
 NEEDED  libgromnithread.so
 NEEDED  libpmt.so
 NEEDED  libstdc++.so.5
 NEEDED  libm.so.6
 NEEDED  libc.so.6
 NEEDED  libgcc_s.so.1

$ objdump -x .libs/libmblock.so | grep RPATH
 RPATH   
/home/meehan/workspace/gnuradio/omnithread/.libs:/home/meehan/workspace/gnuradio/pmt/src/lib/.libs:/usr/local/lib


On 3/1/07, Johnathan Corgan <[EMAIL PROTECTED]> wrote:

Tim Meehan wrote:

> tim /etc/ld.so.conf
>
> /usr/X11R6/lib
> /usr/lib/atlas
>
> /usr/lib/libc5-compat
> /lib/libc5-compat
> /usr/i486-linuxlibc1/lib

Here is mine:

/usr/local/lib
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu
/usr/X11R6/lib

I don't recall if the first line is something I added or if it is the
stock configuration.

> Some more possibly usefull infromation
>
> g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
> test_mblock.o  -pthread ./.libs/libmblock-qa.so -Wl,--rpath
> -Wl,/usr/local/lib

On my Ubuntu 6.10 system:

g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
test_mblock.o  ./.libs/libmblock-qa.so

This is the key difference, as I think was worked out by Bob McGwier
some weeks ago--your libtool has the '-Wl,--rpath -Wl,/usr/local/lib'
arguments appended, mine does not. I have 1.5.22-4.

On my system, in the build tree, this results in:

$ grep dependency libmblock-qa.la

dependency_libs='
/home/jcorgan/gnuradio/trunk/mblock/src/lib/libmblock.la
/home/jcorgan/gnuradio/trunk/omnithread/libgromnithread.la -lrt
/home/jcorgan/gnuradio/trunk/pmt/src/lib/libpmt.la
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../..//libcppunit.la -ldl '

$ objdump -x libmblock-qa.so | grep NEEDED

  NEEDED  libmblock.so
  NEEDED  libcppunit-1.10.so.2
  NEEDED  libdl.so.2
  NEEDED  libstdc++.so.6
  NEEDED  libm.so.6
  NEEDED  libc.so.6
  NEEDED  libgcc_s.so.1

$ objdump -x libmblock-qa.so | grep RPATH

  RPATH   /home/jcorgan/gnuradio/trunk/mblock/src/lib/.libs

$ grep dependency libmblock.la

dependency_libs='
/home/jcorgan/gnuradio/trunk/omnithread/libgromnithread.la -lrt
/home/jcorgan/gnuradio/trunk/pmt/src/lib/libpmt.la  '

$ objdump -x libmblock.so | grep NEEDED

  NEEDED  libgromnithread.so
  NEEDED  libpmt.so
  NEEDED  libstdc++.so.6
  NEEDED  libm.so.6
  NEEDED  libc.so.6
  NEEDED  libgcc_s.so.1

$ objdump -x libmblock.so | grep RPATH

  RPATH
/home/jcorgan/gnuradio/trunk/omnithread/.libs:/home/jcorgan/gnuradio/trunk/pmt/src/lib/.libs


So the net of all this is that in the correctly completed build, both
the .la files and the .so files have all the information needed to
resolve all the interlibrary dependencies from within the build tree.

Can you compare the above to what you see in your tree?

--
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com




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

Re: [Discuss-gnuradio] Which hardware shall i use to implement this SDR?

[David Scaperoth]

On 3/1/07, bhargav b <[EMAIL PROTECTED]> wrote:


Hi!

I am a software radio enthusiast and am a beginner.I have started reading
the codebut i want some guidance as how to proceed.



have you played with the examples in the GNU Radio trunk?
/gnuradio-examples/...
That's the best place to start, then, when you are comfortable there (flow
graphs, sinks, sources)...then I would suggest getting some hardware.

Also,i want to know the complete hardware implementation...i.e... which

boards i can use and where can i get?i am ready to buy a board



Go to www.ettus.com  GNU Radio already comes with the drivers for this
board, and this is what the majority of GNU Radio posts are referencing when
they talk about hardware (FPGA, USB2.0, etc.)


i am confused with this point .I want to implement it practically..please

help me...! I have got a catalog of boards from PENTEK corp. too.Whichboard 
shall i use and how can i customize for a board i do use?(I actually
want to implement it as a pure software radio with minimal hardware).



the USRP is the way to do it


Thanks in advance.

Bhargav,
Graduate Design Engineer,
Imagination Technologies
pune,India

--
Looking for earth-friendly autos?
Browse Top Cars by "Green 
Rating"at
 Yahoo! Autos' Green Center.


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


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

Re: [Discuss-gnuradio] (no subject)

[Eric Blossom]

On Thu, Mar 01, 2007 at 06:33:05AM -0800, Kuntal Majumdar wrote:
> hello,
>
> i just got the new usrp board and built the gnuradio with cygwin
> installed on windows.the first program i ran was the usrp_fft.py
> on giving a 1MHz input to the Rx, i correctly observed it in the
> freq domain, as shown by this program.  thanks for all the help on
> the site on how to build the radio.

Good.

> now, my doubt is that, if i want to use the board as a transmitter,
> say a 4-bit data generator, or simply, if i want to program my fpga
> as a 4-bit counter, how can i do that?  i have generated a .rbf file
> from my verilog code as required but then how do i program the fpga
> and observe the output on the CRO??  my aim initially is to program
> the fpga as a working counter and get the data from the counter and
> display it in the time domain as a train of pulses..plz help me
> in this regard.

We usually handle most things from the host side, including generation
of the waveform to be transmitted.  If you want to write code for the
FPGA, you are certainly welcome to do so, but there is little
documentation available outside of the code itself.

For high-level instructions on how to compile the verilog, please see
usrp/README.  We're using the lastest version of the free Quartus II
web edition.

When using GNU Radio, the host library takes care of loading the .rbf
file into the FPGA for you.  This takes place over the USB.  

However, you can manually load the .rbf using the usrper command:

[EMAIL PROTECTED] mail]$ usrper --help
usrper: invalid option -- -
usage:
  usrper [-v] [-w ] [-x] ...
  usrper load_standard_bits
  usrper load_firmware 
  usrper load_fpga 
  usrper write_fpga_reg  
  usrper set_fpga_reset {on|off}
  usrper set_fpga_tx_enable {on|off}
  usrper set_fpga_rx_enable {on|off}
  - diagnostic routines -
  usrper led0 {on|off}
  usrper led1 {on|off}
  usrper set_hash0 
  usrper get_hash0
  usrper i2c_read i2c_addr len
  usrper i2c_write i2c_addr 
  usrper 9862a_write regno value
  usrper 9862b_write regno value
  usrper 9862a_read regno
  usrper 9862b_read regno


$ usrper load_fpga 

will load the .rbf file into the FPGA.  Please note that it is
possible to permanently damage the USRP by loading buggy code into the
FPGA.

Eric


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

Re: [Discuss-gnuradio] Fewer than 8 bits per sample FPGA support

[Eric Blossom]

On Thu, Mar 01, 2007 at 03:16:12AM -0800, Peter Monta wrote:
> > So the attached patch changes to round-to-nearest-even.
> 
> After thinking a bit, this is wrong: the proper (re-)quantizer is
> just the MSBs of the original sample---one wants a mid-riser
> quantizer to use the even number of output levels symmetrically.
> 
> Revised patch attached (still untested).
> 
> Cheers,
> Peter Monta

I think that you're really going to want a configurable barrel
shifter -- to get the bits where you want them -- then pick them off with
round_X or round_X_nearest_even.

In the 1 bit case, I don't think it matters if you just take the MSB, but in
the other cases, I think you want to be able to adjust to account for gain.

Eric



> --- rx_buffer.v.orig  2007-02-25 14:32:58.0 -0800
> +++ rx_buffer.v   2007-03-01 02:57:00.0 -0800
> @@ -51,8 +51,7 @@
>  output [15:0] debugbus
>  );
>  
> -   wire [15:0] fifodata, fifodata_8;
> -   reg [15:0]  fifodata_16;
> +   reg [15:0] fifodata;
> 
> wire [11:0] rxfifolevel;
> wire rx_empty, rx_full;
> @@ -96,60 +95,51 @@
> store_next <= #1 4'd0;
>   else if(~rx_full & (bitwidth == 5'd8) & (store_next == (channels>>1)))
> store_next <= #1 4'd0;
> + else if(~rx_full & (bitwidth == 5'd4) & (store_next == (channels>>2)))
> +   store_next <= #1 4'd0;
> + else if(~rx_full & (bitwidth == 5'd2))
> +   store_next <= #1 4'd0;
> + else if(~rx_full & (bitwidth == 5'd1))
> +   store_next <= #1 4'd0;
>   else if(~rx_full & (store_next != 0))
> store_next <= #1 store_next + 4'd1;
>  
> -   assignfifodata = (bitwidth == 5'd8) ? fifodata_8 : fifodata_16;
> +   wire [7:0] onebit_vector = 
> {ch_0[15],ch_1[15],ch_2[15],ch_3[15],ch_4[15],ch_5[15],ch_6[15],ch_7[15]};
> +   reg [7:0] onebit_saved;
> +   reg onebit_flag;
>  
> -   assignfifodata_8 = {round_8(top),round_8(bottom)};
> -   reg [15:0] top,bottom;
> -
> -   function [7:0] round_8;
> -  input [15:0] in_val;
> +   always @(posedge rxclk)
> + if(reset)
> +   onebit_flag <= #1 0;
> + else if(rxstrobe & (store_next == 0))
> +   onebit_flag <= #1 ~onebit_flag;
> + else if(~rx_full & (bitwidth == 5'd1))
> +   onebit_saved <= #1 onebit_vector;
>  
> -  round_8 = in_val[15:8] + (in_val[15] & |in_val[7:0]);
> -   endfunction // round_8
> -  
> -   always @*
> - case(store_next)
> -   4'd1 : begin
> -   bottom = ch_0;
> -   top = ch_1;
> -   end
> -   4'd2 : begin
> -   bottom = ch_2;
> -   top = ch_3;
> -   end
> -   4'd3 : begin
> -   bottom = ch_4;
> -   top = ch_5;
> -   end
> -   4'd4 : begin
> -   bottom = ch_6;
> -   top = ch_7;
> -   end
> -   default : begin
> -   top = 16'h;
> -   bottom = 16'h;
> -   end
> - endcase // case(store_next)
> -   
> always @*
> - case(store_next)
> -   4'd1 : fifodata_16 = ch_0;
> -   4'd2 : fifodata_16 = ch_1;
> -   4'd3 : fifodata_16 = ch_2;
> -   4'd4 : fifodata_16 = ch_3;
> -   4'd5 : fifodata_16 = ch_4;
> -   4'd6 : fifodata_16 = ch_5;
> -   4'd7 : fifodata_16 = ch_6;
> -   4'd8 : fifodata_16 = ch_7;
> -   default : fifodata_16 = 16'h;
> - endcase // case(store_next)
> -   
> + case({bitwidth,store_next})
> +   {5'd16,4'd1} : fifodata = ch_0;
> +   {5'd16,4'd2} : fifodata = ch_1;
> +   {5'd16,4'd3} : fifodata = ch_2;
> +   {5'd16,4'd4} : fifodata = ch_3;
> +   {5'd16,4'd5} : fifodata = ch_4;
> +   {5'd16,4'd6} : fifodata = ch_5;
> +   {5'd16,4'd7} : fifodata = ch_6;
> +   {5'd16,4'd8} : fifodata = ch_7;
> +   {5'd8,4'd1} : fifodata = {ch_0[15:8],ch_1[15:8]};
> +   {5'd8,4'd2} : fifodata = {ch_2[15:8],ch_3[15:8]};
> +   {5'd8,4'd3} : fifodata = {ch_4[15:8],ch_5[15:8]};
> +   {5'd8,4'd4} : fifodata = {ch_6[15:8],ch_7[15:8]};
> +   {5'd4,4'd1} : fifodata = 
> {ch_0[11:8],ch_1[11:8],ch_2[11:8],ch_3[11:8]};
> +   {5'd4,4'd2} : fifodata = 
> {ch_4[11:8],ch_5[11:8],ch_6[11:8],ch_7[11:8]};
> +   {5'd2,4'd1} : fifodata = 
> {ch_0[9:8],ch_1[9:8],ch_2[9:8],ch_3[9:8],ch_4[9:8],ch_5[9:8],ch_6[9:8],ch_7[9:8]};
> +   {5'd1,4'd1} : fifodata = {onebit_saved,onebit_vector};
> +   default : fifodata = 16'h;
> + endcase
> +
> fifo_4k rxfifo 
>   ( .data ( fifodata ),
> -   .wrreq (~rx_full & (store_next != 0)),
> +   .wrreq (~rx_full & ( (bitwidth==5'd1) ? (onebit_flag && (store_next 
> != 0)) : (store_next != 0) )),
> .wrclk ( rxclk ),
>  
> .q ( usbdata ),

> ___
> 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] mblock linking error

[Eric Blossom]

On Thu, Mar 01, 2007 at 07:00:37AM -0800, Johnathan Corgan wrote:
> Tim Meehan wrote:
> 
> > tim /etc/ld.so.conf
> > 
> > /usr/X11R6/lib
> > /usr/lib/atlas
> > 
> > /usr/lib/libc5-compat
> > /lib/libc5-compat
> > /usr/i486-linuxlibc1/lib
> 
> Here is mine:
> 
> /usr/local/lib
> /lib/i486-linux-gnu
> /usr/lib/i486-linux-gnu
> /usr/X11R6/lib
> 
> I don't recall if the first line is something I added or if it is the
> stock configuration.
>
> > Some more possibly usefull infromation
> > 
> > g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
> > test_mblock.o  -pthread ./.libs/libmblock-qa.so -Wl,--rpath
> > -Wl,/usr/local/lib
> 
> On my Ubuntu 6.10 system:
> 
> g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
> test_mblock.o  ./.libs/libmblock-qa.so


I recall something in a Debian or Ubuntu bug report about them
changing whether or not they use --rpath based on whether the
destination directory was listed in /etc/ld.so.conf.  It appears that
they are still doing this, and that this could account for the
difference in behavior.  (Seems a bit fragile...)

Tim and Johnathan, can you each perform another experiment for me?
First off do a "make uninstall" to ensure that the install path is
empty.

Then, Tim, please add /usr/local/bin to /etc/ld.so.conf and try

  ./bootstrap
  ./configure
  make
  make check

Johnathan, try the opposite: remove /usr/local/lib from /etc/ld.so.conf
then

  ./bootstrap
  ./configure
  make
  make check


Thanks for your assistance on this.  We may be honing in on the
fundamental libtool change that was made in Debian and/or Ubuntu.

Eric


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

Re: [Discuss-gnuradio] sizeof( bit?)

[Eric Blossom]

On Thu, Mar 01, 2007 at 10:29:48AM +0100, Vincenzo Pellegrini wrote:
> just a quick question, I need to tell the constructor of my first gr block
> to accept a bit by bit input..
> 
> I should call sizeof( what? )
> 
> thanks
> 
> sorry for bothering for such a trivial thing but I haven't found an example
> of this yet..
> 
> -- 
> Vincenzo Pellegrini

If you really want to deal with them bit-by-bit, we generally pack
them 1 bit per byte, since a byte is the smallest conveniently
addressable unit.

Eric


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

Re: [Discuss-gnuradio] mblock linking error

[Johnathan Corgan]

Tim Meehan wrote:

> tim /etc/ld.so.conf
> 
> /usr/X11R6/lib
> /usr/lib/atlas
> 
> /usr/lib/libc5-compat
> /lib/libc5-compat
> /usr/i486-linuxlibc1/lib

Here is mine:

/usr/local/lib
/lib/i486-linux-gnu
/usr/lib/i486-linux-gnu
/usr/X11R6/lib

I don't recall if the first line is something I added or if it is the
stock configuration.

> Some more possibly usefull infromation
> 
> g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
> test_mblock.o  -pthread ./.libs/libmblock-qa.so -Wl,--rpath
> -Wl,/usr/local/lib

On my Ubuntu 6.10 system:

g++ -g -O2 -Wall -Woverloaded-virtual -pthread -o .libs/test_mblock
test_mblock.o  ./.libs/libmblock-qa.so

This is the key difference, as I think was worked out by Bob McGwier
some weeks ago--your libtool has the '-Wl,--rpath -Wl,/usr/local/lib'
arguments appended, mine does not. I have 1.5.22-4.

On my system, in the build tree, this results in:

$ grep dependency libmblock-qa.la

dependency_libs='
/home/jcorgan/gnuradio/trunk/mblock/src/lib/libmblock.la
/home/jcorgan/gnuradio/trunk/omnithread/libgromnithread.la -lrt
/home/jcorgan/gnuradio/trunk/pmt/src/lib/libpmt.la
/usr/lib/gcc/i486-linux-gnu/4.1.2/../../..//libcppunit.la -ldl '

$ objdump -x libmblock-qa.so | grep NEEDED

  NEEDED  libmblock.so
  NEEDED  libcppunit-1.10.so.2
  NEEDED  libdl.so.2
  NEEDED  libstdc++.so.6
  NEEDED  libm.so.6
  NEEDED  libc.so.6
  NEEDED  libgcc_s.so.1

$ objdump -x libmblock-qa.so | grep RPATH

  RPATH   /home/jcorgan/gnuradio/trunk/mblock/src/lib/.libs

$ grep dependency libmblock.la

dependency_libs='
/home/jcorgan/gnuradio/trunk/omnithread/libgromnithread.la -lrt
/home/jcorgan/gnuradio/trunk/pmt/src/lib/libpmt.la  '

$ objdump -x libmblock.so | grep NEEDED

  NEEDED  libgromnithread.so
  NEEDED  libpmt.so
  NEEDED  libstdc++.so.6
  NEEDED  libm.so.6
  NEEDED  libc.so.6
  NEEDED  libgcc_s.so.1

$ objdump -x libmblock.so | grep RPATH

  RPATH
/home/jcorgan/gnuradio/trunk/omnithread/.libs:/home/jcorgan/gnuradio/trunk/pmt/src/lib/.libs


So the net of all this is that in the correctly completed build, both
the .la files and the .so files have all the information needed to
resolve all the interlibrary dependencies from within the build tree.

Can you compare the above to what you see in your tree?

-- 
Johnathan Corgan
Corgan Enterprises LLC
http://corganenterprises.com


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

[Discuss-gnuradio] (no subject)

[Kuntal Majumdar]

hello,

i just got the new usrp board and built the gnuradio with cygwin installed on 
windows.the first program i ran was the usrp_fft.py
on giving a 1MHz input to the Rx, i correctly observed it in the freq domain, 
as shown by this program.
thanks for all the help on the site on how to build the radio.

now, my doubt is that, if i want to use the board as a transmitter, say a 4-bit 
data generator, or simply, if i want to program my fpga as a 4-bit counter, how 
can i do that?
i have generated a .rbf file from my verilog code as required but then how do i 
program the fpga and observe the output on the CRO??
my aim initially is to program the fpga as a working counter and get the data 
from the counter and display it in the time domain as a train of 
pulses..plz help me in this regard.

thanks
Sam



 

Looking for earth-friendly autos? 
Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.
http://autos.yahoo.com/green_center/___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] sizeof( bit?)

[Achilleas Anastasopoulos]

Vincenzo,

I don't think this is possible. The smallest size is a byte,
so you can think of your bits being either unpacket bytes
(ie having values 0 or 1), or packed bytes (in which case
you have to unpack them inside your new block).
If I were you I would go with the former method, since
the packet_to_unpacked block exists already.

Achilleas






--
just a quick question, I need to tell the constructor of my first gr block
to accept a bit by bit input..

I should call sizeof( what? )

thanks

sorry for bothering for such a trivial thing but I haven't found an example
of this yet..

-- Vincenzo Pellegrini


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

Re: [Discuss-gnuradio] problem with gri_fftw

[Greg Troxel]

John Clark <[EMAIL PROTECTED]> writes:

> Greg Troxel schrieb:
>> You left out a lot, like what operating system you are using.  But
>> I'll guess that gr_vmcircbuf_createfilemapping is trying to mmap a
>> file in tmp to get shared memory, and it needs to be writable.
>> Perhaps using mfs or tmpfs, or some other kind of memory filesystem
>> for /tmp is in order.
>
> I'm using Linux... and whatever 'gr-vmcircbuf_createfilemapping' is,
> is buried deep in the gnuradio
> sources.
>
> In this case it looks like there's a presumption about the 'user' and
> having a directory associated with
> that user, where 'preferences', etc. can be read/written, rather than
> using say, /tmp or similar 'well known'
> writeable location.

So far people seem to run GNU Radio as users, so there are probably
hidden assumptions about the environment that need to be tracked down
and fixed.  We were able to make it run as a daemon to receive 802.11
and inject the packets via a tap interface (on NetBSD).  But, we
weren't trying to do this on a ro filesystem.

truss is probably useful to find the failing system call.



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

[Discuss-gnuradio] Fewer than 8 bits per sample FPGA support

[Peter Monta]

> So the attached patch changes to round-to-nearest-even.

After thinking a bit, this is wrong: the proper (re-)quantizer is
just the MSBs of the original sample---one wants a mid-riser
quantizer to use the even number of output levels symmetrically.

Revised patch attached (still untested).

Cheers,
Peter Monta

--- rx_buffer.v.orig2007-02-25 14:32:58.0 -0800
+++ rx_buffer.v 2007-03-01 02:57:00.0 -0800
@@ -51,8 +51,7 @@
 output [15:0] debugbus
 );
 
-   wire [15:0] fifodata, fifodata_8;
-   reg [15:0]  fifodata_16;
+   reg [15:0] fifodata;

wire [11:0] rxfifolevel;
wire rx_empty, rx_full;
@@ -96,60 +95,51 @@
store_next <= #1 4'd0;
  else if(~rx_full & (bitwidth == 5'd8) & (store_next == (channels>>1)))
store_next <= #1 4'd0;
+ else if(~rx_full & (bitwidth == 5'd4) & (store_next == (channels>>2)))
+   store_next <= #1 4'd0;
+ else if(~rx_full & (bitwidth == 5'd2))
+   store_next <= #1 4'd0;
+ else if(~rx_full & (bitwidth == 5'd1))
+   store_next <= #1 4'd0;
  else if(~rx_full & (store_next != 0))
store_next <= #1 store_next + 4'd1;
 
-   assignfifodata = (bitwidth == 5'd8) ? fifodata_8 : fifodata_16;
+   wire [7:0] onebit_vector = 
{ch_0[15],ch_1[15],ch_2[15],ch_3[15],ch_4[15],ch_5[15],ch_6[15],ch_7[15]};
+   reg [7:0] onebit_saved;
+   reg onebit_flag;
 
-   assignfifodata_8 = {round_8(top),round_8(bottom)};
-   reg [15:0] top,bottom;
-
-   function [7:0] round_8;
-  input [15:0] in_val;
+   always @(posedge rxclk)
+ if(reset)
+   onebit_flag <= #1 0;
+ else if(rxstrobe & (store_next == 0))
+   onebit_flag <= #1 ~onebit_flag;
+ else if(~rx_full & (bitwidth == 5'd1))
+   onebit_saved <= #1 onebit_vector;
 
-  round_8 = in_val[15:8] + (in_val[15] & |in_val[7:0]);
-   endfunction // round_8
-  
-   always @*
- case(store_next)
-   4'd1 : begin
- bottom = ch_0;
- top = ch_1;
-   end
-   4'd2 : begin
- bottom = ch_2;
- top = ch_3;
-   end
-   4'd3 : begin
- bottom = ch_4;
- top = ch_5;
-   end
-   4'd4 : begin
- bottom = ch_6;
- top = ch_7;
-   end
-   default : begin
- top = 16'h;
- bottom = 16'h;
-   end
- endcase // case(store_next)
-   
always @*
- case(store_next)
-   4'd1 : fifodata_16 = ch_0;
-   4'd2 : fifodata_16 = ch_1;
-   4'd3 : fifodata_16 = ch_2;
-   4'd4 : fifodata_16 = ch_3;
-   4'd5 : fifodata_16 = ch_4;
-   4'd6 : fifodata_16 = ch_5;
-   4'd7 : fifodata_16 = ch_6;
-   4'd8 : fifodata_16 = ch_7;
-   default : fifodata_16 = 16'h;
- endcase // case(store_next)
-   
+ case({bitwidth,store_next})
+   {5'd16,4'd1} : fifodata = ch_0;
+   {5'd16,4'd2} : fifodata = ch_1;
+   {5'd16,4'd3} : fifodata = ch_2;
+   {5'd16,4'd4} : fifodata = ch_3;
+   {5'd16,4'd5} : fifodata = ch_4;
+   {5'd16,4'd6} : fifodata = ch_5;
+   {5'd16,4'd7} : fifodata = ch_6;
+   {5'd16,4'd8} : fifodata = ch_7;
+   {5'd8,4'd1} : fifodata = {ch_0[15:8],ch_1[15:8]};
+   {5'd8,4'd2} : fifodata = {ch_2[15:8],ch_3[15:8]};
+   {5'd8,4'd3} : fifodata = {ch_4[15:8],ch_5[15:8]};
+   {5'd8,4'd4} : fifodata = {ch_6[15:8],ch_7[15:8]};
+   {5'd4,4'd1} : fifodata = {ch_0[11:8],ch_1[11:8],ch_2[11:8],ch_3[11:8]};
+   {5'd4,4'd2} : fifodata = {ch_4[11:8],ch_5[11:8],ch_6[11:8],ch_7[11:8]};
+   {5'd2,4'd1} : fifodata = 
{ch_0[9:8],ch_1[9:8],ch_2[9:8],ch_3[9:8],ch_4[9:8],ch_5[9:8],ch_6[9:8],ch_7[9:8]};
+   {5'd1,4'd1} : fifodata = {onebit_saved,onebit_vector};
+   default : fifodata = 16'h;
+ endcase
+
fifo_4k rxfifo 
  ( .data ( fifodata ),
-   .wrreq (~rx_full & (store_next != 0)),
+   .wrreq (~rx_full & ( (bitwidth==5'd1) ? (onebit_flag && (store_next != 
0)) : (store_next != 0) )),
.wrclk ( rxclk ),
 
.q ( usbdata ),
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] mblock linking error

[Tim Meehan]

tim /etc/ld.so.conf

/usr/X11R6/lib
/usr/lib/atlas

/usr/lib/libc5-compat
/lib/libc5-compat
/usr/i486-linuxlibc1/lib


Some more possibly usefull infromation

g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
test_mblock.o  -pthread ./.libs/libmblock-qa.so -Wl,--rpath
-Wl,/usr/local/lib

results in

./.libs/libmblock-qa.so: undefined reference to `mb_mblock::handle_message(boost
::shared_ptr)'
...

this symbol,  `mb_mblock::handle_message(boost::shared_ptr)'

is in .libs/mb_mblock.o

but it is not clear to me where g++ was told to find it from the command above.

On 2/28/07, Eric Blossom <[EMAIL PROTECTED]> wrote:

On Wed, Feb 28, 2007 at 04:54:14PM -0500, Tim Meehan wrote:
> Hi Johnathan,
>
> make clean
> ./bootstrap
> ./configure
> make
>
> also fails.  See below
>
> If there is something I can do to help you figure this out let me
> know, but don't sweat it on my account.  For the moment I will just
> run without mblock and when I get some time I will dig into it.
>
> creating libmblock-qa.la
> (cd .libs && rm -f libmblock-qa.la && ln -s ../libmblock-qa.la
> libmblock-qa.la)
> if g++ -DHAVE_CONFIG_H -I. -I. -I../../.. -DOMNITHREAD_POSIX=1
> -I../../../omnithread -I../../../pmt/src/lib -g -O2 -Wall
> -Woverloaded-virtual -pthread -MT test_mblock.o -MD -MP -MF
> ".deps/test_mblock.Tpo" -c -o test_mblock.o test_mblock.cc; \
> then mv -f ".deps/test_mblock.Tpo" ".deps/test_mblock.Po"; else rm -f
> ".deps/test_mblock.Tpo"; exit 1; fi
> /bin/sh ../../../libtool --tag=CXX --mode=link g++ -g -O2 -Wall
> -Woverloaded-virtual -pthread   -o test_mblock  test_mblock.o
> libmblock-qa.la
> g++ -g -O2 -Wall -Woverloaded-virtual -o .libs/test_mblock
> test_mblock.o  -pthread ./.libs/libmblock-qa.so -Wl,--rpath
> -Wl,/usr/local/lib
> ./.libs/libmblock-qa.so: undefined reference to
> `mb_mblock::handle_message(boost::shared_ptr)'
> ./.libs/libmblock-qa.so: undefined reference to
> `omni_thread::init_t::init_t[in-charge]()'
> ./.libs/libmblock-qa.so: undefined reference to
> `mb_mblock_impl::make_accepter(std::basic_string std::char_traits, std::allocator >)'


Tim and Johnathan, can you please post the contents of your /etc/ld.so.conf?

Thanks,
Eric




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

Fwd: Re: [Discuss-gnuradio] USRP.. programming the FPGA..

[pankaj kumar]

hello 

i need help regarding this..

its urgent..



Note: forwarded message attached.
 
-
It's here! Your new message!
Get new email alerts with the free Yahoo! Toolbar.--- Begin Message ---
Hello
   
  i have tried with USRP_fft.py and then took a sinosidal input and then after 
running this on cygwin (on window xp) , we were able to see this sine wave at 
one RX daughter board.
   
  so now we didnt understood that by doing so how the FPGA is programmed for 
this operation, what we have done for that.
   
  as i guess that USRP_FFT.PY must be containing some instantiation of.RBF 
file.
   
  so what i understood is that first we have to generate a .RBF file from a 
verilog code using quartus 2 software and then we have to use usrp_fft.py to 
download it into FPGA.
   
  but i am not clear how it is happening, suppose if i will modify .RBF file 
then should i need to modify usrp_fft.py code also
   
  i hope for more information regarding this..
   
  thank  you
  pankaj 

Eric Blossom <[EMAIL PROTECTED]> wrote:
  On Mon, Feb 26, 2007 at 08:21:10AM -0800, pankaj kumar wrote:
> the code which you have suggested, how to get that..?
> 
> usrp_fft.py 
> 
> where i am supposed to get this one...
> 
> pankaj


First off, download the GNU Radio code.

Start here: http://gnuradio.org/trac/wiki

It's in gnuradio-examples/python/usrp/usrp_fft.py

Eric
 
-
Never Miss an Email
Stay connected with Yahoo! Mail on your mobile. Get started!___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
--- End Message ---
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] sizeof( bit?)

[Vincenzo Pellegrini]

just a quick question, I need to tell the constructor of my first gr block
to accept a bit by bit input..

I should call sizeof( what? )

thanks

sorry for bothering for such a trivial thing but I haven't found an example
of this yet..

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

[Discuss-gnuradio] Which hardware shall i use to implement this SDR?

[bhargav b]

Hi!

I am a software radio enthusiast and am a beginner.I have started reading the 
codebut i want some guidance as how to proceed.

Also,i want to know the complete hardware implementation...i.e... which boards 
i can use and where can i get?i am ready to buy a boardi am confused 
with this point .I want to implement it practically..please help me...! I have 
got a catalog of boards from PENTEK corp. too.Which board shall i use and how 
can i customize for a board i do use?(I actually want to implement it as a pure 
software radio with minimal hardware).

Thanks in advance.
Bhargav,
Graduate Design Engineer,
Imagination Technologies
pune,India

 
-
Looking for earth-friendly autos? 
 Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center.  ___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] rx_buffer testbench

[Peter Monta]

Davide Anastasia writes:


I'm trying to modify the rx_buffer module, in order to obtain a 1 bit
quantization. Is it available a testbench for this module?


I'd also like quantization to less than 8 bits.  Attached is
a rough diff for rx_buffer.v that aims to support 4, 2, and
1-bit quantization.  This is very rough, and I don't even know
if it compiles (have to go get myself a copy of Quartus),
but it would be good to know from others on the list if this
is the right direction.

The stock rx_buffer.v implements round-to-zero.  It's not clear
if this is the most useful, actually---if I request 4-bit
samples, I'm more or less expecting 4-bit uniform quantization,
right?  So the attached patch changes to round-to-nearest-even.

Cheers,
Peter Monta



--- rx_buffer.v.orig2007-02-25 14:32:58.0 -0800
+++ rx_buffer.v 2007-03-01 00:01:05.0 -0800
@@ -51,8 +51,7 @@
 output [15:0] debugbus
 );
 
-   wire [15:0] fifodata, fifodata_8;
-   reg [15:0]  fifodata_16;
+   reg [15:0] fifodata;

wire [11:0] rxfifolevel;
wire rx_empty, rx_full;
@@ -96,60 +95,66 @@
store_next <= #1 4'd0;
  else if(~rx_full & (bitwidth == 5'd8) & (store_next == (channels>>1)))
store_next <= #1 4'd0;
+ else if(~rx_full & (bitwidth == 5'd4) & (store_next == (channels>>2)))
+   store_next <= #1 4'd0;
+ else if(~rx_full & (bitwidth == 5'd2))
+   store_next <= #1 4'd0;
+ else if(~rx_full & (bitwidth == 5'd1))
+   store_next <= #1 4'd0;
  else if(~rx_full & (store_next != 0))
store_next <= #1 store_next + 4'd1;
 
-   assignfifodata = (bitwidth == 5'd8) ? fifodata_8 : fifodata_16;
-
-   assignfifodata_8 = {round_8(top),round_8(bottom)};
-   reg [15:0] top,bottom;
-
-   function [7:0] round_8;
+   function [7:0] round_8_to_nearest_even;
   input [15:0] in_val;
 
-  round_8 = in_val[15:8] + (in_val[15] & |in_val[7:0]);
+  round_8_to_nearest_even = in_val[15:8] + ((in_val[7:0]==8'd128) ? 
in_val[8] : in_val[7]);
endfunction // round_8
-  
-   always @*
- case(store_next)
-   4'd1 : begin
- bottom = ch_0;
- top = ch_1;
-   end
-   4'd2 : begin
- bottom = ch_2;
- top = ch_3;
-   end
-   4'd3 : begin
- bottom = ch_4;
- top = ch_5;
-   end
-   4'd4 : begin
- bottom = ch_6;
- top = ch_7;
-   end
-   default : begin
- top = 16'h;
- bottom = 16'h;
-   end
- endcase // case(store_next)
-   
+
+   wire [7:0] cr0 = round_8_to_nearest_even(ch_0);
+   wire [7:0] cr1 = round_8_to_nearest_even(ch_1);
+   wire [7:0] cr2 = round_8_to_nearest_even(ch_2);
+   wire [7:0] cr3 = round_8_to_nearest_even(ch_3);
+   wire [7:0] cr4 = round_8_to_nearest_even(ch_4);
+   wire [7:0] cr5 = round_8_to_nearest_even(ch_5);
+   wire [7:0] cr6 = round_8_to_nearest_even(ch_6);
+   wire [7:0] cr7 = round_8_to_nearest_even(ch_7);
+
+   wire [7:0] onebit_vector = 
{ch_0[15],ch_1[15],ch_2[15],ch_3[15],ch_4[15],ch_5[15],ch_6[15],ch_7[15]};
+   reg [7:0] onebit_saved;
+   reg onebit_flag;
+
+   always @(posedge rxclk)
+ if(reset)
+   onebit_flag <= #1 0;
+ else if(rxstrobe & (store_next == 0))
+   onebit_flag <= #1 ~onebit_flag;
+ else if(~rx_full & (bitwidth == 5'd1))
+   onebit_saved <= #1 onebit_vector;
+
always @*
- case(store_next)
-   4'd1 : fifodata_16 = ch_0;
-   4'd2 : fifodata_16 = ch_1;
-   4'd3 : fifodata_16 = ch_2;
-   4'd4 : fifodata_16 = ch_3;
-   4'd5 : fifodata_16 = ch_4;
-   4'd6 : fifodata_16 = ch_5;
-   4'd7 : fifodata_16 = ch_6;
-   4'd8 : fifodata_16 = ch_7;
-   default : fifodata_16 = 16'h;
- endcase // case(store_next)
-   
+ case({bitwidth,store_next})
+   {5'd16,4'd1} : fifodata = ch_0;
+   {5'd16,4'd2} : fifodata = ch_1;
+   {5'd16,4'd3} : fifodata = ch_2;
+   {5'd16,4'd4} : fifodata = ch_3;
+   {5'd16,4'd5} : fifodata = ch_4;
+   {5'd16,4'd6} : fifodata = ch_5;
+   {5'd16,4'd7} : fifodata = ch_6;
+   {5'd16,4'd8} : fifodata = ch_7;
+   {5'd8,4'd1} : fifodata = {cr0,cr1};
+   {5'd8,4'd2} : fifodata = {cr2,cr3};
+   {5'd8,4'd3} : fifodata = {cr4,cr5};
+   {5'd8,4'd4} : fifodata = {cr6,cr7};
+   {5'd4,4'd1} : fifodata = {cr0[3:0],cr1[3:0],cr2[3:0],cr3[3:0]};
+   {5'd4,4'd2} : fifodata = {cr4[3:0],cr5[3:0],cr6[3:0],cr7[3:0]};
+   {5'd2,4'd1} : fifodata = 
{cr0[1:0],cr1[1:0],cr2[1:0],cr3[1:0],cr4[1:0],cr5[1:0],cr6[1:0],cr7[1:0]};
+   {5'd1,4'd1} : fifodata = {onebit_saved,onebit_vector};
+   default : fifodata = 16'h;
+ endcase
+
fifo_4k rxfifo 
  ( .data ( fifodata ),
-   .wrreq (~rx_full & (store_next != 0)),
+   .wrreq (~rx_full & ( (bitwidth==5'd1) ? (onebit_flag && (store_next != 
0)) : (store_next != 0) )),
.wrclk ( rxclk ),
 
.q ( usbdata ),
___
Discuss-gnuradio mailing list
Discus