Re: [Discuss-gnuradio] rx_ofdm Does Not Work Past Synchronizer

[Martin Braun]

A good way to test is to use the hier blocks for OFDM (you still need to
reduce amplitude), they will set up everything in a way that will work
for sure. See the loopback example in gr-digital/examples/ofdm.

M

On 03/19/2014 08:41 PM, Jonathan Fox wrote:
> Thanks for the responses.
> 
> When I use the USRPs the UHD sink is placed after the OFDM Cyclic
> Prefixer, right after the Mutliply Const (50m). I haven't changed any
> settings because I remember reading in a few previous emails that the
> most common question people ask is "Did you change anything?"
> 
> Sadly, the delay wasn't the case, at least for the loopback mode.
> 
> I reduced the amplitude of the signal by an additional 0.02, so the
> multiply constant is at 0.03 as opposed to 0.05. It brought the clipping
> well within +1, -1. Before the signal clipped past -1 but never rose
> above +1. No effect but I am not ruling out that it wouldn't help.
> 
> The video is interesting enough that I am going to continue watching
> after the first half, maybe I can figure out more from there.
> 
> Jon
> 
> 
> On Wed, Mar 19, 2014 at 7:50 AM, Martin Braun <address@hidden
> <mailto:address@hidden>> wrote:
> 
>     On 03/19/2014 12:25 AM, Jonathan Fox wrote:
>     > So I have the stock python scripts (tx_ofdm and rx_ofdm) located
>     in the
>     > gr-digital examples and put USRP sources and sinks in the appropriate
>     > spots. I left sampling alone (100K for TX, 3.2M for RX) and had the
>     > TX/RX frequency at 500 MHz. The USRPs used are N210s with WBX
>     > daughterboards. I tested the USRP used for TX out by outputting a
>     signal
>     > to another and looking at it on the GNU Radio spectrum analyzer. Also,
>     > this is through SMA cables and a 30 dB attenuator, no over the air
>     > transmission. I placed file sinks after each block in the process;
>     each
>     > file is a binary file. After multiple runs I felt like something
>     wasn't
>     > working after looking at the binary files.
> 
>     Maybe you're probably screwing up your tx signal by clipping, although I
>     can't say for sure from your flow graphs (where exactly do you put the
>     UHD sink?) See
>     
> http://video.fosdem.org/2014/AW1125/Sunday/Tutorial_OFDM_Packet_Transceivers.webm,
>     starting around ~27 mins for an explanation, or search the mailing list
>     archive.
> 
>     Martin
> 
>     >
>     > When I execute, only the file sinks placed after the Schmidl & Cox
>     OFDM
>     > Synchronizer freq_offset and detect have data in them, at least their
>     > files have some size to them, implying something has been written. The
>     > file sinks after FFT (or the header/payload demux) have no data, 0 KB.
>     >
>     > When I discovered that the receive didn't work, I took the grc file
>     > another user made back in October with both TX mod and RX demod in the
>     > same flowgraph to see if that would work (files attached). Again same
>     > issue, all the binary files after the FFT have no data so something is
>     > getting screwed up in my demod.
>     >
>     > Has any user on this list run into this issue before or can offer some
>     > insight to why the receiver is failing?
>     >
>     > Thank you,
>     >
>     > Jon
>     >
>     > Attached is the python script, grc file, and screen shot of the TXRX
>     > combo in GRC.
>     >
>     >
>     > _______________________________________________
>     > Discuss-gnuradio mailing list
>     > address@hidden <mailto:address@hidden>
>     > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>     >
> 
> 
>     _______________________________________________
>     Discuss-gnuradio mailing list
>     address@hidden <mailto:address@hidden>
>     https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
> 
>