Hello everyone,
I am very fresh in the field of SDRs and encounter some problems in
the implementation. But some basic information first.
I am trying to communicate between gnuradio (USRP) and 802.15.4 sensor
nodes, as it has been done before (see Thomas S. @ UCLA). Because
the hardware has evolved since then, I am using USRP N210s as the
interface to the computer. The N210s are equipped with XCVR2450
daugtherboards. I am using basically the ucla_zigbee_phy
implementation and found an existing adaptation to the UHD driver
online (Master Thesis by Kresimir Dabcevic).
Now to the problem. After some minor changes in the test codes (see
attachments), I can communicate between two N210s at 2.475 GHz.
Problem 1: When changing the center frequency on both Tx and Rx,
communication does not work any longer. Even a 5 MHz shift does the
deal.
Problem 2: Packets send from a sensor node are not received. The
packets are sent from TinyOS. At the N210 receiver I check whether I
find a SFD in the stream, but this does not happen (sending 1/sec).
When increasing the transmission rate to 1/10msec, I occasionally
detect a SFD. I have tried both with CC2420 and RF230 transceivers
communicating at channel 25 (2.475 GHz).
I checked the received spectrum for both USRP tx and node tx with a
simple FFT application. The result is attached as well. For this test
I let the transmitter send every 10msec. Also here I have the feeling
that
the node signal is only processed occasionally.
I played a bit around with sample rates. When increasing the sample
rate (before 1M) to 10M I seem to find the SFD more often, though it
is hard to tell, as the SFD then is also found relatively often in the
noise. I tried to filter the noise with the power squelch in the code,
but the threshold has to be very low to get something from the node,
which in itself is quite weird.
I hope someone might have an idea or a tip what else I could check out.
Thanks in advance, Sebastian
Hi Sebastian!
I don’t really understand what you’re trying to archive, but here’s a
stack for 802.15.4:
http://wiesel.ece.utah.edu/redmine/projects/gr-ieee802-15-4/wiki
I am trying to communicate between gnuradio (USRP) and 802.15.4 sensor
nodes, as it has been done before (see Thomas S. @ UCLA). Because
the hardware has evolved since then, I am using USRP N210s as the
interface to the computer. The N210s are equipped with XCVR2450
Works fine here. The XCVR is a much better choice than the RFX,
because it has TX gain.
Problem 1: When changing the center frequency on both Tx and Rx,
communication does not work any longer. Even a 5 MHz shift does the
deal.
How did you change the frequencies? If you change the center-frequency
on a FFT your USRP2 ↔ PC communication breaks down? What is the
decimation?
Problem 2: Packets send from a sensor node are not received.
Do you send a full 802.15.4 MAC sublayer? The stack you mentioned uses
a Packet Sink that drops packets on certain conditions. I changed that
recently for my efforts.
I have the feeling
that
the node signal is only processed occasionally.
In that case try attaching the GDB and log (verbose define statement
at the C code). Actually if GNU Radio drops vectors it outputs an “S”
indicating an overflow.
I played a bit around with sample rates.
To demodulate you need at least 2 * the frequency of the channel. So
in case of 802.15.4 something like 5 MS/s should be sufficient.
I hope someone might have an idea or a tip what else I could check out.
I actually finished a project on 802.15.4 and used USRP2s with the
WIESEL stack to analyze a real-time sensor network. I’ll commit some
stuff quite soon (this week). E. g. a complete demod and mod path in
GRC. Most stuff is in German though. 
Best,
Marius
Hi Marius,
Thanks for the quick reply. First of all I get a communication now.
When I set the sample rate to 4M then it works. Any idea why? Could it
have something to do with the 2M data rate? But shouldn’t it then work
with every sample rate > 4M, which it doesn’t? See more info below.
I don’t really understand what you’re trying to archive, but here’s a
stack for 802.15.4:
http://wiesel.ece.utah.edu/redmine/projects/gr-ieee802-15-4/wiki
The first step to my goal was to get a communication going between
USRP N210 devices and regular wireless sensor nodes, such as TelosB,
etc. I have seen the stack you mentioned, but it is pretty similar to
the UCLA stack with some extra features. Here, as well as with the
UCLA stack some modifications are needed to make them work with N210s
and the UHD driver.
How did you change the frequencies? If you change the center-frequency
on a FFT your USRP2 ↔ PC communication breaks down? What is the
decimation?
Sorry for that, probably I wasn’t clear here. The frequency change had
nothing to do with the FFT. The FFT I just did to see whether I
actually get something from my sensor nodes and what might be the
reason why I can receive from another N210, but not from a sensor
node.
The frequency change is done in the python script directly, i.e., in
the setup of the USRP device. The original code has 2,475 GHz as its
center frequency (which is channel 25 in the 802.15.4). When I have
two N210s with that frequency, they do communicate. When I change the
frequency to another channel (by changing the center frequency on both
devices), they do not communicate any longer.
To demodulate you need at least 2 * the frequency of the channel. So
in case of 802.15.4 something like 5 MS/s should be sufficient.
I thought the same. As soon as it should be over 2* it should be good.
Thus the test with a rather high sampling rate. Strange is that two
N210s can communicate with a 1M sample rate as long as both devices
have the same sample rate. Now the combination sensor node - N210
works only with 4M. Any idea what might be the reason.
I actually finished a project on 802.15.4 and used USRP2s with the
WIESEL stack to analyze a real-time sensor network. I’ll commit some
stuff quite soon (this week). E. g. a complete demod and mod path in
GRC. Most stuff is in German though.
Let me know when you have some code or report work done on that. The
language should not be an issue
Regards,
Sebastian
For some reason, if I have my USRPs plugged in for a while, they will
not work properly unless I unplug and replug them (so they “reboot”).
It’s worth a try if you leave them plugged in.
I’m still trying to run the ieee 802.15.4 code (I am using the original
USRP). I had to replace flow_graph calls with top_block of course, and
replace Numeric with NumPy. The rx runs but the tx produces segfaults
when trying to send a packet. I’m currently reading and commenting the
code so that I can understand it well enough to determine how to fix the
segfault
The segfault is occurring at the end of the mod block in the
ucla_delay_cc.cc file. A loop is used to shift the imaginary signal by
d_delay memory locations (q-phase delay), but this causes it to access
negative array locations which apparently are not allocated. Perhaps
they should be, but something has changed in the compilers or python to
prevent it. I suppose those samples in the negative region should be 0
in any case, so I can probably fix it with a loop to replace the
negative accesses with 0’s.
Marius, I saw that you had this problem several weeks ago. Do you
recall how you corrected it? Or did it perhaps correct automatically
when you updated other aspects of the code?
-Dave
implementation and found an existing adaptation to the UHD driver
online (Master Thesis by Kresimir Dabcevic).
Based on that 802.15.4 code, which we ported to the USRP2 (before UHD,
though), we implemented a system which runs TinyOS based on the SDR.
Some information can be found in
http://www.google.com/url?sa=t&source=web&cd=1&ved=0CBQQFjAA&url=http%3A%2F%2Fwww.sfb637.uni-
bremen.de%2Fpubdb%2Frepository%2FSFB637-T4-10-003-IC.pdf&ei=4CcxTpSKFceG-
wai-4yNDQ&usg=AFQjCNERfc8DNbtjLhJDg7I3P1SMS5ZdcA&sig2=5O_BjZgR6lbD5F6AjP7kdA
and
http://www.google.com/url?sa=t&source=web&cd=4&ved=0CCQQFjAD&url=http%3A%2F%2Fmail.millennium.berkeley.edu%2Fpipermail%2Ftinyos-
devel%2F2009-May%2F003851.html&ei=4CcxTpSKFceG-
wai-4yNDQ&usg=AFQjCNE0nUyB6KBcAJK1-UXrpZyLZu5fVQ&sig2=1guCm0r6UCCtCn1VYCxTBA
With that, we could make a ‘simulated’/‘emulated’ TinyOS on USRP2 talk
to
TelosB nodes.
The code hasn’t been updated to recent GNUradio, though.
Markus
communicating at channel 25 (2.475 GHz).
noise. I tried to filter the noise with the power squelch in the code,
but the threshold has to be very low to get something from the node,
which in itself is quite weird.
I hope someone might have an idea or a tip what else I could check out.
Thanks in advance, Sebastian
| Dipl.-Ing. Markus Becker
| Communication Networks
| TZI - Center for Computing Technologies
| University Bremen
| Germany