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 <[email protected]> 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 > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > >
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
