[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 

  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.


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

Attachment: pgpHtFeoGUVXh.pgp
Description: PGP signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]