Re: [Discuss-gnuradio] OFDM Updates

[Shravan Rayanchu]

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 <address@hidden> 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
> address@hidden
> http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>