Hey All,
I fixed the code in the pkt.py file so that DSSS with the barker code
now
works. The main issue was the length of the barker interpolation filter
was
way too short (like 8). I changed it so that it is now sample per baud
*
11. Additionally the barker sequence needs to be time reversed on the
receive side so that the correct match filter is formed. Otherwise the
nice
autocorrelation properties of barker will go away.
I am only able to test it using the test script with a channel filter
and
gaussian noise and so far it has been a success there with both 1 and 2
Mbps
modulation rates. Can someone test with USRP2? Also the BER seems to
be
much better as compared to just the RRC filter. Hopefully this will
make
TX/RX much more robust.
The code is uploaded to the CGRAN svn under the branch/usrp2_version in
the
bbn project directory.
Cheers,
Colby B.
On Sun, Jun 14, 2009 at 07:45:32PM -0700, Colby B. wrote:
gaussian noise and so far it has been a success there with both 1 and 2 Mbps
modulation rates. Can someone test with USRP2? Also the BER seems to be
much better as compared to just the RRC filter. Hopefully this will make
TX/RX much more robust.
The code is uploaded to the CGRAN svn under the branch/usrp2_version in the
bbn project directory.
Cheers,
Colby B.
Thanks, Colby!
If I get some free time (probably next week), I’ll try it out between my
USRP2’s. Thanks!
Doug
I think I fixed the one hier block error.
Also I set the default int/dec rate to 4 and spb to 25. This should
give 1
MBaud/sec after despreading. Maybe this will work with 802.11 chipset?
Im
not sure if the sinc shaping has the right bandwidth (barker code
smoothing)
after these changes.
–Colby
On Mon, Jun 15, 2009 at 10:48 AM, Douglas G. <
Hey Ulrika,
I think I fixed that bug. I couldn’t really test the rx/tx files
because I
do not have a USRP2 anymore. I think I made that change that will fix
it. .
. .I think it has something to do with how the parameters are set in
send_pkt. Feel free to play with it if it doesnt work.
The rx file should be able to receive from the AP. I’ll look at it
later
tonight and make sure that file is functioning correctly. The
decimation/spb rate for the receive filter might need fine tuning in
order
to receive packets from an AP.
Regarding this error:
[alot of:] File "/gnu-radio-path/lib/python2.
5/site-packages/gnuradio/gr/hier_block2.py", line 48, in getattr
return getattr(self._hb, name)
RuntimeError: maximum recursion depth exceeded
I get this a lot too, but not everytime. I’ve notice that this
sometimes
comes up if I have a poorly written line of python in the init blocks.
However, it only appears once and a while for me. I am using GNURadio
version 10689.
Eric, do you know what causes this bug or have you seen/heard of it
before?
Regards,
Colby B.
On Mon, Jun 15, 2009 at 08:41:46AM -0700, Colby B. wrote:
I get this a lot too, but not everytime. I’ve notice that this sometimes
comes up if I have a poorly written line of python in the init blocks.
However, it only appears once and a while for me. I am using GNURadio
version 10689.
Eric, do you know what causes this bug or have you seen/heard of it before?
We fixed it for the 3.2 release (better error message). The real
problem is that the user is failing to call
gr.hier_block2.init(self)
in the init of classes that they derive from gr.hier_block2.
Eric