discuss-gnuradio
[Top][All Lists]
Advanced

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

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


From: George Nychis
Subject: Re: [Discuss-gnuradio] in-band signaling & dependent packets (i.e., ACK generation)
Date: Wed, 28 Nov 2007 00:01:01 -0500
User-agent: Thunderbird 2.0.0.6 (X11/20071022)


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?


Let me find out :)

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

Mainly, yes.


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.


I totally agree that 2ms is not that bad and is something that MAC layers can certainly deal with. The goal is an attempt to be compatible with current waveforms using software radios. Are there techniques that we can use to try and achieve these low latencies without implementing the PHY fully in the hardware? This is what I'm interested in. Is any sort of sample pattern matching possible in the slightest bit?

- George





reply via email to

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