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:
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):
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 )
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?
what will be the minimum acceptable time slot duration on a system
that does not require ACK mechanism?
on a system that requires ACK response what would be a minimum
considerable time from a packet being sent until the ACK is received?
Are the timestamps for Rx and Tx on the same USRP correlated?
Are there any other considerations which can prevent EasyMAC or a
similar implementation from working?
I know GNU Radio is not a true Real-time platform when running on
linux General Purpose CPUs, how will this effect the TDMA?
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.
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.
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.
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 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?
. (I was out yesterday, so I did