[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] Final Packet(s) dropped
From: |
Richard Alimi |
Subject: |
Re: [Discuss-gnuradio] Final Packet(s) dropped |
Date: |
Mon, 26 Mar 2007 17:15:56 -0400 |
User-agent: |
KMail/1.9.6 |
Thank you for the response. I was afraid that might be the case :) The
following workaround seems to work well (which seems to validate your
hypothesis):
When a packet is _not_ being sent, the transmitter outputs a continuous
stream of 0-valued samples to the USRP. When a packet _is_ being sent,
modulate and sample as usual.
Not the ideal solution, but it works.
Thanks,
Rich
On Monday 26 March 2007, John Ackermann N8UR wrote:
> Richard Alimi wrote:
> > Hello All,
> >
> > I am currently having a problem with packet transmission similar to the
> > one Tom Rondeau had mentioned in his February 14th 2006 post titled
> > 'Dropped Packets.' However, there was no general resolution given there.
> >
> > When I run the dbpsk/dqpsk/gmsk transmitter/receiver under the
> > gnuradio-examples directory (revision 4796), it always seems to drop the
> > last packet, leading me to believe this hasn't been fully fixed. Using
> > the --discontinuous option produces the same result. Even adding a
> > time.sleep(1) before fg.wait() doesn't seem to fix it, as suggested by
> > that post.
>
> I am dangerously jumping into a place that I don't understand, but I
> have had a similar problem in a non-gnu-radio data system and it's
> possible, I suppose, that something similar is going on here.
>
> The issue is the timing of the signal to turn the TX off versus the time
> required to get the last data bit actually on the air. In the AX.25
> packet system in question, the application would unkey the transmitter
> as soon as the last payload bit was sent. However, there was a
> downstream scrambler that caused a delay of some number of bit times.
> We had to set a parameter to keep the TX keyed for a few milliseconds
> after the end of data in order to allow all the data in the scrambler to
> make it out over the air. In the AX.25 protocol, that was the "txtail"
> parameter.
>
> Again, I have no idea if this applies to your situation, but it caused
> us some real head scratching until we figured out what was going on.
>
> John
pgpHtFeoGUVXh.pgp
Description: PGP signature