Some new 802.15.4 stuff

Bastian_B · April 15, 2013, 2:35pm

Hi all,

I played a bit around with the 802.15.4 blocks [1]. Maybe someone is
interested.

The changes are:

It has a transceiver flow graph. (That was really easy with the new
PDU to tagged stream block)
annotate LQI value in dict of PDUs
CRC check
Wireshark Connector. You can write received packets in a pcap file,
that can be read by Wireshark, which has 802.15.4 dissectors.
and the coolest thing: the whole encoding is now done with standard
GNU Radio blocks. This includes pulse shaping and the byte to chunk to
chip to symbol mapping. It’s really cool what you can do with plain GNU
Radio.

I tested interoperability it with TelosB motes. I guess it compiles only
on Linux due to the gettimeofday(?) call.
Maybe I messed up my installation as I tried the next branch and didn’t
uninstall it cleanly. Now some block names are appended with ‘(old)’. I
hope the flow graphs work nevertheless.

Have fun,
Bastian

[1] GitHub - bastibl/gr-ieee802-15-4: IEEE 802.15.4 ZigBee Transceiver

–
Dipl.-Inform. Bastian B.
Institute of Computer Science
University of Innsbruck, Austria
Phone: +43 512 507-53288 / Fax: -53079
http://ccs.uibk.ac.at/~bloessl/

Bastian_B · April 15, 2013, 2:44pm

On Mon, Apr 15, 2013 at 02:34:35PM +0200, Bastian B. wrote:

and the coolest thing: the whole encoding is now done with
standard GNU Radio blocks. This includes pulse shaping and the byte
to chunk to chip to symbol mapping. It’s really cool what you can do
with plain GNU Radio.

Hi Bastian,

haven’t tested it yet, but just want to say that this is really awesome
work you guys are doing!

Cheers,
MB

–
Karlsruhe Institute of Technology (KIT)
Communications Engineering Lab (CEL)

Dipl.-Ing. Martin B.
Research Associate

Kaiserstraße 12
Building 05.01
76131 Karlsruhe

Phone: +49 721 608-43790
Fax: +49 721 608-46071
www.cel.kit.edu

KIT – University of the State of Baden-Württemberg and
National Laboratory of the Helmholtz Association

Bastian_B · April 15, 2013, 3:38pm

On Mon, Apr 15, 2013 at 8:34 AM, Bastian B.
<[email protected]

wrote:

Wireshark Connector. You can write received packets in a pcap file, that
can be read by Wireshark, which has 802.15.4 dissectors.

and the coolest thing: the whole encoding is now done with standard GNU
Radio blocks. This includes pulse shaping and the byte to chunk to chip to
symbol mapping. It’s really cool what you can do with plain GNU Radio.

I echo what Martin said - this is spectacular work. In fact, I think
this
would be great to have as part of the Signal Processing discussion page
on
the wiki:

http://gnuradio.org/redmine/projects/gnuradio/wiki/SignalProcessing

I think it would be great for the community to get a rundown of the
entire
standard itself, modulation/demodulation within GNU Radio, how you
handled
frequency/sampling offsets, etc.

I know it’s a lot of work, so if you wanted some help making the sub
pages
or getting the information up on the wiki, I’d be glad to take a look
over
the source if you provide some input on where to start and your general
approaches.

[1]
https://github.com/bastibl/gr-**ieee802-15-4 https://github.com/bastibl/gr-ieee802-15-4

Brian

Bastian_B · April 15, 2013, 3:56pm

On Mon, Apr 15, 2013 at 8:34 AM, Bastian B.
[email protected] wrote:

Wireshark Connector. You can write received packets in a pcap file, that
can be read by Wireshark, which has 802.15.4 dissectors.

and the coolest thing: the whole encoding is now done with standard GNU
Radio blocks. This includes pulse shaping and the byte to chunk to chip to
symbol mapping. It’s really cool what you can do with plain GNU Radio.

I tested interoperability it with TelosB motes. I guess it compiles only on
Linux due to the gettimeofday(?) call.
Maybe I messed up my installation as I tried the next branch and didn’t
uninstall it cleanly. Now some block names are appended with ‘(old)’. I hope
the flow graphs work nevertheless.

Hi Bastian,

First, great work!

So can you point out where that gettimeofday call is being made? We
should be dealing with that situation in cmake, so if something’s
going wrong, let us know.

