Re: [Discuss-gnuradio] Bandwidth switching per symbol

[bjoernm]

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" <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,
> > 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/address@hidden/msg12723.html
>
> Regards,
> Matthias