Hi all,
I’m going to be hacking carrier sense in to the FPGA on the USRP2 very
soon. Basically, taking what I did with the “in-band” project from the
USRP1 with carrier sense, and moving it forward to USRP2.
The idea is, just like you can set a timestamp to “gate” a packet on its
way out: only transmit it at time X, you can do something similar with
carrier sense. If the burst has the carrier sense flag set, then you
wait
for the carrier to become idle, then transmit the packet.
For the in-band implementation, I had a command to set the value at
which
the carrier is determined to be busy/idle. This was stored in memory in
the FPGA. Then, when bursts came with a carrier sense bit set, that
value
is used.
OK: so I’d like to re-do this implementation to keep this kind of stuff
alive, and I will use it myself. But in doing so, I’d like to implement
it
in a way that jives well with the higher ups. If I’m going to do it,
I’d
like to do it right so that it lives on through future versions of GNU
Radio. So that means doing it using UHD.
For the life of me, I can’t find the UHD header spec. But I imagine
somewhere in there we can fit a bit to gate based on carrier sense, and
a
new command to set the carrier sense threshold.
If you have any advice/guidance on how you’d like to see this
implemented,
let me know. I sincerely would like this to live long and prosper in
GNU
Radio and the USRPs.
George,
On 03/04/2012 12:51 AM, George N. wrote:
For the life of me, I can’t find the UHD header spec. But I imagine
somewhere in there we can fit a bit to gate based on carrier sense, and
a new command to set the carrier sense threshold.
If you have any advice/guidance on how you’d like to see this
implemented, let me know. I sincerely would like this to live long and
prosper in GNU Radio and the USRPs.
I totally like and support your idea and would love to help realizing
it. Using the timestamp logic inside UHD as a reference is a great idea
that also came to my mind a while ago.
There are a few things from the architecture point of view though that
need to be discussed. Let’s take a CSMA MAC as an example, I guess that
goes into the right direction 
Just having the “if channel free,
transmit packet”-logic inside the FPGA wouldn’t make much sense in a
multi-user environment. What would happen is that if the channel is busy
and multiple nodes have packets in their tx queues, they would all end
up sending their packets more or less at the same time after the channel
gets idle again (assuming all nodes are in sensing range). In a
practical system, one would now start to move parts of the CSMA state
machine, i.e the random backoff, into the FPGA. Trying to control this
via UHD is probably a bad idea as UHD’s main business is transportation.
I do think we need something like what you have suggested but I am still
a bit puzzled about the right way of implementing it.
Best regards,
Andre
George,
I do think we need something like what you have suggested but I am still
a bit puzzled about the right way of implementing it.
Best regards,
Andre
I think a more fundamental issue is that “carrier sense” isn’t actually
defined in any kind of general way. Certainly for some types of
PHYs, you can do simple energy-presence detection. But usually, it’s
more complicated than that, and it varies widely from PHY to
PHY. In some, you’ll need to run a correlator before you even know
whether the channel is busy or not. In others, simple energy
detection works.
I don’t think there’s a general-purpose way of doing this, but that’s
just my POV.
–
Marcus L.
Principal Investigator
Shirleys Bay Radio Astronomy Consortium
On Sun, Mar 4, 2012 at 10:01 AM, Marcus D. Leech [email protected]
wrote:
defined in any kind of general way. Certainly for some types of
PHYs, you can do simple energy-presence detection. But usually, it’s
more complicated than that, and it varies widely from PHY to
PHY. In some, you’ll need to run a correlator before you even know
whether the channel is busy or not. In others, simple energy
detection works.
I don’t think there’s a general-purpose way of doing this, but that’s just
my POV.
Definitely, there are MACs whose form of carrier sense is detecting
preamble rather than detecting energy. In my same piece of work, we put
a
matched filter in the FPGA and the host specifies the coefficients of
the
match filter, then you gate on that. But, I don’t think it’s
unreasonable
to think basic energy detection is not general purpose enough? I think
supporting some basic form of energy detection would start to enable
better
MAC implementations…
and afterwards I have every intention of rolling a match filter in to
the
FPGA also. So, maybe your suggestion is I build a separate FPGA
implementation if people want MAC functionality. I can do that if
people
believe that the functionality is not general enough.
and multiple nodes have packets in their tx queues, they would all end
up sending their packets more or less at the same time after the channel
gets idle again (assuming all nodes are in sensing range). In a
practical system, one would now start to move parts of the CSMA state
machine, i.e the random backoff, into the FPGA. Trying to control this
via UHD is probably a bad idea as UHD’s main business is transportation.
I do think we need something like what you have suggested but I am still
a bit puzzled about the right way of implementing it.
Hi Andre,
Yeppp, the idea is to build part of the MAC in to the FPGA… the part
that
requires low latency operation. So, after the simple “transmit when
idle”
logic, you put some basic form of back off in to the logic also.
I have a paper which argues low latency MAC functionality should be
built
in to the FPGA, but controlled from the host, otherwise it’s as good as
worthless implementing it on the host. If you try to build this part of
the MAC at the host, the latency of receiving the channel state (latency
from FPGA → host), making a decision and performing an action (host →
FPGA), completely makes the information stale. You end up with a
decision
that is something like 1-2ms old, which clearly the state of the channel
changes at a more finer-grain than that.
Sooo… you either implement this kind of functionality in a “split”
kind
of way where the function sits in the FPGA since it requires low
latency,
or it’s as good as worthless 
I’d rather have some form of carrier
sense
that’s commonly used in some side-FPGA implementation, rather than
throwing
in the towel and saying GNU Radio and the USRP’s architecture can never
support something like this that’s usable due to the latency. I get
tons
of e-mails about my split-functionality MAC work, asking if it’s usable
but
it got deprecated along with the m-block, so there is a set of users out
there that I think would be happy with some basic usable carrier sense
and
back-off. Otherwise we’re constantly in the: let’s avoid the whole idea
of
support a true MAC thing, and GNU Radio and USRP continue life as a
source/sink.
(http://dl.acm.org/citation.cfm?id=1558984)
On 03/04/2012 04:01 PM, Marcus D. Leech wrote:
PHYs, you can do simple energy-presence detection. But usually, it’s
more complicated than that, and it varies widely from PHY to
PHY. In some, you’ll need to run a correlator before you even know
whether the channel is busy or not. In others, simple energy
detection works.
I don’t think there’s a general-purpose way of doing this, but that’s
just my POV.
You’re absolutely right, Marcus. I also think it’d be quite difficult to
find a truly general-purpose solution to that.
Knowing George’s field of interested, I was assuming something like a
simple energy detector. I think even this simple example shows the
difficulties quite clearly.
-Andre
On 03/04/2012 04:10 PM, George N. wrote:
up sending their packets more or less at the same time after the channel
(host -> FPGA), completely makes the information stale. You end up with
a decision that is something like 1-2ms old, which clearly the state of
the channel changes at a more finer-grain than that.
Well, I believe it’s just a matter of scaling the whole system by the
right factor. Information that is 1ms old can still be valuable if it
still represents the truth.
I just don’t want to loose all the flexibility of software by moving the
critical but interesting things to hardware.
But of course, it all depends upon your goals.
-Andre
In the amateur radio world, AX.25 “packet radio” terminal node
controllers supported KISS mode, which left the CSMA and HDLC framing
in the TNC but offloaded the state-machine for connection management to
the host CPU stack.
KISS merely provided a way to forward the frame metadata and payload
over the serial link between the TNC and the host. With buffering at
each end of the serial link to the TNC, knowing exactly when a specific
frame of data has been transmitted on air is impossible and this causes
some grief in the Linux kernel’s internal implementation of the state
machines for connected mode AX.25, specifically when scheduling
retransmissions.
To be fair, we are talking about fairly large buffers and fairly low
bit-rates on tx here - 1200 baud typically, but nugatory retransmission
due to channel state backoff without backpressure is a bugger.
I assume that we would want a control plane that can provide that kind
of feedback, and would want some way of tagging transmission data units
as requiring some kind of notification of transmission on-air.
I’m very new in the gr world so can’t talk with authority on anything
other than provide vague waffle such as this for your consideration.
Cheers,
Darren, G0HWW
Let me put it this way… I’m going to build it because I need it 
But
what I’m asking/hoping for is for it to be useful beyond just me and
actually have a lifespan beyond my immediate use of it. So, I’d like to
get some feedback on how others might like to see it tied in to UHD, or
the
type of flexibility the implementation should have. For example, the
programmability of the threshold, the type of back off, the control of
the
back off, etc.
You don’t get these types of people on the list very often because they
simply look at GNU Radio and USRPs architecture and go: well, it doesn’t
support that… moving right along to another platform (e.g., WARP,
Sora,
etc.). But speaking from my area (wireless networking, not so much
wireless communications), it is this kind of functionality that a lot of
people want/need to build a network on top of the OFDM code, for
example.
You can say that energy sensing isn’t general enough or any
implementation
of it wouldn’t be general enough, but IMO staying away from it more
significantly limits possible applications of the platform rather than
expanding it. I think this type of functionality can further support a
new
set of applications and networks. I don’t feel as though it threatens
the
flexibility of GNU Radio because it’s not fundamentally changing the
architecture. It’s exploiting the tight-control that UHD was put in
place
to try and enable. It’s functionality that sleeps in the FPGA unless you
need it to build your application.
Like I said, I can build it as a separate FPGA firmware for those who
want
to use the functionality (though I fear it gets deprecated quite quickly
in
that way)… but it would be good to hear what kind of functionality and
flexibility people would like to see in a carrier sense implementation,
how
it could be controlled, etc. Otherwise, I will go off and “do my thang”
and you simply get what comes out of it
On Mon, Mar 5, 2012 at 9:26 AM, David K. [email protected]
wrote:
George. I have been using the USRP1 for a few years now, using code based
on the old deprecated mblock code (and your code too!) and there have been
a
few times when I have wondered about whether I needed to crack open the
FPGA
code or not… and suffer through the re-fitting and then the required
timing verification that this would require above and beyond verifying any
functional changes I was considering in Verilog.
Thanks David! This kind of thing can impact the design of what I build.
What in particular were you thinking about opening up the FPGA to
modify
that you felt it wasn’t flexible enough?
I just don’t want to loose all the flexibility of software by moving the
critical but interesting things to hardware.
(* But of course, it all depends upon your goals. *)
George (and others),
I think that the above statement is the
basic
issue here and seems to summarize the issues with offering a ‘solution
for
everyone’; although, offering to do this is still noble sentiment from
you,
George. I have been using the USRP1 for a few years now, using code
based
on the old deprecated mblock code (and your code too!) and there have
been a
few times when I have wondered about whether I needed to crack open the
FPGA
code or not… and suffer through the re-fitting and then the required
timing verification that this would require above and beyond verifying
any
functional changes I was considering in Verilog.
How about a middle ground to provide the ultimate programmable state
machine? Would it be feasible, in terms of gate count and IP/GnuPL
licensing terms, to include a small processor core in the FPGA and to
define
a messaging interface to GnuRadio_proper? This could be 8051-like or
maybe
a GPL 32-bit LEON3 or…
If this processing core code had parallel access to sampled I/Q baseband
data in both directions and could be ‘programmed’ dynamically (maybe
supporting two loads in RAM) from the main code and IF (big if) it could
‘keep up’ well enough with the baseband data to do things like calculate
power and/or frame on specific baseband data symbols, make other
decisions
e.t.c. …and then buffer to/insert sequences from data in FPGA ‘RAM’
without substantial further processor involvement, the flexibility
required
by different people could be managed (and managed by them) as different
micro software loads in FPGA RAM.
A real-time messaging mechanism between the two software domains would
allow
PC-based Gnuradio software to steer the lower-level code at a higher
level,
if required, and also to read status information from it too. Ideally,
this
would be a streamed communication mechanism, which piggy-backed on the
I/Q
samples, allowing samples to be tagged anywhere along the signal
processing
chain in either direction. This is not required, however. The
discussion
of applications so far in this thread would seem to be well-served by a
pair
of registers on the FPGA containing one or two shared-memory boolean
flags
in each direction.
Probably more than my two cent allotment. / David K.
View this message in context:
http://old.nabble.com/building-carrier-sense-in-the-FPGA-and-UHD-tp33436450p33443808.html
Sent from the GnuRadio mailing list archive at Nabble.com.