Re: [Discuss-gnuradio] extending gr-trellis to perform Viterbi, MLSD on GMSK

[Grzegorz Suder]

Hi,

I am trying to decode CPM signal according to your email but I have problem
with understanding some things. What I'd like to do is to decode some kind
of I/Q samples according to following scenario:
- decimation of symbol rate N-times
- decoding I/Q symbols according to FSM file and provided constellation

For VA I am using:
 dimensionality = 1
 va =
trellis.viterbi_combined_cb(f,K,0,-1,dimensionality,constellation,trellis.TRELLIS_EUCLIDEAN)

However the results are not as expected to be. My guess is that something
might be wrong with FSM file - I've looked through *.fsm files example and
seems that table OS (output symbols) is generated somehow. What I know about
my state machine is:
- there is S unique states
- each state can have transition to one of I states
- each input symbol is equal to IB bits
- transition from state S(i-1) to S(i) corresponds to O output symbols
- each output symbol is written on OB bits

So in general - I have defined NS table. I thought that OS table in *.fsm
file is just table that tells: transition from state S(a) to state S(b) is
equal to output symbol O(ab) but it seems that I'm wrong. Is there any easy
way to generate OS table in *.fsm file? I have seen fsm constructor that
generates these values according to (n,k) and G - is that only way to
generate OS table?

Regards,

On Tue, Feb 3, 2009 at 11:23 PM, Achilleas Anastasopoulos  wrote:

