It's nice that TCP works for your application, but it's still a deprecated block for multiple technical reasons and I explicitly recommend NOT using it. So, use it if you want to, but no-one will be able to help you with that. The block is really bad.
If you need a better selector alternative, just write a very simple general_block that only produces items on the right outputs if you need them. If you only need to switch something on and off, try the "copy" block with it's "set_enabled" method. Be warned that this isn't properly timed, either, but it'd be easy to add stream tags reading to switch the "enabled" state on a specific stream tag. Regards, Marcus On 31.08.2017 08:14, Muhammad Munir wrote: > 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 <mailto: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 <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
