[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Who has succeeded in using cc1k_sos_pkt of ucla_z

From: Zhonghua
Subject: Re: [Discuss-gnuradio] Who has succeeded in using cc1k_sos_pkt of ucla_zigbee_phy?
Date: Thu, 29 Mar 2012 15:58:07 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20120313 Thunderbird/3.1.20

On 03/28/2012 07:01 PM, Zhonghua wrote:
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.



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!



reply via email to

[Prev in Thread] Current Thread [Next in Thread]