> Nick,
>
> there is no change required in the modules that perform viterbi decoding
> in order to implement either MLSD in ISI or (coherent) GMSK demod.
> The whole idea around gr-trellis was to disentangle the trellis aspect
> of a modulation scheme from the details of the modulation/channel.
>
> So, if you want to implement general (coherent) CPM demodulation, all
> you have to do is to represent the CPM signal as a FSM followed by a
> memoryless modulator. Look up the paper by
> Bixio Rimoldi: A decomposition approach to CPM, or take a look at my
> notes on this at
> http://www.eecs.umich.edu/~anastas/docs/cpm.pdf
>
> You will only need to write an additional
> constructor for the fsm class that takes the CPM parameters and produces
> the appropriate FSM. Similarly, you'll need to write a piece of code
> that takes the incoming waveform and does the metrics calculations
> (eithar as a separate block as in trellis-metrics or inside the viterbi
> block as in trellis-viterbi-combined).
>
> If you want to work on this general problem for a generic CPM modulation
> I can help you.
>
> Adding ISI to this is a piece of cake: you need to combine the two
> trellises into either a combined trellis or to use hard/soft decisions
> from one to feed the other detector.
>
>
> Achilleas
>
>
> ---
> Date: Tue, 3 Feb 2009 02:43:01 +
> From: Nick Foster 
> Subject: [Discuss-gnuradio] extending gr-trellis to perform Viterbi
>MLSD on GMSK
> To: gnuradio 
> Message-ID: 
> Content-Type: text/plain; charset="windows-1252"
>
>
> Hi all,
>
> I've spent a few days familiarizing myself with gr-trellis as best as I
> can, and I'm interested in extending the gr-trellis module to handle
> Viterbi equalization of ISI channels for GMSK demodulation. I saw Toby
> Oliver's thread in Sept. '06
> (http://www.mail-archive.com/discuss-gnuradio@gnu.org/msg05615.html)
> discussing a possible modification with Achilleas Anastasopoulos but
> never saw anything checked in as a result. I'm just looking to use the
> trellis code to demodulate low-BT GMSK in a more optimal way than the
> current Gnuradio implementation, and I have similar questions to Toby's:
>
> * How should I go about modifying make_isi_lookup() to add support for
> two-dimensional modulations? What format is trellis expecting?
>
> * I see the test_viterbi_equalization1.py file, which appears to do MLSD
> on an ISI channel for 4-PAM (and other one-dimensional modulations). Am
> I correct that if make_isi_lookup() is modified to support quadrature
> modulations, simply changing the modulation type in this example would
> be enough to make it work? I guess I'm asking more specifically if
> trellis.viterbi_combined_X will support an ISI lookup table for PSK
> modulations without modification.
>
> * Is there a good reason I should avoid tackling this problem? I'd hate
> to be duplicating someone else's work in this area, or barking up the
> wrong tree.
>
> For further information, I've written a packet-based AIS decoder for
> Gnuradio, and I'm disappointed at the quality of the data coming out of
> the GMSK demodulator. It's 9600 symbols per second @ BT=0.3, so there's
> enough ISI that I think MLSD would provide significant reduction in
> observed BER. Besides, it seems like it would be a useful capability to
> have added to Gnuradio. Any other tips anyone has that might help me in
> doing this would certainly be welcome!
>
> Nick
>
>
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradi

Re: [Discuss-gnuradio] CGRAN downtime

[Frank Brickle]

On Tue, Feb 10, 2009 at 11:44 PM, George Nychis  wrote:


>
> But eek, what I meant was:
> https://www.cgran.org/svn/
>
> rather than:
> https://www.cgran.org/cgran/
>
> I don't think I can have the base URL used for both SVN and web.
>
> Still legit?


Definitely.

Frank


-- 
When small birds sighed, she would sigh back at them. -- Theodore Roethke
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

[Discuss-gnuradio] Usrp2 and Agere ET131x compatibility

[Yc Park]

Hi, guys

I have two questions:

- My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
  Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
(I see the chipset 'bad'
here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
that the linux and ET131 have some problems, not USRP2 and ET131)

- Granted that the compatibility issue exists, do we have any progress
on the latest source code of GR or on the USRP2 firmware?

I'm eager to see it work with my laptop... usrp2 is just sitting on my
desk for more than a month T.T

Regards,
YCpark.
-- 
Posted via http://www.ruby-forum.com/.


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

Re: [Discuss-gnuradio] extending gr-trellis to perform Viterbi, MLSD on GMSK

[Achilleas Anastasopoulos]

The definition of the OS table is different than the one you suggest:

For every state "s" and for every INPUT SYMBOL "i" it tells you what the 
output symbol index "o" should be.

The reason a "transition" "t" is defined
as the pair (s,i) and not as a succession of states (s,s') is that the 
latter case cannot deal with "parallel" transitions.


So you need to rewrite your *.fsm description.

In addition, I suppose you have implemented some sort of "demodulator", 
ie, the device that takes the IQ CPM samples and projects these signals 
onto an (at least approximate) orthonormal basis. The way to do that is 
detailed here:

http://www.eecs.umich.edu/~anastas/docs/cpm.pdf


Achilleas


--
From:   Grzegorz Suder
Subject: 	Re: [Discuss-gnuradio] extending gr-trellis to perform 
Viterbi, MLSD on GMSK

Date:   Wed, 11 Feb 2009 10:19:42 +0100
Hi,

I am trying to decode CPM signal according to your email but I have 
problem with understanding some things. What I'd like to do is to decode 
some kind of I/Q samples according to following scenario:

- decimation of symbol rate N-times
- decoding I/Q symbols according to FSM file and provided constellation

For VA I am using:
 dimensionality = 1
 va = 
trellis.viterbi_combined_cb(f,K,0,-1,dimensionality,constellation,trellis.TRELLIS_EUCLIDEAN)


However the results are not as expected to be. My guess is that 
something might be wrong with FSM file - I've looked through *.fsm files 
example and seems that table OS (output symbols) is generated somehow. 
What I know about my state machine is:

- there is S unique states
- each state can have transition to one of I states
- each input symbol is equal to IB bits
- transition from state S(i-1) to S(i) corresponds to O output symbols
- each output symbol is written on OB bits

So in general - I have defined NS table. I thought that OS table in 
*.fsm file is just table that tells: transition from state S(a) to state 
S(b) is equal to output symbol O(ab) but it seems that I'm wrong. Is 
there any easy way to generate OS table in *.fsm file? I have seen fsm 
constructor that generates these values according to (n,k) and G - is 
that only way to generate OS table?


Regards,


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

Re: [Discuss-gnuradio] Re: [Commit-gnuradio] r10410 -gnuradio/trunk/gnuradio-core/src/lib/missing

[Don Ward]

Michael Dickens wrote:



On Feb 10, 2009, at 11:17 AM, Don Ward wrote:

As far as I can tell, MinGW has no standard aligned-memory
allocation functions. Can we use malloc16.c (in gnuradio-core/.../
general) or something like gcell/lib/runtime/gc_aligned_alloc.cc
instead?


malloc16.c requires the use of both the specific allocating
(malloc16Align () and calloc16Align ()) and freeing (free16Align ())
routines to do what it does, but it would work (even though it might
waste a bit of memory when allocating, in order to guarantee both
alignment as well as a means for storing the actual allocated pointer
value) ... This could be an option for certain issues.

gc_aligned_alloc () uses posix_memalign (), so that's not an option.

A better solution makes use of some built-in memory-alloc-with-
alignment function and uses the standard "free ()" to dealloc.  That's
what the posix_memalign () function is meant to, and currently does,
provide.


Agreed, but as far as I can tell, Windows does not have an aligned memory 
allocation function that works with free() so this solution is not 
available.



The best way to do this would be to add on to the posix_memalign.cc
file for the specific OS and how it does allocating.  Use the
AC_CHECK_HEADER macro to check for the correct headers, then
AC_CHECK_FUNCS to make sure the functions exist and are callable.
Then #ifdef around the appropriate functions after the end of
HAVE_VALLOC in posix_memalign.cc for how this OS does it.


How about a test to automatically disable components that require 
posix_memalign during configuration?


Thanks,

-- Don W.



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

[Discuss-gnuradio] Libusb versions

[Marcus D. Leech]

I've noticed that on my F10 system, the version of libusb is old
(0.1.12), whereas libusb-1.xx series have been out for a while.
  One of the things mentioned in the notes for libusb-1.0 is improved
performance on bulk transfers.  I wonder about
  the version of libusb causing us overrun grief, even on "manly"
processors.

-- 
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] Usrp2 and Agere ET131x compatibility

[Newman, Timothy]

If you're in a hurry to get it to work, your best bet is to go out and buy a 
GigE express card.  I doubt that much work is going into looking into specific 
incompatible chipsets. I could be wrong.

Tim
---
Timothy R. Newman, Ph.D.
Wireless @ Virginia Tech
447 Durham Hall
Blacksburg, VA 24061
Phone: 540-231-2041

> -Original Message-
> From: discuss-gnuradio-bounces+trnewman=vt@gnu.org 
> [mailto:discuss-gnuradio-
> bounces+trnewman=vt@gnu.org] On Behalf Of Yc Park
> Sent: Wednesday, February 11, 2009 8:21 AM
> To: discuss-gnuradio@gnu.org
> Subject: [Discuss-gnuradio] Usrp2 and Agere ET131x compatibility
> 
> Hi, guys
> 
> I have two questions:
> 
> - My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
>   Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
> (I see the chipset 'bad'
> here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
> that the linux and ET131 have some problems, not USRP2 and ET131)
> 
> - Granted that the compatibility issue exists, do we have any progress
> on the latest source code of GR or on the USRP2 firmware?
> 
> I'm eager to see it work with my laptop... usrp2 is just sitting on my
> desk for more than a month T.T
> 
> Regards,
> YCpark.
> --
> Posted via http://www.ruby-forum.com/.
> 
> 
> ___
> 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] Make fails in gr-how-to-write-a-block

