Yes, Thanks
On Wed, Jan 23, 2013 at 8:33 PM, Josh Blum <[email protected]> wrote: > > > On 01/23/2013 12:18 PM, Guy Holtzman wrote: > > 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? > > Actually its the opposite, too little, and you would see an underflow. > Too large, lets say to buffer on the device, then the production of > transmit samples backs up onto the host, so its a non issue. > > > > > could you please send the Presentation file which is seen on the video, > it > > cannot be found on git. > > > > This presentation? > > https://github.com/guruofquality/grextras/blob/f02da842d31c55c44510117efa0ba5f82e2fca90/pre_cog_pres.pdf > > -josh > > > > Thanks Again, > > Guy > > > > > > On Mon, Jan 21, 2013 at 9:09 PM, John Malsbury <[email protected] > >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 <[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 > > > > _______________________________________________ > 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
