discuss-gnuradio
[Top][All Lists]
Advanced

[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




reply via email to

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