Re: [USRP-users] USRP2 FPGA firmware version in uhd-images vs. github repository

2018-02-26 Thread Michał Wróbel via USRP-users 
Hey,

I scanned through all uhd-images packages on files.ettus.com and noticed
that usrp2_fpga.bin hasn't changed since uhd-images_003.006.000
(2013-11-19), so it is impossible for it to contain these changes:

   - 2015-04-09: Increase N2x0 command FIFO depth to 64.
   

   - 2015-12-18: usrp3, usrp2: Fixed inequal path delay in TX & RX I/Q
   balance compensation
   

   - 2015-12-21: Fix digital DC truncation bias in DDC chain.
   

(the
   fix for the problem I have)

It looks like the image files for USRP2 are just copied from the old
uhd-images_003.006.000 to the new release tarballs, instead of being
rebuilt. Is this a deliberate action or an oversight? Any chance for fixing
it?

Thanks,
Michał

2017-11-14 22:42 GMT+01:00 Michał Wróbel :

> Hi,
>
> It seems that my USRP2 with uhd-images_003.010.002.000 firmware has the
> same incorrect behavior (spikes on the frequency spectrum) as described in
> the pull request:
>
> https://github.com/EttusResearch/fpga/pull/4
>
> Do the uhd-images_003.010.002.000 package contain the firmware compiled
> with this patch applied?
>
> Thanks,
> Michał
>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Time resolution GPS module

2018-02-26 Thread Marcus D. Leech via USRP-users 

On 02/26/2018 03:57 PM, André Gomes via USRP-users wrote:
I have some USRPs B200 with GPS modules installed 
(https://www.ettus.com/product/details/GPSDO-TCXO-MODULE). I plan to 
use the GPS for timing alignment purposes of my application. The piece 
of code I have been using is shown below. It displays the time in 
seconds since 01/01/1970. I would like a better resolution than 
seconds. Is it possible?


const uhd::device_addr_t dev_addr;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(dev_addr);
uhd::sensor_value_t gps_time = usrp->get_mboard_sensor("gps_time");
std::cout << gps_time.to_pp_string() << std::endl << std::flush;

Regards,

*André Gomes*
Email: andre.go...@dcc.ufmg.br 
Homepage: http://homepages.dcc.ufmg.br/~andre.gomes/ 


Mobile: +55 31 994859285 

The gps_time sensor is derived from an NMEA sentence that is issued at 
precise 1second intervals, so the fractional part is, by definition, all 
zeros.


If you want the *USRP DEVICE TIME*, then, once you've synchronized time 
with the GPSDO, use use get_time_now(), which returns a time_spec_t:


https://files.ettus.com/manual/classuhd_1_1usrp_1_1multi__usrp.html#afb4bffe3f969c11ee7c0a2cba5178780

The time_spec_t  type contains fractional seconds.




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

[USRP-users] Time resolution GPS module

2018-02-26 Thread André Gomes via USRP-users 
I have some USRPs B200 with GPS modules installed (
https://www.ettus.com/product/details/GPSDO-TCXO-MODULE). I plan to use the
GPS for timing alignment purposes of my application. The piece of code I
have been using is shown below. It displays the time in seconds since
01/01/1970. I would like a better resolution than seconds. Is it possible?

const uhd::device_addr_t dev_addr;
uhd::usrp::multi_usrp::sptr usrp = uhd::usrp::multi_usrp::make(dev_addr);
uhd::sensor_value_t gps_time = usrp->get_mboard_sensor("gps_time");
std::cout << gps_time.to_pp_string() << std::endl << std::flush;

Regards,

*André Gomes*
Email: andre.go...@dcc.ufmg.br
Homepage: http://homepages.dcc.ufmg.br/~andre.gomes/
Mobile: +55 31 994859285 <+55%2031%2099485-9285>
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] RFNoC FPGA OOT Xilinx IP Addition

2018-02-26 Thread Brian Padalino via USRP-users 
Hi,

I'm trying to add a piece of Xilinx IP using an .xci file, similar to how
the normal flow for the FPGA build goes, but I want to keep it associated
with my OOT source, and not change the main FPGA repository.

I haven't found any instructions on how to do this, so I figure I'd ask
here.

Is it as simple as adding a .xci file to the list of sources and having it
build?  The normal FPGA build seems to go through a lot more steps to
generate all the IP and list their simulation and synthesis sources.

Guidance is appreciated on how to do this "correctly" with an OOT module.

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

Re: [USRP-users] Is it possible to time synchronize multiple USRPs B210?

2018-02-26 Thread Piotr Krysik via USRP-users 
W dniu 26.02.2018 o 19:44, Marcus D. Leech via USRP-users pisze:
> On 02/26/2018 01:36 PM, Piotr Krysik via USRP-users wrote:
>>
>> It's hard for me to understand why only one of the devices changes the
>> master clock rate at that moment. This seems a bit arbitrary. It would
>> be best that after creation of usrp_source the master clock rate
>> wouldn't be changed (unless user requests it).
> It's NOT arbitrary on the B2xx series--the sample-rate interface in
> UHD tries to provide maximum flexibility by changing the
>   master clock rate to achieve the desired sample-rate, UNLESS the
> user has specified an explicit master-clock rate.
>
> Since sample-rate can be changed after a USRP block is instantiated, I
> don't see any way to achieve both goal simultaneously. 
What I call arbitrary is that:
1. in this situation it happens for one USRP only,
2. no amount of waiting before calling time synchronization function can
change that.

Why one USRP might be waiting for a moment after calling
set_time_next_pps(...) to change the value of master clock rate is
mystery for me. Why not to do that earlier during call to
set_samp_rate(...) function.

Great that user can avoid that issue by calling set_clock_rate(..)
explicitly :).

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