[Emil Molin]

So i want to learn how to write a block but it fails to install apparently.

after doing ./bootstrap and then ./configure

make gives the following message:

libtool: Version mismatch error.  This is libtool 2.2.6, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
libtool: and run autoconf again.
make[3]: *** [howto.lo] Error 63
make[2]: *** [check] Error 2
make[1]: *** [check-recursive] Error 1

well it seems i should recreate aclocal.m4 with macros from libtool 2.2.6
problem is i dont know how.

Im still using Mac OS X 10.5.6 and i can run the helloworld example so the
other stuff seems fine.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Make fails in gr-how-to-write-a-block

[Eric Blossom]

On Wed, Feb 11, 2009 at 03:45:54PM +0100, Emil Molin wrote:
> So i want to learn how to write a block but it fails to install apparently.
> 
> after doing ./bootstrap and then ./configure
> 
> make gives the following message:
> 
> libtool: Version mismatch error.  This is libtool 2.2.6, but the
> libtool: definition of this LT_INIT comes from an older release.
> libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6
> libtool: and run autoconf again.
> make[3]: *** [howto.lo] Error 63
> make[2]: *** [check] Error 2
> make[1]: *** [check-recursive] Error 1
> 
> well it seems i should recreate aclocal.m4 with macros from libtool 2.2.6
> problem is i dont know how.

  $ rm aclocal.m4
  $ ./bootstrap && ./configure ...

Eric


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

Re: [Discuss-gnuradio] GNU Radio and USRP baseband demodulation/decoding

[Einar Thorsrud]

Ed Criscuolo wrote:

Once you have the actual binary bitstream, decoding NRZI is easy.
There's a custom block to do this provided in the "GMSK Spacecraft
Groundstation" project in CGRAN:

https://www.cgran.org/wiki/Projects

This project would be good for you to study, as it represents
a real-world application that does something very similar to
what you want, performing both bit and packet synchronization.


Thank you. This was a very interesting project indeed. I will try to 
reuse as much as possible.


I am also having problems testing the system as I go along. What I would 
like to do is use a vector sink, and print the received samples to the 
screen. Hover when I tried initially with only a vector source connected 
directly to a vector sink, and using the read()-method, only "()" is 
printed. This seems to be the case no matter where in the code the print 
statement is issued. (Using "print tb.gr_vector_sink_x_0.data()")


What is wrong? And what would be the easiest way to verify the received 
samples?


- Einar


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

Re: [Discuss-gnuradio] 'make check' fails on OS X 10.5 with gnuradio 3.1 release

[Michael Dickens]

On Feb 11, 2009, at 12:15 AM, Jakub Moskal wrote:

unfortunately I do need omniORB and omniORBpy, so I don't want to
uninstall them... The CPATH is not set. Do you think that temporarily
removing it, compiling gnuradio and installing it back on would do the
trick?



Hi Jakob - I'm working on a branch right now which moves  
 to , so that GNU Radio is self- 
contained w/r.t. omnithread headers and will work with omniORB  
installed elsewhere.  More soon. - MLD




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

Re: [Discuss-gnuradio] 'make check' fails on OS X 10.5 with gnuradio 3.1 release

[Jakub Moskal]

Hi Michael,

that would be great. I actually want to use CORBA along with GNU
Radio, so that would be perfect.

Thanks a lot for your help.
Jakub

