RE: [Discuss-gnuradio] Dropped Packets

[Tom Rondeau]

We don't have a Flex board in the lab yet; we're using the Basic TX right
now.

After I sent the last email, I was playing around more with the GMSK code,
and when I make it discontinuous (and changed it to "burst" a single
packet), all packets finished fine, so the time.sleep() works there. I then
just put a time.sleep(1) before the fg.wait(), and everything works fine.
However, it does not work in my application. 

Comparing the two, the GMSK code seems to block the flow graph as it is
transmitting, so each time through the while loop that creates the packets
occurs after each full transmit. With my code (which was modeled after the
GMSK code to create and transmit the packets), hundreds of packets are
generated at once before transmission begins, so my while loop finishes long
before the transmission does. When I put a sleep state in this time, it
stops everything; transmissions stop and get corrupted, and everything just
falls apart.

We are tying to figure out where my code goes wrong and is different from
the GMSK code. Do these symptoms make enough sense to provide some feedback?

Thanks,
Tom


-----Original Message-----
From: Eric Blossom [mailto:address@hidden 
Sent: Tuesday, February 14, 2006 8:14 PM
To: Tom Rondeau
Cc: address@hidden
Subject: Re: [Discuss-gnuradio] Dropped Packets

On Tue, Feb 14, 2006 at 02:12:38PM -0500, Tom Rondeau wrote:
> I am currently developing a BPSK transceiver with a fully-functional PHY
and
> MAC layer defined in the GNU Radio/USRP. Everything almost works perfectly
> (the code will be released on our website once this final problem is
> solved), but I cannot get the final packet to receive correctly. Even when
> using the GMSK2 example, it seems like the final packet always messes up.
> When I take a closer look at the transmissions using our signal analyzer,
I
> notice that the transmitter does not finish transmitting the final signal
> (it sends the preamble (I put this into the packet_utils.py for my
> synchronization loops), the access code, and part of the payload).
> 
>  
> 
> The problem seems to come from the thread handling the transmit procedure
> shutting down the USRP before the packet can be fully transmitted.
> 
> Any ideas?
> 
> Thanks,
> Tom

I can think of two causes.  The one you mentioned, and the possibility
that the FPGA is turning off the transmitter before the last packet is
all the way out.

Are you testing using the Flex 400 board with set_auto_tr(True)?
Is it only the last packet that gets truncated?  Have you tried
transmitting packets discontinuously similar to the benchmark_gmsk_tx?
When using discontinuous transmission are the other packets OK?

A quick fix for your hypotheis goes something like this:

   ...
   fg.run()
   time.sleep(1)
   ...

Eric