[USRP-users] twinrx_freq_hopping example

2018-02-26 Thread Андрей 1 via USRP-users 

Will there be a compiled example for windows?
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] 2 B210 synchronous problem

2018-02-26 Thread Piotr Krysik via USRP-users 
Hi Hideyuki,

For the solution look at the end of "Is it possible to time synchronize
multiple USRPs B210?" thread.
I attached there a working example for two USRPs B210.

--
Best Regards,
Piotr Krysik

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

Re: [USRP-users] Is it possible to time synchronize multiple USRPs B210?

2018-02-26 Thread Marcus D. Leech via USRP-users 

On 02/26/2018 01:36 PM, Piotr Krysik via USRP-users wrote:


It's hard for me to understand why only one of the devices changes the
master clock rate at that moment. This seems a bit arbitrary. It would
be best that after creation of usrp_source the master clock rate
wouldn't be changed (unless user requests it).
It's NOT arbitrary on the B2xx series--the sample-rate interface in UHD 
tries to provide maximum flexibility by changing the
  master clock rate to achieve the desired sample-rate, UNLESS the user 
has specified an explicit master-clock rate.


Since sample-rate can be changed after a USRP block is instantiated, I 
don't see any way to achieve both goal simultaneously.




Anyway I should have expected something like this. Some time back I had
similar issue when doing GPS synchronization.

I attach version of 'recorder.py' that has some unnecessary sleeps removed.




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

Re: [USRP-users] Is it possible to time synchronize multiple USRPs B210?

2018-02-26 Thread Piotr Krysik via USRP-users 
W dniu 26.02.2018 o 17:22, Marcus D. Leech via USRP-users pisze:
> On 02/26/2018 09:16 AM, Piotr Krysik via USRP-users wrote:
>> W dniu 26.02.2018 o 12:43, Piotr Krysik via USRP-users pisze:
>>> W dniu 26.02.2018 o 11:29, Piotr Krysik via USRP-users pisze:
 W dniu 25.02.2018 o 20:08, Marcus D. Leech via USRP-users pisze:
> OK, so (and apologies if this was in your previous data)  what is the
> average magnitude of the time discrepancy?
 Usually it was about few hundreds us (random). I will try to perform
 more measurements.

>>> I measured some values of the delay - they are in the attachment.
>>> Usually the offset is larger than what I said. It's about ~10ms.
>>>
>>> What is interesting is that the values I got in these measurements were
>>> always positive.
>> Hi Marcus,
>>
>> I've finally found out what the reason for the large offset is !!
>> One of USRPs B210 changes master clock rate AFTER setting the internal
>> time counter.
>> I've found it out when I printed USRPs time at the end of time setting
>> function and seen this:
>>
>> ...
>> -- Asking for clock rate 32.00 MHz...
>> -- Actually got clock rate 32.00 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> set_min_output_buffer on block 2 to 1000
>> USRP1 time:  1.003918125
>> USRP2 time:  1.004056625
>> -- Asking for clock rate 16.00 MHz... Asking for clock rate
>> 16.00 MHz...
>> -- Actually got clock rate 16.00 MHz.
>> -- Performing timer loopback test...
>> -- Actually got clock rate 16.00 MHz.
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- Performing timer loopback test... pass
>> -- pass
>> ...
>>
>> Whole part below "USRP2 time:  1.004056625" shouldn't be there. The
>> device at that moment is changing its master clock rate from 32MHz to
>> 16MHz. So what I did was setting master clock rate explicitly to 16MHz.
>> *This solved the issue*.
>>
>> Many thanks for your advices that stimulated me to think about solution
>> the problem.
>>
>> I'm attaching the recorder to the post, so others will be able to start
>> synchronizing their B210s from something that works.
>>
>> Best Regards,
>> Piotr Krysik
>>
> Hmmm, but if you're using the same sample rate on both devices (you
> are, as I recall), things should still "work out", I think?
>
> The advice on B2xx has always been to do the clock-sync "dance"
> *after* sample-rates have been set, or to force a specific master-clock
>   rate early on, since, indeed, the sample-rate logic can change the
> master-clock rate after start-up
It's hard for me to understand why only one of the devices changes the
master clock rate at that moment. This seems a bit arbitrary. It would
be best that after creation of usrp_source the master clock rate
wouldn't be changed (unless user requests it).

Anyway I should have expected something like this. Some time back I had
similar issue when doing GPS synchronization.

I attach version of 'recorder.py' that has some unnecessary sleeps removed.


#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from recorder_grc import *
import time

class recorder(recorder_grc):
def __init__(self, fc=1000e6, gain1=30, gain2=30, samp_rate=1e6, start_time="", rec_len=1, gain3=30, gain4=30, serial1="", serial2=""):
super(recorder, self).__init__(fc=fc, gain1=gain1, gain2=gain2, samp_rate=samp_rate,  rec_len=rec_len, gain3=gain3, serial1=serial1, serial2=serial2)
self.set_time_unknown_pps_costam(uhd.time_spec(0.0)) 
self.uhd_usrp_source_0.set_start_time(uhd.time_spec(3.0))
self.uhd_usrp_source_0_0.set_start_time(uhd.time_spec(3.0))

