|
| From: | Thomas Wilkinson |
| Subject: | Re: [Discuss-gnuradio] Embedded GR-IEEE802-11 |
| Date: | Wed, 3 May 2017 12:05:40 -0400 |
Hi Tom,
On 05/03/2017 05:21 PM, Thomas Wilkinson wrote:
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.Thanks for the reply, Marcus. That you are the only one to reply, is also telling.
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.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.
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.
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.
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.
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.
Another way about this question of an embedded implementation is how much or how little does GR-IEEE802-11 rely on the FPGA?
not the case.My understanding is that GR-IEEE802-11 has pushed time-sensitive functions like CSMA to the FPGA,
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".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 this a viable path?
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.Is there room on the B210 or B200mini--as examples--to push 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.Why not "embed" more onto the FPGA?
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
--
_______________________________________________ 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
| [Prev in Thread] | Current Thread | [Next in Thread] |