On Wed, Feb 11, 2009 at 10:39 AM, Michael Dickens  wrote:
> On Feb 11, 2009, at 12:15 AM, Jakub Moskal wrote:
>>
>> unfortunately I do need omniORB and omniORBpy, so I don't want to
>> uninstall them... The CPATH is not set. Do you think that temporarily
>> removing it, compiling gnuradio and installing it back on would do the
>> trick?
>
>
> Hi Jakob - I'm working on a branch right now which moves  to
> , so that GNU Radio is self-contained w/r.t.
> omnithread headers and will work with omniORB installed elsewhere.  More
> soon. - MLD
>
>


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

Re: [Discuss-gnuradio] Usrp2 and Agere ET131x compatibility

[Matt Ettus]

Yc Park wrote:

Hi, guys

I have two questions:

- My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
  Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
(I see the chipset 'bad'
here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
that the linux and ET131 have some problems, not USRP2 and ET131)

- Granted that the compatibility issue exists, do we have any progress
on the latest source code of GR or on the USRP2 firmware?



I went out and bought a card based on this chipset so that I could 
figure out the problem.  Unfortunately, I can't even get a driver 
compiled for it, since the driver seems to not be in the mainline kernel.


Matt


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

Re: [Discuss-gnuradio] Usrp2 and Agere ET131x compatibility

[ematlis]

I downloaded it from here:

http://sourceforge.net/projects/et131x

I use dkms to auto compile; here is my dkms.conf:
-
PACKAGE_NAME="et131x"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
DEST_MODULE_LOCATION[0]="/kernel/3rdparty/$PACKAGE_NAME/"

AUTOINSTALL=yes
--

Incidentally, a motherboard with the built-in Agere card seemed to work,
but not the pciexpress card.

eric


Eric H. Matlis, Ph.D.
Assistant Research Professor
Aerospace & Mechanical Engineering Dept.
121 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355

On Wed, 11 Feb 2009, Matt Ettus wrote:


Yc Park wrote:

Hi, guys

I have two questions:

- My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
  Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
(I see the chipset 'bad'
here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
that the linux and ET131 have some problems, not USRP2 and ET131)

- Granted that the compatibility issue exists, do we have any progress
on the latest source code of GR or on the USRP2 firmware?



I went out and bought a card based on this chipset so that I could
figure out the problem.  Unfortunately, I can't even get a driver
compiled for it, since the driver seems to not be in the mainline kernel.

Matt


___
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] usrp_siggen.py underruns

[Dominik Auras]

Hi!

I am currently observing an odd behavior of usrp_siggen.py.

When I start the program as follows

./usrp_siggen.py -f 2.40G -i 16 --gaussian

there are a lot of underruns (uU). However, for all other signal 
generation options except gaussian, it works fine (i.e. const, sine, 
uniform). Just to see, I have modified usrp_siggen to enable realtime 
scheduling. It didn't make the underruns go away.

My /etc/security/limits.conf contains the line
@usrp   -   rtprio  90
as suggested by a recent post to mailing list (though I increased the 
maximum priority). libgruel realtime functions sets the priority -30 
(checked with top). CPU usage is ~ 103%.


I have observed a similar behavior with my transmitter system, if I set 
the bandwidth to 8 MHz, which should be the maximum. To me, it seems 
like the GnuRadio USRP driver can hardly keep up with this rate (it 
should be the maximum supported). Measurements without the USRP sink 
revealed that my transmitter actually sustains rates over 30 MS/s. 
Though I didn't test what rate the gaussian noise source in usrp_siggen 
achieves if connected to a nullsink.
Further, with the USRP2, my transmitter sends continuously at a 
bandwidth of 12.5 MHz, no problem. However I need the USRP1 too.


My gnuradio version is from the svn trunk, but it's not the latest one. 
Some revision above 1. If necessary, I could do a test with the 
latest revision.


The program test_usrp_standard_tx reports
xfered 1.34e+08 bytes in 4.19 seconds.  3.2e+07 bytes/sec.  cpu time = 0
0 underruns

My machine is a Core i7 940, 3 Gb RAM. I am using a fresh install of 
Ubuntu 8.10. The USRP owns his proper USB root hub, i.e. no other 
devices connected. Hence I think it is unlikely to be caused by the machine.


Best regards
Dominik


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

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Eric Blossom]

On Wed, Feb 11, 2009 at 07:35:10PM +0100, Dominik Auras wrote:
> Hi!
>
> I am currently observing an odd behavior of usrp_siggen.py.
>
> When I start the program as follows
>
> ./usrp_siggen.py -f 2.40G -i 16 --gaussian
>
> there are a lot of underruns (uU). However, for all other signal  
> generation options except gaussian, it works fine (i.e. const, sine,  
> uniform). Just to see, I have modified usrp_siggen to enable realtime  
> scheduling. It didn't make the underruns go away.
> My /etc/security/limits.conf contains the line

> @usrp   -   rtprio  90

