Hi,,
As it turns out, the verbose output isn't that helpful either. It just
reveals that at some point, the chip-error rate increases drastically.
See the verbose output of receiving one packet below:
Found 0 in chip sequence
Found 1 0 in chip sequence
Found 2 0 in chip sequence
Found 3 0 in chip sequence
Found 4 0 in chip sequence
Found 5 0 in chip sequence
Found 6 0 in chip sequence
Found 7 0 in chip sequence
Found first SFD
Found sync, 0x7a
@ enter_have_sync
Header Search bitcnt=0, header=0x00000000
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
@ enter_have_header (payload_len = 25)
Packet Build count=101, noutput_items=256, packet_len=25
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 0, payloadcnt: 0, payload 0x1, d_packet_byte_index: 2
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 1, payloadcnt: 1, payload 0x0, d_packet_byte_index: 2
Packet Build count=0, noutput_items=132, packet_len=25
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 2, payloadcnt: 2, payload 0xff, d_packet_byte_index: 2
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 3, payloadcnt: 3, payload 0xb, d_packet_byte_index: 2
Packet Build count=0, noutput_items=512, packet_len=25
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 4, payloadcnt: 4, payload 0xb, d_packet_byte_index: 2
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 5, payloadcnt: 5, payload 0xb, d_packet_byte_index: 2
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 6, payloadcnt: 6, payload 0xb, d_packet_byte_index: 2
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 7, payloadcnt: 7, payload 0xb, d_packet_byte_index: 2
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 8, payloadcnt: 8, payload 0xb, d_packet_byte_index: 2
Found sequence with 0 errors at 0x0
Found sequence with 0 errors at 0x0
packetcnt: 9, payloadcnt: 9, payload 0xb, d_packet_byte_index: 2
Found sequence with 11 errors at 0x10c99928
Found sequence with 13 errors at 0x330985b8
packetcnt: 10, payloadcnt: 10, payload 0x9e, d_packet_byte_index: 2
Found sequence with 11 errors at 0x1350324a
Found sequence with 11 errors at 0x24a50958
packetcnt: 11, payloadcnt: 11, payload 0xfc, d_packet_byte_index: 2
Packet Build count=0, noutput_items=508, packet_len=25
Found sequence with 11 errors at 0x24688e44
Found sequence with 10 errors at 0x4938588
packetcnt: 12, payloadcnt: 12, payload 0x97, d_packet_byte_index: 2
Found sequence with 12 errors at 0x3046c256
Found sequence with 10 errors at 0x6ac08430
packetcnt: 13, payloadcnt: 13, payload 0x93, d_packet_byte_index: 2
Found sequence with 10 errors at 0x585a8018
Found sequence with 8 errors at 0x3550840
packetcnt: 14, payloadcnt: 14, payload 0x19, d_packet_byte_index: 2
Found sequence with 11 errors at 0x340181ba
Found sequence with 10 errors at 0x540910c6
packetcnt: 15, payloadcnt: 15, payload 0xdf, d_packet_byte_index: 2
Found sequence with 6 errors at 0x5210082
Found sequence with 9 errors at 0x10a224c2
packetcnt: 16, payloadcnt: 16, payload 0xb9, d_packet_byte_index: 2
Found sequence with 10 errors at 0x4c2852a0
Found sequence with 12 errors at 0x42d28a86
packetcnt: 17, payloadcnt: 17, payload 0xac, d_packet_byte_index: 2
Found sequence with 10 errors at 0x26465804
Found sequence with 10 errors at 0x53e02280
packetcnt: 18, payloadcnt: 18, payload 0xfa, d_packet_byte_index: 2
Found sequence with 11 errors at 0x10964dc
Found sequence with 9 errors at 0xa202466
packetcnt: 19, payloadcnt: 19, payload 0xbd, d_packet_byte_index: 2
Packet Build count=0, noutput_items=512, packet_len=25
Found sequence with 11 errors at 0x4a502e6
Found sequence with 10 errors at 0x30a641c
packetcnt: 20, payloadcnt: 20, payload 0x70, d_packet_byte_index: 2
Found sequence with 11 errors at 0x3c47308
Found sequence with 10 errors at 0x2612aa20
packetcnt: 21, payloadcnt: 21, payload 0xe1, d_packet_byte_index: 2
Found sequence with 10 errors at 0x18e32210
Found sequence with 12 errors at 0x4836a622
packetcnt: 22, payloadcnt: 22, payload 0x53, d_packet_byte_index: 2
Found sequence with 11 errors at 0x68c13908
Found sequence with 12 errors at 0x2d14189a
packetcnt: 23, payloadcnt: 23, payload 0x6f, d_packet_byte_index: 2
Found sequence with 12 errors at 0x4a170938
Found sequence with 11 errors at 0x4c059924
packetcnt: 24, payloadcnt: 24, payload 0xc3, d_packet_byte_index: 2
Adding message of size 25 to queue
@ enter_search
received packet
payload:
['0x1', '0x0', '0xff', '0xb', '0xb', '0xb', '0xb', '0xb', '0xb',
'0xb', '0x9e', '0xfc', '0x97', '0x93', '0x19', '0xdf', '0xb9', '0xac',
'0xfa', '0xbd', '0x70', '0xe1', '0x53', '0x6f', '0xc3']
checksum: 14309, received: 50031
Rx: ok = False len(payload) = 20
802_15_4_pkt: waiting for packet
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
