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
Bjorn
Quoting "Matthias Wilhelm" <wilhelm@informatik.uni-kl.de>:
> Am 29.07.2011 um 13:44 schrieb bjoernm@ee.ethz.ch:
>
>> 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,
>> Bjorn
>
> Hi,
>
> 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):
> gggggggggggggbbbbbbbbbbbb
> 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/discuss-gnuradio@gnu.org/msg12723.html
>
> Regards,
> Matthias
_______________________________________________
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
No comments:
Post a Comment