> as suggested by a recent post to mailing list (though I increased the  
> maximum priority). libgruel realtime functions sets the priority -30  
> (checked with top). CPU usage is ~ 103%.

That won't help.  The problem is that the gaussian RNG is really slow.
You'll need to figure out how to make it faster.

Eric


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

[Discuss-gnuradio] USRP2 for my Radio Astronomy stuff

[Marcus D. Leech]

Well, I now have my first user with a USRP2.

So, what are the gotchas that are going to bite me when supporting USRP2
in code that's used to USRP1?

Setup seems a little different--only 1 TX and 1 RX channel, etc.


Here's my new setup_usrp() function:

def setup_usrp(self):
   
if (self.usrp2 == False):
if (self.dual_mode == False and self.interferometer == False):
if (self.decim > 4):
self.u =
usrp.source_c(decim_rate=self.decim,fusb_block_size=8192)
else:
self.u =
usrp.source_c(decim_rate=self.decim,fusb_block_size=8192,
fpga_filename="std_4rx_0tx.rbf")
self.u.set_mux(usrp.determine_rx_mux_value(self.u,
self.rx_subdev_spec))
# determine the daughterboard subdevice we're using
self.subdev[0] = usrp.selected_subdev(self.u,
self.rx_subdev_spec)
self.subdev[1] = self.subdev[0]
self.cardtype = self.subdev[0].dbid()
else:
self.u=usrp.source_c(decim_rate=self.decim,
nchan=2,fusb_block_size=8192)
self.subdev[0] = usrp.selected_subdev(self.u, (0, 0))
self.subdev[1] = usrp.selected_subdev(self.u, (1, 0))
self.cardtype = self.subdev[0].dbid()
self.u.set_mux(0x32103210)
c1 = self.subdev[0].name()
c2 = self.subdev[1].name()
if (c1 != c2):
print "Must have identical cardtypes for --dual_mode
or --interferometer"
sys.exit(1)
#
# Set 8-bit mode
#
   
width = 8
shift = 8
format = self.u.make_format(width, shift)
r = self.u.set_format(format)
else:
if (self.dual_mode == True or self.interferometer == True):
print "Cannot use dual_mode or interferometer with
single USRP2"
sys.exit(1)
self.u = usrp2.source_32fc(self.interface, self.mac_addr)
self.u.set_decim (self.decim)
self.cardtype = self.u.daughterboard_id()

Also, is there a way to set 8-bit mode on USRP2?   Inquiring minds want
to know.

-- 
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] USRP2 for my Radio Astronomy stuff

[Johnathan Corgan]

On Wed, Feb 11, 2009 at 11:10 AM, Marcus D. Leech  wrote:

> So, what are the gotchas that are going to bite me when supporting USRP2
> in code that's used to USRP1?
>
> Setup seems a little different--only 1 TX and 1 RX channel, etc.

Yes, it is simpler in this regard, no subdev, etc.

One significant change to consider is your sample rate plan--you now
have different ADC and DAC frequencies, so depending on what you're
doing, your integer decimation ratios may need to change.

The floating point source for the usrp1 has a range of [-32768.0
32767.0], while for the usrp2 it is automatically scaled to [-1.0
1.0].  This will affect your front end range scaling or software AGCs.

> Also, is there a way to set 8-bit mode on USRP2?

Not yet.

Johnathan


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

Re: [Discuss-gnuradio] USRP2 for my Radio Astronomy stuff

[Marcus D. Leech]

Johnathan Corgan wrote:
>
> One significant change to consider is your sample rate plan--you now
> have different ADC and DAC frequencies, so depending on what you're
> doing, your integer decimation ratios may need to change.
>   
That's not a problem.  I run at various bandwidths, depending on what
machine I'm running on, what I'm
  observing, etc.  I have a script that invokes the usrp_ra_receiver.py
code, and it can do the necessary
  calculations, etc.
> The floating point source for the usrp1 has a range of [-32768.0
> 32767.0], while for the usrp2 it is automatically scaled to [-1.0
> 1.0].  This will affect your front end range scaling or software AGCs.
>
>   
Oh.  Is that done on the host side?  And, well, why?  [no criticism
here, just a little puzzled]
>
> Not yet.
>
>
>   
Well, geez, Jonathan.   What's taking you?  :-) :-) :-)


-- 
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_siggen.py underruns

[Dominik Auras]

Hi!


That won't help.  The problem is that the gaussian RNG is really slow.
You'll need to figure out how to make it faster.
I am sorry. This was an example and I hoped that the RNG is fast enough. 
Actually, I have observed this behavior with my transmitter. As I 
described, it doesn't send with 8 MHz bandwidth on USRP1. Before we 
received the new USRP2s, I have thought that this is a problem of my 
application. Even though with a nullsink, I have measured a throughput 
in front of the nullsink of more than 30 MSamples per second.


Now with the USRP2, my transmitter is streaming continuously, sending at 
12.5 Mhz bandwidth. It keeps up with this rate. There was no change in 
the transmitter, except for using the USRP2.


