Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)

[Brian Padalino]

On Nov 27, 2007 10:43 PM, George Nychis <address@hidden> wrote:
> To measure the round trip latency we used three USRPs... two in
> contention and a third monitoring.  The two in contention would exchange
> the channel back and forth by reading the RSSI value from the incoming
> packets.  To spare the details and cut to the chase, we measured the gap
> between the time the channel went idle, the contending node detected it
> was idle, and began transmitting.  This is essential measuring dependent
> packets and host-level carrier sense performance.
>
> The average was 1.96ms and sdev 0.62ms.

That doesn't seem too bad to me.

> What do you mean by synchronizing?

Lets say for a TDMA MAC, there is a beaconing time that happens every
50ms for 1 ms and a 200us guard time between beacons for a specified
number of radios.

Can you setup a USRP to transmit some data every 50ms, and have a
second USRP lock on to that periodic 50ms transmission and be sure to
be on the air at 51.2ms +/- 10us?  Is this a reasonable expectation?

> Tens of microseconds would be great... but I'm not sure if this is
> achievable?  Hundreds of microseconds would be decent :)

Is there any driving reason for a requirement of tens of microseconds?
 Is it mainly to be compatible with 802.11 style systems?

To be honest, I feel that trying to achieve the turnaround of tens of
microseconds is too lofty a goal without creating a special FPGA load
for that specific waveform.  I am not saying a custom FPGA load is a
good or bad thing - I just think you can't go over USB and have the
host do processing to then go back over USB for a response.  There's
just too much to do for it to basically be a real-time system.

I feel that if you give a minimum latency of 2ms that there won't be
issues creating latency tolerable MAC layers.

On the other hand, being compatible with current waveforms that may be
completely implemented in custom ASICs might be a bit of a problem.

Brian