|
From: | Tom Rondeau |
Subject: | Re: [Discuss-gnuradio] OFDM Updates |
Date: | Thu, 14 Feb 2008 00:15:12 +0000 |
User-agent: | Thunderbird 2.0.0.9 (Windows/20071031) |
Dan Halperin wrote:
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.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?
Excellent point. Visualization tools are a key to understanding and debugging this stuff.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 knowledge anyway...
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.
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 :)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...
Tom
[Prev in Thread] | Current Thread | [Next in Thread] |