Conclusion: my code can send with at least 12.5 complex MSamples per 
second (equal to 12.5 MHz bandwidth), but using USRP1, I can't send with 
8 Mhz?


Best regards
Dominik


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

Re: [Discuss-gnuradio] USRP2 for my Radio Astronomy stuff

[Johnathan Corgan]

On Wed, Feb 11, 2009 at 11:25 AM, Marcus D. Leech  wrote:

>> The floating point source for the usrp1 has a range of [-32768.0
>> 32767.0], while for the usrp2 it is automatically scaled to [-1.0
>> 1.0].  This will affect your front end range scaling or software AGCs.
>>
> Oh.  Is that done on the host side?  And, well, why?  [no criticism
> here, just a little puzzled]

Yes, on the host, as we convert from the raw wire format into the
format of the particular source or sink block chosen.

We decided to standardize the range of the sample streams into and out
of the USRP2, such that regardless of daughterboard, decim/interp
rates, etc., the maximum and minimum values in the floating point
domain would be [-1.0 1.0].  This simplifies the rest of the flowgraph
design.

We're not there yet.  On the TX side, we're compensating for variable
interpolation gain, but on the RX side, changing decimation ratios
still affects the signal range.  Neither have we worked out the
differences among daughterboards.  Right now if you TX at 1.0 with the
BasicTX or LFTX, you get the full DAC range output.

Someday we'll have predictable RF power to flowgraph value
calculations for both TX and RX (at least for the linear portion of
their ranges), subject only to manufacturing tolerances.  Then a
calibration step by the user can store a board-specific adjustment
factor in the board's EEPROM and we can automatically take this into
account.

Someday.

Johnathan


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

[Discuss-gnuradio] Analyzing FFT for multiple maxima

[Paul Mathews]

Here's a screen shot of FFT output:

http://i394.photobucket.com/albums/pp28/optoeng/2peaks.jpg

The image is typical, in that there are multiple narrow local maxima, but
the amplitude of these particular peaks is quite a bit higher than I expect
'in the field'. I'm trying to work out an efficient way to compute the
locations and relative amplitudes of these maxima. Can someone please
suggest either an algorithm and/or the most similar gnuradio application
that I can examine as candidates for this analyis? Thanks.
Paul Mathews



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

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Eric Blossom]

On Wed, Feb 11, 2009 at 08:35:56PM +0100, Dominik Auras wrote:
> Hi!
>
>> That won't help.  The problem is that the gaussian RNG is really slow.
>> You'll need to figure out how to make it faster.
>
> I am sorry. This was an example and I hoped that the RNG is fast enough.  
> Actually, I have observed this behavior with my transmitter. As I  
> described, it doesn't send with 8 MHz bandwidth on USRP1. Before we  
> received the new USRP2s, I have thought that this is a problem of my  
> application. Even though with a nullsink, I have measured a throughput  
> in front of the nullsink of more than 30 MSamples per second.
>
> Now with the USRP2, my transmitter is streaming continuously, sending at  
> 12.5 Mhz bandwidth. It keeps up with this rate. There was no change in  
> the transmitter, except for using the USRP2.
>
> Conclusion: my code can send with at least 12.5 complex MSamples per  
> second (equal to 12.5 MHz bandwidth), but using USRP1, I can't send with  
> 8 Mhz?

What kind of an EHCI controller do you have?  
We've come across some that won't support 32MB/s on transmit.

Eric


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

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Dominik Auras]

Hi!

What kind of an EHCI controller do you have?  
We've come across some that won't support 32MB/s on transmit.

http://www.asus.com/products.aspx?modelmenu=1&model=2593&l1=3&l2=179&l3=815&l4=0

Intel X58 chipset on an Asus P6 Deluxe. We are using the onboard controller.

test_usrp_standard_tx reports
xfered 1.34e+08 bytes in 4.19 seconds.  3.2e+07 bytes/sec.  cpu time = 0
0 underruns

Identical behavior on another machine, which has Athlon 64 X2 and hence 
different mainboard and chipset, definitely no Intel chipset. But I am 
not at the institute and can't tell you the controller name at the 
moment (but tomorrow, if you need it).


Dominik


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

[Discuss-gnuradio] RFX1800 Transceiver

[Chaudary Saima]

Hi everyone:
I have two questions:
1- I have one RFX1800 Transceiver daughterboard. so can I used benchmark_tx .py 
and benchmark_rx.py by using  this daughterboard.because from documentation I 
read that it is full duplexx but with some limitation.
2- Can I use signal generator to produce AM modulated signal at RF frequency 
which is acceptable to this USRP(e.g.1.8GHz)  and then by useing  "am_demod.py" 
to demodulate it.
Thanks in advance.

cheers
Saima



  Get the world's best email - http://nz.mail.yahoo.com/___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Dominik Auras]

Hi!

An additional note: using usrp_siggen.py with sine, const and uniform at 
8 MHz bandwidth actually works. It is unlikely that my EHCI controller 
does not support 32 MB/s on transmit.


