[USRP-users] Re: Sampling rate and bandwidth - Usrp N210 & source block
Hello Issac: USRP uses I-Q sampling (there are some exceptions, though). When I-Q sampling is used, the Nyquist bandwidth is equal to the sampling rate of the stream, not half of it. So, the theoretical bandwidth of your 25MS/s stream is 25 MHz, not 12.5 MHz. See https://wiki.gnuradio.org/index.php/IQ_Complex_Tutorial and https://dsp.stackexchange.com/questions/36927/bandwidth-with-complex-sampling for further information. I don't know how Ettus Research came up with the 20 MHz figure. I guess they are talking about the filter characteristics. You may experience some aliasing issues at the edges of the spectrum, due to the filter characteristics. Regards, Kyeong Su Shin 보낸 사람: isaac mario tupac davila 보낸 날짜: 2021년 5월 12일 수요일 오전 7:15 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Sampling rate and bandwidth - Usrp N210 & source block Hello community I'm Isaac. I'm dealing with some questions about the interpretation of sampling rate and bandwidth in a USRP source block. What I understand is if I work with an USRP N210, my ADC works with a 100MS/s. If I use a Gigabit Ethernet and a data type of 16bits, I could receive in my host up to 25MS/s with a bandwidth of 20MHz. https://kb.ettus.com/About_USRP_Bandwidths_and_Sampling_Rates My questions are: 1. If I can receive up to 25MS/s on my host, why my bandwidth is 20MHz? I think It is up to 12.5MHz according to Nyquist. 2. Why is the sample rate value in the usrp source block equal to the bandwidth I observe? I think this bandwidth should be the half according to Nyquist too. https://wiki.gnuradio.org/index.php/USRP_Source I appreciate any help to clarify this concepts Regards Isaac T. ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Ettus Projects?
Hello David: I suggest checking out GNU Radio conference papers/recordings, as many of them uses USRP(s) in some ways. (Example: https://events.gnuradio.org/event/8/contributions/ , https://www.youtube.com/c/GNURadioProject , etc.) Regards, Kyeong Su Shin 보낸 사람: David Horn 보낸 날짜: 2022년 3월 16일 수요일 오전 9:03 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Ettus Projects? Hi All! My name’s David, and I am the MarCom Manager at Digilent. We sell Ettus projects on our site (we’re also part of NI), but we don’t have a ton of experience with SDR on our Applications team. I am wondering if you all wouldn’t mind sending me your favorite Ettus projects/applications/writeups/blogs so I can feature them on our own channels. While I am on the topic, I’d be looking to start conversations with anyone that would like to contribute content for the Digilent blog featuring Ettus products (theoretically teaming up with Digilent products). Let me know! Cheers! David Horn MarCom Manager david.h...@digilent.com<mailto:david.h...@digilent.com> M: (214) 552-5559 [cid:image001.jpg@01D837A9.D7FCF6B0] [Facebook]<http://www.facebook.com/Digilent> [Linkedin] <http://www.linkedin.com/company/digilent-inc.> [Twitter] <http://twitter.com/DigilentInc> [Youtube] <http://www.youtube.com/user/DigilentInc> [Blog] <http://blog.digilentinc.com/> ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
[USRP-users] Re: Is it possible to control the sampling position of the baseband signal on the rx side of the usrp?
Hello Fan: USRPs (or any other general-purpose SDRs) do not do the timing recovery for you. It is designed to transmit arbitrary signals, so it simply does not have any idea about the "timing" of your signals. The mismatch in the internal oscillator clocks will cause phase drift over time. You can try using external clock inputs (PPS and 10 MHz inputs) of the USRPs to forcefully synchronize them. This is often not practical in real-world wireless systems, though. It is great for some (albeit limited) applications and for debugging jobs. Something else that you can do is implementing your own synchronization algorithms. You can either oversample your signals and then use signal processing frameworks (like GNU Radio) to do the recovery, or implement them on the FPGA of the B210. Both will give you the same performance, assuming that your USB port can handle the oversampled signals and the FPGA is sufficiently large for your purposes. Regards, Kyeong Su Shin 보낸 사람: fan 보낸 날짜: 2022년 7월 14일 목요일 오후 3:12 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Is it possible to control the sampling position of the baseband signal on the rx side of the usrp? Hi，everyone. I have the question: Is it possible to control the sampling position of the baseband signal on the rx side of the usrp? The situation is as follows: I use a usrp b210 to transmit a set of 16QAM signals, and receive this signal on the rx side of the same device, and repeat this several times. However, under the condition that the transmitted signal, tx gain, rx gain, channel frequency and other settings are unchanged, there are some differences in amplitude and phase between the received data each time. I never moved the position of b210, so the channel should be time-invariant. I think there are two possible reasons: First, even if the transmitted signal and transmit settings are the same each time, the signal actually transmitted by usrp each time is still different; second, the receiver does not sample at the optimal sampling point , but randomly samples. Firstly，let's discuss the second possibility. As far as I know, USRP's dsp module downconverts the received bandpass signal to baseband and then samples the baseband signal. a gardner loop is usually used to get the best sampling point from the sampled data (timing recovery), but the implementation of the gardner rings in 2x2 mimo with 16QAM is more difficult. Is there a UHD interface that can control the position of the sample points? Or, the real reason is the first？ ___ USRP-users mailing list -- usrp-users@lists.ettus.com To unsubscribe send an email to usrp-users-le...@lists.ettus.com
Re: [USRP-users] Making Antenna Array using SDR
Hello Ozair Iqbal, You can't (without using more SDR transceivers or making major modifications to the hardware). USRP-2901 (USRP B210) is only capable of 2x2 MIMO. You can switch between TX/RX and RX2 ports, but you cannot receive from all antenna ports concurrently (USRPs with switchable daughterboards may let you break down one I-Q RX chain to two, but B210 isn't the one). You will have to get more boards and synchronize them together using a common clock, or develop an algorithm that works with 2 antennas (+ 2 switchable antenna ports). Regards, Kyeong Su Shin On Fri, Jul 14, 2017 at 10:11 AM, Ozair Iqbal via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi, > I am using SDR's (NI/2901) for my experiment.From one end, I am > transmitting a signal using Tx//RX port of 1st SDR. While at the other > end , I want to receive the same signal using four antenna by connecting > them at all the four ports (two Tx/Rx, two Rx) of the 2nd SDR at the same > time. But I am receiving the same signal using two antennas(connected at > two RX ports) of second SDR and not by using all the four antennas. > What will be the solution of this problem so that I can receive the signal > using four antennas at the same time. > > Regards, > > > ___ > 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?
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] Distance estimation and phase continuity of LO
Hello All, Just want to note that NI 2921s use XCVR2450, which is half-duplex (cannot rx and tx concurrently). B210s will work better, as they are full-duplex 2x2 MIMO. Regards, Kyeong Su Shin On Wed, Aug 30, 2017 at 8:44 PM, Michael Don via USRP-users < usrp-users@lists.ettus.com> wrote: > > USRPs can do Tx and Rx at the same time. I did an experiment where I > modified the FPGA image of Node 2 to send the Rx samples directly to Tx on > a different freq., and measured the phase difference of the echo from Node > 2 at Node 1. I didn't measure the phase difference of the carrier, rather > the phase difference of a FM sine signal. Didn't play around with it too > much, but I got an accuracy of a few meters, although for some reason I > always had to calibrate the system to measure the processing delay. I'd > also be interested to see anyone else's results. > > -Mike > > On Wed, Aug 30, 2017 at 8:53 PM, Qasim Chaudhari via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi, >> I want to find the distance between two USRPs by sending and >> receiving packets (or a continuous wave) in a bidirectional manner. >> >> Step 1: Node 1 Tx -> Node 2 Rx - measures phase, then switches >> over to become Tx >> Step 2: Node 2 Tx --> Node 1 Rx - measures phase and computes >> distance. >> >> I have two questions. >> >> Q1. If someone else has done/know about this kind of experiment with the >> USRP, can you please point me towards some good reference/source/s? >> >> Q2. When USRP switches from Rx to Tx mode at node 2 (and more >> importantly, from Tx to Rx mode at node 1), does it maintain phase >> continuity of its local oscillator? (Because otherwise the phase >> measurements become meaningless.) >> >> Currently, I am using NI USRP N2921 with the latest version of GNU Radio >> but I can have access to B210s if required. >> >> Cheers, >> Qasim >> >> ___ >> 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
[USRP-users] Is it safe to plug in UBX-160 on USRP N200/N210 (for intentional aliasing)?
Hello all, Would it be safe to plug in a UBX-160 daughterboard to a USRP N200 or N210, if I "want" aliasing? I want to intentionally cause aliasing to the collected data for some experiments, and I think this is a valid option, but I am worried if there are any UBX-160 features that may cause problems if I do this. Any suggestions are welcome. Regards, Kyeong Su Shin ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] FLEX900 + USRP1 Rev2
Hello Angilberto Muniz:
An alternative to this is to modify the USRP 1 motherboard (instead of the
dauthgerboard). There used to be a GNURadio wiki page about this
("USRPSerialBelow500"), but it is apparently gone. You can still find some
old e-mail archives and Chinese articles (with images) regarding this.
Regards,
Kyeong Su Shin
On Mon, Oct 23, 2017 at 11:16 AM, Angilberto Muniz Sb via USRP-users <
usrp-users@lists.ettus.com> wrote:
> Hi,
> I have a USRP1 Rev2 board and a FLEX900 dboard. The flex900 works fine
> with USRP1 Rev4.5, but wont work with USRP1 Rev2.
>
> I read somewhere that I shoud modify the flex900 to make it work with
> USRP1 Rev2.
>
> The problem is I read two different tips...
>
> in "https://files.ettus.com/manual/page_dboards.html#dboards_rfxmod"; it
> says:
>
> "...move R35 to R36 and move R117 to R115..."
>
> *in
> "**https://lists.gnu.org/archive/html/discuss-gnuradio/2009-04/msg00518.html
> <https://lists.gnu.org/archive/html/discuss-gnuradio/2009-04/msg00518.html>"
> it says:*
>
> *".. move R36 to R34 and move R115 to R116..."*
>
> *Any help?*
>
> Thank you,
>
> Angilberto.
>
> ___
> 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] TX power levels. Long term exposure.
It will act as a RF shield. (see: https://en.wikipedia.org/wiki/Electromagnetic_shielding ) Not a recommended way to protect yourself from strong EM waves, but it does make a good joke. Regards, Kyeong Su Shin On Tue, Nov 7, 2017 at 11:01 AM, Kevin Hung via USRP-users < usrp-users@lists.ettus.com> wrote: > Hmm, I am just curious. What does the metal hat do? > > On Mon, Nov 6, 2017 at 11:38 PM, Dan CaJacob via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> But if you want to have some fun with your co-workers. Put on a metal hat >> whenever you TX. If they ask what's going on, say "Don't worry about it" :) >> >> On Mon, Nov 6, 2017 at 4:49 PM Bakshi, Arjun via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> Thanks for clearing that up. >>> >>> >>> AB >>> -- >>> *From:* Nick Foster >>> *Sent:* Monday, November 6, 2017 3:58:05 PM >>> *To:* Bakshi, Arjun >>> *Cc:* usrp-users@lists.ettus.com >>> *Subject:* Re: [USRP-users] TX power levels. Long term exposure. >>> >>> Don't worry about it. You are several orders of magnitude below any sort >>> of permissible exposure limit. >>> >>> Nick >>> >>> On Mon, Nov 6, 2017 at 11:21 AM Bakshi, Arjun via USRP-users < >>> usrp-users@lists.ettus.com> wrote: >>> >>> I'm looking to do long duration experiments in a lab which will have >>> people in it while I TX and Rx, and I'd like to know what health and safety >>> concerns I should keep in mind. >>> >>> >>> I tried looking at FCC and EU for limits on radiation levels, but those >>> specs aren't straightforward to understand. It's also difficult to get an >>> estimate of absolute power rxed/txed from the USRPs. So I'd like to hear >>> from anyone who knows about this stuff. >>> >>> >>> I'm using SBX (max power 100mW), and I'm thinking of using either the >>> 500-700MHz or the 1.2-1.3 GHz band. I'll be transmitting for *5ms every >>> second for a few hours*. The room is about 6m x 15m. Then antennas will >>> be 1-2 meters away from a few people. TX and RX are about 4m apart. With >>> gain set to 25dB, my signal has ~30dB SNR. >>> >>> >>> Sorry if this seems a bit odd/specific. >>> >>> >>> Thank you, >>> >>> >>> AB >>> >>> >>> ___ >>> 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 >>> >> -- >> Very Respectfully, >> >> Dan CaJacob >> >> ___ >> 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
[USRP-users] Improving Sensitivity of the Radio.
Hello Everyone: We are using USRPs for spectrum sensing (on pretty much any frequencies). Before asking my faculty to order a TwinRX daughterboard, however, I would like to see if there are any ways to improve the sensitivity of the hardware that we currently own (UBX/SBX/CBX/WBX). Our USRP + UBX configuration works well, except that we cannot really increase the gain level much without putting the RF frontend into the nonlinear region. Because of this, the noise figure of our data is about ~30dB in the worst case. I believe that the main problem is that we are using a wideband outdoor discone antenna for this - dumping quite a lot of RF energy to the RF frontend. In this case, what could I try to improve the sensitivity of the radio? I think one option could be adding additional filters to the chain (when we know that we are only looking at a certain frequencies), but I wonder if there are anything else that I can try. Also, I wonder what differences we can expect if we switch our daughterboard to a TwinRX. Would it be worth it? What noise figures did people experience when a wideband outdoor antenna was connected to the board? Regards, Kyeong Su Shin ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Improving Sensitivity of the Radio.
Dear Marcus D. Leech: Thank you for the reply. Is the only advantage of the TwinRX the pre-selector filter bank? Or, can the superheterodyne design of the radio also affect the data quality in some ways? We do turn down the gain to get optimal results. (The 'noise figure' that I mentioned was the noise figure that is observed by us, after such adjustments). We will definitely try adding filters. Regards, Kyeong Su Shin On Tue, Nov 14, 2017 at 7:12 PM, Marcus D. Leech via USRP-users < usrp-users@lists.ettus.com> wrote: > On 11/14/2017 10:00 PM, Kyeong Su Shin via USRP-users wrote: > > Hello Everyone: > > We are using USRPs for spectrum sensing (on pretty much any frequencies). > Before asking my faculty to order a TwinRX daughterboard, however, I would > like to see if there are any ways to improve the sensitivity of the > hardware that we currently own (UBX/SBX/CBX/WBX). > > Our USRP + UBX configuration works well, except that we cannot really > increase the gain level much without putting the RF frontend into the > nonlinear region. Because of this, the noise figure of our data is about > ~30dB in the worst case. I believe that the main problem is that we are > using a wideband outdoor discone antenna for this - dumping quite a lot of > RF energy to the RF frontend. > > In this case, what could I try to improve the sensitivity of the radio? I > think one option could be adding additional filters to the chain (when we > know that we are only looking at a certain frequencies), but I wonder if > there are anything else that I can try. > > Also, I wonder what differences we can expect if we switch our > daughterboard to a TwinRX. Would it be worth it? What noise figures did > people experience when a wideband outdoor antenna was connected to the > board? > > Regards, > Kyeong Su Shin > > > ___ > USRP-users mailing > listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com > > In the case of overload, the noise-figure is NOT the dominating factor in > determining system sensitivity. > > If you are "sensing" across a limited band, then a filter that covers that > band, and that band only, will definitely help keep the very first gain > stages, > which are "wide open" from going into overload. > > The TwinRX has some significant advantage here, since it has pre-selector > filters, but those filters may or may not have band edges that correspond > adequately to the band that your are "sensing". > > Basically, there's a "tension" in small-signal RF amplifiers. They can > either have very high dynamic range, or they can have very-low noise figure. > That general axiom still applies, although things are getting somewhat > better in this regard.But taking the output of an outdoor disc-cone > antenna > in a normal urban environment is pretty-much begging for > non-linearity.You might try turning *down* the gain. > > > > > > ___ > 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] Improving Sensitivity of the Radio.
Dear Marcus D. Leech: Thank you very much! I will think about this. Regards, Kyeong Su Shin On Tue, Nov 14, 2017 at 7:37 PM, Marcus D. Leech wrote: > On 11/14/2017 10:31 PM, Kyeong Su Shin wrote: > > Dear Marcus D. Leech: > > Thank you for the reply. > > Is the only advantage of the TwinRX the pre-selector filter bank? Or, can > the superheterodyne design of the radio also affect the data quality in > some ways? > > A Low-IF superhet design has some advantages, but the UBX has the same > overall architecture. With a Zero-iF design, mixer balance is extremely > important, and not always easy to achieve "perfectly". In the end, it's > a matter of where your mixer images end up. > > > We do turn down the gain to get optimal results. (The 'noise figure' that > I mentioned was the noise figure that is observed by us, after such > adjustments). We will definitely try adding filters. > > Keep in mind that filters "out front" necessarily add to the noise figure > of your receiver, since they aren't loss-free. RF system design is all > about > trade-offs. > > > > > Regards, > Kyeong Su Shin > > On Tue, Nov 14, 2017 at 7:12 PM, Marcus D. Leech via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> On 11/14/2017 10:00 PM, Kyeong Su Shin via USRP-users wrote: >> >> Hello Everyone: >> >> We are using USRPs for spectrum sensing (on pretty much any frequencies). >> Before asking my faculty to order a TwinRX daughterboard, however, I would >> like to see if there are any ways to improve the sensitivity of the >> hardware that we currently own (UBX/SBX/CBX/WBX). >> >> Our USRP + UBX configuration works well, except that we cannot really >> increase the gain level much without putting the RF frontend into the >> nonlinear region. Because of this, the noise figure of our data is about >> ~30dB in the worst case. I believe that the main problem is that we are >> using a wideband outdoor discone antenna for this - dumping quite a lot of >> RF energy to the RF frontend. >> >> In this case, what could I try to improve the sensitivity of the radio? I >> think one option could be adding additional filters to the chain (when we >> know that we are only looking at a certain frequencies), but I wonder if >> there are anything else that I can try. >> >> Also, I wonder what differences we can expect if we switch our >> daughterboard to a TwinRX. Would it be worth it? What noise figures did >> people experience when a wideband outdoor antenna was connected to the >> board? >> >> Regards, >> Kyeong Su Shin >> >> >> ___ >> USRP-users mailing >> listUSRP-users@lists.ettus.comhttp://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> In the case of overload, the noise-figure is NOT the dominating factor in >> determining system sensitivity. >> >> If you are "sensing" across a limited band, then a filter that covers >> that band, and that band only, will definitely help keep the very first >> gain stages, >> which are "wide open" from going into overload. >> >> The TwinRX has some significant advantage here, since it has pre-selector >> filters, but those filters may or may not have band edges that correspond >> adequately to the band that your are "sensing". >> >> Basically, there's a "tension" in small-signal RF amplifiers. They can >> either have very high dynamic range, or they can have very-low noise figure. >> That general axiom still applies, although things are getting somewhat >> better in this regard.But taking the output of an outdoor disc-cone >> antenna >> in a normal urban environment is pretty-much begging for >> non-linearity.You might try turning *down* the gain. >> >> >> >> >> >> ___ >> 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] using uhd_fft with usrp N210
Dear Sung Bok,Lee: You are using BasicRX/BasicTX daughterboards. These daughterboards do not have any mixers, so they cannot 'tune' to any frequencies and you have to supply your own RF frontends to get reasonable performances. All these daughterboards do for you is just buffering the ADC/DAC and then providing SMA connectors for the connection. You have to use different daughterboards if you do not want to come up with your own frontends and yet want to get good signals. If you use BasicRX/BasicTX and ask your USRP to tune to frequency x, it will actually tune to an aliased frequency. USRP N200/N210 have native sampling rate of 100MS/s. DAC sampling rate is rated to 400MS/s, but the master clock is still at 100MS/s - it is just that the DAC is internally interpolating the data you are inputting by 4x. So, if you ask it to tune to 100MHz, it will tune to 0MHz instead - where the 100MHz signals will alias onto. Regards, Kyeong Su Shin On Mon, Nov 27, 2017 at 8:51 PM, 이성복 via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi > > I have 2Questions > > I was install Linus Ubuntu 16.04 LTS, > > sudo apt-get update > > sudo apt-get upgrade > > and install uhd and gnuradio (https://kb.ettus.com/ > Building_and_Installing_the_USRP_Open-Source_Toolchain_( > UHD_and_GNU_Radio)_on_Linux) > > and uhd_images_downloader > > uhd_image_loader --args="type=usrp2,addr=192.168.10.2" > > benchmark_rate --tx 10e6 --rx 10e6 > > and test it tx_waveforms --rate 10e6 --freq 100e6 > > then > > Using Device: Single USRP: > Device: USRP2 / N-Series Device > Mboard 0: N210r4 > RX Channel: 0 > RX DSP: 0 > RX Dboard: A > RX Subdev: BasicRX (AB) > TX Channel: 0 > TX DSP: 0 > TX Dboard: A > TX Subdev: BasicTX (AB) > > > > Setting TX Rate: 10.00 Msps... > Actual TX Rate: 10.00 Msps... > > Setting TX Freq: 100.00 MHz... > Actual TX Freq: 0.00 MHz... > > > > 1. Why Actual TX Freq is 0?? And when I run uhd_fft , I can see only 0hz > signal. But I set center freq 100Mhz. > > 2.I try to example (uhd_tx_dpsk of gr-uhd) and run in gnuradio-companion > and see flowgraph, but I measured signal using spectrum analyzer I can't > see signal. > > I put subdev A:AB in USRP SINK block and antenna is TX/RX. What should i > do for transmit dpsk signal? > > > > > > Windows 10용 메일 <https://go.microsoft.com/fwlink/?LinkId=550986>에서 보냄 > > > > ___ > 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] using uhd_fft with usrp N210
Dear Sung Bok,Lee: Forgot to mention - so, in short, all it can do is 'digitally' shifting signals if you use BasicRX/BasicTX daughterboards. The analog frontends do not filter any signals (although the daughterboards themselves act as poor low pass filters with bandwidth of 250MHz), nor mix them down to any frequencies. The 'tuning' that I mentioned in the second paragraph of the previous e-mail is 'digitally' shifting down the signal (done by the USRP motherboard's FPGA). Regards, Kyeong Su Shin On Tue, Nov 28, 2017 at 6:41 AM, Kyeong Su Shin wrote: > Dear Sung Bok,Lee: > > You are using BasicRX/BasicTX daughterboards. These daughterboards do not > have any mixers, so they cannot 'tune' to any frequencies and you have to > supply your own RF frontends to get reasonable performances. All these > daughterboards do for you is just buffering the ADC/DAC and then providing > SMA connectors for the connection. You have to use different daughterboards > if you do not want to come up with your own frontends and yet want to get > good signals. > > If you use BasicRX/BasicTX and ask your USRP to tune to frequency x, it > will actually tune to an aliased frequency. USRP N200/N210 have native > sampling rate of 100MS/s. DAC sampling rate is rated to 400MS/s, but the > master clock is still at 100MS/s - it is just that the DAC is internally > interpolating the data you are inputting by 4x. So, if you ask it to tune > to 100MHz, it will tune to 0MHz instead - where the 100MHz signals will > alias onto. > > Regards, > Kyeong Su Shin > > On Mon, Nov 27, 2017 at 8:51 PM, 이성복 via USRP-users < > usrp-users@lists.ettus.com> wrote: > >> Hi >> >> I have 2Questions >> >> I was install Linus Ubuntu 16.04 LTS, >> >> sudo apt-get update >> >> sudo apt-get upgrade >> >> and install uhd and gnuradio (https://kb.ettus.com/Building >> _and_Installing_the_USRP_Open-Source_Toolchain_(UHD_and_GNU_ >> Radio)_on_Linux) >> >> and uhd_images_downloader >> >> uhd_image_loader --args="type=usrp2,addr=192.168.10.2" >> >> benchmark_rate --tx 10e6 --rx 10e6 >> >> and test it tx_waveforms --rate 10e6 --freq 100e6 >> >> then >> >> Using Device: Single USRP: >> Device: USRP2 / N-Series Device >> Mboard 0: N210r4 >> RX Channel: 0 >> RX DSP: 0 >> RX Dboard: A >> RX Subdev: BasicRX (AB) >> TX Channel: 0 >> TX DSP: 0 >> TX Dboard: A >> TX Subdev: BasicTX (AB) >> >> >> >> Setting TX Rate: 10.00 Msps... >> Actual TX Rate: 10.00 Msps... >> >> Setting TX Freq: 100.00 MHz... >> Actual TX Freq: 0.00 MHz... >> >> >> >> 1. Why Actual TX Freq is 0?? And when I run uhd_fft , I can see only 0hz >> signal. But I set center freq 100Mhz. >> >> 2.I try to example (uhd_tx_dpsk of gr-uhd) and run in gnuradio-companion >> and see flowgraph, but I measured signal using spectrum analyzer I can't >> see signal. >> >> I put subdev A:AB in USRP SINK block and antenna is TX/RX. What should >> i do for transmit dpsk signal? >> >> >> >> >> >> Windows 10용 메일 <https://go.microsoft.com/fwlink/?LinkId=550986>에서 보냄 >> >> >> >> ___ >> 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] Gnu radio IQ streaming
Hello Benny Alexander: What is meant is that you must multiply your samples by a constant number, 1.0/(2**15-1), to scale it from 0 - 32767 to 0 - 1 (range accepted by the USRP). Regards, Kyeong Su Shin On Mon, Dec 11, 2017 at 8:50 AM, Benny Alexandar via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Anon, > > You mean make the input to complex, by multiplying with cosine ? But the > input file is already complex and by adding the block Ishort to complex" > its already complex. Why again multiply by cosine with low amplitude ? > > -ben > -- > *From:* Anon Lister > *Sent:* Monday, December 11, 2017 7:34 PM > *To:* Benny Alexandar > *Cc:* usrp-users > *Subject:* Re: [USRP-users] Gnu radio IQ streaming > > Add a multiply block after ishort and multiply by 1.0/(2**15-1) or > thereabouts. (If you only are using 14 bits of that 16 b, do 14) > > On Dec 10, 2017 07:00, "Benny Alexandar via USRP-users" < > usrp-users@lists.ettus.com> wrote: > > Hi, > > I want to stream an IQ file base band signal using usrp. The format of IQ > signal is 16bit complex values of I and Q each interleaved and having > sample rate of 48kHz stored in a file as follows [IQIQIQ]. I created a > flow graph in usrp by selecting file block as source and used the block > "Ishort To Complex" and passed the output to rational resampler with > interpolation factor as 250 and decimation 48. This is to upsample from > 48kHz to 250kHz for usrp to stream it. Usrp is connected as sink and set > the sample rate as 250kHz. Output of usrp is not able to decode. When I > checked with FFT sink I can see the spectrum, but lot of noise is being > added, noise floor is too high. The baseband signals in the file doesn't > have any noise. > What could be the problem. Please help in streaming an IQ file using > gnu-radio and usrp. > > Thanks, > Ben > > ___ > 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] Enable aliasing using USRP
Hello Wahhab, If I recall correctly, you can *not* change the bandwidth of SBX (always 40MHz), and the sampling rate of the USRP2 (always 100MS/s). What you are actually setting by setting --rate 2e6 is the decimation ratio. The signals will be always sampled at 100MS/s, and then decimated by the decimator within the FPGA. It is still possible to cause aliasing - one way is to just sample at a fast sampling rate and then decimate by yourself. An other way would be tinkering the digital filters used by the decimator, but I am not sure if there are good APIs to do that. I am pretty sure that rx_samples_to_file is not suitable for the task, though (correct me if I am wrong). That is just an example program. Regards, Kyeong Su Shin On Thu, Dec 28, 2017 at 6:29 PM, Wahhab Albazrqaoe via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi John, > Thank you for your reply. > We would like to create aliasing. This means that we should set ADC to > sample at speed less than Nyquist rate. > In our setting, we target RF front end to be 50MHz and ADC speed is 2MHz. > The question is how to do it? We use some commands (as shown in my > previous email) but seems not working as expected, i.e. RF front end > bandwidth is still 2MHz. > > Best, > > On Thu, Dec 28, 2017 at 9:24 PM, John Shields > wrote: > >> Hi Wahhab, >>This is a fairly basic issue – the ‘bandwidth’ (if >> that is really what you are really meaning) is related to the sample_rate >> by The Nyquist Frequency >> >> https://en.wikipedia.org/wiki/ >> Nyquist_frequency >> >> Kind Regards, >> >> John >> >> *From:* Wahhab Albazrqaoe via USRP-users >> *Sent:* Friday, December 29, 2017 3:04 PM >> *To:* usrp-users@lists.ettus.com >> *Subject:* [USRP-users] Enable aliasing using USRP >> >> Dear All, >> I have question about how to create aliasing using USRP. >> Basically, I have USRP2 with SBX (with recent installations of GnuRadio >> and UHD). >> I would like to set the bandwidth of the RF front end to 50 MHz, and use >> 2MHz of sampling rate (ADC speed). >> I am using the following command: >> sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 >> --freq=2460e6 --bw=50e6 --rate 2e6 --gain=50 --wirefmt sc8 --nsamps 0 >> >> >> >> Problem: it seems to me that the system (GnuRadio/USRP) observes only >> 2MHz of RF front end bandwdith. How do I know this? Ans: I compare such >> settings with the following settings: >> sudo ./rx_samples_to_file --args addr=192.168.10.2 master_clock_rate=50e6 >> --freq=2460e6 --bw=50e6 --rate 50e6 --gain=50 --wirefmt sc8 --nsamps 0 >> >> The later setting seems to be actual 50 MHz of Rf front end. >> >> Any comments and advices on how to create aliasing using USRP are >> appreciate. >> >> Best, >> Wahhab >> >> >> >> -- >> ___ >> USRP-users mailing list >> USRP-users@lists.ettus.com >> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com >> >> >> >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> Virus-free. >> www.avast.com >> <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient> >> <#m_-1409356437401843074_m_5211752623429318912_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2> >> > > > ___ > 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] USRP to Wireshark
Hello, A good example of this is gr-ieee-802-11 ( https://github.com/bastibl/gr-ieee802-11 ) . That is for IEEE802.11 a/g/p, which you probably aren't looking at (as you are usually better off with COTS WiFi transceivers for sniffing purposes). Yet, it is something that you can look at if you are implementing your own codes. Regards, Kyeong Su Shin On Thu, Feb 8, 2018 at 7:32 AM, Jeff Long via USRP-users < usrp-users@lists.ettus.com> wrote: > The short answer is no, there is no easy way. > > The long answer is: build up the appropriate RF/L1 packet decoder in GNU > Radio, send the resulting messages to a socket or tuntap device, and use > Wireshark to see the packets. You still may have to build a parser for > Wireshark if it does not already support the protocol you are sniffing. > > On 02/07/2018 04:45 PM, Ammar Alhosainy via USRP-users wrote: > >> Hi, >> >> I use USRP B200 to sniff the traffic between to nodes. The output file >> contains the Q and I components of the samples captured with specific rate. >> Is there any easy way to convert it to PCAP file so that I can see the >> packets using Wireshark? >> >> Thanks >> >> -- >> /Ammar Alhosainy, Ph.D./ >> Research Associate | Systems and Computer Engineering | Carleton >> University >> _http://sce.carleton.ca/~amammar/ <http://sce.carleton.ca/%7Eamammar/>_ >> / >> >> /// >> >> >> ___ >> 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] MIMO Cable for USRPN200 and USRP2
Hello Wahhab, In my experience, that should work. However, Ettus Research dropped the USRP 2 support a long ago, so you can only expect community support and no official feedbacks (=basically at your own risk). Regards, Kyeong Su Shin On Thu, Feb 8, 2018 at 10:49 AM, Wahhab Albazrqaoe via USRP-users < usrp-users@lists.ettus.com> wrote: > Hi Nate, > I know it works for usrp2. > My question is about connecting usrp2 and usrpn200 with MIMO cable. Is it > possible to connect such different usrp devices? > I know that connecting two usrp2 devices via mimo cable is possible. > I know that connecting two usrpn200 devices via mimo cable is possible. > > But what about connecting usrp2 and usrpn200 with mimo cable? > > Best, > > > On Feb 7, 2018 7:31 PM, "Nate Temple" wrote: > >> Hi Wahhab, >> >> The MIMO Cable will work with the USRP2. Please see this section of the >> UHD Manual: http://files.ettus.com/manual/page_usrp2.html#usrp2_mimocable >> >> >> Regards, >> Nate Temple >> >> On Tue, Feb 6, 2018 at 1:34 PM, Wahhab Albazrqaoe via USRP-users < >> usrp-users@lists.ettus.com> wrote: >> >>> I would like to use MIMO cable to connect (synchronize) USRPN200 and >>> USRP2. >>> >>> Is it possible to do so? Is it safe to do so? >>> >>> I appreciate your comments. >>> >>> Wahhab Albazrqaoe >>> >>> >>> ___ >>> 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
[USRP-users] Fwd: i want to ask something
Hello Kim: Since you mention a MIMO cable, I assume that you are using USRP 2 / N200 / N210. Do the following: 1. Assign unique IP addresses to one of the USRPs (if you haven't yet). See: https://files.ettus.com/manual/page_usrp2.html#usrp2_network_changeip 2. Set "Device Address" or "Device Arguments" parameter of the GNU Radio UHD blocks to address specific USRP devices. See: https://files.ettus.com/ manual/page_identification.html Regards, Kyeong Su Shin On Thu, Feb 8, 2018 at 12:49 PM, 김무연 via USRP-users < usrp-users@lists.ettus.com> wrote: > Recently I am researching using two usrp, and I use gnuradio program > > Through gnuradio I can handle one usrp > > To conduct experiment, I need to connect two usrp > > To connect usrp I used two method > > First one is unsing mimo cable > > Last one is using giga-bit desktop switch > > By using both method I can check two usrps are connected > > But when I execute gnuradio, only one of them sends a signal, the other > doesn’t work > > I need to find the way to use two usrps simultaneously > > Are there any method to connect usrps or any method to send signals from > both usrps simultaneously in gnuradio? > > ___ > 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] UBX vs SBX
Hello Hojoon Yang,
Both SBX and UBX will work fine (*Assuming X3x0 series only, no N2x0 or older
boards).
You can align the phase of the UBX and SBX boards by using the timed commands (
https://kb.ettus.com/Synchronization_and_MIMO_Capability_with_USRP_Devices ) ,
but you will have to correct (manually calibrate) a constant phase offset
between the channels. Also, the accuracy of the alignment over time is not
guaranteed by Ettus Research. ("Periodic calibration will be necessary for
phase-coherent applications" - src:
https://files.ettus.com/manual/page_sync.html ). So, I recommend against
relying on the phase alignment accuracy of the daughterboards.
Other RF performance data (noise figure, etc) is available at:
http://files.ettus.com/performance_data/ . Please note that you can'not' always
use the max receive gain settings, due to the possible nonlinearity issues.
Personally, I like the UBX boards better than the SBX boards. But both are
generally suitable for such experiments.
Regards,
Kyeong Su Shin
보낸 사람: Hojoon Yang via USRP-users 대신 USRP-users
보낸 날짜: 2018년 3월 14일 수요일 오후 3:20:56
받는 사람: usrp-users@lists.ettus.com
제목: [USRP-users] UBX vs SBX
Hi.
I have two USRP X310s and wonder which board between SBX and UBX would be the
suitable for me.
I'm gonna buy four daughterboards to use it as 2x2 MIMO. One USRP X310 for Tx,
the other USRP for Rx.
My target frequency is from 1.8GHz to 2.8GHz. According to datasheet, Both UBX
and SBX work on the target frequency.
I saw the schematic of both SBX and UBX and figured it out that UBX has a
significantly different structure from SBX.
I wonder, which board performs better "in the target frequency" in terms of
MIMO performance(i.e. phase align accuracy, noise level, etc..).
I don't have price issue. If the UBX performs better or same as the SBX in
target frequency(1.8GHz~2.8GHz), I would like to buy UBX since it has more wide
frequency range.
Regards,
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Configurating B210 transmitter into two different central frequencies.
Hello José, I am pretty sure that AD9361 has only one PLL for the both TX chains. So, there is a hardware-level limitation for this. If the difference between the highest (RF) frequency and the lowest (RF) frequency occupied by the two waveforms (combined) is smaller than the effective sampling rate of the board, you will be able to transmit the two different signals. If the seperation has to be larger, you are pretty much out of luck. The easiest fix is to get more USRPs and synchronize them (if necessary) using a reference signal. Regards, Kyeong Su Shin 보낸 사람: Jose Benito Diéguez Teixeira via USRP-users 대신 USRP-users 보낸 날짜: 2018년 3월 15일 목요일 오후 10:22:52 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Configurating B210 transmitter into two different central frequencies. Hello usrp users, We are using a B210 SDR device for our application. This device has two RF frontends, but we are in doubt about their mutual independence. We need to transmit two different waveforms, each into its own frequency. We have tried to create two tx_streamers, but the creation of the second one seems to overwrite the first streamer. Is this approach the correct way to implement the dual frequency transmittion? Or more focused on the hardaware, is it possible to set two different transmittion frequencies with the B210? Thanks in advance, -- <http://www.gradiant.org/> José Benito Diéguez Teixeira ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Configurating B210 transmitter into two different central frequencies.
(You can ignore my previous response, if you read Derek's response - poor timing.) An alternative way to fix the problem (when you need to xmit on two different frequencies which are not located close enough) is to use the B210 as IF stages and to add your own RF stages on top of it. Anyway, this is a hardware limitation and the only way to fix the problem is to add more hardware (or re-design the system, so as you wouldn't have to transmit on two distinct frequencies). Regards, Kyeong Su Shin ____ 보낸 사람: Kyeong Su Shin via USRP-users 대신 USRP-users 보낸 날짜: 2018년 3월 15일 목요일 오후 10:39:12 받는 사람: Jose Benito Diéguez Teixeira; usrp-users@lists.ettus.com 제목: Re: [USRP-users] Configurating B210 transmitter into two different central frequencies. Hello José, I am pretty sure that AD9361 has only one PLL for the both TX chains. So, there is a hardware-level limitation for this. If the difference between the highest (RF) frequency and the lowest (RF) frequency occupied by the two waveforms (combined) is smaller than the effective sampling rate of the board, you will be able to transmit the two different signals. If the seperation has to be larger, you are pretty much out of luck. The easiest fix is to get more USRPs and synchronize them (if necessary) using a reference signal. Regards, Kyeong Su Shin 보낸 사람: Jose Benito Diéguez Teixeira via USRP-users 대신 USRP-users 보낸 날짜: 2018년 3월 15일 목요일 오후 10:22:52 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Configurating B210 transmitter into two different central frequencies. Hello usrp users, We are using a B210 SDR device for our application. This device has two RF frontends, but we are in doubt about their mutual independence. We need to transmit two different waveforms, each into its own frequency. We have tried to create two tx_streamers, but the creation of the second one seems to overwrite the first streamer. Is this approach the correct way to implement the dual frequency transmittion? Or more focused on the hardaware, is it possible to set two different transmittion frequencies with the B210? Thanks in advance, -- <http://www.gradiant.org/> José Benito Diéguez Teixeira ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] IQ transmission using grc
Hello Ben:
USRP N210 samples at 100MS/s (with an additional 4x interpolation in case of Tx
- making it 400MS/s). The maximum effective sampling rate, however, is
bottlenecked by the connection between the USRP and the PC. The 1Gbps Ethernet
connection can keep up with a 25MS/s 16bit I-Q data stream or a 50MS/s 8bit I-Q
data stream. Faster rate will cause a data loss.
What is important is that the internal sampling rate of the USRP N210 is fixed.
It is always 100MS/s. When you set the effective sampling rate (which is
different from the internal sampling rate of the ADC and DAC) of the USRP in
your code, the data is transferred to the USRP at the configured rate and then
resampled by the FPGA of the USRP to meet the ADC/DAC sampling rate (100MS/s).
This resampler(interpolator) has several restrictions, and restrics the valid
choice of the effective sampling rate (the sampling rate that you are setting
in your software). That is what Marcus explained in the previous e-mail.
So, yes, you can get 50MS/s from your board, but the precision of the data
should be 8 bit instead of 16 bit (which is usually not a good idea).
Furthermore, this does not concern the analog filters installed on the
daughterboard, which may further reduce the usable bandwidth.
Also, yes, at N=200, the effective sampling rate of the board is 500kS/s and
that should work without a problem.
Regards,
Kyeong Su Shin
보낸 사람: Benny Alexandar via USRP-users 대신
USRP-users
보낸 날짜: 2018년 3월 24일 토요일 오후 2:32:24
받는 사람: Marcus Müller via USRP-users; Marcus D. Leech; Marcus Müller
제목: Re: [USRP-users] IQ transmission using grc
Hi Marcus,
I'm not clear on maximum sample rate support for USRP N210. According to you
>> In case of the N210, these frequencies are integer fractions of 100 MHz
>> i.e. 100 MHz / N, with the restriction that N be an integer 3 < n <=
>> 128 , an even integer 2 < n <= 256 or an integer multiple of 4 <= 512.
Assume I use N an even minimum integer say 2, then the sampling frequency I
can get
on USRP N210 is 100 MHz / 2 = 50 MHz. Is that correct ?
Can USRP sample at such high rates ?
If I need a bandwidth of say 500kHz, from USRP then I need to set N = 200, is
my math correct
and the sample rates to set for usrp ?
-ben
From: USRP-users on behalf of Marcus
Müller via USRP-users
Sent: Wednesday, March 21, 2018 2:10 AM
To: Marcus D. Leech; usrp-users@lists.ettus.com
Subject: Re: [USRP-users] IQ transmission using grc
Hi ben,
also, no USRP can directly deal with a sampling rate as low as 48 kHz –
you'll first have to resample to a rate that your USRP can deal with.
In case of the N210, these frequencies are integer fractions of 100 MHz
i.e. 100 MHz / N, with the restriction that N be an integer 3 < n <=
128 , an even integer 2 < n <= 256 or an integer multiple of 4 <= 512.
tx_samples_from_file can't resample – you should have been getting UHD
warnings about impossible sampling rates; your IQ file has simply been
played back at a higher rate.
Best regards,
Marcus
On Tue, 2018-03-20 at 12:58 -0400, Marcus D. Leech via USRP-users
wrote:
> On 03/20/2018 12:37 PM, Benny Alexandar via USRP-users wrote:
> > Hi,
> >
> > I have an IQ file sampled at 48kHz and want to transmit through gnu
> > radio. The IQ samples are each 16bit, and stored interleaved in a
> > file
> > ie, IQIQIQIQ... I 16 bit and Q 16bit
> >
> > I tried creating a grc using iShort to Complex block and send to
> > USRP sink block (usrp n210), but the signal received is distorted.
> > Do I need to convert the short values into float -1.0 to +1.0
> > before transmission. Please help in resolving it.
> >
> > I want to use it only through grc and not to use
> > tx_samples_from_file which does the same.
> >
> > -ben
> >
> You'll need to scale your samples into {-1.0,1.0}
>
>
>
> ___
> 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] start read data from source file not from the beginning
Hello Ishai, Although it is a bit hacky way, you can probably use a "skip head" block to drop a first few samples of the data (drop first 1024 bytes of information using it). I guess this topic better fits "discuss-gnuradio" mailing list - please consider using that. Regards, Kyeong Su Shin 보낸 사람: Allouche Ishai via USRP-users 대신 USRP-users 보낸 날짜: 2018년 4월 25일 수요일 오전 12:39:28 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] start read data from source file not from the beginning Hi everyone, I am using the Source File block at Gnuradio and I read the file successfully, but I steel have an issue that I don’t know how to do it. I have .bin file that instead of read it from the beginning, I want to start to read the file after 1024 Bytes. Someone maybe can help to understand how I can do it. Thank in advance BR Ishai sensitive information. Unauthorized interception of this e-mail may constitute a violation of law. If you are not the intended recipient, you are hereby notified that any review, dissemination, distribution or duplication of this communication is strictly prohibited. You are also asked to contact the sender by reply email and immediately destroy all copies of the original message. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] (no subject)
Hello Kazem: Just follow the instructions in the error message: "/usr/local/lib/uhd/utils/uhd_images_downloader.py" "/usr/local/bin/uhd_image_loader" \ --args="type=usrp2,addr=192.168.10.3" You may have to add "sudo" in front of the commands. Also, you may have to install python-request to get uhd_images_downloader.py working. Finally, you may have to power-cycle the USRP after running the above commands. Regards, Kyeong Su Shin 보낸 사람: kazem chm via USRP-users 대신 USRP-users 보낸 날짜: 2018년 4월 28일 토요일 오후 11:14:04 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] (no subject) Good day dear Sir, I am a new user of Ubuntu and USRP. I'm trying to connect my PC to USRP N200, but I have encountered the error below. I have installed and uninstalled my GNU radio and UHD several times, but what I get is still the latest version in which is not compatible with my FPGA. I guess I need to upgrade my FPGA on USRP but I have no idea how to do that. Please give me a step by step guide to solve this problem. warm regards, Kazem The error: RuntimeError: Please update the firmware and FPGA images for your device. See the application notes for USRP2/N-Series for instructions. Expected FPGA compatibility number 11, but got 10: The FPGA build is not compatible with the host code build. Please run: "/usr/local/lib/uhd/utils/uhd_images_downloader.py" "/usr/local/bin/uhd_image_loader" \ --args="type=usrp2,addr=192.168.10.3" Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for Windows 10 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP Underruns "UUUUU"
Hello Yeo Jin, First, find the maximum effective sampling rate that you can achieve with your computer. Connect a constant source to a USRP sink (for USRP sink underruns), or connect a USRP source to a null sink (for USRP source overruns) and run the flow graph. Try different sampling rates to find the maximum achievable sampling rate for your hardware (max samp rate that gives no underruns or overruns). If the maximum stable sampling rate that you can achieve is still 4MS/s, then you are pretty much out of luck. You can try installing different versions of GNU Radio and UHD (older version/newer version, version with AVX support, etc) and then try again. If that does not help (very likely), then you WILL have to upgrade your computer. In some cases, using a different network card (for network-based USRPs) or USB card (for USB-based USRPs) may improve the achivable rate (when the bottleneck is the link between the USRP and the PC). If that doesn't work either, then you will have to get a faster machine. If you can achieve a higher sampling rate with the simple flow graphs stated above, then the problem is the maximum throughput of your code. You can try optimizing your GNU Radio flow graphs and blocks. Try using simpler filters, and parallelize the bottlenecks within your flow graphs if possible (so as the CPU usage would go up to approx. 100% during the execution). You can run top and press H to see which block is taking the most CPU time (assuming a typical GNU/Linux distro). If you do not need to generate your I-Q data in real time, then generate your data before the execution of the flow graph and simply play back the pre-generated data (with a File Source block). You can also push down some of your DSP logics to the FPGA of the USRPs, if you have licences for the needed software (and if you are okay with HDL). Regards, Kyeong Su Shin 보낸 사람: Yeo Jin Kuang Alvin (IA) via USRP-users 대신 USRP-users 보낸 날짜: 2018년 5월 4일 금요일 오후 6:29:09 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] USRP Underruns "U" Hi all, I am getting underruns and overruns when trying to run the UHD programs, both GNU radio and C++. The maximum my computer can handle is 4MHz sampling rate before seeing “U”. I’ve searched online and most people say, change a new computer into quad core etc. Are there any other ways to solve this problem? I want to hit around 20 MHz, but 30 MHz – 40MHz if possible. Thank you in advance! ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP Underruns "UUUUU"
Hello Yeo Jin: * If your maximum sampling rate on Windows is 4MS/s and if you are using the MIMO capability of the device, you may want to double-check the USB2/USB3 issue that Alfredo Gardel mentioned (because (8/channels)MS/s is the approximately the maximum rate that you can achieve with USB 2.0). * The Windows GNU Radio distribution comes with a few out-of-tree modules pre-installed. You will have to find and install the missing out-of-tree module on your Linux system. The modules can be found from http://www.cgran.org/ or GitHub. My guess is that you are missing gr-radar:https://github.com/kit-cel/gr-radar . * Just want to mention - questions that are related to GNU Radio but not related to USRP can be directed to discuss-gnuradio mailing list or the GNU Radio IRC channel. They could be better addressed there. * I am not really experienced with RADAR systems, but it seems like that the FMCW signals are deterministic (Please correct me if I am wrong). If so, you can pre-generate the signals, store them into files (use tmpfs if the drive is too slow), and then simply play back the pre-generated files using the "File Source". * If your flow graph is not keeping up but the CPU usage is under 100% (=not all cores are being fully used), then you can crunch out more throughput by parallelizing the block which is acting as the bottleneck. The bottleneck can be located by looking for the block (usually a single thread) which is occupying the most CPU time during the execution. In my computer, running top and pressing H (in upper-case letter!) does the job. If you can somehow parallelize that thread into multiple threads (modify the algorithm of the block itself, or modify the flow graph), then the maximum throughput may improve. But this is not always possible - maybe the block cannot be parallized at all! Regards, Kyeong Su Shin 보낸 사람: Yeo Jin Kuang Alvin (IA) 보낸 날짜: 2018년 5월 7일 월요일 오후 12:02:57 받는 사람: Kyeong Su Shin; usrp-users@lists.ettus.com 제목: RE: USRP Underruns "U" Hi all, Thank you for all the help! I have tested what kyeong Su Shin mentioned, both on windows and Ubuntu. However, the maximum sampling rate I can go in Windows is 4MS/s but for Ubuntu it can go up to 40MS/s with a only 2-3 U’s to be seen. The problem for me now is that I want to use the FMCW source generator that can be found on my Windows GNU Radio Companion, but I cant find it in Ubuntu, so I cant test out my project using Ubuntu. I’ve tried running https://github.com/scivision/piradar/FMCW_usrp.grc on Ubuntu and the maximum sampling rate I can hit is about 8MS/s. What do you mean by parallelize the bottlenecks (listed below), is there something that I can do to the FMCW_usrp.grc for this? I’ve tried pressing H while running top and nothing seems to pop out or show. Thank you in advance! ---Try using simpler filters, and parallelize the bottlenecks within your flow graphs if possible (so as the CPU usage would go up to approx. 100% during the execution). You can run top and press H to see which block is taking the most CPU time (assuming a typical GNU/Linux distro). --- From: Kyeong Su Shin [mailto:kss...@postech.ac.kr] Sent: Friday, 4 May 2018 6:05 PM To: Yeo Jin Kuang Alvin (IA); usrp-users@lists.ettus.com Subject: RE: USRP Underruns "U" Hello Yeo Jin, First, find the maximum effective sampling rate that you can achieve with your computer. Connect a constant source to a USRP sink (for USRP sink underruns), or connect a USRP source to a null sink (for USRP source overruns) and run the flow graph. Try different sampling rates to find the maximum achievable sampling rate for your hardware (max samp rate that gives no underruns or overruns). If the maximum stable sampling rate that you can achieve is still 4MS/s, then you are pretty much out of luck. You can try installing different versions of GNU Radio and UHD (older version/newer version, version with AVX support, etc) and then try again. If that does not help (very likely), then you WILL have to upgrade your computer. In some cases, using a different network card (for network-based USRPs) or USB card (for USB-based USRPs) may improve the achivable rate (when the bottleneck is the link between the USRP and the PC). If that doesn't work either, then you will have to get a faster machine. If you can achieve a higher sampling rate with the simple flow graphs stated above, then the problem is the maximum throughput of your code. You can try optimizing your GNU Radio flow graphs and blocks. Try using simpler filters, and parallelize the bottlenecks within your flow graphs if possible (so as the CPU usage would go up to approx. 100% during the execution). You can run top and press H to see which block is taking the most CPU time (assuming a typical GNU/Linux distro). If you do not need to genera
Re: [USRP-users] [Discuss-gnuradio] USRP DDC and GNURadio Bandwidth Problem
Hello Ali,
That "bandwidth" parameter of the UHD Source/Sink block is used to adjust the
'analog bandwidth' of the 'daughterboard'. Most of the daughterboards have a
fixed analog bandwidth, so that parameter will be simply ignored in most cases
('uhd_usrp_probe' will give the detailed info about the daughterboard). They
are not used to configure digital filter taps.
If you want to add digital filters, you can simply add them on GNU Radio as
seperate blocks. Software FIR/IIR filters are pretty slow, but they can keep up
when the sampling rate is that low. If you want to push down some codes to the
FPGA, consider RFNoC.
Regards,
Kyeong Su Shin
보낸 사람: Ali <03do...@gmail.com> 대신 Discuss-gnuradio
보낸 날짜: 2018년 5월 17일 목요일 오후 10:10:27
받는 사람: discuss-gnura...@gnu.org; usrp-users@lists.ettus.com
제목: Re: [Discuss-gnuradio] USRP DDC and GNURadio Bandwidth Problem
Hi,
I don't want my sampling rate to be 25 kHz. My sampling rate is already 195312
Hz which is I think the minimum sampling rate for X310.
What I want is to filter out the frequencies which are at least 25 kHz away
from my center frequency. For example I don't want to see a transmission which
is 50 kHz away from my center frequency. Is it possible? How does the
"bandwidth" parameter in UHD Source Block in GNURadio affect the captured IQ
data?
Regards,
Ali
2018-05-14 12:19 GMT+03:00 Derek Kozel
mailto:derek.ko...@ettus.com>>:
Hello Ali,
To extend what Marcus has said, here is a link to the UHD manual page about
sample rates.
http://files.ettus.com/manual/page_general.html#general_sampleratenotes
Regards,
Derek
On Mon, May 14, 2018 at 8:54 AM, Müller, Marcus (CEL)
mailto:muel...@kit.edu>> wrote:
Hi Ali,
just like the console will tell you, 25 kS/s is simply impossible with
an X310; instead, the minimum possible rate was used.
You should probably just configure your X310 to get you e.g. 500 kS/s,
and then resample in digital domain. If you're hesitant to design your
own decimating filter, use the "rational resampler" block and configure
it to decimate by (500/25)=20.
Best regards,
Marcus
On Mon, 2018-05-14 at 10:18 +0300, Ali wrote:
> Hi to all,
>
> I am using GNURadio to control an X310. I want to get IQ samples for only 25
> kHz bandwidth.
>
> When I wrote 25 kHz to the bandwidth line in UHD-Source block in GNURadio, I
> still see the signals at 50 kHz or 75 kHz away from the center. My sampling
> rate is 195312 Hz. When checked in MATLAB, the signals are there. It looks
> like I cannot control the bandwidth with GNURadio.
>
> I suspected that there is not any DDC filter for this bandwidth. If it is so,
> what is the minimum bandwidth for USRPs? Are the bandwidths that I can use
> discrete? I am confused.
>
> Thanks in advance,
> Ali
>
> ___
> Discuss-gnuradio mailing list
> discuss-gnura...@gnu.org<mailto:discuss-gnura...@gnu.org>
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
Discuss-gnuradio mailing list
discuss-gnura...@gnu.org<mailto:discuss-gnura...@gnu.org>
https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Noise vs Sample rate
Hello Thibaud, Think this in the frequency domain. A typical decimator 1. applies a low-pass filter to the incoming samples, and then 2. downsamples the data by extracting every n th sample. The low-pass filter does not only filter out non-desired signals, but also filters out noise. So, you must observe reduced noise. In your case, the thermal noise becomes -174 + 10*log(400kHz) when you decimate the signal. Your actual noise floor would be somewhat higher than the thermal noise (because real-world devices never achieve the thermal noise bound), however, and the actual noise level would depend on various factors, including the hardware itself and the low-pass filter design of the decimator. Regards, Kyeong Su Shin 보낸 사람: Thibaud Vial via USRP-users 대신 USRP-users 보낸 날짜: 2019년 12월 7일 토요일 오전 12:34 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Noise vs Sample rate Hi, I'm currently working on USRP sensitivity and noise. Noise power depends on receiver bandwidth (https://en.wikipedia.org/wiki/Johnson%E2%80%93Nyquist_noise#Noise_power_in_decibels). But what if : - I sample a signal at 4MHz with USRP + GNURadio (Thermal noise power = -174 + 10*log(4MHz) ) - I add a decimation by 10 in GNURadio What is the new thermal noise power ? The same, or -174 + 10*log(400kHz) ? I've made some tests with USRP + GNURadio, and the noise seems to be lower after decimation, but not of 20 dB (more of 10 dB). Thanks for your help, ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] GNU Radio UHD Blocks Resolution
To whom it may concern:
A few points to add:
-12-bit ADCs do not necessarily mean that you will get 12-bit resolutions from
your received data. Resamplers may increase the effective bit depth. Say you
have the smallest step of 1 and have [1 2] as samples; You downsample that to
[1.5] and now the smallest step is 0.5. I don't know how B200 works, but it is
a common practice to oversample and then resample in a DSP or a FPGA to get
higher bit resolutions.
-I think AD9361 (used in B200) has a hardware AGC (not turned on by default).
However, as Marcus mentioned, it is best left to the application. Without
knowing the signals and the channel conditions, AGC designers must make many
assumptions which may be incorrect or make the performance suboptimal. You can
give it a shot, but the best way is to roll your own AGC (you can change the
gain level of your USRP on the fly).
-As Marcus mentioned, in many cases, it does _not_ make sense to increase the
gain level until every ADC bit is utilized. That does _not_ necessarily
increase the SNR of the received signal, as LNAs may get overloaded and show
nonlinear behaviors. In fact, the SNR may degrade as you increase the gain
level.
Regards,
Kyeong Su Shin
보낸 사람: Marcus D. Leech via USRP-users 대신
USRP-users
보낸 날짜: 2020년 2월 21일 금요일 오전 4:07
받는 사람: Alvaro Pendas
참조: USRP-users@lists.ettus.com
제목: Re: [USRP-users] GNU Radio UHD Blocks Resolution
On 02/20/2020 01:54 PM, Alvaro Pendas wrote:
I get what you mean, but maybe I did not explain myself correctly. Let's forget
about GNU Radio and focus on the ADC. The ADC resolution is 12 bits, so it has
4096 digital levels. The question here is, does the usrp adapts those levels to
the signal it is receiving at each moment? If that adaptation does not exist,
the ACD is going to use all the 4096 only when the analog input signal is close
to the input max of the ADC. Otherwise, only some of those levels are used. For
example, half of them (2048) if the level of the ACD input is half the max.
You're talking about AGC -- no, it does not do AGC by default. AGC strategies
are generally best left to the downstream application.
Also, mind that, in the receiving part, I think that what you explained is not
completely right. I am working with a QPSK receiver and I demodulate the
symbols correctly (with a lot of noise), but the output of the UHD:USRP Source
are actually about 0.0003. That's why I'm afraid of the problem I've mentioned
above.
Something to be aware of is that increasing gain beyond the level where SNR no
longer improves, just gives you a louder (signal+noise), but
does nothing to improve SNR. Keep in mind that on the B2xx, the maximum
gain setting in RX is about 72dB, so if you're using a setting of
30dB (you mentioned that setting before), then you still have 40dB of
head-room in the RX gain setting...
Thank you for your patient.
El jue., 20 feb. 2020 a las 19:28, Marcus D. Leech
(mailto:patchvonbr...@gmail.com>>) escribió:
On 02/20/2020 11:38 AM, Alvaro Pendas wrote:
However, the way I see it, this represents a problem in the receiving part. Let
me put it this way: the max output of the ADC is 1, and that corresponds with
the max input. That max input would represent the case when you receive a high
power signal and you set your drive amplifier next to its max.
So, If you are receiving a low power QPSK signal, with your gain set to 30 dB,
the output of your ADC would use a really small part of the range (let's say
from -0.05 to 0.05). However, if your digital levels go from -1 to 1 and are
represented with 12 bits, using such a small part of the range would make the
quantization error a problem.
Gnu Radio uses a floating-point {-1.0, 1.0} representation, which UHD *scales*
into a range that is appropriate for whatever hardware
you're using.
So, your 0.05 is scaled to about 102 by UHD prior to presentation to the DAC,
and conversely in the receive direction.
El mié., 19 feb. 2020 a las 20:04, Marcus D Leech
(mailto:patchvonbr...@gmail.com>>) escribió:
Indeed. You’d have to use an external calibration source at several places over
your parameter space (frequency gain sample rate)
Sent from my iPhone
On Feb 19, 2020, at 1:54 PM, Alvaro Pendas
mailto:alvarop...@gmail.com>> wrote:
Marcus thank your for your answer,
First of all, you are right, the range is -1 to 1 (instead of 0 to 1 as I said
before). So, for example, in the receiving part, the values you get out of the
UHD Source have a linear relationship with the voltage of the analog signal,
but I understand there is no easy way to calculate that level with the only
information of the GNU Radio samples. Is that correct?
El mié., 19 feb. 2020 a las 19:22, Marcus D. Leech via USRP-users
(mailto:usrp-users@lists.ettus.com>>) escribió:
On 02/19/2020 12:01 PM, Alvaro Pendas via USRP-users wro
Re: [USRP-users] 10.23Msps Sample Rate
Hello Guowang: First, if you are woking on GNSS (it's just my guess, but that's where 10.23 MHz usually comes from), you usually DON'T need to use 10.23 MS/s (see GNSS-SDR and gps-sdr-sim source codes). So, you may want to think about that before proceeding further. If you absolutely want to use 10.23 MS/s, then you can try resampling your data (either on your PC, on the FPGA, or both). It may require a pretty serious resampler, though (could be difficult to this in real-time). You can try altering the actual hardware clock of the board, but do not expect it to be a trivial task. Regards, Kyeong Su Shin 보낸 사람: guowang qiu via USRP-users 대신 USRP-users 보낸 날짜: 2020년 4월 28일 화요일 오전 3:52 받는 사람: usrp-users@lists.ettus.com 참조: Damon Qiu 제목: [USRP-users] 10.23Msps Sample Rate Hi all, We are trying to get 10.23Msps or 20.46Msps sample rate with X310. Latest UHD driver enables USRP x310 support 184.32MHz to 200MHz master clock rate. But it just support some discrete values，unfortunately, it just didn't support 10.23M*18 or 10.23M*19. We have tried to input an external reference clock of 10.23MHz, and we want to cheat x310 that the external clock is 10MHz. We set the master clock rate of the system as 200MHz. If the PLL can lock to the external clock source, the actual master clock rate is 10.23 × 20MHz. However, when the program is running, the UHD driver throws an exception, indicating: terminate called after throwing an instance of 'uhd::runtime_error' what(): RuntimeError: Reference Clock PLL failed to lock to external source. Is there any way to obtain 10.23Msps sample rate with X310? Best regards, Damon ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] 10.23Msps Sample Rate
Hello Damon, That does not mean that you have to use a physical 10.23 MHz clock. A good digital resampler should allow the device to transmit essentially the same signal. Implementing a good resampler could be challenging (a rational-resampler may take too much taps to implement), but there are still some feasible designs (especially if it does not need to process the data in real-time, by any chance, or if you are okay with writing HDL codes). In fact, USRPs already do this. Their Rx chains sample at a faster rate, and then decimate the sampled data to the target sampling rates. Their Tx chains do the opposite. When you ask USRPs to sample at, say, 10 MS/s, their ADCs are not sampling at 10 MS/s: they sample at 200 MS/s, then provide you resampled version of the data at 10 MS/s. It's just that the default resamplers included in their FPGAs have limited capabilities, so they cannot cover the sampling rates that you are looking for. Also, I do not know what applications you are working on, but if you are working on GNSS (it's just my guess, since 10.23 MHz is a common rate for GNSS satellites), the precision of the data stream does not actually matter that much. Yes, you do want to use a good clock, so as the signals would correlate well, but you can make rough estimates (like using square shaping filter) when you are generating the data, and still get decent correlation peaks, as long as the assumptions are not bad enough to significantly break the correlation properties of the signals. This is regularly exploited in GNSS receivers and transmitters. If you still believe that you want to use a physical 10.23 MHz clock, then maybe you want to check out the fact that USRP x300s support 30.72 MHz external ref clock ( https://files.ettus.com/manual/page_usrp_x3x0.html#x3x0_hw_x3x0_hw_ref10M ). Maybe you can try inputting something like 30.69 MHz (10.23 * 3) as your ext ref clock.. but I am not so sure about this. (It WILL screw up some timing, but how bad?) Please note that you may need to use a recent version of the UHD and the FPGA firmware. Regards, Kyeong Su Shin 보낸 사람: guowang qiu 보낸 날짜: 2020년 4월 29일 수요일 오전 3:13 받는 사람: Kyeong Su Shin 참조: usrp-users@lists.ettus.com ; Damon Qiu 제목: Re: [USRP-users] 10.23Msps Sample Rate Hi Kyeong Su Shin, Thank you for your reply. We need to send out signal at a very precise time. Interval between packet transmitting needs to be an integral multiple of 1 / 10.23M, so the master clock rate is should be N*10.23MHz. Best regards, Damon On Tue, 28 Apr 2020 at 12:45, Kyeong Su Shin mailto:kss...@postech.ac.kr>> wrote: Hello Guowang: First, if you are woking on GNSS (it's just my guess, but that's where 10.23 MHz usually comes from), you usually DON'T need to use 10.23 MS/s (see GNSS-SDR and gps-sdr-sim source codes). So, you may want to think about that before proceeding further. If you absolutely want to use 10.23 MS/s, then you can try resampling your data (either on your PC, on the FPGA, or both). It may require a pretty serious resampler, though (could be difficult to this in real-time). You can try altering the actual hardware clock of the board, but do not expect it to be a trivial task. Regards, Kyeong Su Shin 보낸 사람: guowang qiu via USRP-users mailto:usrp-users@lists.ettus.com>> 대신 USRP-users mailto:usrp-users-boun...@lists.ettus.com>> 보낸 날짜: 2020년 4월 28일 화요일 오전 3:52 받는 사람: usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> mailto:usrp-users@lists.ettus.com>> 참조: Damon Qiu mailto:qiu.guowang...@gmail.com>> 제목: [USRP-users] 10.23Msps Sample Rate Hi all, We are trying to get 10.23Msps or 20.46Msps sample rate with X310. Latest UHD driver enables USRP x310 support 184.32MHz to 200MHz master clock rate. But it just support some discrete values，unfortunately, it just didn't support 10.23M*18 or 10.23M*19. We have tried to input an external reference clock of 10.23MHz, and we want to cheat x310 that the external clock is 10MHz. We set the master clock rate of the system as 200MHz. If the PLL can lock to the external clock source, the actual master clock rate is 10.23 × 20MHz. However, when the program is running, the UHD driver throws an exception, indicating: terminate called after throwing an instance of 'uhd::runtime_error' what(): RuntimeError: Reference Clock PLL failed to lock to external source. Is there any way to obtain 10.23Msps sample rate with X310? Best regards, Damon ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Modulation technique for sliding correlator channel sounder
Hello Akinyele: You do not need to use any specific modulation techniques to implement a channel sounder. This is because the receiver already knows the transmitted I-Q sequence, and correlation is taken directly on the incoming I-Q sequences to measure the channel. Of course, you should still carefully design the transmitted sequences, as some sequences have poor correlation properties. Maybe you can use something like BPSK-modulated PN sequences. Regards, Kyeong Su Shin 보낸 사람: AKINYELE ITAMAKINDE via USRP-users 대신 USRP-users 보낸 날짜: 2020년 5월 28일 목요일 오전 8:26 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Modulation technique for sliding correlator channel sounder I am working on propagation channel measurement using a sliding correlator channel sounder flowgraph for Tx and Rx. The sliding correlator channel sounder flowgraphs I've gotten so far from internet search have no modulation technique. Does that show it does not require modulation technique? If yes, why? Thanks. Akinyele ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] spectrum availability measurement with usrp
Hello Trang: It depends on your applications. USRPs CAN be used to scan and map the wireless spectrum, but you will have to determine whether the spectrum is empty or not, and it is not a trivial question. For an example, signals from satellites and spacecrafts are often below the thermal noise, so you will need to use special dish antennas and/or correlate the signals with known sequences in order to detect them. Also, USRP B200/B210 are not high-end spectrum analyzers, so they may show you some spurious signals (possible false positives). So, yes, it is possible, but I don't know whether they are suitable for your use cases. Regards, Kyeong Su Shin 보낸 사람: My St via USRP-users 대신 USRP-users 보낸 날짜: 2020년 10월 20일 화요일 오전 10:40 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] spectrum availability measurement with usrp Dear all, I'm new with USRP but I would like to use a B200 or B210 card to show the spectrum availability in time. That means, I want to put a USRP card in a place, connect it to a computer, choose a frequency and show the statistics about the occupation/availability of this frequency over an observation period. Is it possible? Could someone tell me the starting point ? Thank you very much. With kind regards, Trang Nguyen ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] spectrum availability measurement with usrp
Hello Trang: Then you can probably start with energy detection. Just tune to the channel that you intend to check, collect samples, take FFT -> mag^2 (optional), then check whether the power level of the channel stays below some level for a pre-defined length of time. If it stays under that level, you claim that the channel is available (occupied otherwise). Once that's done, you can hop to the next channel and repeat the whole proces. Just search something like "usrp energy detection" or "usrp cognitive radio" on your search engines, and you will see some articles regarding this. Please note that this is probably not an acceptable practice on some bands. For Wi-Fi bands, this is probably acceptable (because those bands are intended for unlicensed uses anyway). Regards, Kyeong Su Shin 보낸 사람: My St via USRP-users 대신 USRP-users 보낸 날짜: 2020년 10월 21일 수요일 오전 7:57 받는 사람: Marcus D. Leech 참조: usrp-users@lists.ettus.com 제목: Re: [USRP-users] spectrum availability measurement with usrp Dear Kyeong and Marcus, Thank you very much for your answers which help me to see better the challenges. I intend to start with Wi-Fi signals. We have a lot of Wi-Fi networks around us and I want to show the occupation/availability of Wi-Fi channels. I also intend to use gnu-radio. With best regards, Trang Nguyen Le mar. 20 oct. 2020 à 07:37, Marcus D. Leech via USRP-users mailto:usrp-users@lists.ettus.com>> a écrit : On 10/20/2020 01:05 AM, Kyeong Su Shin via USRP-users wrote: Hello Trang: It depends on your applications. USRPs CAN be used to scan and map the wireless spectrum, but you will have to determine whether the spectrum is empty or not, and it is not a trivial question. For an example, signals from satellites and spacecrafts are often below the thermal noise, so you will need to use special dish antennas and/or correlate the signals with known sequences in order to detect them. Also, USRP B200/B210 are not high-end spectrum analyzers, so they may show you some spurious signals (possible false positives). So, yes, it is possible, but I don't know whether they are suitable for your use cases. Regards, Kyeong Su Shin Some further wisdom. SDRs are *components* in an overall engineered RF *system and application*. They aren't "born" knowing your particular application. You'll need some non-trivial knowledge of software development methodologies, DSP knowledge, and knowledge of radio and electronics to develop an application that suits your needs. Now, there are lots of applications for SDRs in general out there. I'd suggest you query the discuss-gnuradio mailing list as well. But don't be surprised to find that an application that fits precisely what you want to do doesn't exist. Consider two things: The set that could be described as "useful things you might want to do with radio technology" The set that could be described as "useful things you might want to do with a computer" Both of those sets are staggeringly large. So even an intersection will also be staggeringly large. So it should not perhaps be surprising that not everything that could possibly be done with this technology has already been invented, and conveniently packaged. ___ 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 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] USRP sample rate and bandwidth
Hello Koyel: Yes, BUT please be warned that most USRP daughterboards have fixed filter bandwidth, and they may simply ignore the bandwidth parameter (without notifications). Regards, Kyeong Su Shin 보낸 사람: Koyel Das (Vehere) via USRP-users 대신 USRP-users 보낸 날짜: 2021년 1월 13일 수요일 오후 3:08 받는 사람: USRP-users@lists.ettus.com 제목: [USRP-users] USRP sample rate and bandwidth Hi, The USRP sample rate and bandwidth are two different parameters in gnuradio so if I want 20 MHz bandwidth and 100 MSps sample rate then will setting bandwidth = 20 MHz and sample rate = 100 MHz serve my purpose? Normally sample rate (100 MHz in this case) is the bandwidth unless filter is used so does that mean USRP is filtering out 20 MHz keeping sample rate at 100 MHz by itself? Regards, Koyel Das Senior – Product Engineer Vehere | Proactive Communications Intelligence & Cyber Defence M: +919051132173 | T: +91 33 40545454 | F: +91 33 40545455 | W: www.vehere.com<http://www.vehere.com/> [unnamed]<https://www.linkedin.com/company/vehere-interactive-p-ltd> [unnamed (1)] <https://twitter.com/VehereIndia> [unnamed (2)] <https://www.facebook.com/VehereIndia/> Vehere is the proud recipient of the Fastest Growing Technology Company Awards in India & Asia since 2012! The content of this e-mail is confidential and intended solely for the use of the addressee. The text of this email (including any attachments) may contain information, which is proprietary and/or confidential or privileged in nature belonging to Vehere Interactive Pvt Ltd and/or its associates/ group companies/ subsidiaries. If you are not the addressee, or the person responsible for delivering it to the addressee, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and remove this communication entirely from your system. The recipient acknowledges that no guarantee or any warranty is given as to completeness and accuracy of the content of the email. The recipient further acknowledges that the views contained in the email message are those of the sender and may not necessarily reflect those of Vehere Interactive Pvt Ltd. Before opening and accessing the attachment please check and scan for virus. WARNING: Computer viruses can be transmitted via email. The recipient should check this email and any attachments for the presence of viruses. The company accepts no liability for any damage caused by any virus transmitted by this email. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] ALSA audio problem
Hello Munir, You are not supposed to use 'throttle' blocks if the rate of the flowgraph is already limited by attached hardware (ex: USRP src /sink, audio source / sink). As Derek mentioned, this is probably due to the two-clock problem of the system. Try inserting a few seconds of delays to the audio stream by using a "Delay" block right before the Audio Sink - if this slows down the occurance of the problem, then it is likely caused by the clock mismatch. See: https://www.google.com/search?q=two-clock+problem+GNU+Radio Regards, Kyeong Su Shin 보낸 사람: Muhammad Munir via USRP-users 대신 USRP-users 보낸 날짜: 2018년 7월 27일 금요일 오후 1:40:42 받는 사람: Derek Kozel 참조: usrp-users 제목: Re: [USRP-users] ALSA audio problem Hi Derek, Thanks for the response. The answer to your question "Do you have a throttle block or a piece of hardware?" is that I used USRP N200 hardware to get data. I also placed throttle block as well. I checked on different possible sample rate of sound card. The problem is whenever I run the same program on 8 core CPU, it works fine. I changed the motherboard as well. It is working fine with 8 core processor on any motherboard; but create choppy sound on 12 core processor. Munir On Tue, Jul 24, 2018 at 7:47 PM, Derek Kozel mailto:derek.ko...@ettus.com>> wrote: Hello Mr Munir, Yes, GNU Radio will work with a 12 core CPU. Problems with the audio sink are usually a clock crossing issue. Your sound card is running at a slightly different sample rate than whatever the source of your samples is. Do you have a throttle block or a piece of hardware such as a radio which is the source of the samples GNU Radio is processing? Derek On Mon, Jul 9, 2018 at 11:11 AM, Muhammad Munir via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Dear All, I am facing problem with audio sink block on Gnuradio. When I run application, there is a clear sound for about 8 to 10 minutes. After that sound becomes choppy with knocking sound. I tried different sample rate including 16kHz, 24kHz, 44.1kHz, 48kHz, and 96kHz with appropreate resampling. When I record .wav file the signal during that choppy sound and play it in player , it playback with no error. I am using Core i7 8th Generation 12 core processor. I have attached a picture. When i test the sound application in sound setting, it shows a flickering of ALSA plug-in [Python 2.7]. My queries are i. Is it a problem with sound card of the motherboard? ii. Does Gnuradio version 3.7.10 supported at 12 core processor? because when I run the same application at 8 core processor, it has no issue of audio. iii. Suggest solutions to this problem. Regards, M. 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 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Max instantaneous bandwidth on USRP2
Hello Diniz, 40 MHz (analog filter bandwidth of the daughterboard). A USRP 2 can continuously stream at 50 MS/s (complex baseband samples) using the 8-bit wire mode. That means that the maximum bandwidth that the device can cover is limited by the analog filter bandwidth of the daughterboard, which is 40 MHz. But the 8-bit wire mode reduces the dynamic range of the data, and since the USRP 2 does not have a large internal buffer, you cannot really use the 16-bit wire mode at 50 MS/s (unless you are happy with very short, discontinous snapshots of I-Q data). The maximum sustainable rate at the 16-bit wire mode is 25MS/s (=25MHz max bandwidth). (Also, do not forget that the filters - either analog or digital - are not ideal, and that may further reduce the usable bandwidth of the device in some scenarios.) Regards, Kyeong Su Shin. 보낸 사람: Rafael Diniz via USRP-users 대신 USRP-users 보낸 날짜: 2018년 8월 25일 토요일 오전 8:48:21 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Max instantaneous bandwidth on USRP2 Hi all, Which is the maximum instantaneous bandwidth I can capture from a USRP 2 with a WBX daughterboard? Thanks, Rafael Diniz ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] SBX-120 transmit power
Hello, I wouldn't expect the full 20 dBm output power from the board, even when the board is at the 31.5 dB TX gain setting. Actual power level will depend on several other factors, including the center frequency that the board is tuned at. The power would be lower than 20 dBm in most scenarios. That said, I would still use a relatively low TX gain power level when using loopback configurations, just to be on the safe side. Regards, Kyeong Su Shin 보낸 사람: Michael Don via USRP-users 대신 USRP-users 보낸 날짜: 2018년 11월 14일 수요일 오후 11:10:46 받는 사람: leoechevar...@gmail.com 참조: USRP-users@lists.ettus.com 제목: Re: [USRP-users] SBX-120 transmit power I think the answers are yes and yes. On Wed, Nov 14, 2018 at 6:46 AM Leandro Echevarría via USRP-users mailto:usrp-users@lists.ettus.com>> wrote: Hey folks, The Knowledge Base webpage for the SBXs daughterboards [1] mentions that their maximum output power is 100 mW (20 dBm), and that the transmit gains range goes from 0 to 31.5 dB. Does this mean 20 dBm is the power output when the gain is set to 31.5 dB? Also, the X300 Starting Guide [2] mentions that you shouldn't apply more than -15 dBm to any RF input. If I use 30 dB of attenuation in a loopback configuration (actually, TX/RX from one X310 to RX2 of another), and considering the answer to my last question is positive, would ~25 dB of TX gain be the overall maximum value you can use? Thanks in advance! Leo [1] https://kb.ettus.com/SBX [2] https://kb.ettus.com/X300/X310_Getting_Started_Guides ___ 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 ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Overrun on USB vs Ethernet
Hello Remco: If benchmark_rate runs fine at the target rx rate, the processing speed of the CPU is probably the main bottleneck. If you want to test it further, you can check the "maximum throughput" of your software (maximum rx rate that your software can keep up). If your program is in GNU Radio, one thing that you can do is replacing the "USRP Source" to a file source with pre-recorded data (or maybe a random source, if the performance of your flow graph is not affected by the incoming data), and attaching a "Probe Rate" and a"Message Debug" right after that. If the processing rate, printed to stdout, is slower than the target sampling rate, then your your CPU is not keeping up. If it is keeping up, the problem could be caused by some other issues, including but not limited to two-clock issues, USB controller issues, and USB connection issues (faulty USB 3.0 connection; it does happen!). You should be able to do something similar even if your program is not in GNU Radio (I don't have directions for that, though). In my experience, Ethernet-based USRPs (like N200s and X300s) are indeed a bit better at this. However, if the bottleneck is caused by the software, then replacing the SDR board won't fix the problem. Regards, Kyeong Su Shin 보낸 사람: Remco Vink via USRP-users 대신 USRP-users 보낸 날짜: 2019년 8월 28일 수요일 오후 4:00 받는 사람: usrp-users@lists.ettus.com 제목: [USRP-users] Overrun on USB vs Ethernet All, I am experiencing some issues with overruns stopping the streamer of our USB B200 devices. Currently the computers in use are not the fastest in their kind, but I am wondering where the limitation is coming from. I haven't found a way to measure the throughput of the USB, so it might either be the USB controller or processor which is not fast enough to handle all the data. The benchmark_rate seems to run fine at the rx_rate the program is running on. If for instance I would to switch to a network based device and have the connection over ethernet, would this possibly fix the issue or would the processor or some other bottleneck still arise. Would like to hear your thoughts on this overrun and most likely bottleneck problem. ___ USRP-users mailing list USRP-users@lists.ettus.com http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
Re: [USRP-users] Overrun on USB vs Ethernet
Hello Remco: There's probably a better way to do the job, but here's something that I can suggest: What you need to do to find out the maximum sustainable rate of your program is feeding in dummy data to it. I don't know how do this without replacing the USRP input stream to a stream of samples read from a pre-recorded complex data (preferably stored in a tmpfs as a data file). Then you can add some kind of a counter to count number of samples that your program processes per a second to see the processing speed of your program. With that information, you can try optimising your software or upgrading your hardware to match the required processing rate. If that is a bit troublesome and if you are unsure whether your processing speed or the USB interface between the device and the PC is the main bottleneck, then you can perhaps try running benchmark_rate at a bit higher rate or a bit longer duration and see if any samples are dropped. If it does not drop any samples, then the processing speed (or the processing power) is probably the culprit. Regards, Kyeong Su Shin 보낸 사람: Remco Vink via USRP-users 대신 USRP-users 보낸 날짜: 2019년 8월 30일 금요일 오전 12:17 받는 사람: usrp-users@lists.ettus.com 제목: Re: [USRP-users] Overrun on USB vs Ethernet Thank you Kyeong for the input. I was able to find the "probe rate" in Gnuradio, but unfortunately my program is indeed not build in Gnuradio. Does anyone know of a way to achieve this by the use of C++ and the UHD Driver? Op wo 28 aug. 2019 om 18:00 schreef mailto:usrp-users-requ...@lists.ettus.com>>: Send USRP-users mailing list submissions to usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com> To subscribe or unsubscribe via the World Wide Web, visit http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com or, via email, send a message with subject or body 'help' to usrp-users-requ...@lists.ettus.com<mailto:usrp-users-requ...@lists.ettus.com> You can reach the person managing the list at usrp-users-ow...@lists.ettus.com<mailto:usrp-users-ow...@lists.ettus.com> When replying, please edit your Subject line so it is more specific than "Re: Contents of USRP-users digest..." Today's Topics: 1. Re: RFNoc Testbench / EOB (Timothy Kurp) 2. e320 GPIO pinout (Aaron Holtzman) 3. Re: e320 GPIO pinout (Robin Coxe) 4. Overrun on USB vs Ethernet (Remco Vink) 5. Re: Overrun on USB vs Ethernet (Kyeong Su Shin) 6. Re: RFNoc Testbench / EOB (Jonathon Pendlum) 7. Re: RFNoc Testbench / EOB (Timothy Kurp) -- Message: 1 Date: Tue, 27 Aug 2019 12:06:54 -0400 From: Timothy Kurp mailto:timothy.k...@gmail.com>> To: Jonathon Pendlum mailto:jonathon.pend...@ettus.com>> Cc: usrp-users mailto:usrp-users@lists.ettus.com>> Subject: Re: [USRP-users] RFNoc Testbench / EOB Message-ID: mailto:b8cz9yy...@mail.gmail.com>> Content-Type: text/plain; charset="utf-8" Hi Jon, This doesn't answer my question, perhaps I didn't convey the problem clearly. I am trying to test the case where TLAST occurs on an odd sample, at the same time as EOB. Push word provides access to tlast, but not EOB. To throw eob I need to use send() which takes in pkt.payload and pkt.header. I can manipulate eob in the metadata there. pkt.payload is of type cvita_payload_t, which is 64 bits wide. Send() will throw tlast at the end of the packet, which will always contain a multiple of 2 complex samples since the payload is defined at 64 bits. That is my problem. There is no way to throw eob and tlast on a packet that contains an odd number of i/q samples. Tim On Tue, Aug 27, 2019 at 12:21 AM Timothy Kurp mailto:timothy.k...@gmail.com>> wrote: > Thanks! I will look at that example. > > Tim > > On Tue, Aug 27, 2019 at 12:15 AM Jonathon Pendlum < > jonathon.pend...@ettus.com<mailto:jonathon.pend...@ettus.com>> wrote: > >> Hi Tim, >> >> Look at noc_block_fft_tb.v for an example on how to operate on a 32-bit >> sample by sample basis. Unfortunately, if you want to do sizes smaller than >> 32-bit, you'll need to write your own version of send()/recv() or >> push_word()/pull_word() from sim_rfnoc_lib.svh. >> >> Jonathon >> >> On Tue, Aug 27, 2019 at 1:05 PM Timothy Kurp via USRP-users < >> usrp-users@lists.ettus.com<mailto:usrp-users@lists.ettus.com>> wrote: >> >>> Hey Users! >>> >>> I think this may be a possible deficiency in the test bench >>> architecture, or perhaps I just don't know how to instrument it properly. I >>> have a custom block that performs a 2:1 rate change roughly, performing >>> compression of the 16 bit I/Q from t
