Re: [USRP-users] TXRX_loopback_to_file problem with USRP N210 and MIMO

[Marcus Müller via USRP-users]

Dear Sarah,


with 50 dB attenuation in place, you'll definitely want some gain!

Best regards,

Marcus


On 09/18/2017 02:36 PM, Sarah Tran via USRP-users wrote:
>
> Hello!
>
>  
>
> I am trying to use 2 N210's connected by a MIMO cable to execute the
> uhd example program txrx_loopback_to_file. I have one host machine and
> would like one SDR to transmit the signal and the other SDR to receive
> it to a file. I would like to eventually modify the code so that I can
> make a bit error rate tester between the two N210's, but I was trying
> to get the threading to work first.
>
>  
>
> I have the args: --tx-args="addr=192.168.10.2"
> --rx-args="addr=192.168.10.3" --type="float" --nsamps=1e6
> --tx-rate=5e6 --rx-rate=5e6 --tx-freq=900e6 --rx-freq=900e6
> --tx-ant="TX/RX" --rx-ant="TX/RX" --ref="mimo" --wave-type="SINE"
> --wave-freq="2000"
>
>  
>
> I am using matlab to convert the binary file "usrp_samples.dat" into a
> complex array and I plot the results. I have attached the plot.
>
>  
>
> The results I get from the receive function do not resemble a sine
> wave; it looks more like noise. I have 50 db (50 ohm) attenuation
> inline with the cable that is connecting the two usrps (I am not
> actually transmitting over the air). However when I run the code, I
> see that LED’s indicating that they are transmitting and receiving as
> they should, but the results are not what is expected.
>
>  
>
> I am fairly new to usrp and C++, so any help or direction as to what
> could be the problem would be greatly appreciated. Thank you for your
> time!
>
>  
>
> -Sarah Leony
>
> Electrical Engineer
>
>
>
> ___
> 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 X310/UBX Tx/Rx antenna for single channel pulsed radar

[Marcus Müller via USRP-users]

Hey Rob,

so, it's probably the good ol' radar bandwidth conundrum: For good range
resolution, you'd typically want high TX and RX bandwidth, but at least
on TX, it feels kinda bad to stream a full 200MS/s to the USRP, just to
be able to turn a sine wave on and off again within a few nanoseconds.
And to confirm your suspicion: Yes, if you use a lower rate than that,
the X310 will interpolate to the 200MS/s MCR, and that happens with a
low-pass filter (to get rid of spectral aliasing in the general use
case), and that "washes out" your pulses. So, meh.

As long as you're not sending constantly, but more in terms of single
pulses or short pulse packets, sending the signal at a full 200 MS/s
might be the right thing to do – the USRP would buffer the sample
packets until the TX timestamp "happens", and there's no unnecessarily
high CPU load.

You could also replace the DUC with a simple "repeat" NoC block. Or with
an upsampler without an anti-imaging filter (ie. a zero-padder), for
that manner. Or, upsample, but use the desired pulse shape as filter.

1) well, close reflections are usually very strong with radar. If you're
using an external amplifier, that might be a problem.
2) There's a the auto-TX/RX switching functionality that you can use to
switch when you start/stop streamers. Also, yes, antenna switches are
just "normal" GPIO, so you can basically look into the daughterboard
driver to see which GPIO gets toggled when you change the antenna, and
do the same in your application.

Hope that helps,

best regards,

Marcus


On 09/18/2017 01:55 PM, Rob Kossler via USRP-users wrote:
> Hi, 
> I am interested in implementing a pulsed CW radar using a single
> channel (X310/UBX) via the TX/RX antenna port.  
>
> My initial implementation works, but not that well.  In this
> implementation, I continuously stream the receiver with antenna set to
> TX/RX and I simultaneously send timed transmit bursts for each pulse. 
> The USRP automatically switches the T/R switch to transmit during the
> transmit bursts and then back to receive when the transmit burst
> completes.  The switch time seems good enough for my application. 
> However, the transmit pulse doesn't look as expected at the beginning
> - likely due to start up filtering in the DUC.
>
> I am considering a different implementation such that transmit and
> receive both run continuously and I just manually "hot-switch" the T/R
> switch between transmit and receive using timed commands.  I have 2
> questions:
> 1) is there a problem with this approach (e.g., possibility of
> damaging the device)?
> 2) how do I manually control the T/R switch?  (I am expecting I need
> to use the GPIO registers, but I can't find the relevant info in the
> manual).
>
> Rob
>
>
> ___
> 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] TXRX_loopback_to_file problem with USRP N210 and MIMO

[Sarah Tran via USRP-users]

Hello!



I am trying to use 2 N210's connected by a MIMO cable to execute the uhd 
example program txrx_loopback_to_file. I have one host machine and would like 
one SDR to transmit the signal and the other SDR to receive it to a file. I 
would like to eventually modify the code so that I can make a bit error rate 
tester between the two N210's, but I was trying to get the threading to work 
first.