And the ‘(old)’ block were recently discussed in a mailing list post
from a couple of weeks ago. This is just us telling you that these are
the old-style blocks in 3.6. They will still work for the time being,
but if you upgrade to 3.7, they will have disappeared. The (old)
indication is so that you can switch them out with the new blocks that
are functionally equivalent but now in the 3.7 style so they can be
future compatible when updating to 3.7.

Hope this helps,
Tom

Bastian_B · April 15, 2013, 3:43pm

On 04/15/2013 02:42 PM, Martin B. (CEL) wrote:

Hi Bastian,

haven’t tested it yet, but just want to say that this is really awesome
work you guys are doing!

Thanks Martin!

We give a sensor networks class where students program TelosB motes.
With the sensor blocks I want to setup a demo and hopefully get some
students interested in lower layer stuff (we are computer
scientists…).

If someone has an idea for a cool demo please let me know

Best,
Bastian

Bastian_B · April 15, 2013, 4:22pm

Hi Tom,

thanks for your response!

On 04/15/2013 03:55 PM, Tom R. wrote:

So can you point out where that gettimeofday call is being made? We
should be dealing with that situation in cmake, so if something’s
going wrong, let us know.
It’s not a problem of GNU Radio. I use gettimeofday to time stamp the
received packets for the pcap trace file. I guess I should search for a
better function. I will have a look at the UHD blocks.

And the ‘(old)’ block were recently discussed in a mailing list post
from a couple of weeks ago. This is just us telling you that these are
the old-style blocks in 3.6. They will still work for the time being,
but if you upgrade to 3.7, they will have disappeared. The (old)
indication is so that you can switch them out with the new blocks that
are functionally equivalent but now in the 3.7 style so they can be
future compatible when updating to 3.7.
I was just not sure what happens when I upload a flow graph where (at
least locally) some blocks are marked ‘(old)’ and someone with 3.6.4
tries to run them. But it looks like it should work, as at least in the
.grc files there is no ‘old’.

Best,
Bastian

Bastian_B · April 15, 2013, 4:54pm

On Mon, Apr 15, 2013 at 10:21 AM, Bastian B.
[email protected] wrote:

It’s not a problem of GNU Radio. I use gettimeofday to time stamp the
received packets for the pcap trace file. I guess I should search for a
better function. I will have a look at the UHD blocks.

Ok, good to know. Yeah, there are ways to handle that cross-platform.

them. But it looks like it should work, as at least in the .grc files there
is no ‘old’.

Best,
Bastian

Yeah, you’ll be fine. The .grc files only keep track of the key tag of
the XML code that defines the block in GRC; that’s translated in GRC
to the block’s name tag, which is where the (old) string is added.

Tom

Bastian_B · April 16, 2013, 11:26am

Hi Bastian,

I am newbie to USRP and Gnuradio. I did make and make install of your
project. But when I opened the rx.grc, I got some errors. Could you
please
take a look what is the cause for that?

Thanks in advance.

<<< Welcome to GNU Radio Companion 3.6.4.1 >>>

Loading: “/home/pdv/work/usrp/gr-ieee802-15-4/examples/rx.grc”

Error: Block key “ieee802_15_4_mac_deframer” not found in Platform -
grc(GNU Radio Companion)
Error: Block key “ieee802_15_4_rime_deframer” not found in Platform -
grc(GNU Radio Companion)
Error: Block key “ieee802_15_4_packet_sink” not found in Platform -
grc(GNU Radio Companion)
Error: Block key “blocks_file_sink” not found in Platform - grc(GNU
Radio Companion)
Error: Block key “ieee802_15_4_wireshark_connector” not found in
Platform - grc(GNU Radio Companion)
Error: Connection between digital_clock_recovery_mm_xx_0(0) and
ieee802_15_4_packet_sink_0(0) could not be made.
sink block id “ieee802_15_4_packet_sink_0” not in block ids
Error: Connection between ieee802_15_4_packet_sink_0(out) and
ieee802_15_4_mac_deframer_0(pdu in) could not be made.
source block id “ieee802_15_4_packet_sink_0” not in block ids
Error: Connection between ieee802_15_4_mac_deframer_0(pdu out) and
ieee802_15_4_rime_deframer_0(pdu in) could not be made.
source block id “ieee802_15_4_mac_deframer_0” not in block ids
Error: Connection between ieee802_15_4_rime_deframer_0(pdu out) and
gr_socket_pdu_0(pdus) could not be made.
source block id “ieee802_15_4_rime_deframer_0” not in block ids
Error: Connection between ieee802_15_4_packet_sink_0(out) and
ieee802_15_4_wireshark_connector_0(in) could not be made.
source block id “ieee802_15_4_packet_sink_0” not in block ids
Error: Connection between ieee802_15_4_wireshark_connector_0(0) and
blocks_file_sink_0(0) could not be made.
source block id “ieee802_15_4_wireshark_connector_0” not in block
ids
Done

