Re: [Discuss-gnuradio] Hardware advice for TDMA MAC implementation

[Guy Holtzman]

Hi Again, and thanks for you answer :) . (I was out yesterday, so I did not see your answer)

As I understood the lead time is a jitter buffer inside the USRP, which buffers the samples before it launches them to the air. This buffer is limited by the FPGA memory. for example, if one  configures the lead time to a too large number, it will cause an over run.

since B100 uses a smaller FPGA, and does not have SRAM memory, is it possible that the lead time that could be configured is limited to a number which is smaller than the jitter? I know it depends on the host computer and on the application running on it. in other words, is there a reasonable margin to play with? 

could you please send the Presentation file which is seen on the video, it cannot be found on git.

Thanks Again,

Guy

On Mon, Jan 21, 2013 at 9:09 PM, John Malsbury <address@hidden> wrote:

Guy,

Sorry for the the delayed response.  You seem to have a reasonable understanding of the way timestamps and tags are working in GNU Radio.

Here's a basic overview of how the pre-cog TDMA block works.  To get a sense of time the block reads samples from a UHD source.  When streaming starts, the UHD source block issues a rx_time and rx_rate tags.  After receiving these tags, the block will count sample to maintain knowledge of the USRP time.

The block will schedule a transmission to occur based on several parameters - slot interval and count, guard interval, etc.  To ensure that the tagged samples arrive to the USRP DSP chains before the transmit time passes, the block will produce the frame and output sometime before that transmit time.  The parameter 'lead_limit' sets how far in advance the block will produce the frame, and should be set to the worst case delay caused by process timing jitter on the host and interface  latency.  IIRC, I've tested this with 1-5 ms slots, 2-10 slots per frame, and a lead limit of about 5 ms with the USRP N210.  Typical data rates I tested were between  250 kbps to 1 mbps.  You might specify a different lead limit with the B100.

The demo I've run uses 1 PPS to sync the USRPs.  In theory, with a few small modifications, you could set the USRP time based on time of received frames instead.  You will need to understand and account for additional latency when you set the time of the USRPs, and your guard intervals will probably need to be larger.

This TDMA implementation is mostly a proof-of-life.  I'll be glad to help you get something running, and can advise on worthwhile improvements to this implementation.  Porting to C++ is one obvious suggestion to improve performance.

-John

On Mon, Jan 21, 2013 at 6:16 AM, Guy Holtzman <address@hidden> wrote:

I am thinking of developing a TDMA MAC + PHY using GNURadio for low speed  communication (upto 200KBits per second) for prototyping. since OpenBTS has successively implemented a GSM BS using GNURadio, this seems to be a reasonable choice. but unlike OpenBTS, I want to avoid HW (clock changes) or FPGA programming and develop only on the GNURadio Platform.

recently I have seen the pre-cog (or EasyMAC) project presentation using the USRP N210:

www.youtube.com/watch?v=pF_4dFQHAZE

wiki:

https://github.com/jmalsbury/pre-cog/wiki

as I understood (and you are welcomed to correct me if I am wrong), UHD provides a timestamp  (and tags) functionality for sending IQs and for receiving IQs, so all the latency and jitter problems will likely come from the host side (Drivers and GNU Radio application)  

since I do not need high speed data, the USB speed is more than enough. I do not know what limitations I will experience using this platform.

I don't have any USRP devices on my hands yet, due to that fact I have a few questions regarding the use of USRP B100 (and not USRP N210): 

1. What will be the expected latency using USB  what will be the maximum  jitter (unexpected latency)?, I have read the FAQ, but it is too theoretical, and the paper from 2007 could be out of date ( http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQLatency ) 
   
2. The USRP1 had accuracy problems with the clock when using OpenBTS, was this problem solved with USRP B100? in other words, could two or more USRPs work on a TDMA network without an external common clock?
   
3. what will be the minimum acceptable time slot duration on a system that does not require ACK mechanism?
   
4. on a system that requires ACK response  what would be a minimum considerable time from a packet being sent until the ACK is received?
   
5. Are the timestamps for Rx and Tx on the same USRP correlated?
6.  Are there any other considerations which can prevent EasyMAC or a similar implementation  from working?
   
7. I know GNU Radio is not a true Real-time platform when running on linux General Purpose CPUs, how will this effect the TDMA?

Thank you very much, and sorry for the long email  :)

Regards, Guy

_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio