Re: [Discuss-gnuradio] USRP1 cannot transmit/receive a OFDM packet discontinuously sometimes

[Tom Rondeau]

On Tue, Sep 14, 2010 at 12:52 AM, Fisheep <address@hidden> wrote:
>
> Hi,
>
> My problem is that I try to discontinuously send "a" OFDM packet by using
> time.sleep() on USRP1, but fail to successfully receive this OFDM packet at
> the receiver sometimes.
>
> Brief Setting Description:
> Code : gnuradio-example/python/ofdm/benchmark_ofdm_tx{rx}.py
> Daughterboard : FLEX900
> OS : Ubuntu 8.10
> Tx :
>    send_pkt(data) -> time.sleep(1) -> send_pkt(data) -> time.sleep(1) ->
> ...
> Rx :
>  ok = False , pktno = 65537, ....
>  ok = True  , pktno = 1      , ....
>  ...
>
> I have surveyed about this discussion on the forum. Using discontinuous
> transmission is to ensure the transmitter successly sending a packet and
> receiver will receive this packet. And I try this scheme on single carrier
> case like benchmark_tx{rx}.py on digital file, every packet is successful
> receive at receiver. But when changing to OFDM, not every packet is
> successful receive.
>
> Is it that fft consumes lots of time and causes the transmitter doesn't send
> this packet?
> I think this is the main different between single carrier and OFDM.
>
> If anyone have any idea about this problem, please let me know.
> I am deeply appreciative.
>
>
> Fisheep


Fisheep,

I don't think anyone has actually tried doing this. I know when Matt
and I put the system together, we were concerned only with the
continuous case. We have some improvements to the OFDM pieces that are
on my todo list, though, and once the continuous case is finished,
we'll work on the discontinuous. Until then, though, I'm afraid the
only advice I could give would be completely speculative.

My first thought would be to see how the synchronization is behaving;
that's almost certainly where the problem is. We have the
"gr_plot_ofdm.py" script that helps to visualize what's happening with
the received symbols (you'll need to turn logging on and have scipy
and matplotlib installed). Play with that in loopback mode to
understand what you're seeing, then see what happens with your
over-the-air tests.

If you figure out ways to make it better, I'd love to hear it!

Tom