[Top][All Lists]

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

Re: [Discuss-gnuradio] Bandwidth switching per symbol

From: bjoernm
Subject: Re: [Discuss-gnuradio] Bandwidth switching per symbol
Date: Fri, 29 Jul 2011 14:36:34 +0200
User-agent: Internet Messaging Program (IMP) H3 (4.2)


Well its the first case (strange behavior)
(g means good symbol, b means bad): gggggggggggggbbbbbbbbbbbb

more precisely, Preamble, SFD, packet length (PHR) is all received correctly. Additionally, also a part of the payload is received correctly. Here an example:

I send the following packet:
['0x0', '0x0', '0x0', '0x0', '0xa7', '0x19', '0x1', '0x0', '0xff', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0x68', '0x44', '0x0']

and receive the following:
['0x0', '0x0', '0x0', '0x0', '0xa7', '0x19', '0x1', '0x0', '0xff', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb', '0xca', '0x8f', '0x45', '0xa5', '0x79', '0xab', '0x35', '0x9a', '0x8c', '0x32', '0xf9', '0x8c', '0xa0', '0xba', '0x2']

If this would be during the packet_sink, then the error would occur somewhere in the middle of decode_chips()...

best regards, and thanks again

Quoting "Matthias Wilhelm" <address@hidden>:

Am 29.07.2011 um 13:44 schrieb address@hidden:

Hi again,

Thanks a lot for your mail from yesterday!

In order to figure out what changes are needed at the receiver, I do not change the bandwidth per symbol, but constantly, by using the following lines within ucla_qpsk_modulator_cc.cc.

 *out++ = gr_complex(0.0, 0.0);
 *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343);
 *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
 *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953);
 *out++ = gr_complex(iphase, qphase);
 *out++ = gr_complex(iphase * 0.92387953, qphase * 0.92387953);
 *out++ = gr_complex(iphase * 0.70710678, qphase * 0.70710678);
 *out++ = gr_complex(iphase * 0.38268343, qphase * 0.38268343);

Now in the file: ieee802_15_4.py @ ieee802_15_4_demod
I have changed the variable sps from 2 to 4, as previously suggested.
The result is, that the receiver receives half the packet correctly, and the whole second half appears to be random.

I don't think that we need to change the file "ucla_ieee802_15_4_packet_sink.cc" in this case.

Now it would be great if I could just tweak the parameters in "ieee802_15_4_demod", but how?

clock_recovery and the iir filter are gnuradio specific functions, hence tweaking the parameters should in general work in a constant BW case, right?

Do you have any suggestions on those parameters?

many thanks and have a good weekend soon,


to clarify, do you get a good half packet each time a packet arrives, or are 50% of the packets good and 50% broken (or undetected)?
I understand that you have something like (g means good symbol, b means bad):
for all packets you see, which would be a rather strange behavior. It would suggest that everything is working fine and robust for the first half, and somehow breaks down in-between. My remote diagnose in this case is that the state machine in the packet sink detects the preamble and SFD (and maybe the header as well) for each packet, but has some hard-coded parts that expects the default bandwidth, producing arbitrary results for the rest of the packet. You should check how far the state machine works correctly, and debug the problem case. You can active the debug symbols in the UCLA code (VERBOSE and VERBOSE2) to see what is happening in the state machine of the receiver.

If it's 50/50% good/bad packets, then I would suspect the timing recovery, but the parameters are also rather magical for me. But I think its the standard(?) Mueller&Müller clock recovery algorithm, so there should be some info in textbooks how it works and what parameters are suitable. I found this: http://www.mail-archive.com/address@hidden/msg12723.html


reply via email to

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