Dear Marcus, 1. TCP works fine for my application if I am not using selector blocks. It creates problems with selectors only for my flow graphs. 2. I have used the method of multiplying the flow with 0 or 1. It taxes double the processing. Processing does matter when applying filters and FFT algorithms. so, it is not good for larger applications.
Regards: Muhammad Munir On Tue, Aug 29, 2017 at 11:00 PM, Marcus Müller <marcus.muel...@ettus.com> wrote: > 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> 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 >> >> 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> 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> 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 >>> >>> 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 >>> >> >> >> >> _______________________________________________ >> USRP-users mailing >> listUSRP-users@lists.ettus.comhttp://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 > >
_______________________________________________ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