def set_time_unknown_pps_costam(self, time_spec):
time_last_pps = self.uhd_usrp_source_0.get_time_last_pps()
while(self.uhd_usrp_source_0.get_time_last_pps() == time_last_pps):
time.sleep(0.01)

self.uhd_usrp_source_0.set_time_next_pps(time_spec)
self.uhd_usrp_source_0_0.set_time_next_pps(time_spec)

time.sleep(1.0)


if __name__ == '__main__':
main(top_block_cls=recorder)
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] USRP-users help needed

2018-02-26 Thread Derek Kozel via USRP-users 
Hello Joe,

The source code for both the driver and FPGA HDL are hosted on GitHub. Here
are links to them:
https://github.com/EttusResearch/uhd
https://github.com/EttusResearch/fpga

The manual has a short section about sample rate options:
http://files.ettus.com/manual/page_general.html#general_sampleratenotes

The B200mini's decimation is provided by its DDC. The host controls are in
this file:
https://github.com/EttusResearch/uhd/blob/7ac01c7f979aab8fac5e62f596ff0af52cedec40/host/lib/usrp/cores/rx_dsp_core_3000.cpp

You are probably most interested in this function:
https://github.com/EttusResearch/uhd/blob/7ac01c7f979aab8fac5e62f596ff0af52cedec40/host/lib/usrp/cores/rx_dsp_core_3000.cpp#L148

On the FPGA side
https://github.com/EttusResearch/fpga/blob/maint/usrp3/lib/dsp/ddc_chain.v

Did you have specific questions?

Regards,
Derek


On Mon, Feb 26, 2018 at 5:07 PM, Stern, Joseph via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear USRP users:
>
>
>
> We have been trying to understand the low-level details of the USRP
> architecture (namely, for the B200mini); there seems very little explicit
> insight provided on the Ettus web site into how decimation is performed in
> the FPGA (and commanded from the driver side).  I also cannot locate the
> open-source and freely available FPGA code.  Could someone assist me in
> gaining this insight?
>
>
>
> Thank you very much!
>
>
>
> Joe Stern
> This message and any enclosures are intended only for the addressee.
> Please
> notify the sender by email if you are not the intended recipient. If you
> are
> not the intended recipient, you may not use, copy, disclose, or distribute
> this
> message or its contents or enclosures to any other person and any such
> actions
> may be unlawful. Ball reserves the right to monitor and review all
> messages
> and enclosures sent to or from this email address.
>
> ___
> 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-users help needed

2018-02-26 Thread Marcus D. Leech via USRP-users 

On 02/26/2018 12:07 PM, Stern, Joseph via USRP-users wrote:


Dear USRP users:

We have been trying to understand the low-level details of the 
USRP architecture (namely, for the B200mini); there seems very little 
explicit insight provided on the Ettus web site into how decimation is 
performed in the FPGA (and commanded from the driver side).  I also 
cannot locate the open-source and freely available FPGA code.  Could 
someone assist me in gaining this insight?


Thank you very much!

Joe Stern

Ettus don't provide detailed design documents, but the source-code, as 
you say, is freely available:


Get the source from here:

https://github.com/EttusResearch/uhd

The do a "git submodule init"

The source bits of source code are somewhat separate, the the FPGA 
source code being a GIT sub-module.


In terms of "how is decimation commanded", that's the host-side driver 
in setting sample rates.  The job is divided between the capabilities of the
  AD9361 chip, and the FPGA.  In many cases, almost the entirety of 
decimation/filtering is done inside the AD9361 chip, since it 
effectively has an internal
  ADC that samples at 750Msps (can't remember the precise number), and 
the sample rate offered on its data interface is relatively to that, so 
in many
  cases, there is NO decimation performed within the FPGA.   This is 
all in the source code a shown above.



This message and any enclosures are intended only for the addressee. 
Please
notify the sender by email if you are not the intended recipient. If 
you are
not the intended recipient, you may not use, copy, disclose, or 
distribute this
message or its contents or enclosures to any other person and any such 
actions
may be unlawful. Ball reserves the right to monitor and review all 
messages

and enclosures sent to or from this email address.


___
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-users help needed

2018-02-26 Thread Leandro Echevarría via USRP-users 
Dear Joe,

All the FPGA Verilog code is available in the Github Repo:
https://github.com/EttusResearch/fpga I believe the B200mini falls within
the USRP3 category.

And about the decimation itself, after a quick search through the repo
folders I found a DSP block that seems to indicate decimation is done using
a CIC filter.

Regards,

Leo

On Mon, Feb 26, 2018 at 2:59 PM Stern, Joseph via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Dear USRP users:
>
>
>
> We have been trying to understand the low-level details of the USRP
> architecture (namely, for the B200mini); there seems very little explicit
> insight provided on the Ettus web site into how decimation is performed in
> the FPGA (and commanded from the driver side).  I also cannot locate the
> open-source and freely available FPGA code.  Could someone assist me in
> gaining this insight?
>
>
>
> Thank you very much!
>
>
>
> Joe Stern
> This message and any enclosures are intended only for the addressee.
> Please
> notify the sender by email if you are not the intended recipient. If you
> are
> not the intended recipient, you may not use, copy, disclose, or distribute
> this
> message or its contents or enclosures to any other person and any such
> actions
> may be unlawful. Ball reserves the right to monitor and review all
> messages
> and enclosures sent to or from this email address.
> ___
> 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] USRP-users help needed

2018-02-26 Thread Stern, Joseph via USRP-users 
Dear USRP users:



We have been trying to understand the low-level details of the USRP 
architecture (namely, for the B200mini); there seems very little explicit 
insight provided on the Ettus web site into how decimation is performed in the 
FPGA (and commanded from the driver side).  I also cannot locate the 
open-source and freely available FPGA code.  Could someone assist me in gaining 
this insight?



Thank you very much!



Joe Stern

This message and any enclosures are intended only for the addressee.  Please 
notify the sender by email if you are not the intended recipient.  If you are 
not the intended recipient, you may not use, copy, disclose, or distribute this 
message or its contents or enclosures to any other person and any such actions 
may be unlawful.  Ball reserves the right to monitor and review all messages 
and enclosures sent to or from this email address.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Is it possible to time synchronize multiple USRPs B210?

2018-02-26 Thread Marcus D. Leech via USRP-users 

On 02/26/2018 09:16 AM, Piotr Krysik via USRP-users wrote:

W dniu 26.02.2018 o 12:43, Piotr Krysik via USRP-users pisze:

W dniu 26.02.2018 o 11:29, Piotr Krysik via USRP-users pisze:

W dniu 25.02.2018 o 20:08, Marcus D. Leech via USRP-users pisze:

OK, so (and apologies if this was in your previous data)  what is the
average magnitude of the time discrepancy?

Usually it was about few hundreds us (random). I will try to perform
more measurements.


I measured some values of the delay - they are in the attachment.
Usually the offset is larger than what I said. It's about ~10ms.

What is interesting is that the values I got in these measurements were
always positive.

Hi Marcus,

I've finally found out what the reason for the large offset is !!
One of USRPs B210 changes master clock rate AFTER setting the internal
time counter.
I've found it out when I printed USRPs time at the end of time setting
function and seen this:

...
-- Asking for clock rate 32.00 MHz...
-- Actually got clock rate 32.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
set_min_output_buffer on block 2 to 1000
USRP1 time:  1.003918125
USRP2 time:  1.004056625
-- Asking for clock rate 16.00 MHz... Asking for clock rate
16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- pass
...

Whole part below "USRP2 time:  1.004056625" shouldn't be there. The
device at that moment is changing its master clock rate from 32MHz to
16MHz. So what I did was setting master clock rate explicitly to 16MHz.
*This solved the issue*.

Many thanks for your advices that stimulated me to think about solution
the problem.

I'm attaching the recorder to the post, so others will be able to start
synchronizing their B210s from something that works.

Best Regards,
Piotr Krysik

Hmmm, but if you're using the same sample rate on both devices (you are, 
as I recall), things should still "work out", I think?


The advice on B2xx has always been to do the clock-sync "dance" *after* 
sample-rates have been set, or to force a specific master-clock
  rate early on, since, indeed, the sample-rate logic can change the 
master-clock rate after start-up.







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

Re: [USRP-users] twinrx_freq_hopping example

2018-02-26 Thread Андрей 1 via USRP-users 

What you mean about timed commands?
Im only translate to C API twinrx_freq_hopping.cpp

Thank you

 26.02.2018, 18:10, Derek Kozel  I'm not sure how you
 are responding, but it is still not threading correctly. Thanks for trying
 though.

 I would not expect the C API to make a performance difference like that since
 it is only a wrapper. Are you still using timed commands? If not then the
 additional overhead of sending commands from the host computer to the USRP
 and back could account for some of the performance difference.

 On Mon, Feb 26, 2018 at 3:53 PM, Андрей 1 via USRP-users 

 wrote:
 Thank you for the clarification about set_rx_lo_freq.
 Can the problem with long setup time arise due to the fact that I use C API?
 Thank you

 On Mon, Feb 26, 2018 at 3:44 PM, Derek Kozel  wrote:

   Hello,

   Please can you keep your emails in a single thread so it is easier to
   read.

   The goal with the frequency hopping example is to instantly jump between
   frequencies. Normally those 3-5 ms of tuning would be dead time, no
   meaningful signal could be received. By using the RF synthesizers of both
   channels and switching the LO source back and forth you are always
   jumping to a frequency after the synthesizers have already tuned and
   settled.

   The text written at the top of the example should be rewritten to be a
   bit clearer. There are other situations, such as using an external LO,
   where the set_rx_lo_freq call is useful. In this example however the
   benefit comes from tuning the unused synthesizers. If all the frequencies
   which you wish to tune to the receiver to are known ahead of time it
   would be possible to have UHD pre-calculate all the LO frequencies, store
   them in your application, and then save a few microseconds by using the
   set_rx_lo_freq function to avoid UHD doing extra work to configure the
   filters on the unused channel. This is almost never useful since there is
   some margin in the 5 ms frequency hopping time. Also often applications
   will actually want to sit on one frequency longer than 5 ms and are only
   using the LO source swapping ability to avoid the dead time of
   synthesizer tuning.

   Regards,
   Derek

   On Mon, Feb 26, 2018 at 3:21 PM, Андрей 1 via USRP-users 

   wrote:
   I have no any error in twinrx_recv.If the tuning frequency is already
   sufficiently small, then why these special calls(set_rx_lo_freq) for
   twinRX?
   Thank you
   ___
   USRP-users mailing list
   USRP-users@lists.ettus.com
   http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

   On Mon, Feb 26, 2018 at 3:08 PM, Андрей 1  wrote:

 Im using UHD 3.10.3 and have no error in twinrx_recv

   26.02.2018, 17:01, Derek Kozel  Hello,

   The tuning time is approximately 5 ms, which is why the example
   uses that number. The example should work the same on either
   Windows or Linux. What version of UHD are you using on Windows
   which does not include it?

   Are you seeing any streaming errors on Windows?

   Regards,
   Derek

   On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users 

   wrote:


 Hello
 Im using X300+TwinRX in Windows.In source UHD 3.10.3 for
 linux I found example twinrx_freq_hopping.How much I
 understand in this example the receiver is tuned with the
 period 5ms.As written in the title of the example, I need to
 use set_rx_lo_freq.But it is not in the source code of the
 example.When I compile and run this example in windows I
 found much more begger times (about 30-40 ms) to receive
 correct spectrum.(If I leave the time as in the example, then
 there are no parts of the spectrum and so the receiver does
 not have time to tune in).
 My questions
 What minimum tuning time for TwinRX+X300?Why is there no such
 example for Windows?Is it necessary to use set_rx_lo_freq to
 reduce setup time?
 Thank you
 .

 ___
 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] twinrx_freq_hopping example