Could this be a timing problem? I mean, that the data is generated very 
fast, but then the generator waits, e.g. because the buffer is full. 
Does the double buffering of the TPB scheduler work as supposed? Using 
STS scheduler with usrp_siggen didn't change anything.


Summary:
The application supports 12.5 complex MS/s (100 MB/s) if using USRP2, 
but can't sustain 8 complex MS/s with USRP1, even though usrp_siggen.py 
does support 8 MS/s with the generators sine,const and uniform on the 
USRP1 (and test_usrp_standard_tx estimates an achievable rate of 32 
MB/s). Furthermore, this behavior shows up on 2 different machines.


Do you have an idea how I could benchmark the application, e.g. to 
characterize the stream timing in front of the USRP?


Best regards
Dominik


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

[Discuss-gnuradio] Calculating Phase angle between received downconverted complex baseband samples!!

[Bishal Thapa]

Hi All,
  I am using ./benchmark_tx.py -f 2.4G to send some bytes from my own input
file, and using ./usrp_rx_cfile -f 2.4G to receive the downconverted complex
baseband samples. The modulation I am using on the sender side is dbpsk.
Then, I use
read_complex_binary.m to read the samples into the matlab. Now, I analyze
the phase angle between those samples using"angle" function of the matlab.
Shouldn't I find some burst where the angle would be something like
"0 3.14 0 3.14 0 3.14.." if the bits I sent where "0 0 1 0 1
0 1 0 1 0 1 0". I hope this makes sense. Thanks..

-B

PS: My final goal is to implement DSSS, and I am making quite a progress
thanks to all of you.
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] Analyzing FFT for multiple maxima

[John Clark]

Paul Mathews schrieb:

Here's a screen shot of FFT output:

http://i394.photobucket.com/albums/pp28/optoeng/2peaks.jpg

The image is typical, in that there are multiple narrow local maxima, but
the amplitude of these particular peaks is quite a bit higher than I expect
'in the field'. I'm trying to work out an efficient way to compute the
locations and relative amplitudes of these maxima. Can someone please
suggest either an algorithm and/or the most similar gnuradio application
that I can examine as candidates for this analyis? Thanks.
Paul Mathews


I thought Analog TV was going of the air in the US... The difficulty is 
that when the FFT is taken
from the real world, and the signal tends to the noise level, most 
'peak' detection algorithms fail,

well, have lots of noise in the 'accept' condition...

So, long term averaging, and 'knowing' that a peak would appear at 
offset x from the right or

left side of the spectrum will be more likely to succeed.

John Clark.




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

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Eric Blossom]

On Wed, Feb 11, 2009 at 10:26:25PM +0100, Dominik Auras wrote:
> Hi!
>
> An additional note: using usrp_siggen.py with sine, const and uniform at  
> 8 MHz bandwidth actually works. It is unlikely that my EHCI controller  
> does not support 32 MB/s on transmit.

OK.

> Could this be a timing problem? I mean, that the data is generated very  
> fast, but then the generator waits, e.g. because the buffer is full.  
> Does the double buffering of the TPB scheduler work as supposed? Using  
> STS scheduler with usrp_siggen didn't change anything.

Yes. Double buffering works.

> Summary:
> The application supports 12.5 complex MS/s (100 MB/s) if using USRP2,  

Uhh, 12.5 MS/s is 50MB/s (16-bit I&Q across the wire).

> but can't sustain 8 complex MS/s with USRP1, even though usrp_siggen.py  
> does support 8 MS/s with the generators sine,const and uniform on the  
> USRP1 (and test_usrp_standard_tx estimates an achievable rate of 32  
> MB/s). Furthermore, this behavior shows up on 2 different machines.

> Do you have an idea how I could benchmark the application, e.g. to  
> characterize the stream timing in front of the USRP?

Yes, there are lots of ways to do this.  In this particular case,
you're going to want to keep track of the worst case and average run
times. 

Are you really trying to use the Gaussian PRNG?  If so you'll have to
fix it.  If you look at the code for it, you'll see that it samples a
distribution until it gets something it likes.  The worst case time
can be huge.  The difference between the USRP1 and the USRP2 is the
amount of buffering available in the Tx path in the kernel and on the
board.

If you're not using the Gaussian PRNG, I suggest that you stop worrying
about it.  Virtually all of the signal processing algs we run are
designed so that there's not much difference between the average and
worst cases.

Eric


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

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Frank Brickle]

On Wed, Feb 11, 2009 at 6:03 PM, Eric Blossom  wrote:


> Are you really trying to use the Gaussian PRNG?  If so you'll have to
> fix it.  If you look at the code for it, you'll see that it samples a
> distribution until it gets something it likes.


A classical reference for fast generation of random numbers under various
distributions is

Lorrain, D. 1980. *"A Panoply of Stochastic 'Cannons'."* Computer Music
Journal 4(1)

The common shortcut to Gaussian random sequences is to sum some number of
uniform variates, usually 12, for each Gaussian output.

