Start/end of burst issues

GNU Radio
1

Hi guys:

Here is the problem. If I receive a packet whose timestamp is out of
date, I trash the packet. If there are packets afterwards that is a
continuation of the first packet, I should trash those as well despite
the fact that their timestamp indicates now. (They belong to the same
high level packet, if the first one can not be sent, why bother sending
the later ones). The way to tell if a packet is a continuation of the
earlier ones is by burst flags. The start of burst flag indicate the
start of a sequence of packets and the end of burst flag indicate the
end of that sequence.

Under svn directory
http://gnuradio.org/svn/branches/developers/zhuochen/inband/usrp/fpga/inband_lib
there are two files, chan_fifo_reader.v and channel_ram.v that are
responsible for storing incoming usb_data into ram and sending it
accordingly. channel_ram.v accepts incoming packets, store them in its
ram and outputs packets with rd signal. Chan_fifo_reader on the other
hand sends the packets and discard any packets with expired timestamp.

Under svn directory
http://gnuradio.org/svn/branches/developers/zhuochen/simulation/burst_test
there are three files, test_chan_fifo_reader.v, strobe_gen.v and
math_real.v
that can be used as testbenches to the two files above.

In the test_chan_fifo_reader.v I send a seqence of packets with expired
timestamp and then a seqence of packets with future timestamp. When I
run the simulation, the sequences of packets with expired timestamp got
discarded and the sequences of packets with the future timestamp is
delayed and then sent. So everything looks fine.

However, when I upload the whole thing to the board and my partner send
me a sequence of packets with expired timestamp, only the packet with
start of burst got discarded. The later packets did not get discarded
even though they are continuations of the first one.

I don’t understand why there is a difference in behavior between the
simulation and the board, can anyone take a look at my files and give me
some pointers?

Leo

2

Brian P. wrote:

On 8/3/07, Zhuocheng Y. [email protected] wrote:

You haven’t really modeled what the board is doing properly, so your
code is probably doing exactly what it should in the circumstances
you’re giving to it. You should get a dump of the raw packets
George’s server is trying to send to the USRP and run them through
your simulation.

This basically solved the problem. It turns out that the start and end
burst flags were swapped in the host side code. This obviously created
problems :slight_smile: By using live packets, we were able to pinpoint it. Once
the host followed spec, the problem was solved and we are now moving on
with life :slight_smile:

As a side note, we also tested out spacing like you suggested using the
oscope and timestamps. The FPGA is properly waiting for the timestamp
to reach and transmitting at that point. Using the oscope we checked
proper spacing according to our timestamps and it is correct.

Moreover, I think you may have some signed/unsigned issues. I
haven’t been able to recreate the problem you specifically see, but
it could possibly be related to another problem that I see when I run
your code - specifically when the time has become negative (in a
signed sense).

Right, we agree with this. This is something we also need to fix.
Thanks for this heads up :slight_smile:

  • George
3

On 8/3/07, Zhuocheng Y. [email protected] wrote:

Hi guys:

Here is the problem. If I receive a packet whose timestamp is out of date, I trash the packet. If there are packets afterwards that is a continuation of the first packet, I should trash those as well despite the fact that their timestamp indicates now. (They belong to the same high level packet, if the first one can not be sent, why bother sending the later ones). The way to tell if a packet is a continuation of the earlier ones is by burst flags. The start of burst flag indicate the start of a sequence of packets and the end of burst flag indicate the end of that sequence.

– snip –

I don’t understand why there is a difference in behavior between the simulation and the board, can anyone take a look at my files and give me some pointers?

You haven’t really modeled what the board is doing properly, so your
code is probably doing exactly what it should in the circumstances
you’re giving to it. You should get a dump of the raw packets
George’s server is trying to send to the USRP and run them through
your simulation.

Moreover, I think you may have some signed/unsigned issues. I haven’t
been able to recreate the problem you specifically see, but it could
possibly be related to another problem that I see when I run your code

  • specifically when the time has become negative (in a signed sense).

I notice that if you send a packet to transmit around 0x80000000, the
math seems to skip the packet every time due to your +/- JITTER on your timestamp during the WAIT state. I consistently see the state
transition from WAIT -> IDLE. I can get around this by comparing to
the exact value during your first if statement on line 125 of
chan_fifo_reader.v, so compare (timestamp == adc_time) instead of
doing a comparison with the jitter.

Greater Than/Less Than might not be a good check since we just have a
free running counter. The `JITTER is a decent idea, but I think you
need to either check a larger range or setup some type of
synchronization between the host and the counter to have 0 be the
beginning of a new TDMA slot/frame/epoch/what have you and only count
into positive time.

I think this would be a bit more difficult but possible if there is a
command that can set the counter modulus and reset the counter to a
load value that is some difference between the interested time and the
current time. For example, I receive a packet and process it and
notice a correlation at time N mod M. The counter is obviously at
time N+x mod M, but I know that N should be my synchronization time.
If I could send a control packet down to the USRP to set my “reset”
time to N, I should be able to subtract down that N from my free
running counter to synchronize with my timed system, but this all adds
some decent complexity to an already unfinished system.

Brian