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".
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
_______________________________________________
Discuss-gnuradio mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
|