Showing: “/home/pdv/work/usrp/gr-ieee802-15-4/examples/rx.grc”

Dingwen

2013/4/15 Bastian B. [email protected]

Bastian_B · April 16, 2013, 1:48pm

Hello Dingwen,

On 04/16/2013 11:24 AM, Dingwen Yuan wrote:

<<< Welcome to GNU Radio Companion 3.6.4.1 >>>

Loading: “/home/pdv/work/usrp/gr-ieee802-15-4/examples/rx.grc”

Error: Block key “ieee802_15_4_mac_deframer” not found in Platform

grc(GNU Radio Companion)

Error: Block key “ieee802_15_4_rime_deframer” not found in Platform

grc(GNU Radio Companion)

Error: Block key “ieee802_15_4_packet_sink” not found in Platform -

I tried to reproduce the error, but without success. I searched in my
local installation path and assured that I really uninstalled
everything. Then, I did ‘git clean -xdf’ and ‘git reset --hard’ in the
git repo and installed everything again.

I guess the problem is that GRC can’t find the XML files.
Where do you have your other GRC blocks installed? Was the installation
really successful?

I’m afraid you are the first tester So maybe its a CMake bug and the
files are not placed where they are supposed to be placed.

Best,
Bastian

Bastian_B · April 16, 2013, 2:20pm

Hi Bastian,

I am using Ubuntu 12.04. I first try to compile the gnuradio with
build-gnuradio script. But the system crashed after starting making
gnuradio.

So later I use the precompiled gnuradio and uhd directly from ettus. It
seems that the gnuradio is install in the folder
/usr/local/lib/python2.7/dist-packages.

I did compile your gr-ieee802-15-4 and everything works all right. After
sudo make install, it is installed in /usr/share/gnuradio. So I think
the
problem is due to the path setting. I will try to set the path properly.

Thanks!

Dingwen

2013/4/16 Bastian B. [email protected]

Bastian_B · April 17, 2013, 10:39am

Hi Bastian,

Now the grc examples work with no error. The crash of the system during
gnuradio compilation is due to the boost version (the version 1.46
causes
the problem). After I switched to version 1.48, the compilation of the
current gnuradio from the git repository works all right.

Regards,

Dingwen

2013/4/16 Bastian B. [email protected]

Bastian_B · April 16, 2013, 12:49pm

Hey Brian,

first, thank you for your comment.

On 04/15/2013 03:37 PM, Brian P. wrote:

I think it would be great for the community to get a rundown of the
entire standard itself, modulation/demodulation within GNU Radio, how
you handled frequency/sampling offsets, etc.

I thought about that and as it is all-supervisors-are-at-infocom-week, I
tried something…

I made an IPython notebook, and reimplemented the transmitter iterative
(i.e. non-stream) in python in the browser. I annotated it with text and
plots and pictures.
It leads the reader step by step through the whole encoding process
until we are at complex baseband representation. Than it writes the
samples into a file. (The whole stuff happens in the browser, or is
controlled through the browser).

I included a script, that creates a Linux pipe and starts the file_tx
program, which is part of the UHD library. So the samples are really
transmitted.
I can receive the signal that I send in the browser with my TelosB mote.

It’s somehow funny and you can look at the signal in every stage of the
encoding process.

It’s a bit hard to describe and maybe some don’t have ipython installed.
So I made a really, really ugly video [1], but maybe it helps to see
what going on.

You can have a look at the notebook here [2]. It is a Gist rendered by
the notebook viewer. You can download the Gist [3] and run it
interactively in your browser.

The whole stuff is not prove read, contains a lot of errors, is just 4
fun and should just show the idea.

Best,
Bastian

[1] - YouTube
[2] http://nbviewer.ipython.org/5394322
[3] https://gist.github.com/bastibl/5394322

–
Dipl.-Inform. Bastian B.
Institute of Computer Science
University of Innsbruck, Austria
Phone: +43 512 507-53288 / Fax: -53079
http://ccs.uibk.ac.at/~bloessl/

Bastian_B · April 19, 2013, 5:17pm

Hi Bastian,