2018-02-26 Thread Derek Kozel via USRP-users 
I'm not sure how you are responding, but it is still not threading
correctly. Thanks for trying though.

I would not expect the C API to make a performance difference like that
since it is only a wrapper. Are you still using timed commands? If not then
the additional overhead of sending commands from the host computer to the
USRP and back could account for some of the performance difference.

On Mon, Feb 26, 2018 at 3:53 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:
Thank you for the clarification about set_rx_lo_freq.

Can the problem with long setup time arise due to the fact that I use C API?

Thank you


On Mon, Feb 26, 2018 at 3:44 PM, Derek Kozel  wrote:

> Hello,
>
> Please can you keep your emails in a single thread so it is easier to read.
>
> The goal with the frequency hopping example is to instantly jump between
> frequencies. Normally those 3-5 ms of tuning would be dead time, no
> meaningful signal could be received. By using the RF synthesizers of both
> channels and switching the LO source back and forth you are always jumping
> to a frequency after the synthesizers have already tuned and settled.
>
> The text written at the top of the example should be rewritten to be a bit
> clearer. There are other situations, such as using an external LO, where
> the set_rx_lo_freq call is useful. In this example however the benefit
> comes from tuning the unused synthesizers. If all the frequencies which you
> wish to tune to the receiver to are known ahead of time it would be
> possible to have UHD pre-calculate all the LO frequencies, store them in
> your application, and then save a few microseconds by using the
> set_rx_lo_freq function to avoid UHD doing extra work to configure the
> filters on the unused channel. This is almost never useful since there is
> some margin in the 5 ms frequency hopping time. Also often applications
> will actually want to sit on one frequency longer than 5 ms and are only
> using the LO source swapping ability to avoid the dead time of synthesizer
> tuning.
>
> Regards,
> Derek
>
> On Mon, Feb 26, 2018 at 3:21 PM, Андрей 1 via USRP-users <
> usrp-users@lists.ettus.com> wrote:
> I have no any error in twinrx_recv.
> If the tuning frequency is already sufficiently small, then why these
> special calls(set_rx_lo_freq) for twinRX?
>
> Thank you
>
> ___
> USRP-users mailing list
> USRP-users@lists.ettus.com
> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>
> On Mon, Feb 26, 2018 at 3:08 PM, Андрей 1  wrote:
>
>> Im using UHD 3.10.3 and have no error in twinrx_recv
>>
>>
>> 26.02.2018, 17:01, Derek Kozel 
>> Hello,
>>
>> The tuning time is approximately 5 ms, which is why the example uses that
>> number. The example should work the same on either Windows or Linux. What
>> version of UHD are you using on Windows which does not include it?
>>
>> Are you seeing any streaming errors on Windows?
>>
>> Regards,
>> Derek
>>
>> On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>
>> Hello
>>
>> Im using X300+TwinRX in Windows.
>> In source UHD 3.10.3 for linux I found example twinrx_freq_hopping.
>> How much I understand in this example the receiver is tuned with the
>> period 5ms.As written in the title of the example, I need to use
>> set_rx_lo_freq.But it is not in the source code of the example.
>> When I compile and run this example in windows I found much more begger
>> times (about 30-40 ms) to receive correct spectrum.(If I leave the time as
>> in the example, then there are no parts of the spectrum and so the receiver
>> does not have time to tune in).
>>
>> My questions
>>
>> What minimum tuning time for TwinRX+X300?
>> Why is there no such example for Windows?
>> Is it necessary to use set_rx_lo_freq to reduce setup time?
>>
>> Thank you
>>
>> .
>>
>>
>> ___
>> 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] twinrx_freq_hopping example

2018-02-26 Thread Андрей 1 via USRP-users 

Thank you for the clarification about set_rx_lo_freq.
Can the problem with long setup time arise due to the fact that I use C API?
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] twinrx_freq_hopping example

2018-02-26 Thread Derek Kozel via USRP-users 
Hello,

Please can you keep your emails in a single thread so it is easier to read.

The goal with the frequency hopping example is to instantly jump between
frequencies. Normally those 3-5 ms of tuning would be dead time, no
meaningful signal could be received. By using the RF synthesizers of both
channels and switching the LO source back and forth you are always jumping
to a frequency after the synthesizers have already tuned and settled.

The text written at the top of the example should be rewritten to be a bit
clearer. There are other situations, such as using an external LO, where
the set_rx_lo_freq call is useful. In this example however the benefit
comes from tuning the unused synthesizers. If all the frequencies which you
wish to tune to the receiver to are known ahead of time it would be
possible to have UHD pre-calculate all the LO frequencies, store them in
your application, and then save a few microseconds by using the
set_rx_lo_freq function to avoid UHD doing extra work to configure the
filters on the unused channel. This is almost never useful since there is
some margin in the 5 ms frequency hopping time. Also often applications
will actually want to sit on one frequency longer than 5 ms and are only
using the LO source swapping ability to avoid the dead time of synthesizer
tuning.

Regards,
Derek

On Mon, Feb 26, 2018 at 3:21 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:
I have no any error in twinrx_recv.
If the tuning frequency is already sufficiently small, then why these
special calls(set_rx_lo_freq) for twinRX?

Thank you

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

On Mon, Feb 26, 2018 at 3:08 PM, Андрей 1  wrote:

> Im using UHD 3.10.3 and have no error in twinrx_recv
>
>
> 26.02.2018, 17:01, Derek Kozel 
> Hello,
>
> The tuning time is approximately 5 ms, which is why the example uses that
> number. The example should work the same on either Windows or Linux. What
> version of UHD are you using on Windows which does not include it?
>
> Are you seeing any streaming errors on Windows?
>
> Regards,
> Derek
>
> On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>
> Hello
>
> Im using X300+TwinRX in Windows.
> In source UHD 3.10.3 for linux I found example twinrx_freq_hopping.
> How much I understand in this example the receiver is tuned with the
> period 5ms.As written in the title of the example, I need to use
> set_rx_lo_freq.But it is not in the source code of the example.
> When I compile and run this example in windows I found much more begger
> times (about 30-40 ms) to receive correct spectrum.(If I leave the time as
> in the example, then there are no parts of the spectrum and so the receiver
> does not have time to tune in).
>
> My questions
>
> What minimum tuning time for TwinRX+X300?
> Why is there no such example for Windows?
> Is it necessary to use set_rx_lo_freq to reduce setup time?
>
> Thank you
>
> .
>
>
> ___
> 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] twinrx_freq_hopping example

2018-02-26 Thread Андрей 1 via USRP-users 

I have no any error in twinrx_recv.If the tuning frequency is already
sufficiently small, then why these special calls(set_rx_lo_freq) for twinRX?
Thank you
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] (no subject)

2018-02-26 Thread Андрей 1 via USRP-users 

Im using UHD 3.10.3 and have no error in twinrx_recv
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] twinrx_freq_hopping example

2018-02-26 Thread Derek Kozel via USRP-users 
Hello,

The tuning time is approximately 5 ms, which is why the example uses that
number. The example should work the same on either Windows or Linux. What
version of UHD are you using on Windows which does not include it?

Are you seeing any streaming errors on Windows?

Regards,
Derek

On Mon, Feb 26, 2018 at 2:53 PM, Андрей 1 via USRP-users <
usrp-users@lists.ettus.com> wrote:

>
> Hello
>
> Im using X300+TwinRX in Windows.
> In source UHD 3.10.3 for linux I found example twinrx_freq_hopping.
> How much I understand in this example the receiver is tuned with the
> period 5ms.As written in the title of the example, I need to use
> set_rx_lo_freq.But it is not in the source code of the example.
> When I compile and run this example in windows I found much more begger
> times (about 30-40 ms) to receive correct spectrum.(If I leave the time as
> in the example, then there are no parts of the spectrum and so the receiver
> does not have time to tune in).
>
> My questions
>
> What minimum tuning time for TwinRX+X300?
> Why is there no such example for Windows?
> Is it necessary to use set_rx_lo_freq to reduce setup time?
>
> Thank you
>
> .
>
>
> ___
> 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] twinrx_freq_hopping example

2018-02-26 Thread Андрей 1 via USRP-users 

Hello
Im using X300+TwinRX in Windows.In source UHD 3.10.3 for linux I found example
twinrx_freq_hopping.How much I understand in this example the receiver is tuned
with the period 5ms.As written in the title of the example, I need to use
set_rx_lo_freq.But it is not in the source code of the example.When I compile 
and
run this example in windows I found much more begger times (about 30-40 ms) to
receive correct spectrum.(If I leave the time as in the example, then there are
no parts of the spectrum and so the receiver does not have time to tune in).
My questions
What minimum tuning time for TwinRX+X300?Why is there no such example for
Windows?Is it necessary to use set_rx_lo_freq to reduce setup time?
Thank you
.
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

Re: [USRP-users] Is it possible to time synchronize multiple USRPs B210?

