[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Discuss-gnuradio] problem with start/end of burst inband FPGA code

From: George Nychis
Subject: [Discuss-gnuradio] problem with start/end of burst inband FPGA code
Date: Wed, 01 Aug 2007 16:59:09 -0400
User-agent: Thunderbird (X11/20070604)

Hey all,

We're looking for someone to look over our shoulder on an inband FPGA problem we've been stuck on for a couple days now.

The problem is that we never had code that throws out additional packets in a burst if the initial packet had a timestamp that expired. When an m-block message is fragmented into multiple USB packets, the packets are considered a single burst, where the first packet has the start of burst flag set and the last packet has the end of burst flag set. The first packet has the timestamp set to the desired timestamp, and each additional packet in the burst is given the 'NOW' timestamp.

The problem was that our code would throw away the first packet if the timestamp expired, but the additional packets in the burst had a timestamp of 'NOW' so they would be sent... but they shouldn't be since they are part of an 'expired' burst.

Ok, so on to the code:

The logic needs to be "if the packet with the start of burst flag was thrown away, throw away all packets until we see the end of burst flag."

If we see the start of burst flag, we set 'burst' to be 1.

If the timestamp has expired on the packet, set 'trash' to 1, and 'skip' set to 1:

Finally, if we get a packet that does not have start of burst set, it *must* be an intermediate packet or the last packet in a burst... either way it does not matter. If 'trash' is set to 1, we want to skip it:

If we see the end of burst flag, 'burst' is reset:

If the next packet has a correct timestamp, we set trash back to 0. We could just set trash to 0 when end of burst is read, but it doesn't really matter:

So... as you can guess, this doesn't work. This hasn't been our only attempt. We've trashed the code and re-written it a couple different times with no success.

To test this we've been setting all packets to have a timestamp of 0. This means we should get no sine wave on an oscope when transmitting, regardless of the number of packet sin the burst. However, we see chunks of the wave here and there when the number of packets in the burst is greater than 1. If we set it so that a single m-block message only creates 1 USB packet, it works... everything is thrown away.

We'd greatly appreciate any help, thanks!

- George, Leo

reply via email to

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