I played a bit with your examples. The tx all works perfect. But for rx,
sometimes I get the “hello gnuradio” messages, sometimes not. What
daughterboard are you using, I use the RFX2400.

Regards,

Dingwen

2013/4/17 Bastian B. [email protected]

Bastian_B · April 19, 2013, 6:41pm

Hi Dingwen,

On 04/19/2013 05:16 PM, Dingwen Yuan wrote:

I played a bit with your examples. The tx all works perfect. But for rx,
sometimes I get the “hello gnuradio” messages, sometimes not. What
daughterboard are you using, I use the RFX2400.

Cool, that it compiles and at least does something

I use a XCVR2450 with an N210. Up until now I did not do any real
performance measurements, but with the PCAP output it sould be easy to
quantify your losses. You can just open the PCAP file, with Wireshark
for example, and immediately see how many packets you received. Note
that currently all packets are written to PCAP (i.e. CRC is not
checked).

If you think its a bug in the code and let’s say the packet format is
wrong and thus every n-th packet is wrongly encoded, then you can check
it with the loopback flow graph.

Some other stuff you could try:

more gain
less gain
other channel (if you have a lot of WiFi traffic there)
are your USRPs close to each other? Try moving them some meters apart
from each other.

Just out of curiosity, did you try the transceiver? Is it working for
you?

Hope it helps,
Bastian

Bastian_B · April 17, 2013, 11:07am

Hi Dingwen,

On 04/17/2013 10:38 AM, Dingwen Yuan wrote:

Now the grc examples work with no error. The crash of the system during
gnuradio compilation is due to the boost version (the version 1.46
causes the problem). After I switched to version 1.48, the compilation
of the current gnuradio from the git repository works all right.

Great that it works now! …and thanks for reporting the problem.

Best,
Bastian

Bastian_B · April 22, 2013, 10:14am

Hi Bastian,

Thanks for your reply.

I think the loopback works. I get some logs in the gnuradio-companion
likes
this:
Hello World!
ut
Hello World!
ut
Hello World!
ut
Hello World!
ut

Some other stuff you could try:

more gain

less gain

other channel (if you have a lot of WiFi traffic there)

are your USRPs close to each other? Try moving them some meters apart
from each other.

Changing gain and the direction of antenna really improves the packet
reception rate. I have just one USRP, therefore I tried the
communication
between USRP and your contiki code.
The log I got always look like a number of Os folowing by Hello Gun
Radio,
like OOOOOOOOOHello Gnu Radio. What does the O means?

Just out of curiosity, did you try the transceiver? Is it working for you?

I tried transceiver, it doesn’t work. But tx works perfectly.
BTW, what have you changed in your code in comparison with the original
UCLA Zigbee.

Regards,

Dingwen

Bastian_B · April 23, 2013, 9:37am

Hello Dingwen,

On 04/22/2013 10:13 AM, Dingwen Yuan wrote:

I think the loopback works. I get some logs in the gnuradio-companion
likes this:
Hello World!
ut

I casted the not-0-terminated buffer to char as debug output
Should be fixed now.

Changing gain and the direction of antenna really improves the packet
reception rate. I have just one USRP, therefore I tried the
communication between USRP and your contiki code.
The log I got always look like a number of Os folowing by Hello Gun
Radio, like OOOOOOOOOHello Gnu Radio. What does the O means?

OOOO means that the PC can’t keep up with the sampling rate and thus,
experiences 'O’verruns. That was because I set the sampling rate way
higher then needed. I just pushed the flow graphs with a rate of 4Msps.

You can play around with that, you just have to set the ‘Omega’ of the
‘Clock Recovery MM’ block accordingly (samp_rate / Omega != 2Msps).

Just out of curiosity, did you try the transceiver? Is it working
for you?
I tried transceiver, it doesn’t work. But tx works perfectly.

Maybe because you are using a full-duplex daughterboard while I use a
half-duplex one. Would be great if you try to set the antenna of the
USRP source and sink blocks manually to the same value. Then it should
operate in half-duplex mode. (I think this is possible with your board,
check ‘uhd_usrp_probe’ to see a list of options)

BTW, what have you changed in your code in comparison with the original
UCLA Zigbee.
The receiver structure, the parameters of the flow graph (clock
recovery…), and the ‘packet_sink’ block is from the UCLA
implementation. This is where all decoding happens.
It is based on this implementation, so you can see the changes in git.

I just pushed the changes to github.

Hope it helps!
Bastian