2018-02-26 Thread Piotr Krysik via USRP-users 
W dniu 26.02.2018 o 12:43, Piotr Krysik via USRP-users pisze:
> W dniu 26.02.2018 o 11:29, Piotr Krysik via USRP-users pisze:
>> W dniu 25.02.2018 o 20:08, Marcus D. Leech via USRP-users pisze:
>>> OK, so (and apologies if this was in your previous data)  what is the
>>> average magnitude of the time discrepancy? 
>> Usually it was about few hundreds us (random). I will try to perform
>> more measurements.
>>
> I measured some values of the delay - they are in the attachment.
> Usually the offset is larger than what I said. It's about ~10ms.
>
> What is interesting is that the values I got in these measurements were
> always positive.
Hi Marcus,

I've finally found out what the reason for the large offset is !!
One of USRPs B210 changes master clock rate AFTER setting the internal
time counter.
I've found it out when I printed USRPs time at the end of time setting
function and seen this:

...
-- Asking for clock rate 32.00 MHz...
-- Actually got clock rate 32.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
set_min_output_buffer on block 2 to 1000
USRP1 time:  1.003918125
USRP2 time:  1.004056625
-- Asking for clock rate 16.00 MHz... Asking for clock rate
16.00 MHz...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test...
-- Actually got clock rate 16.00 MHz.
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- Performing timer loopback test... pass
-- pass
...

Whole part below "USRP2 time:  1.004056625" shouldn't be there. The
device at that moment is changing its master clock rate from 32MHz to
16MHz. So what I did was setting master clock rate explicitly to 16MHz.
*This solved the issue*.

Many thanks for your advices that stimulated me to think about solution
the problem.

I'm attaching the recorder to the post, so others will be able to start
synchronizing their B210s from something that works.

Best Regards,
Piotr Krysik




recorder.grc
Description: application/gnuradio-grc
#!/usr/bin/env python2
# -*- coding: utf-8 -*-

from recorder_grc import *
import time

class recorder(recorder_grc):
def __init__(self, fc=1000e6, gain1=30, gain2=30, samp_rate=1e6, start_time="", rec_len=1, gain3=30, gain4=30, serial1="", serial2=""):
super(recorder, self).__init__(fc=fc, gain1=gain1, gain2=gain2, samp_rate=samp_rate,  rec_len=rec_len, gain3=gain3, serial1=serial1, serial2=serial2)
self.set_time_unknown_pps_costam(uhd.time_spec(0.0)) 
self.uhd_usrp_source_0.set_start_time(uhd.time_spec(3.0))
self.uhd_usrp_source_0_0.set_start_time(uhd.time_spec(3.0))

def set_time_unknown_pps_costam(self, time_spec):
time.sleep(4.0)
time_last_pps = self.uhd_usrp_source_0.get_time_last_pps()
while(self.uhd_usrp_source_0.get_time_last_pps() == time_last_pps):
time.sleep(0.01)

self.uhd_usrp_source_0.set_time_next_pps(time_spec)
self.uhd_usrp_source_0_0.set_time_next_pps(time_spec)

time.sleep(2.0)
print "USRP1 time: ",self.uhd_usrp_source_0.get_time_now().get_real_secs()
print "USRP2 time: ",self.uhd_usrp_source_0_0.get_time_now().get_real_secs()


if __name__ == '__main__':
main(top_block_cls=recorder)
#!/usr/bin/env python2
# -*- coding: utf-8 -*-
##
# GNU Radio Python Flow Graph
# Title: Recorder Grc
# Generated: Mon Feb 26 14:57:51 2018
##

from gnuradio import blocks
from gnuradio import eng_notation
from gnuradio import gr
from gnuradio import uhd
from gnuradio.eng_option import eng_option
from gnuradio.filter import firdes
from optparse import OptionParser
import time


class recorder_grc(gr.top_block):

def __init__(self, fc=1000e6, gain1=20, gain2=20, gain3=20, gain4=20, rec_len=4, samp_rate=1e6, serial1='3094DB1', serial2='30AD35A'):
gr.top_block.__init__(self, "Recorder Grc")

##
# Parameters
##
self.fc = fc
self.gain1 = gain1
self.gain2 = gain2
self.gain3 = gain3
self.gain4 = gain4
self.rec_len = rec_len
self.samp_rate = samp_rate
self.serial1 = serial1
self.serial2 = serial2

##
# Blocks
##
self.uhd_usrp_source_0_0 = uhd.usrp_source(
	",".join(("serial="+serial2, '')),
	uhd.stream_args(
		cpu_format="fc32",
		channels=range(2),
	),
)
self.uhd_usrp_source_0_0.set_clock_rate(16e6, uhd.ALL_MBOARDS)
self.uhd_usrp_source_0_0.set_clock_source('external', 0)
self.uhd_usrp_source_0_0.set_time_source('external', 0)
self.uhd_usrp_source_0_0.set_samp_rate(samp_rate)

Re: [USRP-users] Error in Installing Hardware Driver of B200

2018-02-26 Thread Marcus D. Leech via USRP-users 

On 02/26/2018 02:28 AM, Anuja Kokil via USRP-users wrote:


Hello,

 I have  B200 USRP Board and have one technical query regarding the same.

I am installing UHD Driver on our Ubuntu 16.04 i386 system. But during 
UHD installation we are getting error continuously.


Following is the procedure I do for UHD installation

*sudo apt-get update*


  Installing the dependencies

