Dear Muhammad, selector() is really deprecated for a reason: It stops the whole flow graph, reconfigures the block connections, and then starts the flow graph again. The TCP sink is deprecated, too. So, you're using two blocks that shouldn't be used in new applications at the heart of your flow graph.
So, don't use anything that is in the [deprecated] category. Instead of TCP Sink, use the zeroMQ blocks, or UDP. For inter-process communications, I recommend zeroMQ with the appropriate IPC transport. Instead of the selector: Depends on what you need, but maybe a set of multiply_const with 0 or 1, or a matrix multiply with an appropriate permutation matrix would help? Best regards, Marcus On 08/28/2017 07:59 AM, Muhammad Munir wrote: > Hi All, > Thank you for your valuable comments. > Another problem I faced is that when I used selector block of Gnuradio > to switch between two different flow of data, it disconnected the > ethernet and did not connected again unless I restart the application. > I think this behavior is due to lock()/unlock() commands used in > Selector block. Because of this problem I am unable to transfer data > from one application to the other using TCP module of Gnuradio. > Any suggestion would be appreciable > > Regards: > Muhammad Munir > > On Sat, Aug 26, 2017 at 5:12 PM, Marcus Müller via USRP-users > <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote: > > Hi Kyeong, hi Cladio, dear Muhammad > > so, let me confirm a few things: > > 1. yes, a USRP can only be "owned" by one host at a time. > > 2. yes, a USRP N2xx has one complex ADC and one complex DAC. It > usually makes no sense to "split" these. They're really just one > channel of complex signal. Exceptions do exist (Basic and LF > daughterboards), but in that case, I'd still wonder what > application this would be useful for. > > 3. UDP is not offering any link-layer security, indeed. But: The > N2xx isn't meant to be used over "the internet", but on direct > links, where one doesn't even have to expect reordering of > packets, leave alone packet loss. So yes, UDP is used, and the > USRP never drops a packet (or at least, in my years working with > USRPs, I've never seen that happen). If a packet is dropped, it's > by a switch, or by your computer, because they aren't able to keep > up with the load, or they are buggy (yes, there's buggy ethernet > hardware). > > 4. No different software solution will inherently solve this. The > "U" is not because a packet got lost, but because your computer > was *too slow* at sending samples to the USRP. You must make your > sending flowgraph faster, or you must use a more capable PC, or > maybe both. > > Then: > > Yes, with the N200, there is a chance to control the USRP with UHD > running on one computer, and streaming samples to another computer > [1] and stream them from another computer (simply send vita49 > packets with a fake sender IP address to the right port on the > N200). Again, I highly doubt this solves Munir's real problem, but > I don't *know* that problem so far. I only know what he thinks the > solution is (which I doubt it is). > > So, Muhammad, please do feel encouraged to tell us in detail what > your application does, and where it spends the most of its time; > then I'm optimistic we'll be able to help you better! > > Best regards, > > Marcus > > [1] http://files.ettus.com/manual/page_usrp2.html#usrp2_altstream > <http://files.ettus.com/manual/page_usrp2.html#usrp2_altstream> > > On 25.08.2017 12:59, Kyeong Su Shin via USRP-users wrote: >> To whom it may concern: >> >> First, I am not an expert of USRP, so I could be wrong. >> >> A few thoughts: >> >> 1. A USRP N200 does have two DACs / ADCs, but they are typically >> used for the I-Q sampling, so whether you can get two RX channels >> from a USRP N200 depends on the installed daughterboards. (Well, >> you can theoretically split the I channel and the Q channel, but >> I don't really see much benefit.) >> >> 2.I did not try manually decoding packets from the USRPs, so I >> could be wrong, but maybe you can LAN tap your USRP using a dumb >> hub if the passive listening is sufficient. (However, you >> probably have to write your own GNU Radio sources). >> >> 3. Yes, TCP and UDP are theoretically unreliable, but you really >> shouldn't lose too much packets when the connection is reliable >> and you are staying under the capability of your network hardare. >> In fact, USRP N200 /uses/ UDP to communicate with your PC at >> approx. 800Mbps rate (for 25MS/s I-Q sampling), and it rarely >> drops a packet (I saw a few packet drops, but when and only when >> I used old NICs, switches, or cables). >> >> Regards, >> Kyeong Su Shin >> >> On Fri, Aug 25, 2017 at 1:14 AM, Claudio Cicconetti via >> USRP-users <usrp-users@lists.ettus.com >> <mailto:usrp-users@lists.ettus.com>> wrote: >> >> Dear Munir, >> Your experiment confirms my theory: you cannot drive a single >> USRP from >> two applications. >> >> You need a custom application. I am no expert on Gnuradio, >> but I very >> much doubt you can achieve your objective with it. You should try >> writing a C/C++ application (or python with the new API if >> performance >> is not a major concern). >> >> Claudio >> >> On 08/25/2017 09:44 AM, Muhammad Munir wrote: >> > Dear Claudio, >> > Thanks for the reply. >> > I connected a single USRP with two PCs and tried to access >> USRP using two >> > different host PCs. When a USRP is engaged with one host, >> the other can not >> > get access to USRP. It means, we can access USRP by a >> single host at a >> > time. >> > The problem with the solution you suggested is that >> Gnuradio support for >> > communication between two applications is only through TCP >> or UDP which is >> > not reliable. I connected the application as given in >> figure. It gives USRP >> > underflow or overflow error. (UUUUUUUUUUUUUU or DDDDDDDDDDDD). >> > >> > Regards: >> > Munir >> > >> > >> > On Fri, Aug 25, 2017 at 12:16 PM, Claudio Cicconetti < >> > cciccone...@mbigroup.it <mailto:cciccone...@mbigroup.it>> >> wrote: >> > >> >> Dear Muhammad, >> >> 1. Yes, it is possible to connect an N200 to a switch, >> then you can use >> >> any PC connected to that as the host for the USRP device. >> Just make sure >> >> the switch is GbE (1000 Mb/s), not Fast Ethernet (10/100 >> Mb/s). Note >> >> that this approach has been discouraged by Ettus in the >> past for a >> >> number of reasons, but it works in practice. >> >> >> >> 2. No, it is not possible for multiple applications to use >> the same USRP >> >> device, regardless of whether they reside in the same host >> or in >> >> different hosts in a LAN. >> >> >> >> If you really need to access the same USRP (any series) >> from two >> >> applications, then you have to use a "broker": a single >> application >> >> drives the USRP, then it dispatches/receives data via >> network or any >> >> other mechanism (shared memory, whatever) to/from other >> applications, >> >> possibly on different hosts. This solution is 100% in your >> hands: AFAIK >> >> there are not examples from Ettus on this. >> >> >> >> Note: the N200 has a single ADC/DAC, therefore I am >> assuming you have in >> >> mind some kind of TDD operation. >> >> >> >> Ciao, >> >> Claudio >> >> >> >> On 08/25/2017 07:41 AM, Muhammad Munir via USRP-users wrote: >> >>> Hi, >> >>> The USRP N200 has two channels. I want data of each >> channel to two >> >>> different computers (PCs). There is only one Ethernet >> connection is >> >>> available with USRP. My questions are >> >>> 1. Is it possible to connect a single USRP with two >> different PCs >> >> connected >> >>> on a same network through Ethernet switch? >> >>> 2. Is it possible to stream two channels of USRP to two >> different PCs? >> >>> Please Let me know the solution? >> >>> >> >>> Thanks in advance >> >>> Muhammad Munir >> >>> >> >>> >> >>> >> >>> _______________________________________________ >> >>> USRP-users mailing list >> >>> USRP-users@lists.ettus.com >> <mailto:USRP-users@lists.ettus.com> >> >>> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >> >>> >> >> >> >> >> > >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >> >> >> >> >> _______________________________________________ >> USRP-users mailing list >> USRP-users@lists.ettus.com <mailto:USRP-users@lists.ettus.com> >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> > _______________________________________________ USRP-users mailing > list USRP-users@lists.ettus.com > <mailto:USRP-users@lists.ettus.com> > http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > <http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com> >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
