|
From: | Guy Holtzman |
Subject: | Re: [Discuss-gnuradio] Hardware advice for TDMA MAC implementation |
Date: | Mon, 3 Jun 2013 22:34:44 +0300 |
Yes, ThanksOn Wed, Jan 23, 2013 at 8:33 PM, Josh Blum <address@hidden> wrote:
Actually its the opposite, too little, and you would see an underflow.
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?
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.
This presentation?
>
> could you please send the Presentation file which is seen on the video, it
> cannot be found on git.
>
https://github.com/guruofquality/grextras/blob/f02da842d31c55c44510117efa0ba5f82e2fca90/pre_cog_pres.pdf
-josh
>>> 1. What will be the expected latency using USB what will be the
> 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):
>>>
>>> maximum jitter (unexpected latency)?, I have read the FAQ, but it is too>>> 2. The USRP1 had accuracy problems with the clock when using OpenBTS,
>>> theoretical, and the paper from 2007 could be out of date (
>>> http://gnuradio.org/redmine/projects/gnuradio/wiki/UsrpFAQLatency )
>>> was this problem solved with USRP B100? in other words, could two or more>>> 3. what will be the minimum acceptable time slot duration on a system
>>> USRPs work on a TDMA network without an external common clock?
>>> 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
>>>
>>>
>>
>
>
>
> _______________________________________________
> Discuss-gnuradio mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Prev in Thread] | Current Thread | [Next in Thread] |