Who has succeeded in using cc1k_sos_pkt of ucla_zigbee_phy?

Hi all,

I am trying to use cc1k of ucla_zigbee_phy. The testbench are
cc1k_txtest.py and cc1k_rxtest.py in which the signal source and sink
are amended to UHD since my platform is USRP E100. There is nothing
outputs from the RX TB. I checked the ucla_sos_packet_sink.cc, it can
receive data when TX sends although there is no data matches the access
code. I want to know why there is no access code be demodulated
correctly so I studied the relevant codes of cc1k.py and
cc1k_sos_pkt.py. Many problems emerge in front of me. I don’t know if
anybody has succeeded in using it. If so, very thankful for your explain
and suggestions.
1 The spb in TX and sps in RX are set to 8, what is the reason?

2 In TX there is preamble but in ucla_sos_packet_sink.cc, no preamble
needs to be found before the sync data. Actually it is just a simple
comparison between input data and the access code. So why we need
transmit preamble in TX?

3 In cc1k_txtest.py the access code is set as 0x33 plus 0xcc, but in
cc1k_sos_pkt the access code of cc1k_demod_pkts module is
0x999999995a5aa5a5. The ucla_sos_packet_sink.cc also requires the access
code to be 8 bytes. How can the access code in TX be discerned in RX?
BTW, even after I changed the access code of TX to 0x999999995a5aa5a5,
the packet_sink still can not detect out the sync data.

4 In cc1k.py, the cc1k_mod module sets ‘sensitivity’ to 3.5*pi / spb but
the cc1k_demod module set ‘sensitivity’ to (pi/2)/sps. Actually I am not
sure what is the functionality of this variable but I think it may
should be set as identical in both mod and demod module.

5 In cc1k_demod module, the alpha variable, which is parameter of
gr.single_pole_iir_filter_ff, is set to 0.0512/sps. I don’t know why it
should be this value. In ieee802_15_4.py, the demodulation module sets
it to 0.0008/self.sps. What is foundation to set this variable?

At last, what configuration in TX and RX can make the communication runs
well?

Appreciate in advance for your reply.

Sincerely,

Zhonghua

On 03/28/2012 07:01 PM, Zhonghua wrote:

anybody has succeeded in using it. If so, very thankful for your
0x999999995a5aa5a5. The ucla_sos_packet_sink.cc also requires the
5 In cc1k_demod module, the alpha variable, which is parameter of

Zhonghua

I composed a tidy version by directly connect TX and RX together to
thoroughly exclude the influence of radio front end. TX is nothing but
packet making and modulation. RX is demodulation and packet sink(to do
Manchester decoding and sync detect). I also experimented to set sps and
spb to be 1, 2 or 8. It is still has no correct data in packet sink.
I suspect is it right that the adopted bsfk mechanism which uses
‘gr.frequency_modulator_fc(sensitivity)’ as modulator and
‘gr.quadrature_demod_cf(1 / sensitivity)’ as demodulator. In
ieee802_15_4.py we can see the modulator is ucla.qpsk_modulator_cc() and
the demodulator is also gr.quadrature_demod_cf(1). That means the
quadrature demodulation can demodulate both qpsk and fm?
Could somebody give me any help? Thanks!

Br,

Zhonghua

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs