Quick reply to your first point: I apologize that my comment was not clear. It was no complaint at all. I asked about a very specific application of GR-IEEE802-11, namely whether anyone had tried to implement it using an embedded system. It has been almost a month (12APR) since I initially posted the inquiry. No one replied, and I reposted two days later (14APR), to which you replied. Since then (almost three weeks) no one else has weighed in. I am not being critical of the community. I simply take this lack of response to be "telling" of whether someone has tried to do what I am proposing. In this case silence is not affirmation. I'm not being critical of the community, I take the lack of a response as an answer to my question.
On Wed, May 3, 2017 at 11:49 AM, Marcus Müller <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> >> 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 >> SMART Scholar <http://smart.asee.org/> >> MS Student, Electrical Engineering >> NC State University >> c: 919.951.4449 <%28919%29%20951-4449> >> e: [email protected] >> >> >> _______________________________________________ >> Discuss-gnuradio mailing >> [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >> >> _______________________________________________ Discuss-gnuradio mailing >> list [email protected] https://lists.gnu.org/mailman/ >> listinfo/discuss-gnuradio > > -- > Regards, > Tom Wilkinson > SMART Scholar <http://smart.asee.org/> > MS Student, Electrical Engineering > NC State University > c: 919.951.4449 <%28919%29%20951-4449> > e: [email protected] > > _______________________________________________ > Discuss-gnuradio mailing > [email protected]https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > > _______________________________________________ > Discuss-gnuradio mailing list > [email protected] > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio > > -- Regards, Tom Wilkinson SMART Scholar <http://smart.asee.org/> MS Student, Electrical Engineering NC State University c: 919.951.4449 e: [email protected]
_______________________________________________ Discuss-gnuradio mailing list [email protected] https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
