buffer
management is hard, but not impossible.
Best,
Miklos
On Fri, Jun 11, 2021 at 10:42 PM Marcus Müller
wrote:
> Hi Nick,
>
> On 11.06.21 16:58, Nicholas Long wrote:
> > Hi, so I have been wondering what people do to implement mac layer type
> things with GNURadio?
> >
Hi Nick,
On 11.06.21 16:58, Nicholas Long wrote:
> Hi, so I have been wondering what people do to implement mac layer type
> things with GNURadio?
> (for example automatic detection/handshaking type protocols before
> transmitting digital
> data packets.)
Well, "we" (
Hi, so I have been wondering what people do to implement mac layer type
things with GNURadio?
(for example automatic detection/handshaking type protocols before
transmitting digital data packets.)
>From my perspective gnuradio is good for physical layer development, but
less so for state mach
On Mon, Mar 18, 2019 at 01:16:32AM +0530, Rachuri Sri Pramodh wrote:
>Hi GNU Radio Community,
>As suggested by Marcus, I have made a design plan which can be found in
>the attached proposal for GSOC.
Rachuri,
thanks for submitting! You need to make modifications to make this
follow th
tion of MAC layer
on FPGA because of time-sensitive tasks. There are several attempts
addressing this issue for SDRs(There are also pure hardware implementations
for PHY and MAC layer like WARP project), I found the followings:
1. An IEEE 802.11 MAC Software Defined Radio Implementation
Hi everyone,
I am trying to develop a MAC layer protocol on the USRP. Is there any thing
that would help me.
Thanks___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi everyone,
I am trying to develop a MAC layer protocol on the USRP. Is there any thing
that would help me.
Thanks___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Hi everyone,
I am trying to develop MAC implementation on the USRP. Is there any thing that
would help me do that.
Thanks___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
On 04/24/2012 10:10 AM, Josh Stevens wrote:
> Hey All,
>
>I have explored the basic functions that benchmark_tx and rx
> provide with modulation support (generic_mod_demod) , packet construction
> and recovery but what im trying to develop is a MAC layer implemen
Hey All,
I have explored the basic functions that benchmark_tx and rx
provide with modulation support (generic_mod_demod) , packet construction
and recovery but what im trying to develop is a MAC layer implementation
over a single carrier with the help of a customized packet structure
On 07/06/2011 07:33 PM, Morgan Redfield wrote:
> I'm still working on my MAC, and there's a lot of room for
> improvement. At the moment, I get throughput of about 1kbps. What kind
> of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using
On 07/06/2011 07:33 PM, Morgan Redfield wrote:
> I'm still working on my MAC, and there's a lot of room for
> improvement. At the moment, I get throughput of about 1kbps. What kind
> of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using
On 07/06/2011 07:33 PM, Morgan Redfield wrote:
> I'm still working on my MAC, and there's a lot of room for
> improvement. At the moment, I get throughput of about 1kbps. What kind
> of throughput are you getting?
In a setup of two nodes we have a end-to-end throughput (measured using
iperf using
I'm still working on my MAC, and there's a lot of room for
improvement. At the moment, I get throughput of about 1kbps. What kind
of throughput are you getting?
Andre and George, thanks for pointing me to those papers. I'll look
through them and see if I can figure out any ways to improve my MAC.
On 07/01/2011 03:16 AM, Morgan Redfield wrote:
> Hi,
>
> I've been working on building a CSMA/CA MAC for the past couple of
> weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
> working now, but I don't think it's very efficient. I ended up having
> to relax a lot of timing par
On Sun, Jul 3, 2011 at 8:16 AM, Tom Rondeau wrote:
> On Thu, Jun 30, 2011 at 9:16 PM, Morgan Redfield wrote:
>
>> Hi,
>>
>> I've been working on building a CSMA/CA MAC for the past couple of
>> weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
>> working now, but I don't think
On Thu, Jun 30, 2011 at 9:16 PM, Morgan Redfield wrote:
> Hi,
>
> I've been working on building a CSMA/CA MAC for the past couple of
> weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
> working now, but I don't think it's very efficient. I ended up having
> to relax a lot of t
Sorry for the brevity, traveling abroad and only have my phone. I am
the author of the MAC code in cgran and have a paper on the work, give
it a read: Enabling MAC Protocol implementations on software-defined
radios. It gives you an idea of what all we did to gnu radio to build
Macs and what the sp
Hi,
I've been working on building a CSMA/CA MAC for the past couple of
weeks. I built it in Python, and used ofdm/tunnel.py as a guide. It's
working now, but I don't think it's very efficient. I ended up having
to relax a lot of timing parameters to get it working, so my
throughput is pretty bad.
On Wed, Apr 7, 2010 at 4:54 PM, Per Zetterberg wrote:
> Dear All,
>
> Regarding MAC layer development I would like to empasize on the importance
> of time-stamps. With time-stamps we can at least do slotted schemes. Maybe
> non-slotted schemes can be approximated by slotted ones ?
Dear All,
Regarding MAC layer development I would like to empasize on the
importance of time-stamps. With time-stamps we can at least do slotted
schemes. Maybe non-slotted schemes can be approximated by slotted ones ?
BR/
Per
___
Discuss-gnuradio
John-
>> Which part of the Linux issue... sustained throughput or latency? I
>> wouldn't be surprised to find that latency
>> hasn't
>> improved substantially because it's not a priority for server software.
>> Even VoIP applications are not concerned
>> about a 1 msec improvement... whereas t
Marcus-
> On 04/06/2010 09:44 PM, John Gilmore wrote:
>>> Which part of the Linux issue... sustained throughput or latency? I
>>> wouldn't be surprised to find that latency
>>> hasn't
>>> improved substantially because it's not a priority for server software.
>>> Even VoIP applications are not
n the board. Good luck conjuring up
>> $10-15k
>> > just for a single WARP board plus frontends though :P
>>
>> Is there anything that would prevent GNUradio developers to push the
>> MAC layer functionality on the USRP?
>>
> The USRP and USRP2, from what I unde
George-
>> Did you see my previous post about the accelerator PCIe card? To some
>> extent the Microsoft approach is what we're
>> doing. But we want to stay compatible with USRP2 hardware so we connect
>> GbE to the accelerator card; non MAC-related
>> dataflow is PCIe from there. Buffering re
On 04/06/2010 09:44 PM, John Gilmore wrote:
>> Which part of the Linux issue... sustained throughput or latency? I
>> wouldn't be surprised to find that latency hasn't
>> improved substantially because it's not a priority for server software.
>> Even VoIP applications are not concerned
>> about
> Which part of the Linux issue... sustained throughput or latency? I wouldn't
> be surprised to find that latency hasn't
> improved substantially because it's not a priority for server software. Even
> VoIP applications are not concerned
> about a 1 msec improvement... whereas that makes or br
rd plus frontends though :P
> >
>
> Is there anything that would prevent GNUradio developers to push the
> MAC layer functionality on the USRP?
>
>
The USRP and USRP2, from what I understand, are both tight for space in the
FPGA. I'm pretty confident you can't fit an OFDM im
PS. if you haven't seen, SORA is able to interoperate with 802.11g, which
is impressive. It meets all of the timing requirements. However, it does
not come with the exact ease of programming that we're familiar with. They
do have to push the use of SSE and tradeoff a lot of computation for memo
>
> Did you see my previous post about the accelerator PCIe card? To some
> extent the Microsoft approach is what we're
> doing. But we want to stay compatible with USRP2 hardware so we connect
> GbE to the accelerator card; non MAC-related
> dataflow is PCIe from there. Buffering required to st
On Tue, Apr 6, 2010 at 5:35 PM, Jeff Brower wrote:
> Philip-
>
> > On 04/06/2010 04:19 PM, George Nychis wrote:
> >> Jeff, I definitely agree that buffering also adds significant latency.
> How
> >> much of the MAC can you get around? I just think that, there are a
> number
> >> of people who w
Charles-
>> I would tend to blame Linux and buffering more than GbE itself (MAC + PHY).
>> Here is an interesting doc where the
>> researchers were asking similar questions:
>>
>> http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf
>>
>> I'm not sure yet how much buffering is d
Philip-
> On 04/06/2010 04:19 PM, George Nychis wrote:
>> Jeff, I definitely agree that buffering also adds significant latency. How
>> much of the MAC can you get around? I just think that, there are a number
>> of people who want the flexibility of the SDR, but want to do MAC research,
>> and
George-
> Jeff, I definitely agree that buffering also adds significant latency. How
> much of the MAC can you get around? I just think that, there are a number
> of people who want the flexibility of the SDR, but want to do MAC research,
> and current common SDR architecture is just not good en
lly think we need a better interface to reduce
> latency. Some platforms take the: run on the board approach, such as WARP
> which puts the MAC on a core on the board. Good luck conjuring up $10-15k
> just for a single WARP board plus frontends though :P
>
Is there anything that wou
On 04/06/2010 04:19 PM, George Nychis wrote:
Jeff, I definitely agree that buffering also adds significant latency. How
much of the MAC can you get around? I just think that, there are a number
of people who want the flexibility of the SDR, but want to do MAC research,
and current common SDR ar
Jeff, I definitely agree that buffering also adds significant latency. How
much of the MAC can you get around? I just think that, there are a number
of people who want the flexibility of the SDR, but want to do MAC research,
and current common SDR architecture is just not good enough. We need lo
> I would tend to blame Linux and buffering more than GbE itself (MAC + PHY).
> Here is an interesting doc where the
> researchers were asking similar questions:
>
> http://www.hep.man.ac.uk/u/rich/atlas/docs/atlas_net_note_draft5.pdf
>
> I'm not sure yet how much buffering is done in the USRP2
Two independent PC+USRP nodes. All the ACK related logic was
implemented at the Python layer.
Another thing that I tried was to connect the two nodes via Ethernet
(I have two Ethernet NICs in each of the PCs) and then use USRPs for
data and Ethernet for ACKs. I still couldn't get good results,
alt
Veljko-
> I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but
> the delay was too long and inconsistent. I can't remember the exact
> figures, but definitely up to milliseconds.
Do you mean two USRP2s back-to-back? Or both connected to motherboard ports?
-Jeff
> 2010/4/6 George
I tried with a stop-and-wait ARQ and two USRP2s with XCVR2450s, but
the delay was too long and inconsistent. I can't remember the exact
figures, but definitely up to milliseconds.
Veljko
2010/4/6 George Nychis :
>
>
> On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick wrote:
>>
>> Thanks for the rep
George-
>> Thanks for the reply George. I'm still looking for a little more
>> information on this topic.
>>
>> - What is PMT
>
> http://gnuradio.org/redmine/wiki/1/TypePMT
>
>> - Why was m-block removed
>
> http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/msg00066.html
>
>> - Has anyone measured
On Tue, Apr 6, 2010 at 10:07 AM, Charles Irick wrote:
> Thanks for the reply George. I'm still looking for a little more
> information on this topic.
>
> - What is PMT
>
http://gnuradio.org/redmine/wiki/1/TypePMT
> - Why was m-block removed
>
http://osdir.com/ml/discuss-gnuradio-gnu/2010-01/m
aw. (3)
> kind of depends on whether you use realtime scheduling and how your
> data hits delays in queues mainly.
>
> All in all... still an open problem IMO.
>
> - George
>
>
> On Sun, Mar 14, 2010 at 5:06 PM, Charles Irick wrote:
>> I've been reading some pa
at 5:06 PM, Charles Irick wrote:
> I've been reading some papers related to MAC layer development on the
> USRP, but they seem to have tapered off with the USRP2. Does anyone
> have any information about MAC layer and protocol development for the
> USRP2. Has this been satisfied with
I've been reading some papers related to MAC layer development on the
USRP, but they seem to have tapered off with the USRP2. Does anyone
have any information about MAC layer and protocol development for the
USRP2. Has this been satisfied with things like timestamps and gigE?
Any current pape
Doug Geiger writes:
> As far as my understanding goes, there is not a complete
> implementation of the 802.11b-spec MAC. The files you've found are, to
> the best of my knowledge, the only released code out there
> implementing a partial MAC (i.e. it performs some carrier-sensing
> functions in
Juan Ramon Gutierrez Agullo wrote:
Hello
I've been analyzing the BBN project code (trunk and branches versions)
and I can't understand how is the MAC layer working.
As the standard 802.11 says, the minimal functionality is CSMA/Carrier
Avoidance but I haven't seen any impleme
Hello
I've been analyzing the BBN project code (trunk and branches versions)
and I can't understand how is the MAC layer working.
As the standard 802.11 says, the minimal functionality is CSMA/Carrier
Avoidance but I haven't seen any implementation in this project.
Which par
Hi Chin-Ya,
MAC implementations are currently a work in progress in GNU Radio, that
is making headway with the new m-blocks and in-band signaling but not
done yet.
You do not need a true MAC layer to transmit packets. The PHY
transforms bits in to some waveform, right? There is nothing
Hey,
Does gnuradio implement any MAC layer thinngs, otherwise how the ofdm send and
receive packets?
Thanks
Chin-Ya
___
Discuss-gnuradio mailing list
Discuss-gnuradio@gnu.org
http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
51 matches
Mail list logo