Frank


-- 
When small birds sighed, she would sigh back at them. -- Theodore Roethke
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio

Re: [Discuss-gnuradio] usrp_siggen.py underruns

[Eric Blossom]

On Wed, Feb 11, 2009 at 06:28:16PM -0500, Frank Brickle wrote:
> 
> A classical reference for fast generation of random numbers under various
> distributions is
> 
> Lorrain, D. 1980. *"A Panoply of Stochastic 'Cannons'."* Computer Music
> Journal 4(1)
> 
> The common shortcut to Gaussian random sequences is to sum some number of
> uniform variates, usually 12, for each Gaussian output.
> 
> Frank

Thanks, Frank!

Eric


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

Re: [Discuss-gnuradio] Usrp2 and Agere ET131x compatibility

[Matt Ettus]

OK, we got the driver to compile, and spent some time trying to get the 
card to talk to the USRP2.  If you try enough times, it sort of runs, 
but with a lot of noise.  It has the same behavior when running through 
an ethernet switch.  It turns out that the card and/or driver has some 
weird sort of data corruption which puts errors in nearly every received 
packet.  We also got a lot of syslog messages which were warnings from 
the driver.


When I tried to connect the card to my router and do normal TCP/IP over 
it, it can't even get an IP address from DHCP successfully.


Basically, I think that the kernel drivers are simply not working, so 
there's no hope of getting these cards to connect to a USRP2 properly if 
they can't connect to anything else either.  The fact that this driver 
has not been included in the main line kernel even though the chipset 
has been out for a long time (its no longer even owned by Agere -- it 
was bought by LSI) tells me that there are much deeper problems.


There are much better supported interfaces available.  If you are using 
a laptop with this chip in it, I would suggest buying an ExpressCard 
(next generation of PCMCIA) GigE card with a Marvell chip in it.  They 
should be less than $50.


Matt


emat...@nd.edu wrote:

I downloaded it from here:

http://sourceforge.net/projects/et131x

I use dkms to auto compile; here is my dkms.conf:
-
PACKAGE_NAME="et131x"

BUILT_MODULE_NAME[0]="$PACKAGE_NAME"
DEST_MODULE_LOCATION[0]="/kernel/3rdparty/$PACKAGE_NAME/"

AUTOINSTALL=yes
--

Incidentally, a motherboard with the built-in Agere card seemed to work,
but not the pciexpress card.

eric


Eric H. Matlis, Ph.D.
Assistant Research Professor
Aerospace & Mechanical Engineering Dept.
121 Hessert Center for Aerospace Research
University of Notre Dame
Notre Dame, IN 46556-5684
Phone: (574) 631-6054
Fax:   (574) 631-8355

On Wed, 11 Feb 2009, Matt Ettus wrote:


Yc Park wrote:

Hi, guys

I have two questions:

- My laptop has AgereET131x chipset but it works perfect on Ubuntu8.10.
  Then, wonder why I fail to find USRP2 by the 'find_usrps' command?
(I see the chipset 'bad'
here(http://gnuradio.org/trac/wiki/USRP2GigEReports), but it looks like
that the linux and ET131 have some problems, not USRP2 and ET131)

- Granted that the compatibility issue exists, do we have any progress
on the latest source code of GR or on the USRP2 firmware?



I went out and bought a card based on this chipset so that I could
figure out the problem.  Unfortunately, I can't even get a driver
compiled for it, since the driver seems to not be in the mainline kernel.

Matt


___
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] Analyzing FFT for multiple maxima

[Paul Mathews]

Signal has nothing to do with TV.

Paul Mathews schrieb:
> Here's a screen shot of FFT output:
>
> http://i394.photobucket.com/albums/pp28/optoeng/2peaks.jpg
>
> The image is typical, in that there are multiple narrow local maxima, 
> but the amplitude of these particular peaks is quite a bit higher than 
> I expect 'in the field'. I'm trying to work out an efficient way to 
> compute the locations and relative amplitudes of these maxima. Can 
> someone please suggest either an algorithm and/or the most similar 
> gnuradio application that I can examine as candidates for this 
> analyis? Thanks. Paul Mathews

I thought Analog TV was going of the air in the US... The difficulty is 
that when the FFT is taken
from the real world, and the signal tends to the noise level, most 
'peak' detection algorithms fail,
well, have lots of noise in the 'accept' condition...

So, long term averaging, and 'knowing' that a peak would appear at 
offset x from the right or
left side of the spectrum will be more likely to succeed.

John Clark.








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

Re: [Discuss-gnuradio] Overrun when there shouldn't be

[Chris Stankevitz]

Juha Vierinen wrote:
> usrp_standard_rx* rx = usrp_standard_rx::make(UsrpNumber,
> DecimRate,2,-1,0,4096,4096);


Using gnuradio 3.1.3 and applying the above change plus the
gr_enable_realtime_scheduling(); change fixed my problem.  I should try
just making one of the two changes too to see which one does the trick.

Thanks for your help!

Chris


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