Dan Halperin wrote:
Shravan Rayanchu wrote:
Basically, I seem to completely lose some of the packets in the air.
Of the packets I receive, almost all the packets are received
correctly. Initially, the error rate was too high (The packets were
getting lost and also among the packets received, lot of them were in
errors), so I increased tx-amplitude to ~3000.
Am I using the right version of the code ? Is the tarball release
better to use ? Can you please let me know if there are any parameters
which I need to change ?
Tom mentioned an existing problem in the email you replied to, which you
didn't address in your response. Could that be the problem or have you
ruled it out?
Yes, thanks for pointing that out, Dan. The problem I discussed in my
original email is certainly the problem; it's exactly what I was seeing.
For debugging these types of errors, I really do suggest (from
experience!) that you start saving the outputs of the intermediate
stages to disk and seeing what they look like. It might require some
understanding of the receiver, but then again you probably want that
Excellent point. Visualization tools are a key to understanding and
debugging this stuff.
By using the --log option, the receiver will dump output data files for
every important (and even some not-so-important) block in the chain. The
gr_plot_XXX.py scripts are useful for getting a quick look at the
output. There is a local gr_plot_ofdm.py script distributed as part of
the ofdm example directory that provides a specific way of looking at
the output of the OFDM system.
It's likely (as I found with older versions of the DBPSK code, for
instance) that some of the synchronization and/or timing algorithms
aren't working in your setup. But maybe there's lots of cochannel
interference. Maybe the RSSI is low. Maybe the frequency offset of your
daughterboards is too large to be handled by the PLLs...
Always the case, really. These methods are as straight-forward as we can
make them to do the basic receivers for different modulations. Most
standard/commercial digital radios do a whole lot more to make sure the
signal is properly received. Cochannel interference will quickly kill
these implementations. And in the case of the M-PSK code, my first
version was textbook while the second version was the right way; that
helps, too :)
Discuss-gnuradio mailing list