Re: [Discuss-gnuradio] Final Packet(s) dropped

[Richard Alimi]

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