[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] rx_ofdm Does Not Work Past Synchronizer
From: |
Martin Braun |
Subject: |
Re: [Discuss-gnuradio] rx_ofdm Does Not Work Past Synchronizer |
Date: |
Thu, 20 Mar 2014 10:05:31 +0100 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 |
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
>
>