2010年11月28日星期日

install bbn and gr3.2.2 in ubuntu10.04

building bbn needs omnithread.h. However, this file is obsolete in gr3.3.
I'd better use gr3.2.2, as guanbo and many discussions suggest.

I download gr3.2.2 from http://ftp.gnu.org/gnu/gnuradio/
first, building 3.2.2 ends with error.

libtool: Version mismatch error.  This is libtool 2.2.6b Debian-2.2.6b-2ubuntu1, but the
libtool: definition of this LT_INIT comes from libtool 2.2.6.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.6b Debian-2.2.6b-2ubuntu1
libtool: and run autoconf again.
make[4]: *** [realtime.lo] 错误 63

I try to understand autoconf. I delete aclocal.m4 and run ./bootstrap again.
This time, it passes the "mismatch" error, but ends with another error.
this error is also found at http://www.ruby-forum.com/topic/213656
I delete all the ./gnuradio-3.2.2/gr-qtgui/src/lib/*moc.cc file and run ./configure and make again.
 finally, gr3.2.2 is built successfully in ubuntu10.04

Then, I try to build bbn. when building bbn_tap.cc, it ends with some error. It indicates some functions missed, including "memset", "stderr", ...

Man command will indicate what header files I should include, such as "man memset". Thus, I add these two lines to bbn_tap.h.
#include "stdio.h"
#include "string.h"
bbn building is OK too.
now let me solve the hier_block2 issue.

With a little patience, I transfer the hier_block to hier_block2. Now, I have better understanding of hier_block2.

sudo ./bbn_80211b_rx.py -d 8 -f 2472e6 -b -p -v -R A:0
I read the README file in bbn package.
this command will start receiver. I configure my wireless router to work in 802.11b only mode with 1000ms beacon interval.

and it prints
PKT: len=10, rssi=-13, src=UNKNOWN, time=61218432, rate=1 Mbps
PKT: len=26, rssi=-39, src=00:27:13:e4:9C:C5, time=61219032, rate=1 Mbps
PKT: len=10, rssi=-15, src=UNKNOWN, time=61219464, rate=1 Mbps
PKT: len=129, rssi=-43, src=94:0c:6d:56:B7:8A, time=61433040, rate=1 Mbps
PKT: len=141, rssi=-13, src=74:ea:3a:b9:7E:6A, time=61475656, rate=1 Mbps
PKT: len=129, rssi=-42, src=94:0c:6d:56:B7:8A, time=61944976, rate=1 Mbps
...

2010年11月25日星期四

grub trouble

this morning, I did an upgrade of ubuntu. During upgrading, I clicked a "grub xx hard disk...". Then, my computer is stuck after restart, directly entering "grub rescue“。

solved in this way:
create an ubuntu startup disk

start from "usb hard disk"
#sudo apt-get install lilo
#sudo lilo -M /dev/sda mbr
it seems grub and lilo are contradictory.

2010年11月23日星期二

usage of scrambler_bb in gnuradio

from this page
http://gnuradio.org/doc/doxygen/gri__lfsr_8h-source.html
I know

00029 /*!
00030  * \brief Fibonacci Linear Feedback Shift Register using specified polynomial mask
00031  * \ingroup misc
00032  *
00033  * Generates a maximal length pseudo-random sequence of length 2^degree-1
00034  * 
00035  * Constructor: gri_lfsr(int mask, int seed, int reg_len);
00036  *  
00037  *      mask - polynomial coefficients representing the locations
00038  *             of feedback taps from a shift register which are xor'ed
00039  *             together to form the new high order bit.
00040  *
00041  *             Some common masks might be:
00042  *              x^4 + x^3 + x^0 = 0x19
00043  *              x^5 + x^3 + x^0 = 0x29
00044  *              x^6 + x^5 + x^0 = 0x61
00045  *
00046  *      seed - the initialization vector placed into the register
00047  *             durring initialization.   Low order bit corresponds
00048  *             to x^0 coefficient -- the first to be shifted as output.
00049  *
00050  *   reg_len - specifies the length of the feedback shift register 
00051  *             to be used.   Durring each iteration, the register
00052  *             is rightshifted one and the new bit is placed in bit reg_len.
00053  *             reg_len should generally be at least order(mask) + 1
00054  *
00055  *
00056  * see http://en.wikipedia.org/wiki/Linear_feedback_shift_register 
00057  * for more explanation.
 
However, in this page, a different view is introduced. 
http://www.mail-archive.com/patch-gnuradio@gnu.org/msg00180.html
For Gal', one only has to use the binary representation (e.g. x^4+x^3+1 => 
2^4+2^3+1 = 0x19) and shift it one bit left ( 0x13>>1 = 0x9).
For Fib, the following has to be done: Reverse the binary representation (0x19 
= 11001 => 10011), strip the highest bit. The resulting parameters for the 
lfsr are (mask=0x3, len=(degree-1)=3). (Yes, this is somewhat contrary to the 
comments in gri_lfsr.h. IMHO, the documentation is wrong/misleading. Most 
noteworthy, the len paramater is not the register len, but the bitshift).
- Internal state of the two types differs. For self synchronizing 
applications, this is a non issue, for synchronous operation, either use the 
same type, or calculate the corresponding seed values for both types.

2010年11月21日星期日

Can I drive my USRP1 at 32M sample/s?

conf:
USRP1 GR3.3 RFX2400 ubuntu 10.04 kernel 2.6.32.25
Manual says the DAC rate of USRP1 is 128MHz, the interpolation rate should vary from 4 to 512, being a multiple of 4.
However, when I try to u.set_interp(4), it fails. u.set_interp(16) is OK.

I find a discussion about interpolation.
http://www.ruby-forum.com/topic/64788
'''
The USRP DACs sample at 128 MS/s.  You can't send samples that fast over
USB, so you send them at a lower rate.  When they get to the USRP, they
are interpolated to 128 MS/s.  If you have an interpolation rate of 16
(the minimum), you need to send 8 MS/S over the bus (16 * 8e6 = 128e6).
In essence, the USRP inserts 15 zeros between every sample you send it,
and then filters it so that the intermediate samples form a smooth
curve.
'''

In my experiment, I try to transmit 802.11 DSSS 1Mbps signal. The chip rate is 11Mbps. Supposing the perfect sampling is every 8 samples per chip, I need 88M sampling rate. Nevertheless, USRP1 only permit me to input a signal with 8M sampling rate.

I suppose DSSS is very robust, even at 8M sampling rate. If perfect sampling rate is 88M, there are 88 samples to present 1 bit. Now, the sampling rate is 8M, so I only extract 1 per 11samples. I still get a distorted sample sequency, with 8 samples to present a bit. Can this signal be decoded?

this table from http://gnuradio.org/redmine/wiki/1/USRP2GenFAQ, also tells that the RF bandwidth of USRP1 is only 8MHz.


# about bbn code
the receiver code of bbn 802.11b is OK; but the transmitter part is said to be not working.
In my environment, it can not build.
gnuradio-discuss has found that problem.
http://lists.gnu.org/archive/html/discuss-gnuradio/2010-05/msg00315.html
"
Douglas Geiger-2 wrote:
>
>  You probably want to take a look at the usrp2_version branch to see
> how to get the transmit code working with the hier_block2 API, and
> then modify it to work with the USRP1. Two things: you cannot transmit
> the 802.11b waveform through the USRP1 (you don't have enough
> bandwidth
- in the original code base I believe they simply skipped
> the DSSS step, and transmitted the pulse-shaped DPSK-modulated
> signal), also I believe the usrp2_version branch transmit code fixed
> some of the bugs in the original transmit code (i.e. using a USRP2,
> the transmit code could send a standard-compliant waveform).
>  Doug
"
PS:
uU = USRP underrun
uO = USRP overrun
aU = audio underrun
aO = audio overun

a discussion about interpolation rate
http://www.ruby-forum.com/topic/91092

2010年11月12日星期五

useful GNU radio links

Ettus Research
GNU Radio
experiment notes
Josh knows
guanbo's blog
The Comprehensive GNU Radio Achive Network
        ftw80211ofdm
        bbn_80211 branch
discuss-gnuradio archives
an online USRP document

WiFi protocol analyzer
Normally, general driver only provide a fake ethernet packet to host, so wireshark can not give PHY and MAC information of WiFi. Wireshark official site tells that which WiFi chips and drivers are known to support raw WiFi info. Atheros is a good choice. With a PCMCIA outlook, always supported by Ubuntu, Atheros WiFi chips can provide the raw PHY and MAC info.

manual
GNU radio has two popular manuals. One is doxygen doc telling C++ libraries; the other is "Simple-Gnuradio-User-Manual-v1.0" telling Python interface.