*sudo apt-get -y install swig g++ automake1.9 libtool python-dev 
libcppunit-dev sdcc libusb-dev libasound2-dev libsdl1.2-dev 
python-wxgtk2.8 subversion guile-1.8-dev libqt4-dev ccache 
python-opengl libgsl0-dev python-cheetah python-lxml libqwt5-qt4-dev 
libqwtplot3d-qt4-dev qt4-dev-tools fftw3-dev doxygen libusb-1.0-0-dev 
python-cheetah doxygen python-docutils *


*www.boost.org *

Download release(Unix:*boost_1_55_0.tar.gz*)

*xxx@ubuntu:~$ **sudo tar –xvf ~/Downloads/boost_1_55_0.tar.gz*

*xxx@ubuntu:~$ **cd boost_1_55_0/*

*xxx@ubuntu/boost_1_55_0/:~$ **./bootstrap.sh*

*xxx@ubuntu/boost_1_55_0/:~$ **sudo ./b2 install --prefix=/usr *


UHD Installation

*sudo apt-get install zeroc-ice libcomedi-dev*


Install Git:

*$ sudo add-apt-repository ppa:git-core/ppa*

*$ sudo apt-get update*

*$ sudo apt-get install git*

Download UHD

*go to http://github.com/EttusResearch/uhd.git go to branch 
and**Download uhd-release_003_010_000_000 zip file and extract it in home*



*Build UHD*

*cd /uhd-release_003_010_000_000/host/ *

*mkdir build *

*cd build *

*cmake ../ *


*After cmake ../*

we are getting error *boost not found*

*Configuring LibUHD support...
-- Dependency Boost_FOUND = 0
-- Dependency HAVE_PYTHON_PLAT_MIN_VERSION = TRUE
-- Dependency HAVE_PYTHON_MODULE_MAKO = TRUE
CMake Error at cmake/Modules/UHDComponent.cmake:51 (MESSAGE):
Dependencies for required component LibUHD not met.
Call Stack (most recent call first):
CMakeLists.txt:368 (LIBUHD_REGISTER_COMPONENT**)*

and then I can not do *make*and further procedure.

My current System is Ubuntu 16.04.1LTS i386.

Kindly Help us regarding this issue.


Thanks and Regards

Anuja


There are a number of paths to getting UHD+Gnu Radio installed. Here is 
the installation documentation for  just UHD:


http://files.ettus.com/manual/page_install.html#install_linux

And building from source:

http://files.ettus.com/manual/page_build_guide.html

I'd recommend going the binary route, since you'll get release-tagged 
"stuff".




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

Re: [USRP-users] uhd rfnoc-devel branch

2018-02-26 Thread Дмитрий Михайличенко via USRP-users 
Thanks Nicolas,

now it is clear.

2018-02-26 12:17 GMT+03:00 Nicolas Cuervo :

> Hi Dmitry,
>
> RFNoC is supported fully only on top of the rfnoc-devel branch, so that is
> the branch you'd want to use for any custom development. We will merge
> fixes from master into rfnoc-devel really soon, but if you are having
> issues that are already solved in maint of master, I believe cherry-picking
> them into rfnoc-devel might be the easiest before the official merge.
>
> Regards,
> - Nicolas
>
> On Mon, Feb 26, 2018 at 10:02 AM, Дмитрий Михайличенко via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> Hi,
>>
>> could anybody advise if rfnoc-devel branch is regularly synchronized to
>> maint branch?
>>
>> In my case I use rfnoc-devel branch because I want to develop custom
>> RFNoC blocks. From the other hand I need fixes for X310 device I use which
>> are published in maint branch. Should I continue to use rfnoc-devel and
>> apply necessary maint fixes by hand or it is better to switch to maint
>> branch and try to move necessary RFNoC blocks to maint? And which version
>> of FPGA sources should I use?
>>
>> thanks,
>> Dmitry
>>
>> ___
>> 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] uhd rfnoc-devel branch

2018-02-26 Thread Nicolas Cuervo via USRP-users 
Hi Dmitry,

RFNoC is supported fully only on top of the rfnoc-devel branch, so that is
the branch you'd want to use for any custom development. We will merge
fixes from master into rfnoc-devel really soon, but if you are having
issues that are already solved in maint of master, I believe cherry-picking
them into rfnoc-devel might be the easiest before the official merge.

Regards,
- Nicolas

On Mon, Feb 26, 2018 at 10:02 AM, Дмитрий Михайличенко via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi,
>
> could anybody advise if rfnoc-devel branch is regularly synchronized to
> maint branch?
>
> In my case I use rfnoc-devel branch because I want to develop custom RFNoC
> blocks. From the other hand I need fixes for X310 device I use which are
> published in maint branch. Should I continue to use rfnoc-devel and apply
> necessary maint fixes by hand or it is better to switch to maint branch and
> try to move necessary RFNoC blocks to maint? And which version of FPGA
> sources should I use?
>
> thanks,
> Dmitry
>
> ___
> 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] uhd rfnoc-devel branch

2018-02-26 Thread Дмитрий Михайличенко via USRP-users 
Hi,

could anybody advise if rfnoc-devel branch is regularly synchronized to
maint branch?

In my case I use rfnoc-devel branch because I want to develop custom RFNoC
blocks. From the other hand I need fixes for X310 device I use which are
published in maint branch. Should I continue to use rfnoc-devel and apply
necessary maint fixes by hand or it is better to switch to maint branch and
try to move necessary RFNoC blocks to maint? And which version of FPGA
sources should I use?

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