Re: [USRP-users] systemverilog files in rfnoc block
i think i found the issue... tcl script file usrp3/tools/scripts/viv_utils.tcl actually contains instructions to add files to project based on their extensions and .sv is not listed so files are skipped. adding a case for .sv works but it also includes axi_crossbar_intf.sv which seems to be a simulation file and won't compile so i had to exclude that file... is there any reason why sv files are not included or is that just a lazy way to exclude simulation sources? unfortunately i need to use some systemverilog constructs and with .v extension those seem not to be accepted... thanks, Dario Pennisi ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
[USRP-users] systemverilog files in rfnoc block
hi, i am trying to include a couple of systemverilog files in the list of sources for a custom rfnoc block. if i do that i can see in the log that all files with .sv extension are ignored and of course their modules are not found. if i launch compilation in gui mode and then add files back it works... is there any way of avoiding this manual step? thanks, Dario Pennisi ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Receiver not reporting any data
That makes sense then. Thanks! - Jacob Knoles On Fri, Aug 25, 2017 at 10:03 AM, wrote: > An LO offset tunes the analog hardware to desired_freq+LO_offset, and then > digitally basebands the desired frequency. However, if the analog > bandwidth is narrow enough that the digital basebanding (DDC) doesn't have > any useful signal, then this will be the result. > > > > > > > > > On 2017-08-25 12:47, Jacob Knoles wrote: > > Thanks. > > I didn't expect the actual input to shift with the LO offset. > > - > Jacob Knoles > > > On Fri, Aug 25, 2017 at 9:08 AM, wrote: > >> That's probably because you set your bandwidth to be somewhat narrow, so >> with offset tuning, you were only seeing the deeply-filtered data. >> >> >> >> >> >> >> On 2017-08-25 11:23, Jacob Knoles wrote: >> >> I found my issue. When I set my center frequency to monitor I also >> provided a LO offset. The intention is to not have the LO included in the >> response. >> >> For some reason it seams this pulled the receive frequency with it. By >> removing the LO offset I am getting the data I expect to see. >> >> At this time I am not sure why this is happening? >> >> - >> Jacob Knoles >> >> >> On Fri, Aug 25, 2017 at 8:12 AM, Jacob Knoles wrote: >> >>> The numbers coming out are essentially zero. Looking at the chart it >>> reads -1.3e-17. There are a lot of values that do come out exactly zero, as >>> they become -inf (or something like -370) after going through the log10 >>> mathematics. >>> >>> The signal I am inputting however is a simulated BT signal with the peak >>> at -40 dBm and modulated. At the one frequency I am monitoring it results >>> in a square wave. So I expect to see a distinct change in the output >>> numbers. >>> >>> - >>> Jacob Knoles >>> >>> >>> On Thu, Aug 24, 2017 at 6:15 PM, Marcus D. Leech via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> On 08/24/2017 08:11 PM, Jacob Knoles via USRP-users wrote: Hello, I am trying to do a simple receive function that grabs data for 12 seconds, calculates the log10 power and then plots power vs time. I am using the GnuRadio C++ API and have done a prototype using GnuRadio Companion. I am also feeding in a dummy signal using a vector signal generator. While running the Companion code I get exactly the results I expect to get, as seen in this image: [image: Inline image 1] The top time plot is displaying each step of the calculation chain, Red is the real part of the complex number, green is the imaginary part and blue is the magnitude. The lower plot shows the power vs time trace that I am after for this test, the calculation being used is 20*Log10(mag) - 17. The offset was calculated by comparing a known signal on a spectrum analyzer. So now my issue. When I take this prototype and implement it in C++ (that is what my program is using) I do not get any results back at all. Here is the C++ resulting plot of the real complex values only: [image: Inline image 2] As can be seen all the values are essentially zero. Here is the code snippet that is handling the capture, it returns a std::vector which is plotted elsewhere in the software. (I have confirmed that the plotting software is not the issue.) _rate = 5e6; //-- -- //-- Make a top block //-- -- auto tb = gr::make_top_block( "TraceCapture" ); //-- -- //-- make the usrp //-- -- auto stream_args = uhd::stream_args_t( "fc32", "sc16" ); stream_args.channels.push_back( 0 ); auto usrp_source = gr::uhd::usrp_source::make( uhd::device_addr_t( "" ), stream_args ); usrp_source->set_samp_rate( _rate ); usrp_source->set_center_freq( uhd::tune_request_t(carrier_freq, 10e6) ); usrp_source->set_gain( _gain_one ); usrp_source->set_bandwidth( 1e6 ); usrp_source->set_antenna( "RX2" ); //-- -- //-- Make the necessary flowgraph blocks //-- - auto complex_to_mag_sptr = gr::blocks::complex_to_mag::make( ); //auto nlog10_sptr = gr::blocks::nlog10_ff::make( 20, 1, -17.4 );
Re: [USRP-users] Receiver not reporting any data
An LO offset tunes the analog hardware to desired_freq+LO_offset, and then digitally basebands the desired frequency. However, if the analog bandwidth is narrow enough that the digital basebanding (DDC) doesn't have any useful signal, then this will be the result. On 2017-08-25 12:47, Jacob Knoles wrote: > Thanks. > > I didn't expect the actual input to shift with the LO offset. > > - > Jacob Knoles > > On Fri, Aug 25, 2017 at 9:08 AM, wrote: > > That's probably because you set your bandwidth to be somewhat narrow, so with > offset tuning, you were only seeing the deeply-filtered data. > > On 2017-08-25 11:23, Jacob Knoles wrote: > I found my issue. When I set my center frequency to monitor I also provided a > LO offset. The intention is to not have the LO included in the response. > > For some reason it seams this pulled the receive frequency with it. By > removing the LO offset I am getting the data I expect to see. > > At this time I am not sure why this is happening? > > - > Jacob Knoles > > On Fri, Aug 25, 2017 at 8:12 AM, Jacob Knoles wrote: > > The numbers coming out are essentially zero. Looking at the chart it reads > -1.3e-17. There are a lot of values that do come out exactly zero, as they > become -inf (or something like -370) after going through the log10 > mathematics. > > The signal I am inputting however is a simulated BT signal with the peak at > -40 dBm and modulated. At the one frequency I am monitoring it results in a > square wave. So I expect to see a distinct change in the output numbers. > > - > Jacob Knoles > > On Thu, Aug 24, 2017 at 6:15 PM, Marcus D. Leech via USRP-users > wrote: > > On 08/24/2017 08:11 PM, Jacob Knoles via USRP-users wrote: > > Hello, > > I am trying to do a simple receive function that grabs data for 12 seconds, > calculates the log10 power and then plots power vs time. > > I am using the GnuRadio C++ API and have done a prototype using GnuRadio > Companion. I am also feeding in a dummy signal using a vector signal > generator. > > While running the Companion code I get exactly the results I expect to get, > as seen in this image: > > The top time plot is displaying each step of the calculation chain, Red is > the real part of the complex number, green is the imaginary part and blue is > the magnitude. > > The lower plot shows the power vs time trace that I am after for this test, > the calculation being used is 20*Log10(mag) - 17. > > The offset was calculated by comparing a known signal on a spectrum analyzer. > > > So now my issue. When I take this prototype and implement it in C++ (that is > what my program is using) I do not get any results back at all. > > Here is the C++ resulting plot of the real complex values only: > > As can be seen all the values are essentially zero. > > Here is the code snippet that is handling the capture, it returns a > std::vector which is plotted elsewhere in the software. (I have > confirmed that the plotting software is not the issue.) > > _rate = 5e6; > // > > //-- Make a top block > // > > auto tb = gr::make_top_block( "TraceCapture" ); > > // > > //-- make the usrp > // > > auto stream_args = uhd::stream_args_t( "fc32", "sc16" ); > stream_args.channels.push_back( 0 ); > auto usrp_source = gr::uhd::usrp_source::make( uhd::device_addr_t( "" ), > stream_args ); > usrp_source->set_samp_rate( _rate ); > usrp_source->set_center_freq( uhd::tune_request_t(carrier_freq, 10e6) ); > usrp_source->set_gain( _gain_one ); > usrp_source->set_bandwidth( 1e6 ); > usrp_source->set_antenna( "RX2" ); > > // > > //-- Make the necessary flowgraph blocks > //--- > > auto complex_to_mag_sptr = gr::blocks::complex_to_mag::make( ); > //auto nlog10_sptr = gr::blocks::nlog10_ff::make( 20, 1, -17.4 ); > auto vector_sink_sptr = gr::blocks::vector_sink_f::make( ); > auto complex_to_real_sptr = gr::blocks::complex_to_real::make( ); > > // > > //-- Connect the flowgraph > // > > //tb->connect( complex_to_mag_sptr, 0, nlog10_sptr, 0 ); > //tb->connect( nlog10_sptr, 0, vector_sink_sptr, 0 ); > //tb->connect( complex_to_mag_sptr, 0, vector_sink_sptr, 0 ); > tb->connect( complex_to_real_sptr, 0, vector_sink_sptr, 0 ); >
Re: [USRP-users] Receiver not reporting any data
Thanks. I didn't expect the actual input to shift with the LO offset. - Jacob Knoles On Fri, Aug 25, 2017 at 9:08 AM, wrote: > That's probably because you set your bandwidth to be somewhat narrow, so > with offset tuning, you were only seeing the deeply-filtered data. > > > > > > > On 2017-08-25 11:23, Jacob Knoles wrote: > > I found my issue. When I set my center frequency to monitor I also > provided a LO offset. The intention is to not have the LO included in the > response. > > For some reason it seams this pulled the receive frequency with it. By > removing the LO offset I am getting the data I expect to see. > > At this time I am not sure why this is happening? > > - > Jacob Knoles > > > On Fri, Aug 25, 2017 at 8:12 AM, Jacob Knoles wrote: > >> The numbers coming out are essentially zero. Looking at the chart it >> reads -1.3e-17. There are a lot of values that do come out exactly zero, as >> they become -inf (or something like -370) after going through the log10 >> mathematics. >> >> The signal I am inputting however is a simulated BT signal with the peak >> at -40 dBm and modulated. At the one frequency I am monitoring it results >> in a square wave. So I expect to see a distinct change in the output >> numbers. >> >> - >> Jacob Knoles >> >> >> On Thu, Aug 24, 2017 at 6:15 PM, Marcus D. Leech via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> On 08/24/2017 08:11 PM, Jacob Knoles via USRP-users wrote: >>> >>> Hello, >>> >>> I am trying to do a simple receive function that grabs data for 12 >>> seconds, calculates the log10 power and then plots power vs time. >>> >>> I am using the GnuRadio C++ API and have done a prototype using GnuRadio >>> Companion. I am also feeding in a dummy signal using a vector signal >>> generator. >>> >>> While running the Companion code I get exactly the results I expect to >>> get, as seen in this image: >>> >>> [image: Inline image 1] >>> >>> The top time plot is displaying each step of the calculation chain, Red >>> is the real part of the complex number, green is the imaginary part and >>> blue is the magnitude. >>> >>> The lower plot shows the power vs time trace that I am after for this >>> test, the calculation being used is 20*Log10(mag) - 17. >>> >>> The offset was calculated by comparing a known signal on a spectrum >>> analyzer. >>> >>> So now my issue. When I take this prototype and implement it in C++ >>> (that is what my program is using) I do not get any results back at all. >>> >>> Here is the C++ resulting plot of the real complex values only: >>> >>> [image: Inline image 2] >>> >>> As can be seen all the values are essentially zero. >>> >>> Here is the code snippet that is handling the capture, it returns a >>> std::vector which is plotted elsewhere in the software. (I have >>> confirmed that the plotting software is not the issue.) >>> >>> _rate = 5e6; >>> //-- >>> -- >>> //-- Make a top block >>> //-- >>> -- >>> auto tb = gr::make_top_block( "TraceCapture" ); >>> >>> //-- >>> -- >>> //-- make the usrp >>> //-- >>> -- >>> auto stream_args = uhd::stream_args_t( "fc32", "sc16" ); >>> stream_args.channels.push_back( 0 ); >>> auto usrp_source = gr::uhd::usrp_source::make( >>> uhd::device_addr_t( "" ), stream_args ); >>> usrp_source->set_samp_rate( _rate ); >>> usrp_source->set_center_freq( uhd::tune_request_t(carrier_freq, >>> 10e6) ); >>> usrp_source->set_gain( _gain_one ); >>> usrp_source->set_bandwidth( 1e6 ); >>> usrp_source->set_antenna( "RX2" ); >>> >>> //-- >>> -- >>> //-- Make the necessary flowgraph blocks >>> //-- >>> - >>> auto complex_to_mag_sptr = gr::blocks::complex_to_mag::make( ); >>> //auto nlog10_sptr = gr::blocks::nlog10_ff::make( 20, 1, -17.4 ); >>> auto vector_sink_sptr = gr::blocks::vector_sink_f::make( ); >>> auto complex_to_real_sptr = gr::blocks::complex_to_real::make( >>> ); >>> >>> //-- >>> -- >>> //-- Connect the flowgraph >>> //-- >>> -- >>> //tb->connect( complex_to_mag_sptr, 0, nlog10_sptr, 0 ); >>> //tb->connect( nlog10_sptr, 0, vector_sink_sptr, 0 ); >>> //tb->connect( complex_to_mag_sptr, 0, vector_sink_sptr
Re: [USRP-users] Receiver not reporting any data
That's probably because you set your bandwidth to be somewhat narrow, so with offset tuning, you were only seeing the deeply-filtered data. On 2017-08-25 11:23, Jacob Knoles wrote: > I found my issue. When I set my center frequency to monitor I also provided a > LO offset. The intention is to not have the LO included in the response. > > For some reason it seams this pulled the receive frequency with it. By > removing the LO offset I am getting the data I expect to see. > > At this time I am not sure why this is happening? > > - > Jacob Knoles > > On Fri, Aug 25, 2017 at 8:12 AM, Jacob Knoles wrote: > > The numbers coming out are essentially zero. Looking at the chart it reads > -1.3e-17. There are a lot of values that do come out exactly zero, as they > become -inf (or something like -370) after going through the log10 > mathematics. > > The signal I am inputting however is a simulated BT signal with the peak at > -40 dBm and modulated. At the one frequency I am monitoring it results in a > square wave. So I expect to see a distinct change in the output numbers. > > - > Jacob Knoles > > On Thu, Aug 24, 2017 at 6:15 PM, Marcus D. Leech via USRP-users > wrote: > > On 08/24/2017 08:11 PM, Jacob Knoles via USRP-users wrote: > > Hello, > > I am trying to do a simple receive function that grabs data for 12 seconds, > calculates the log10 power and then plots power vs time. > > I am using the GnuRadio C++ API and have done a prototype using GnuRadio > Companion. I am also feeding in a dummy signal using a vector signal > generator. > > While running the Companion code I get exactly the results I expect to get, > as seen in this image: > > The top time plot is displaying each step of the calculation chain, Red is > the real part of the complex number, green is the imaginary part and blue is > the magnitude. > > The lower plot shows the power vs time trace that I am after for this test, > the calculation being used is 20*Log10(mag) - 17. > > The offset was calculated by comparing a known signal on a spectrum analyzer. > > > So now my issue. When I take this prototype and implement it in C++ (that is > what my program is using) I do not get any results back at all. > > Here is the C++ resulting plot of the real complex values only: > > As can be seen all the values are essentially zero. > > Here is the code snippet that is handling the capture, it returns a > std::vector which is plotted elsewhere in the software. (I have > confirmed that the plotting software is not the issue.) > > _rate = 5e6; > // > > //-- Make a top block > // > > auto tb = gr::make_top_block( "TraceCapture" ); > > // > > //-- make the usrp > // > > auto stream_args = uhd::stream_args_t( "fc32", "sc16" ); > stream_args.channels.push_back( 0 ); > auto usrp_source = gr::uhd::usrp_source::make( uhd::device_addr_t( "" ), > stream_args ); > usrp_source->set_samp_rate( _rate ); > usrp_source->set_center_freq( uhd::tune_request_t(carrier_freq, 10e6) ); > usrp_source->set_gain( _gain_one ); > usrp_source->set_bandwidth( 1e6 ); > usrp_source->set_antenna( "RX2" ); > > // > > //-- Make the necessary flowgraph blocks > //--- > > auto complex_to_mag_sptr = gr::blocks::complex_to_mag::make( ); > //auto nlog10_sptr = gr::blocks::nlog10_ff::make( 20, 1, -17.4 ); > auto vector_sink_sptr = gr::blocks::vector_sink_f::make( ); > auto complex_to_real_sptr = gr::blocks::complex_to_real::make( ); > > // > > //-- Connect the flowgraph > // > > //tb->connect( complex_to_mag_sptr, 0, nlog10_sptr, 0 ); > //tb->connect( nlog10_sptr, 0, vector_sink_sptr, 0 ); > //tb->connect( complex_to_mag_sptr, 0, vector_sink_sptr, 0 ); > tb->connect( complex_to_real_sptr, 0, vector_sink_sptr, 0 ); > tb->connect( usrp_source, 0, complex_to_real_sptr, 0 ); > > tb->start( ); > std::this_thread::sleep_for( std::chrono::milliseconds( static_cast long>( capture_time * 1000 ) ) ); > > tb->stop( ); > tb->wait( ); > > return std::make_shared>( vector_sink_sptr->data( ) ); > > When I run the code on my B210 I get no errors, the RX2 led lights as > expected, all the numbers get calculated as expected yet no matter what I > have tried I am getting only zeros from the B210 > > Additional
[USRP-users] Multiple X310 (NI-2943R) configuration issues
Hello everyone, we have a couple of X310 connected via PCIe to a Windows host and I’m trying to get a slightly more elaborate multi USRP example up and running to dump IQ data from multiple radio chains. Somehow stuff seems to work alright for a single radio with two RX chains at 10 MSamples/s or 8 RX chains at 4 MSamples/s (after a switch to the 3.10.2 UHD driver). Building a compound device with up to 7 X310 (e.g. 14 rx chains) seems to work fine in the initialisation phase even though I’m running into overflow issues which might be related to my usage of recv() and the buffers in the background. I’ll have a look at the kitchen_sink example that Rob pointed out to see if that might help with that issue. Long story short, above 7 X310 the driver seems to have issues keeping the parallel communication going. I’ll receive a lot of the following errors: UHD Error: x300 fw communication failure #1 EnvironmentError: IOError: x300 fw poke32 - operation timed out or UHD Error: x300 fw communication failure #1 EnvironmentError: IOError: x300 fw peek32 - operation timed out I’m guessing that this is somehow related to how the driver handles the compound USRP device or some misconfiguration on our side. Can anyone tell me what the errors actually mean? Do you have any suggestion how to avoid running into those issues e.g. where do they come from? Our host is running LV Comms with NI drivers in parallel but afaik the UHD application shouldn’t be confused by that as I’m building against the 3.10.2 UHD and the application output shows that it uses the current lvbit file from the runtime folder. Thank you in advance, Jens ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] How to connect single USRP N200 with two PCs?
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. (UU or ). > > > > 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 list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] How to connect single USRP N200 with two PCs?
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. (UU or ). > > 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
Re: [USRP-users] How to connect single USRP N200 with two PCs?
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. (UU or ). 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
Re: [USRP-users] How to connect single USRP N200 with two PCs?
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
