# GNU Radio / Software Radio conceptual question **URL:** \ **Category:** GNU Radio\ **Created:** [June 17, 2014, 4:27am UTC](https://www.ruby-forum.com/t/gnu-radio-software-radio-conceptual-question/230409 "2014-06-17T04:27:29Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![jason\_sam](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/j/7993a0/32.png) [@jason\_sam](https://www.ruby-forum.com/u/jason_sam)\ **Post date:** [June 17, 2014, 4:27am UTC](https://www.ruby-forum.com/t/gnu-radio-software-radio-conceptual-question/230409/1 "2014-06-17T04:27:29Z")
Hi all, I have a relatively high level question regarding gnuradio and software radio in general. Is it a fair generalization to say that gnuradio is operating at the application layer and is essentially emulating a physical layer implementation (or the implementation of other lower layer protocols)? For example, if I have a link between two USRPs (more specifically, N series USRPs), the digitally sampled received data comes in on the ethernet NIC and moves up the stack to the software radio “application.” The signal processing that would typically be done in lower layers is then handled by the application. The second part of my question is, given a flow graph in gnuradio, what sort of steps would be necessary to “push it back down the stack” or implement in a chipset such that it can be used as an interface in a typical network stack? Is this something that anyone using gnuradio has considered or should I assume the next step would involve re-implementation? NOTE: This is by no means for a commercial product, but rather for demonstration. My research has led me to use gnuradio for some proof of concept implementations and I’m curious how much additional effort would be required to port the work to a practical device - for example, implementation on a smart phone. (you can read this as “will it cause me to postpone graduation a few weeks? months? years?”) Thanks in advance - any input is greatly appreciated. Regards, Michael R. PhD Candidate Boston University, Boston, MA ---
**Author:** ![roa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8e7dd6/32.png) [@roa](https://www.ruby-forum.com/u/roa)\ **Post date:** [June 17, 2014, 4:41am UTC](https://www.ruby-forum.com/t/gnu-radio-software-radio-conceptual-question/230409/2 "2014-06-17T04:41:11Z")
On 06/16/2014 10:24 PM, Michael R. wrote: > typically be done in lower layers is then handled by the application. > of concept implementations and I’m curious how much additional effort > Boston University, Boston, MA This presentation is several years old at this point, but I give it to ham-radio clubs from time to time: [http://www.sbrac.org/files/sdr\_introduction.ppt](http://www.sbrac.org/files/sdr_introduction.ppt) ---
**Author:** ![roa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8e7dd6/32.png) [@roa](https://www.ruby-forum.com/u/roa)\ **Post date:** [June 17, 2014, 11:33am UTC](https://www.ruby-forum.com/t/gnu-radio-software-radio-conceptual-question/230409/3 "2014-06-17T11:33:20Z")
On 17.06.2014 04:24, Michael R. wrote: > I have a relatively high level question regarding gnuradio and software > radio in general. Is it a fair generalization to say that gnuradio is > operating at the application layer and is essentially emulating a > physical layer implementation (or the implementation of other lower > layer protocols)? For example, if I have a link between two USRPs (more > specifically, N series USRPs), the digitally sampled received data comes > in on the ethernet NIC and moves up the stack to the software radio > “application.” The signal processing that would typically be done in > lower layers is then handled by the application. In most cases, GNU Radio handles pretty much what comes out of the A/D converter (well, not quite, there’s some decimation and filtering in there. But for the sake of this argument, this is irrelevant). So, we have this: ADC → GNU Radio → DAC To say GNU Radio “operates at application layer” would therefore be not good description of what it does; it doesn’t “emulate a PHY”, it _is_ the PHY for all intents and purposes. This is the software radio principle: Using A/D converters, we bring the software very close to the antenna. This is not an academic view on things. While most wireless devices (and I guess that means mobile phones) are what you could call “hardware radio”, i.e. they have dedicated circuits to do the PHY, many other applications such as base stations are actually driven by software. So when you say data “moves up the stack”, it’s not going up the stack in terms of ISO/OSI layers. The means of getting the sample data (which is the raw signal, even before the PHY layer) to the software are just slightly more elaborate than having the PHY chip connected directly to the ADC. GNU Radio was specifically designed to implement PHYs, it can also implement MACs. Above that, you would probably use something else. > The second part of my question is, given a flow graph in gnuradio, what > sort of steps would be necessary to “push it back down the stack” or > implement in a chipset such that it can be used as an interface in a > typical network stack? Is this something that anyone using gnuradio has > considered or should I assume the next step would involve re-implementation? I’m not sure what you’re trying to do here. Maybe what you’re trying to do is what Balint and John have done with their gr-mac module, which allows you to create a TCP/IP connection over your own user-defined PHY? > NOTE: This is by no means for a commercial product, but rather for > demonstration. My research has led me to use gnuradio for some proof of > concept implementations and I’m curious how much additional effort would > be required to port the work to a practical device - for example, > implementation on a smart phone. (you can read this as “will it cause me > to postpone graduation a few weeks? months? years?”) GNU Radio works on some embedded devices, which might be what you’re interested in. If you have no experience in embedded development, it can take you months to years to figure out, but if you’re a smart guy you might be able to get some results sooner than that. Note that I’m not talking about smartphones here, but rather commercially available embedded SDR devices, such as the Ettus E100. Martin ---
**Author:** ![roa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8e7dd6/32.png) [@roa](https://www.ruby-forum.com/u/roa)\ **Post date:** [June 17, 2014, 1:39pm UTC](https://www.ruby-forum.com/t/gnu-radio-software-radio-conceptual-question/230409/4 "2014-06-17T13:39:52Z")
Thanks for the quick replies. I can see how putting the SDR in a block directly before the DAC or after the ADC is a PHY implementation, and how this is the case when using embedded devices such as the E series USRPs and the embedded SDR components in a base station. My confusion is when gnuradio is operating in an OS where the sole purpose isn’t the comms link (i.e., running on my PC rather than on an embedded linux micro). In the case of the N series USRPs, my understanding is that the signal chain wraps whatever is implemented in gnuradio (PHY, MAC, etc) within network and Ethernet packets to send to the USRP, the USRP unwraps this and places the samples on the physical channel and vice versa at the receiver. To me, the wrapping and passing of digital samples seems to put a stack within the stack. The ends of the chain are unaware of the internal message passing and act as if the samples were directly passed to the DAC and ADC, which is why I see it as an emulation of the PHY. Perhaps this is strictly a case of my definitions being incorrect (and I definitely realize that network layer models are models rather than standards), but please confirm if my sense of what is occurring in the signal chain is correct. Thanks again, -Mike On Tue, Jun 17, 2014 at 5:31 AM, Martin B. [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) ---
**Author:** ![roa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8e7dd6/32.png) [@roa](https://www.ruby-forum.com/u/roa)\ **Post date:** [June 17, 2014, 2:11pm UTC](https://www.ruby-forum.com/t/gnu-radio-software-radio-conceptual-question/230409/5 "2014-06-17T14:11:57Z")
On 17.06.2014 13:52, Sylvain M. wrote: > emulation as well ? The way the samples are transported from one > endpoint to the other is largely irrelevant here … I agree, this is the point I was trying to make. Somehow, the samples have to get from the ADC to the PHY. In the case of a networked device, it’s by Ethernet. On an embedded device, there might be an AXI connection. The PHY is where the physical signal is handled (or samples in case of digital systems), hence the name, regardless of where the samples are from. Of course Ethernet has its own PHY and MAC, but our comms system doesn’t care about this. M ---
**Author:** ![roa](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/r/8e7dd6/32.png) [@roa](https://www.ruby-forum.com/u/roa)\ **Post date:** [June 17, 2014, 1:53pm UTC](https://www.ruby-forum.com/t/gnu-radio-software-radio-conceptual-question/230409/6 "2014-06-17T13:53:32Z")
> To me, the wrapping and passing of digital samples seems to put a > stack within the stack. The ends of the chain are unaware of the internal > message passing and act as if the samples were directly passed to the DAC > and ADC, … Yes, and ? These are un-related stacks. Some highend DAC/ADC have high speed serial interfaces and encode/packetize the data before sensing them to the CPU/FPGA/ASIC that will deal with the samples, would you consider that a PHY emulation as well ? The way the samples are transported from one endpoint to the other is largely irrelevant here … Cheers, Sylvain