discuss-gnuradio
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Discuss-gnuradio] Embedded GR-IEEE802-11


From: Marcus Müller
Subject: Re: [Discuss-gnuradio] Embedded GR-IEEE802-11
Date: Wed, 3 May 2017 17:49:29 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0

Hi Tom,


On 05/03/2017 05:21 PM, Thomas Wilkinson wrote:
Thanks for the reply, Marcus. That you are the only one to reply, is also telling.
Of what, exactly? That's an honest question: I, and the whole project, are pretty concerned with how make the GR community work best, I'm really not sure how to interpret that. I'm kinda infamous for replying before others had the chance to. Is that some kind of complaint that only one person reacted? Well, maybe the others simply didn't have enough to add that'd justify spending their, or their employer's, time on an answer.
Some more context may help. The GR-IEEE802-11 transceiver appears to be the best jumping off point for a radio system that takes advantage of the robust wifi/OFDM waveform.
When you need a packet radio network system, yes, that'd be the case. If you more in for a streaming thing, look at the gr-dtv digital TV systems.
As a radio, this would be implemented without a laptop or PC in an enclosed system, which is essentially why I ask about embedded implementations of GR-IEEE802-11.

More specifically, by embedded I mean size, weight, power and thermal management are limiting factors in design.While an x86 single board computer is not out of the question, it does challenge size and thermal management design criteria.
You might be significantly underestimating the computational power needed to do a complete software stack implementation of WiFi. Yes, you'll need an x86 single board computer, or a VERY beefy ARM/Sparc/... system.

Another way about this question of an embedded implementation is how much or how little does GR-IEEE802-11 rely on the FPGA?
Not at all. GNU Radio is a pure _software_ radio implementation. All the FPGA does is convert the samples to the sampling rate you need.
My understanding is that GR-IEEE802-11 has pushed time-sensitive functions like CSMA to the FPGA,
not the case.
while most other functions are processed by the CPU. I assume that pushing more onto the FPGA would reduce CPU performance requirements, making GR-IEEE802-11 "more embeddable".
Is this a viable path?
Yes, sure! But: the main motivation to implement the Wifi handling in hardware is not CPU load – it's latency, and solving that by moving MAC to the FPGA of a USRP implies that you have to implement significant parts of the PHY in FPGA hardware.
Is there room on the B210 or B200mini--as examples--to push more onto the FPGA?
Yes, there's some, limited, unused ressources on the FPGA, but the B210 and B200mini are definitely not the devices with plenty FPGA to spare. In the B2xx series, that'd be the 205mini-i.
Why not "embed" more onto the FPGA?
Simply: SDR is hard, because it's software engineering and radio engineering in one. You need experts of both fields to get significant progress at significantly optimized speed. Add FPGA engineering to that, and you need yet another steep-learning-curve skillset.

Best regards,
Marcus

On Fri, Apr 14, 2017 at 1:19 PM, Marcus Müller <address@hidden> wrote:

Hi Tom,

define "embedded". If you use an x86 or powerful multi-core ARM Single-Board-Computer, which I'd argue can be an embedded device, then sure, I don't see any limitations with that compared to what you can do on a PC. Of course, dealing with 20 MHz channels on a poor ARM processor is very hard, so this might or might not work out, and might require hand-tweaking system performance. Don't forget that if using gr-ieee-802-11, you'll need a high-bandwidth link to your SDR hardware – typically, Gigabit Ethernet or USB3, the CPU power to handle the torrent of data that enters and leaves your computer as samples through that link, the power to process that data, and only if you've got all that covered and still have CPU to spare to actually do something with your data payload, you might consider doing a sensible network data rate benchmark.

Generally, regarding rate: This is not 100.0% true, but in essence: Either your computer is fast enough to run the flow graph at the sampling rate you need to cover the full channel, or not. It's not like "my slow computer can reliably use gr-ieee-802-11, but to get great rates, I'll need a slightly faster one".
It's more like "my computer is too slow, the CPU can't keep up with the millions of samples needing processing per second, so it totally does not work", or "my computer is fast enough, it reliably works in all modes".

Best regards,

Marcus


On 14.04.2017 18:58, Thomas Wilkinson wrote:
Just wanted to push this inquiry back to the surface:

Is anyone aware of GR-IEEE802-11 having been implemented with an embedded system? If so, what is the maximum data rate achieved?

Thanks,

Tom

On Wed, Apr 12, 2017 at 3:22 PM, Thomas Wilkinson <address@hidden> wrote:
Is anyone aware of GR-IEEE802-11 having been implemented with an embedded system? If so, what is the maximum data rate achieved?

Thanks,

Tom



--
Regards,

Tom Wilkinson
MS Student, Electrical Engineering
NC State University


_______________________________________________
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
--
Regards,
Tom Wilkinson
MS Student, Electrical Engineering
NC State University
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio

reply via email to

[Prev in Thread] Current Thread [Next in Thread]