Re: [Discuss-gnuradio] Bandwidth switching per symbol

[bjoernm]

Hi,

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" <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