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

[John Malsbury]

Guy,

Thanks for trying out pre-cog.  I am glad you got it working, despite the poor documentation.  Its worth mentioning that there's an effort to incorporate some of the functionality of pre-cog into gnuradio.

"sample rate is set to 256000, any other value didn't work, but"

What does it mean when it "didn't work?  Did the application produce an error?  Or did you just never see data transfer between the two radios?  Are you seeing any "L's" in the output of the program by any chance?  You might also increase the "lead limit", which is the amount of time in advance of the transmission the flowgraph actually sends the data to the USRP.  Also, I assume you are actually running two instances of this program.  Can copy the command line w/ parameters that you are using into your next e-mail?

-John

On Mon, Jun 3, 2013 at 12:34 PM, Guy Holtzman <address@hidden> wrote:

I started to work on making the TDMA work on two B100s with WBX I have.

I have them connected to a common 1 pps (rubidium based clock refrance) and 10MHz clock

the computer I am working in is a bit old, dell latitude 620, with ubuntu 12.04 LTS

I have all the latest software installed

the simple mac (without TDMA) from the pre-cog examples dir works fine with a one exception:

the sample rate is set to 256000, any other value didn't work, but this is not related to the MAC since even with a simple FM example the default sample rate (1e6) did not work.

my other problem is that the slot size on 10 ms did not work at all, and increasing the slot size to 40ms worked, but with many problems. one on them was underflow occurred almost always.

how can I set the parameters to suit my B100 and my "not state of the art" computer?

how can I solve the sample rate problem? the problem is not related to the rate itself since 250000 does not work while 256000 does work (and they both divide by 64MHz with an even result, the clock I am using)

Thanks, Guy

On Wed, Jan 23, 2013 at 10:46 PM, Guy Holtzman <address@hidden> wrote:

Yes, Thanks

On Wed, Jan 23, 2013 at 8:33 PM, Josh Blum <address@hidden> 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 <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
>>>
>>>
>>
>
>
>
> _______________________________________________
> 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