Hi
I figured it out... the problem was just the sender itself.
I forgot to change the parameter: static const int SAMPLES_PER_SYMBOL = 4;
to: static const int SAMPLES_PER_SYMBOL = 8;
in "ucla_qpsk_modulator_cc.cc"
At the receiver side, I actually only had to change the variable
"sps". I guess the filter and clock recovery still work, as the
parameter of those are influenced by the variable sps.
Well thank you for all your help! I hope I can get even some day...
best regards,
Bjorn
Quoting "Matthias Wilhelm" <wilh...@informatik.uni-kl.de>:
Am 29.07.2011 um 13:44 schrieb bjoe...@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
