Hi Dan and Tom, Thanks for your comments. I'll trying changing the parameters and look at the log files to see what might be wrong.
Shravan On Feb 13, 2008 6:15 PM, Tom Rondeau <[EMAIL PROTECTED]> wrote: > 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 > > knowledge anyway... > > > 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 :) > > Tom > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > _______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
