[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Discuss-gnuradio] start/end of burst issues
From: |
Brian Padalino |
Subject: |
Re: [Discuss-gnuradio] start/end of burst issues |
Date: |
Mon, 6 Aug 2007 09:48:32 -0400 |
On 8/3/07, Zhuocheng Yang <address@hidden> 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