I have the args: --tx-args="addr=192.168.10.2" --rx-args="addr=192.168.10.3" 
--type="float" --nsamps=1e6 --tx-rate=5e6 --rx-rate=5e6 --tx-freq=900e6 
--rx-freq=900e6 --tx-ant="TX/RX" --rx-ant="TX/RX" --ref="mimo" 
--wave-type="SINE" --wave-freq="2000"



I am using matlab to convert the binary file "usrp_samples.dat" into a complex 
array and I plot the results. I have attached the plot.



The results I get from the receive function do not resemble a sine wave; it 
looks more like noise. I have 50 db (50 ohm) attenuation inline with the cable 
that is connecting the two usrps (I am not actually transmitting over the air). 
However when I run the code, I see that LED's indicating that they are 
transmitting and receiving as they should, but the results are not what is 
expected.



I am fairly new to usrp and C++, so any help or direction as to what could be 
the problem would be greatly appreciated. Thank you for your time!



-Sarah Leony

Electrical Engineer
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Using X310/UBX Tx/Rx antenna for single channel pulsed radar

[Rob Kossler via USRP-users]

Hi,
I am interested in implementing a pulsed CW radar using a single channel
(X310/UBX) via the TX/RX antenna port.

My initial implementation works, but not that well.  In this
implementation, I continuously stream the receiver with antenna set to
TX/RX and I simultaneously send timed transmit bursts for each pulse.  The
USRP automatically switches the T/R switch to transmit during the transmit
bursts and then back to receive when the transmit burst completes.  The
switch time seems good enough for my application.  However, the transmit
pulse doesn't look as expected at the beginning - likely due to start up
filtering in the DUC.

I am considering a different implementation such that transmit and receive
both run continuously and I just manually "hot-switch" the T/R switch
between transmit and receive using timed commands.  I have 2 questions:
1) is there a problem with this approach (e.g., possibility of damaging the
device)?
2) how do I manually control the T/R switch?  (I am expecting I need to use
the GPIO registers, but I can't find the relevant info in the manual).

Rob
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] rfnoc developemnt

[Marcus Müller via USRP-users]

phase shift == multiply with unit-circle complex number. I think you can
work up from that realization!

Best regards,

Marcus


On 09/18/2017 04:08 PM, Snehasish Kar via USRP-users wrote:
>
> Hello
>
>
> I just need to perform a phase shift. Is there any alternate of rotator?
>
>
> BR
>
> Snehasish
>
> 
> *From:* Nicolas Cuervo 
> *Sent:* Monday, September 18, 2017 7:11:08 PM
> *To:* Snehasish Kar
> *Cc:* usrp-users@lists.ettus.com
> *Subject:* Re: [USRP-users] rfnoc developemnt
>  
> Hello Snehasish,
>
> The RFNoC block library is not (yet?) as extensive as the library of
> blocks available in GNURadio. You can see a list of available blocks
> in the Ettus' Knowledge Base [1]. This means that you won't generally
> find an exact implementation of GNURadio blocks in RFNoC as of now,
> although the RFNoC list of blocks is constantly increasing.
>
> Please have a look at the available blocks in RFNoC and check if you
> can implement the flowgraph with the blocks provided by Ettus.
> Otherwise, you have also the option of implementing a RFNoC block
> yourself [2].
>
> Regards,
> - Nicolas
>
> [1] 
> https://kb.ettus.com/Getting_Started_with_RFNoC_Development#Image_building_using_the_command_line
> [2] https://kb.ettus.com/Getting_Started_with_RFNoC_Development
>
> On Mon, Sep 18, 2017 at 2:35 PM, Snehasish Kar via USRP-users
> > wrote:
>
> Hello
>
>
> I wanted to perform the attached flowgraph in rfnoc. But I am not
> able to find the corresponding blocks of the same. Please help me
> with it.
>
>
> BR
>
> Snehasish
>
>
>
> ___
> 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] Audio Control loop testing

[Marcus Müller via USRP-users]

Hi Ben,


that's the old multi-clock problem we've been talking about multiple
times – it's hard to even define what the "correct" clock is, so you
usually just settle on recovering the transmitter clock and, if you were
doing this in hardware, would derive the audio DAC's clock from that.

In a software receiver, you need to estimate the offset of the audio DAC
clock from the sender's audio clock. That's hard to do properly, because
these clock offsets might be to fine to do it with general purpose PC
CPU software. But we've talked about all that before on the
Discuss-gnuradio list!


As a way around that, you might use the same clock to derive the RF
receiver's sampling clock and the audio DAC's sampling clock. You then
get a direct relation between RF sampling and audio playback, for
example "every 1 million RF samples, I need to produce one audio
sample". Fons and I really tried to explain that in about 20 emails on
discuss-gnuradio. So, I think we've covered the stage of "any
suggestions on this would be helpful" pretty well. It is a hard problem,
and there's a solid chance you can't solve it for all use cases in
software. There's also a solid chance you might be able to solve it for
a specific use case, but that would require you to become an expert on
multi-rate processing and clock matching, and frankly, you're not
showing much progress at that over last 10 months.


