UCLA Zigbee PHY examples updated for UHD

Hello list!

I’ve updated (or at least tried updating) two of UCLA ZIGBEE PHY
project’s examples to work with UHD - cc2420_txtest.py and
cc2420_rxtest.py. I think the tx one works fine (spectrum analyzer says
that we truly are transmitting at the given frequency), however the rx
example isn’t receiving/decoding packages. Could someone take a look at
the modifications to see what I’m doing wrong (maybe I am setting the
frequencies/some other parameters wrong - does using
self.u.set_center_freq function suffice, or should I somehow be tuning
the frequency - if so, how?)?

It seems that the variable self.rcvd_pktq is empty (line 258 in
ieee802_15_4_pkt.py):
(part of the code where we fill up the “msg” variable):
def run(self):
while self.keep_running:
print “802_15_4_pkt: waiting for packet”
msg = self.rcvd_pktq.delete_head()
ok = 0
payload = msg.to_string()
print "received packet "

It confuses me why we aren’t receiving packets (especially since the
cc2420_channel_test.py works fine).

This is the output of uhd_cc2420_rxtest.py (regardless whether I’m
running the uhd_cc2420_txtest.py on the other machine or not):

kresimir@kresimir-U52F:~/ucla_zigbee_phy/src/examples$
./uhd_cc2420_rxtest.py -c 2450000000 -r 100 -A TX/RX -g 20 -f rxtest.dat
linux; GNU C++ version 4.4.5; Boost_104200; UHD_003.001.000-9f1e49e

Blocked waiting for GDB attach (pid = 5466)
Press Enter to continue:
cordic_freq = 2.45G
data_rate = 100
samples_per_symbol = 2
fs = 200
– Opening a USRP2/N-Series device…
– Current recv frame size: 1472 bytes
– Current send frame size: 1472 bytes
– mboard0 is MIMO master
Center frequency: 2450000000

gr_fir_fff: using SSE
802_15_4_pkt: waiting for packet
Statistics: good 0 received 0

I’ve been using two USRP N210s (also tried on only one with TX/RX as
transmitter and RX2 as receiver - same thing) for testing with
gnuradio3.3.0 on Ubuntu 10.10

Links to files:
http://marvin.kset.org/~sunshine/uhd_cc2420_rxtest.py
http://marvin.kset.org/~sunshine/uhd_cc2420_txtest.py

Regards,
Kresimir

Blocked waiting for GDB attach (pid = 5466)
Press Enter to continue:
cordic_freq = 2.45G

Not sure whats wrong, but, cordic_freq should be the error in tuning the
RF center freq, so only a few kHz really. That may be a good place to
start looking.

-josh

Thanks for the reply Josh.

However, I’m confused by all the frequency setting/tuning functions at
our disposition. In my example,
1)I am setting cordic-freq (set by parser) while calling the main
program, e.g. -c 2450000000 -that’s the frequency I want to set my USRP
to.

2)output of
self.u.set_center_freq(options.cordic_freq, 0)
print “Center frequency: %d” %(self.u.get_center_freq())
is:
Center frequency: 2450000000

3)output of
uhd.tune_request(options.cordic_freq, 0)
print “Center frequency: %d " %(self.u.get_center_freq())
print (”%s") %(uhd.tune_result())
is:
Center frequency: 2600000000
Tune Result:
Target RF Freq: 0.000000 (MHz)
Actual RF Freq: 0.000000 (MHz)
Target DSP Freq: 0.000000 (MHz)
Actual DSP Freq: 0.000000 (MHz)

Why is uhd.tune_request setting the center frequency to 2.6 instead of
2.45 GHz?
Also, am I calling the uhd.tune_result function wrong - why are all the
values 0?
Furthermore, what is the difference between
self.u.set_center_freq(options.cordic_freq,0).actual_rf_freq and
self.u.set_center_freq(options.cordic_freq,0) functions?

Regards,
Kresimir

update: turns out the problem was power squelch block - connecting
self.u directly to self.packet_receiver did the trick…

However, I’m confused by all the frequency setting/tuning functions at our
disposition. In my example,
1)I am setting cordic-freq (set by parser) while calling the main program, e.g.
-c 2450000000 -that’s the frequency I want to set my USRP to.

OK, I guess everything is fine. As a matter of terminology, calling it
center freq might make more sense. The cordic frequency is the DSP
frequency.

Why is uhd.tune_request setting the center frequency to 2.6 instead of 2.45 GHz?
Also, am I calling the uhd.tune_result function wrong - why are all the values
0?

You are making a new (empty tune result object). Not the one returned by
the set center frequency.

Furthermore, what is the difference between
self.u.set_center_freq(options.cordic_freq,0).actual_rf_freq and
self.u.set_center_freq(options.cordic_freq,0) functions?

Accessing a parameter vs not accessing a parameter?

-josh