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 Braun <martin.br...@ettus.com> wrote: > On 17.06.2014 04:24, Michael Rahaim 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 > > > > > > _______________________________________________ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > https://lists.gnu.org/mailman/listinfo/discuss-gnuradio >
_______________________________________________ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