Best regards,

Marcus



On 09/16/2017 05:38 AM, Benny Alexandar via USRP-users wrote:
> Hi,
>
> I want to create an artificial audio drift in transmitter side and
> test it using my audio control loop in receiver. This is what I'm
> planning.
>
> Take an audio wav file which is sampled at 12 kHz. Re sample it such
> that the sample rate is now having a drift of 100 ppm, ie with sample
> frequencies with an error up to 12000*100e-6 is 1.2Hz in case of 12kHz
> sample frequency. Now transmit this audio file  using Gnu radio and USRP.
> Receiver does the channel decoding and audio decoding.
> So in this most extreme case the receiver drifts with more than one
> sample per second, so after an hour it is drifted by 1.2*3600 = 4320
> samples
>
> If the receiver doesn't have an audio control loop then it will go
> into under run.  By enabling the audio control loop i can check the
> drift compensation.
>
> Any suggestions on this method of testing.
>
> -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

Re: [USRP-users] Testing with single B200

[Kevin McQuiggin via USRP-users]

Hi Renaissance:

Your B200 isn't being found by your computer.  Try the usrp_probe utility, I 
forget the exact name but it is in the same directory/folder as uhd_fft.  

The USB cable can sometimes be problematic as it has to be high quality, some 
cheap cables don't work as they are noisy or have poor connections.

What type of computer and OS are you using?  On Windows there are sometimes 
problems with the USB drivers.

Don't worry about the eeprom at all, get the base unit working first.

Let us know how you make out with the probe.

Kevin
Sent from my iPhone

> On Sep 18, 2017, at 03:54, Rensi Mathew  wrote:
> 
> Hi Kevin
> 
> when I try to run uhd_fft, I get the error
> 
> RuntimeError: LookupError: KeyError: No devices found for ->
> Empty Device Address
> 
> How can I assign a device address?
> 
> I tried  ./usrp_burn_mb_eeprom --args=addr --values="192.168.10.2" but it is 
> not working.
> 
> Pl do help.
> Thanking you
> 
> Rensi
> 
> 
> On Friday, September 15, 2017 9:12 PM, Kevin McQuiggin  
> wrote:
> 
> 
> Hi Rensi:
> 
> I’d suggest using the UHD utility programs that come with the B200.  There is 
> a spectrum analyzer application, called uhd_fft, and a simple radio receiver 
> that can, for example, be used to test your unit with local broadcast 
> stations in the FM band.  You’ll need a small antenna for one of the SMA 
> connectors.  If you don’t have a proper antenna or connector, you could 
> simply stick a short piece of wire into the SMA connector for testing.
> 
> For transmitting, an antenna is more critical as you shouldn’t really 
> transmit into an unconnected or mismatched antenna.  I’d suggest looking 
> again at the utilities provided with either the B200 or gnuradio.  You can 
> build a simple transmitter and use an “FM band” broadcast radio to receive 
> the transmissions from your USRP.
> 
> I would also suggest going to the gnuradio.org web site and working through 
> the tutorial series.  This will help you get started!
> 
> Kevin
> 
> 
>> On Sep 15, 2017, at 3:27 AM, Rensi Mathew via USRP-users 
>>  wrote:
>> 
>> Hi all
>> 
>> I have a single B200 with me and I want to test whether it is 
>> receiving/transmitting the signal properly.
>> How can i test this?
>> 
>> I am new to B200/SDRs and to programming too?
>> 
>> Thanking you
>> Rensi
>> ___
>> 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] rfnoc developemnt

[Snehasish Kar via USRP-users]

Hello


I just need to perform a phase shift. Is there any alternate of rotator?


BR

Snehasish


From: Nicolas Cuervo 
Sent: Monday, September 18, 2017 7:11:08 PM
To: Snehasish Kar
Cc: usrp-users@lists.ettus.com
Subject: Re: [USRP-users] rfnoc developemnt

Hello Snehasish,

The RFNoC block library is not (yet?) as extensive as the library of blocks 
available in GNURadio. You can see a list of available blocks in the Ettus' 
Knowledge Base [1]. This means that you won't generally find an exact 
implementation of GNURadio blocks in RFNoC as of now, although the RFNoC list 
of blocks is constantly increasing.

Please have a look at the available blocks in RFNoC and check if you can 
implement the flowgraph with the blocks provided by Ettus. Otherwise, you have 
also the option of implementing a RFNoC block yourself [2].

Regards,
- Nicolas

[1] 
https://kb.ettus.com/Getting_Started_with_RFNoC_Development#Image_building_using_the_command_line
[2] https://kb.ettus.com/Getting_Started_with_RFNoC_Development

On Mon, Sep 18, 2017 at 2:35 PM, Snehasish Kar via USRP-users 
> wrote:

Hello


I wanted to perform the attached flowgraph in rfnoc. But I am not able to find 
the corresponding blocks of the same. Please help me with it.


BR

Snehasish


___
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