Re: [Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP
Tom, That is actually what I was going to do. I installed Ubuntu as a dual boot on my Mac and I must say the installation of gnuradio went very smooth, much faster than on the OSX. Too bad this approach is not platform-independent, although it will do for now. Thank you for the advice! Jakub On Mon, Apr 12, 2010 at 8:44 AM, Tom Rondeau wrote: > On 3/7/2010 3:31 PM, Eric Blossom wrote: >> >> On Thu, Mar 04, 2010 at 02:45:54PM -0500, Jakub Moskal wrote: >> >>> >>> Hi everyone, >>> >>> I am trying to use the GNU-Radio+USRP to implement a cognitive radio >>> use case in which radios exchange information (XML-based documents) >>> between each other in order to achieve a defined goal (e.g. to improve >>> connectivity), without disturbing the usual communication. I have >>> several questions regarding this scenario.. >>> >>> In a packet-based communication (e.g. tunnel.py) I imagine that I >>> could transmit my own packets which would include the "cognitive >>> information" and then receive them on the other end. It would require >>> some special marking of the packets (binary level?) to distinguish the >>> cognitive information from the regular data, so that it could be >>> filtered out on the receiver side. I looked into the tunnel.py, but it >>> seems that it doesn't implement anything higher than the MAC layer - >>> therefore I cannot use it to reliably transfer data, packets get lost >>> or are too small and I would have to split/merge data manually. Would >>> it be possible to combine the tunnel.py with the TCP source/sinks in >>> order to achieve a reliable link? >>> >> >> In reality, you'd need some kind of FEC to get the packet error rate >> down to something you can deal with. Then you could run TCP across >> the interface. No need for TCP sources or sinks. You've got a >> (virtual) network interface with an IP address. Just run something >> that uses TCP on that IP address. >> > > Definitely follow Eric's advice and apply some kind of FEC to reduce the > packet error rate. When you've done that, the tunnel.py provides you with a > TUN/TAP interface, which is a networking interface like eth0 (that is, once > you get it working with your Mac, for which I can't be of any help). This > will allow you to use a TCP/IP interface to the GNU Radio physical layer. > Instead of trying to interleave your cognitive radio control bits into the > PHY-layer stream, you should be able to use a TCP port specifically for > those purposes. So you'd have two logical links on the TCP layer over the > single physical link. > > Tom > > > > > ___ > Discuss-gnuradio mailing list > Discuss-gnuradio@gnu.org > http://lists.gnu.org/mailman/listinfo/discuss-gnuradio > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP
On 3/7/2010 3:31 PM, Eric Blossom wrote: On Thu, Mar 04, 2010 at 02:45:54PM -0500, Jakub Moskal wrote: Hi everyone, I am trying to use the GNU-Radio+USRP to implement a cognitive radio use case in which radios exchange information (XML-based documents) between each other in order to achieve a defined goal (e.g. to improve connectivity), without disturbing the usual communication. I have several questions regarding this scenario.. In a packet-based communication (e.g. tunnel.py) I imagine that I could transmit my own packets which would include the "cognitive information" and then receive them on the other end. It would require some special marking of the packets (binary level?) to distinguish the cognitive information from the regular data, so that it could be filtered out on the receiver side. I looked into the tunnel.py, but it seems that it doesn't implement anything higher than the MAC layer - therefore I cannot use it to reliably transfer data, packets get lost or are too small and I would have to split/merge data manually. Would it be possible to combine the tunnel.py with the TCP source/sinks in order to achieve a reliable link? In reality, you'd need some kind of FEC to get the packet error rate down to something you can deal with. Then you could run TCP across the interface. No need for TCP sources or sinks. You've got a (virtual) network interface with an IP address. Just run something that uses TCP on that IP address. Definitely follow Eric's advice and apply some kind of FEC to reduce the packet error rate. When you've done that, the tunnel.py provides you with a TUN/TAP interface, which is a networking interface like eth0 (that is, once you get it working with your Mac, for which I can't be of any help). This will allow you to use a TCP/IP interface to the GNU Radio physical layer. Instead of trying to interleave your cognitive radio control bits into the PHY-layer stream, you should be able to use a TCP port specifically for those purposes. So you'd have two logical links on the TCP layer over the single physical link. Tom ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP
On Thu, Mar 04, 2010 at 02:45:54PM -0500, Jakub Moskal wrote: > Hi everyone, > > I am trying to use the GNU-Radio+USRP to implement a cognitive radio > use case in which radios exchange information (XML-based documents) > between each other in order to achieve a defined goal (e.g. to improve > connectivity), without disturbing the usual communication. I have > several questions regarding this scenario.. > > In a packet-based communication (e.g. tunnel.py) I imagine that I > could transmit my own packets which would include the "cognitive > information" and then receive them on the other end. It would require > some special marking of the packets (binary level?) to distinguish the > cognitive information from the regular data, so that it could be > filtered out on the receiver side. I looked into the tunnel.py, but it > seems that it doesn't implement anything higher than the MAC layer - > therefore I cannot use it to reliably transfer data, packets get lost > or are too small and I would have to split/merge data manually. Would > it be possible to combine the tunnel.py with the TCP source/sinks in > order to achieve a reliable link? In reality, you'd need some kind of FEC to get the packet error rate down to something you can deal with. Then you could run TCP across the interface. No need for TCP sources or sinks. You've got a (virtual) network interface with an IP address. Just run something that uses TCP on that IP address. > It looks like some of the examples don't use the concept of a packet > (eg. usrp_tv_rcv.py) -- how would I add my own data and filter it in > such streams? Would it require writing a C++ block? If so, how would I > ensure the reliability then? Good question, see below for reading suggestions. > I have a CS background and the digital communication is rather new to > me, I would appreciate any help or links to resources. To really grok s/w radio, folks need to have a decent clue about software, dsp, digital comms and RF. Sounds like you've got the software part wired, so that's handled. Other folks come with the digital comms background but lacking experience in s/w. There's always something new to learn :-) Take a look at this list of suggested reading, and spend some time with a few things that capture your interest: http://gnuradio.org/redmine/wiki/gnuradio/SuggestedReading For DSP, I'd suggest starting with Lyons. For Digital Comms, try Sklar. > Thanks, > Jakub You're welcome! Eric ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP
Michael, Thank you for the response. What I am doing right now is forwarding the packets from the tunnel.py to a JMS (Java Message Service) server using the STOMP (http://stomp.codehaus.org/) protocol, available for python. JMS server is pushing packets from its clients to the tunnel.py. What JMS gives me is the asynchronous message-based communication and reliability. The JMS server can talk to clients written in a variety of languages (Java, C, C++, C#, Ruby, Perl, Python, PHP). At this point the only issue is that I forward packets from the PHY/MAC layer almost directly to the application layer.. I guess using the TUN/TAP would forward packets through the kernel's network stack and provide implementation of the higher levels of the OSI model, so I wouldn't have to worry about things like lost packets and segmentation.. Jakub On Sat, Mar 6, 2010 at 8:13 PM, Michael Dickens wrote: > On Mar 4, 2010, at 2:45 PM, Jakub Moskal wrote: >> >> Last question.. I own to USRPs and I successfully installed the >> gnuradio with grc on two MacBooks (10.6.2). Examples run fine, but >> when it comes to the tunnel.py I cannot make the TUN/TAP interface to >> work on OSX, has anyone had luck with that? I browsed the list >> archives, but I couldn't find a tutorial to make it happen. After >> reading the >> http://lists.gnu.org/archive/html/discuss-gnuradio/2009-01/msg00047.html >> I tried the tuntaposx and Tunnelblick, but with no luck. For now I >> replaced the tun/tap with a STOMP/JMS layer. > > > I have no answers to your previous questions, but I'll address the one > above. tap/tun on OSX works differently than it does on Linux; I don't > remember the details. I've (still, as per the link about) never gotten it > to work for me, though admittedly I haven't tried very hard either. If you > can find a way of doing the equivalence of tap/tun on OSX, then I say go for > it & good for you & let us know what it was & how you did it. - MLD > > ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Enabling the cognitive radio with GNU Radio+USRP
On Mar 4, 2010, at 2:45 PM, Jakub Moskal wrote: Last question.. I own to USRPs and I successfully installed the gnuradio with grc on two MacBooks (10.6.2). Examples run fine, but when it comes to the tunnel.py I cannot make the TUN/TAP interface to work on OSX, has anyone had luck with that? I browsed the list archives, but I couldn't find a tutorial to make it happen. After reading the http://lists.gnu.org/archive/html/discuss-gnuradio/2009-01/msg00047.html I tried the tuntaposx and Tunnelblick, but with no luck. For now I replaced the tun/tap with a STOMP/JMS layer. I have no answers to your previous questions, but I'll address the one above. tap/tun on OSX works differently than it does on Linux; I don't remember the details. I've (still, as per the link about) never gotten it to work for me, though admittedly I haven't tried very hard either. If you can find a way of doing the equivalence of tap/tun on OSX, then I say go for it & good for you & let us know what it was & how you did it. - MLD ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
