from:"Piotr Krysik via USRP\-users"

[USRP-users] Example: sending samples in bursts and controlling GPIO pins

2017-07-13 Thread Piotr Krysik via USRP-users

Hi all,

Yesterday I had a problem with configuring GPIO pins in USRP X310. I
wanted to send signal in bursts to get pulsed transmission and to turn
on GPIO pin when transmitting, but what I did didn't work correctly. I
received very good advices from Nate Temple on IRC together with custom
version of tx_waveform example from UHD. In return I want to contribute
something back, so maybe someone who will have similar problem in the
future won't have to spend too much time on it.

I moved changes made by Nate from tx_waveform to tx_bursts example. With
it it is possible to see how GPIO outputs behave for each burst that is
sent. The resulting code is attached to this message. It is compiled with:

mkdir build
cd build
cmake ..
make

The program can be invoked with following arguments:

./tx_bursts_gpio --freq 12e6 --rate 20e6 --nsamp 2000 --gain 30 --repeat
--rep-delay 0.0002 --dilv

Here is the result seen on an oscilloscope connected to RF-A RF2 and
GPIO pin number 3 (configured to switch to "1" when transmitting) of a
USRP X310: http://imgur.com/a/hHO5I

The yellow line is GPIO pin and the blue line is signal coming out of
the RF port.

Best Regards,
Piotr Krysik



gpio_bursts.tar.gz
Description: application/gzip
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] USRP's B210 sluggish start of transmission

2017-09-23 Thread Piotr Krysik via USRP-users

Hi all,

I'm currently trying to find out how much USRPs B210 are capable of
doing in different tasks.

One of these tasks is transmission of burst with use of UHD's burst api.
To access it I have implemented a GNU Radio app that uses tx_time and
packet_len tags.
Particularly the application was configured to send bursts containing
complex sinusoid (frequency 1kHz) every 2.5ms. Length of the burst is
2ms, so there should be 0.5us of gap between bursts.

The result of recording of this signal is shown on the attached picture
and it is not what is expected: the gap is about 800us and the length of
pulse is about 1.7ms. About 300us of signal is not transmitted at all.

What it means is that it is problematic to send bursts with use of burst
api. I can attach 300us of signal at the beginning of a burst but what
if there are two bursts in a row that are closer than 300us? One of my
aims is to add ability to transmit gsm bursts to gr-gsm. GSM bursts are
spaced by 8.25us of guard periods... Probably I could find some other
workaround with use of hacks that probably will fail in specific
situations and the whole simplicity provided by burst api will go away
anyway. But I would prefer to not do that if it's possible.

I checked on USRP X310 and everything is fine there - it starts to
transmit almost immediately.


Why does it take so long (and loss of 0.3ms of signal at the beginning)
for USRP B210 to start transmit anything?
Do you know how to make it start transmit faster (100x faster definitely
would make burst api in B210 much more usable).

(UHD used for the test was 3.9.2, carrier frequency of the signal was
940MHz)

--
Best Regards,
Piotr Krysik


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

[USRP-users] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Piotr Krysik via USRP-users

Hi all,

I'm trying trying to use multiple USRPs B210 (that have GPSDOs mounted)
for tasks requiring good phase coherence between the devices (i.e.
phased antenna array) and there is some problem. In the recorded signal
I have found abrupt phase jumps that make B210s unusable for performing
phase coherent tasks (and that generally might be a problem).

The devices were synchronized with use of Octoclock-G providing PPS and
10MHz ref signal. To check phase coherence I used a signal generator
(generating sinusoid: -40dBm at 690MHz with USRPs tuned to 690.1MHz with
sample rate 1MHz, PPS and ref signals taken from external ports, version
of UHD 3.9.2). See the attached picture in which I removed expected
phase of the sinusoid (recorded with one of the channels) from the phase
of the recorded signal. In this example phase jumps happen almost
periodically (about every 10 seconds).

Now is the funny part: after taking out GPSDO the problem goes away
(checked with 3 USRPs B210). Hence the very probable theory is that
GPSDO's interference causes the problem.

Have you observed this? And more importantly: do you a have solution?
(Taking GPSDOs out from all our B210s is not one of them as there are
many valid tasks that require both GPSDOs and good quality of signal
signal phase measurement. I still have to check if the same thing
happens without Octoclock-G.)

(in the next episode: slow start of transmission in USRP 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] Phase jumps in USRP B210 with GPSDO

2017-09-22 Thread Piotr Krysik via USRP-users

Hi Sylvain,

W dniu 22.09.2017 o 11:44, Sylvain Munaut pisze:
> Hi Piotr,
>
>
> And do you set both the Clock and Time source to the external ones
> when using it in that configuration ?
I think I have written this at least twice before. I will try again to
describe it again as clear as I can. Recipe to reproduce the problem:
1. take a USRP B210 with GPSDO inside,
2. connect external source (i.e. Octoclock-G) of PPS and 10MHz ref to it,
3. set sources of PPS and 10MHz ref to "external",
4. record sinusoid,
5. look at the sinusoid's phase (one simple solution is to uwrap phase,
fit first order polynomial to it and remove it from the original).

> I just had a look at both the schematic and VHDL and there is actual
> switches ... the GPSDO 10M and PPS should basically be completely
> disconnected when the reference for time and clock is external.
I suppose they are not enough. Anyway problem with combo of USRP B210
equipped with GPSDO and Octoclock-G was confirmed yesterday by mixbit on
usrp-users list (he said they have it in their bug tracker).
> Also, are you using an external power supply ?  Maybe the issue is the
> added load on the supply rails when the GPSDO is plugged in.
>
External supply doesn't help. Only removing GPSDO from USRP B210 helps.
Which is not bad.

p.s. Now we are fighting with frequency offset between two USRPs B210
synchronized with octoclock. It causes phase drift of about 1
degree/second, and changes with time. When I will know more I will
describe it in a new thread on the mailing list.

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] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Piotr Krysik via USRP-users

W dniu 21.09.2017 o 19:16, Piotr Krysik via USRP-users pisze:
> W dniu 21.09.2017 o 17:19, mle...@ripnet.com pisze:
>> You talk about board-mounted GPSDOs in each of your B210s, but then
>> talk about using an Octoclock-G.
>>
>> In the Octoclock-G example, you are explicitly selecting "external"
>> for your refclock and time source?
>>
>> It is fully-expected that no two GPSDOs will precisely agree on
>> frequency and phase, and will have some amount of mutual phase-noise. 
>> Even when fed with the same antenna. 
>>
> I explicitly written that I configured USRPs to take PPS and 10MHz ref
> from external inputs. We just happen to have board mounted GPSDOs in all
> USRPs B210 that we have, but in this example they were not used for
> synchronization.
>
> --
> Piotr Krysik
>
>
Also take into account that I'm not comparing phase signals observed by
two different USRPs. What I have shown is for single channel of one USRP
in which such jumps are observed (I'm comparing phase of digitally
generated sinusoid with phase of recorded one). Same thing, however, can
be observed when recording signal with two USRPS in situation where one
have board mounted GPSDO and another one doesn't (with simple
unwrap(angle(x1.*conj(x2))) where x1 and x2 are signal vectors). Both
USRPs synchronized with use of Octoclock-G.

To make the matter simpler to gasp I will check if the same problem can
be observed on one USRP B210 with board mounted GPSDO - without any
additional hardware.

--
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] Phase jumps in USRP B210 with GPSDO

2017-09-21 Thread Piotr Krysik via USRP-users

W dniu 21.09.2017 o 17:19, mle...@ripnet.com pisze:
>
> You talk about board-mounted GPSDOs in each of your B210s, but then
> talk about using an Octoclock-G.
>
> In the Octoclock-G example, you are explicitly selecting "external"
> for your refclock and time source?
>
> It is fully-expected that no two GPSDOs will precisely agree on
> frequency and phase, and will have some amount of mutual phase-noise. 
> Even when fed with the same antenna. 
>
I explicitly written that I configured USRPs to take PPS and 10MHz ref
from external inputs. We just happen to have board mounted GPSDOs in all
USRPs B210 that we have, but in this example they were not used for
synchronization.

--
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] Fwd: Re: USRP's B210 sluggish start of transmission

2017-10-06 Thread Piotr Krysik via USRP-users

W dniu 06.10.2017 o 17:48, Nick Foster pisze:
> This is especially baffling to me, because I recall that the
> SKY13335-187LF switches used in B210 must be isolated from DC on all
> RF ports. But they are! The only components connected to the SMA
> connectors are a series 470pF capacitor.
>
> Perhaps the problem is exacerbated by poor impedance matching rather
> than by lack of a DC path. If reflected power was causing the problem
> I'd expect lowering the transmit gain to affect your results. Could
> you try that for me?
>
>
Nick,

There is no difference. Even for transmit gain 0 the problem persists.

I have a feeling that the answer to the question might be easier to find
if we know what is state of TX/RX switches before start of burst and
after it.

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] USRP's B210 sluggish start of transmission

2017-09-25 Thread Piotr Krysik via USRP-users

Hi all,

For comparison: screenshot of much more "civilized" behavior of USRP
X310 in the same situation.

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] USRP's B210 sluggish start of transmission

2017-09-24 Thread Piotr Krysik via USRP-users

Hi Dario,

Of course I can try to use software workarounds duplicating
functionality that doesn't work correctly in B210. But let's at least
try to find an answer what might cause the problem. Then maybe let's try
to estimate how hard it would be to make B210 behave better.

I know that B210 is low cost product (in comparison with other USRPs)
and it's also low on a list of priorities in terms of support. But this
settling time whenever there is start of burst or an underflow seems to
be a symptom of a bigger problem. 300us can't be explained by the time
to turn on amplifier. It might mean for example that every time there is
start of transmission ad9361 chip is restarted. If yes it might be worth
to fix this as UHD's burst mode might not be the only victim of this
approach.

Best Regards,
Piotr Krysik

W dniu 24.09.2017 o 05:56, Dario Fertonani pisze:
> Hi Piotr,
>
> Because of the problem you described, and other similar limitations
> for stop-and-go usage of the tx_streamer (I'm referring to the C++ UHD
> API here), I suggest keeping the tx_streamer always on and just
> feeding it with IQ zeros when you don't want to transmit anything.
> This solution is a tradeoff: On the pro side the stop-and-go
> transients will go away, while on the con side you won't get a
> perfectly zero RF output when you feed IQ zeros (e.g., because of
> carrier leakage and other RF effects).
>
> Best,
> Dario 
>
> On Sat, Sep 23, 2017 at 4:27 AM, Piotr Krysik via USRP-users
> <usrp-users@lists.ettus.com <mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi all,
>
> I'm currently trying to find out how much USRPs B210 are capable of
> doing in different tasks.
>
> One of these tasks is transmission of burst with use of UHD's
> burst api.
> To access it I have implemented a GNU Radio app that uses tx_time and
> packet_len tags.
> Particularly the application was configured to send bursts containing
> complex sinusoid (frequency 1kHz) every 2.5ms. Length of the burst is
> 2ms, so there should be 0.5us of gap between bursts.
>
> The result of recording of this signal is shown on the attached
> picture
> and it is not what is expected: the gap is about 800us and the
> length of
> pulse is about 1.7ms. About 300us of signal is not transmitted at all.
>
> What it means is that it is problematic to send bursts with use of
> burst
> api. I can attach 300us of signal at the beginning of a burst but what
> if there are two bursts in a row that are closer than 300us? One of my
> aims is to add ability to transmit gsm bursts to gr-gsm. GSM
> bursts are
> spaced by 8.25us of guard periods... Probably I could find some other
> workaround with use of hacks that probably will fail in specific
> situations and the whole simplicity provided by burst api will go away
> anyway. But I would prefer to not do that if it's possible.
>
> I checked on USRP X310 and everything is fine there - it starts to
> transmit almost immediately.
>
>
> Why does it take so long (and loss of 0.3ms of signal at the
> beginning)
> for USRP B210 to start transmit anything?
> Do you know how to make it start transmit faster (100x faster
> definitely
> would make burst api in B210 much more usable).
>
> (UHD used for the test was 3.9.2, carrier frequency of the signal was
> 940MHz)
>
> --
> 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] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

2017-10-11 Thread Piotr Krysik via USRP-users

Hi all,

After discussion on IRC and few questions (by Brian Padalino and Marcus
D. Leech), that made me not so sure about how I made the measurement, I
found the reason for frequency offset.

It wasn't fault of USRP B210 or broken cable providing 10MHz reference
signal. The issue was a bit more complex:
-two B210s were not time synchronized,
-signal generator wasn't producing ideal sine wave but with slightly
drifting frequency (connecting the generator's Ref input to Octoclock
didn't help in case of that particular generato, which was FLUKE 6061A).

If at two points in time frequency of the generated signal is different,
then by looking at the phase difference between two USRPs, that are time
shifted with respect to each other, the effects of that frequency
difference will be observed.

I made the following experiment to show that it was generator's fault:
-phase difference between inputs of two USRPs was constantly measured,
-first I connected FLUKE 6061A signal generator to USRPs (through splitter),
-then I've disconnected the splitter from that generator and connected
another one(Agilent N5182A),
-both generators' Ref inputs were connected to Octoclock-G.

The effect can be seen on the attached image. For FLUKE 6061A you can
observe frequency offset while for Agilent N5182A in the measured period
no frequency offset effect can be observed.

So the conclusion is to synchronize USRPs B210 in time and to not trust
our FLUKE 6061A signal generator as a laboratory equipment.

Best Regards,
Piotr Krysik
___
USRP-users mailing list
USRP-users@lists.ettus.com
http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com

[USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission

2017-09-26 Thread Piotr Krysik via USRP-users

Hi all,

I narrowed down when the issue occurs.

When using separate sides of B210 for transmitting (i.e. TX/RX port on
RF A side) and receiving (i.e. RX2 port on RF B side) everything is fine and 
B210 starts transmitting like i.e. X310.


The problem appears when transmitting and receiving on the same side of
B210 and it is dependent on what you connect to the TX port. The 300us
transition appears if I don't connect anything and measure the TX-RX
leakage or when VERT900 antenna from Ettus is connected.

I tried also to connect a power splitter to the TX port and an antenna
to one of the splitter's ports - with the same result. But as soon as I
connected the 30dB attenuator to another port of the splitter, the
problem immediately goes away.

> The attenuator also has a path (resistive 50 ohms) to groundan
>antenna with a small pad on it (say 1 db) will probably work fine as well.
> Kent Torell

So you might be right here Kent that it was the path to the ground in the 
attenuator that
changed how the output behaves. It is funny thought that the problem
only appears when RX2 port on the same side of B210 is also used :).

--
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] Frequency offset between two USRPs B210 synchronized with use of Octoclock-G

2017-10-09 Thread Piotr Krysik via USRP-users

W dniu 09.10.2017 o 09:36, Piotr Krysik via USRP-users pisze:
> One thing that helped was replacing one of the USRP B210 in the pair
> with another one.
Hi,

I checked everything again and I found out that after replacing one of
my 10MHz ref SMA cable the phase difference between any devices behaves
much better. It seems that one of the cables was faulty. So... mea culpa
guys (for the first time with B210 ;) ). Many thanks for your time, you
are always very helpful.

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] Underflows with simple rx/tx GNU Radio flowgraph on USRP X310 under RFNOC UHD

2017-10-24 Thread Piotr Krysik via USRP-users

W dniu 22.10.2017 o 12:04, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I'm prepared a basic GNU Radio flow-graph that does simultaneous
> transmission and reception (see the attachment). For USRP X310 and RFNOC
> UHD (version above 3.10.x) soon after starting the flow-graph there is a
> lot of buffer underflows (even for low sample rate like 1MS/s). For
> pre-RFNOC UHD (3.9.6) everything works fine.
>
> What is a bit strange is that txrx_loopback_to_file UHD example works
> fine for all versions of UHD.
>
> Is anybody here able to run GNU Radio flow-graphs with simultaneous tx
> and rx on X310 with RFNOC UHD and without underflows?
Little update:
I've got the issue only on 10 gigabit ethernet interface. For the 1
gigabit one it works well.
So it might be fault of my particular setup.

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

Re: [USRP-users] Fwd: Re: USRP's B210 sluggish start of transmission

2017-11-13 Thread Piotr Krysik via USRP-users

Dear list,

Little update on transmitting bursts and simultaneous receiving with
USRP B210. When I connect anything that has some path between TX/RX SMA
port's body and inner female sleeve contact (like 3dB attenuator or even
my finger) the output signal starts to look ok. I don't know what is
causing this and if it can be corrected with a firmware change (I'm not
actively looking for the cause currently).

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] Fwd: Re: USRP's B210 sluggish start of transmission

2017-11-28 Thread Piotr Krysik via USRP-users

W dniu 13.11.2017 o 11:36, Piotr Krysik via USRP-users pisze:
> Dear list,
>
> Little update on transmitting bursts and simultaneous receiving with
> USRP B210. When I connect anything that has some path between TX/RX SMA
> port's body and inner female sleeve contact (like 3dB attenuator or even
> my finger) the output signal starts to look ok. I don't know what is
> causing this and if it can be corrected with a firmware change (I'm not
> actively looking for the cause currently).

Another update:

With a log periodic antenna connected to Tx port (the 850-6500MHz one
from Ettus) everything works fine. With vertical antennas (like VERT900
or VERT2450 from Ettus) the mentioned problem appears.

I suppose that for all antennas that have connection between the active
pin and the ground it might work fine.

Best Regards,
Piotr Krysik

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

[USRP-users] Underflows with simple rx/tx GNU Radio flowgraph on USRP X310 under RFNOC UHD

2017-10-22 Thread Piotr Krysik via USRP-users

Hi all,

I'm prepared a basic GNU Radio flow-graph that does simultaneous
transmission and reception (see the attachment). For USRP X310 and RFNOC
UHD (version above 3.10.x) soon after starting the flow-graph there is a
lot of buffer underflows (even for low sample rate like 1MS/s). For
pre-RFNOC UHD (3.9.6) everything works fine.

What is a bit strange is that txrx_loopback_to_file UHD example works
fine for all versions of UHD.

Is anybody here able to run GNU Radio flow-graphs with simultaneous tx
and rx on X310 with RFNOC UHD and without underflows?

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-24 Thread Piotr Krysik via USRP-users

W dniu 22.02.2018 o 23:37, Marcus D. Leech via USRP-users pisze:
> On 02/22/2018 09:15 AM, Piotr Krysik via USRP-users wrote:
>> Hi all,
>>
>> There was a thread on this topic started by Hideyuki Matsunaga that
>> didn't resolve this question.
>>
>> I want to reiterate this question here but from different point: it
>> seems that at this moment it isn't possible. I did my best to
>> synchronize two USRPs B210 (the description is below) and the result was
>> negative.
>> Please prove my hypothesis is wrong.
>>
>>
>> Here is the description how to reproduce the problem (keep in mind that
>> the code below was tested on USRP X310 and it worked correctly):
>>
>> 1. connect REF and PPS inputs of USRPs to reference clock source (i.e.
>> octoclock-G),
>>
>> 2. connect noise source (i.e. another USRP) at 1GHz central frequency
>> (this is default frequency of the recorder) through an attenuator and
>> splitter to inputs of USRPs B210,
>>
>> 3. run:
>>
>> recorder.py --serial1  --serial2
>> 
>>
>> (recorder.py implements synchronization of two usrp_source objects, the
>> function that does that is Python re-implementation of
>> set_time_unknown_pps uhd function).
>>
>> 4. then open octave-cli and in it run:
>>
>> show_cross_corrs
>>
>>
>> You should get the results like below:
>>
>> The result of cross-correlation between channels of single USRP:
>>
>> https://imgur.com/a/66Z2g
>>
>> Everything is fine here, the correlation peak is in the zero, which
>> means that correlated signals are time-synchronized.
>>
>>
>> The result of cross-correlation between channels of different USRPs:
>>
>> https://imgur.com/a/sCKCS
>>
>> Here there is problem: the peak is not in zero, the signals recorded by
>> two different USRPs *are not time-synchronized*.
>>
>>
>> I tested with UHD installed from Ubuntu 16.04 packages and fresh
>> compilation, for different B210s and different Octoclocks-G and the
>> synchronization of B210s doesn't work. Why is it the case? I might be
>> doing something wrong, but please take into consideration that there is
>> something wrong with B210s time-synchronization in general. It would be
>> great if someone can reproduce the problem or show that it works for him
>> (if yes: how he did it).
>>
>>
>> I attach whole code of the recorder (with grc file that was used to
>> generate part of it) and processing and image of the flowgraph.
>>
> I took a quick look at your flow-graphs.
>
> Two things come to mind
>
> (A) What if more than 3 seconds of wall-time occur between your __init
> function, and the code finally calling tb.start()?   That would cause
> the B210 to
>   begin streaming immediately, and since this is two different
> multi_usrps, there's no time-alignment between them.
>
> (B) There is a 180deg ambiguity in the AD9361 clock logic, so that two
> AD9361s given the same clock can have a 180deg phase-difference at the
> mixer
>  (or 0deg phase difference, depending on divider state) this is
> probably not your issue, but it is an *additonal* headache you'll have
> to deal with.
Hi Marcus,

Ad.A  I doubted it as the time reported by both USRPs at the end of
synchronization function is about ~0.005 s. Anyway I increased the value
of start time to 9 seconds - with the same (negative) result.

Ad.B When I get these B210s to time-synchronize I plan to implement
phase calibration method that doesn't rely on the capabilities provided
by B210's LO synthesizer. But I need to get to that point first. BTW
180deg ambiguity is still better than what I expected.

--
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-25 Thread Piotr Krysik via USRP-users

W dniu 24.02.2018 o 23:10, Marcus D. Leech via USRP-users pisze:
> On 02/24/2018 04:27 PM, Piotr Krysik via USRP-users wrote:
>> Hi Marcus,
>>
>> Ad.A  I doubted it as the time reported by both USRPs at the end of
>> synchronization function is about ~0.005 s. Anyway I increased the value
>> of start time to 9 seconds - with the same (negative) result.
>>
>> Ad.B When I get these B210s to time-synchronize I plan to implement
>> phase calibration method that doesn't rely on the capabilities provided
>> by B210's LO synthesizer. But I need to get to that point first. BTW
>> 180deg ambiguity is still better than what I expected.
>>
>> -- 
>> Best Regards,
>> Piotr Krysik
>>
> What if you use the time-stamps on the streams to time-align, and THEN
> cross-correlate?
>
> Remember that multi-usrp does this as a first step when it's dealing
> with multiple notionally-time-aligned streams from multiple devices.
>
> But that's only *WITHIN* a single multi-usrp object, and you
> necessarily have more than one multi_usrp object

To check this I connected two tag_debug blocks to usrp sources. They
caught following tags at offset 0 (first sample of the stream):
--
Tag Debug:
Input Stream: 00
  Offset: 0  Source: gr uhd usrp source2 Key: rx_time   Value: {9
3.86875e-05}
  Offset: 0  Source: gr uhd usrp source2 Key: rx_rate   Value: 1e+06
  Offset: 0  Source: gr uhd usrp source2 Key: rx_freq   Value: 1e+09
--

--
Tag Debug:
Input Stream: 00
  Offset: 0  Source: gr uhd usrp source1 Key: rx_time   Value: {9
3.86875e-05}
  Offset: 0  Source: gr uhd usrp source1 Key: rx_rate   Value: 1e+06
  Offset: 0  Source: gr uhd usrp source1 Key: rx_freq   Value: 1e+09
--


There are two rx_time tags with the same value. So they should be
aligned in time, but they aren't.

What is a bit unexpected for me is the non-zero fractional part.

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

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-25 Thread Piotr Krysik via USRP-users

W dniu 25.02.2018 o 11:16, Piotr Krysik via USRP-users pisze:
> W dniu 24.02.2018 o 23:10, Marcus D. Leech via USRP-users pisze:
>>
>> What if you use the time-stamps on the streams to time-align, and THEN
>> cross-correlate?
>>
>> Remember that multi-usrp does this as a first step when it's dealing
>> with multiple notionally-time-aligned streams from multiple devices.
>>
>> But that's only *WITHIN* a single multi-usrp object, and you
>> necessarily have more than one multi_usrp object
> To check this I connected two tag_debug blocks to usrp sources. They
> caught following tags at offset 0 (first sample of the stream):
> --
> Tag Debug:
> Input Stream: 00
>   Offset: 0  Source: gr uhd usrp source2 Key: rx_time   Value: {9
> 3.86875e-05}
>   Offset: 0  Source: gr uhd usrp source2 Key: rx_rate   Value: 1e+06
>   Offset: 0  Source: gr uhd usrp source2 Key: rx_freq   Value: 1e+09
> --
>
> --
> Tag Debug:
> Input Stream: 00
>   Offset: 0  Source: gr uhd usrp source1 Key: rx_time   Value: {9
> 3.86875e-05}
>   Offset: 0  Source: gr uhd usrp source1 Key: rx_rate   Value: 1e+06
>   Offset: 0  Source: gr uhd usrp source1 Key: rx_freq   Value: 1e+09
> --
>
>
> There are two rx_time tags with the same value. So they should be
> aligned in time, but they aren't.
>
> What is a bit unexpected for me is the non-zero fractional part.
>
For X310 there is also constant fractional part in rx_time tag. So this
probably won't lead to the source of the problem.


___
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-01-24 Thread Piotr Krysik via USRP-users

 dniu 23.01.2018 o 19:11, Martin Braun via USRP-users pisze:
> On Thu, Jan 18, 2018 at 10:34:14AM +0100, Piotr Krysik via USRP-users wrote:
>> Hi Hideyuki,
>>
>> Our students were working (with my help) on synchronizing two USRPs B210
>> with use of Octoclock-G.
>> To make your code work without any race-conditions I would add a loop
>> that waits for pps edge before your adjustment code, like this:
>> ```
>>   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)
>> ```
> This is good advice. You can go to multi_usrp.cpp and take a look at
> set_time_unknown_pps() for a reference on how to do that.
>
Hi Martin,

The problem is that even when I replicated exactly the
set_time_unknown_pps() function in Python it doesn't work with USRPs B210.

It works perfectly well with X310s but somehow with B210s there is some
time offset (few hundreds us) that changes from one program execution to
another. I still have to check on different B210s and different
Octoclocks but it requires some time and in the end I don't expect a
surprise (probably I will just be more sure that it is fault of the B210).

So even to get information from someone like: "I checked and it works
for me" would help me and others a lot.

--
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 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_sou

[USRP-users] Reusing UHD transport to send signal samples between processes

2018-11-08 Thread Piotr Krysik via USRP-users

Hello everyone,

I'm considering to create virtual SDR device based on UHD (as libuhd
module) and virtual radio channel (probably a GNU Radio based program).
The main aim is to enable (at least partial) testing of programs using
without need to run actual hardware (i.e. to run base transceiver
station and at digital signal level connect to it mobile stations -
purely in software).

I need some way to send digital samples between fake SDR devices and
fake radio radio channel and I'm looking at different, already existing
options. One of them is to reuse one of transports from UHD
(https://files.ettus.com/manual/namespaceuhd_1_1transport.html). I'm
trying to find something from what I can start and at the moment it
doesn't seem to be straightforward (possibly because I don't know too
much about how UHD transports work).

So I decided to ask these questions here:

1. Is there some example how to use any of UHD transports to send signal
samples, meta-data and control information (carriers, gains, etc.) from
one process to another on the same host or over network (at the moment
anything is good for me)?

2. If there is no, can such example be easily created?

3. If not - does it make sense to try to reuse UHD transports for the
described purpose? Maybe there exists something more universal or maybe
it's better to do it from scratch?

--
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] Number of receivers at the same time USRP X-310

2018-11-13 Thread Piotr Krysik via USRP-users

Hi,

No, it's not. Each of your UBX-160 has one Rx chain.

BTW somehow it is common confusion that Tx/Rx and Rx2 ports can be used
to receive signals simultaneously. I have to explain this even to people
with professor degree in electronic engineering, that behind these ports
there is one Rx chain and there are switches on UBX/SBX/WBX/etc that
select to which of these ports this Rx chain is connected.

As Fabian has written there are TwinRX daughter cards, each with two Rx
chains, that you can use on a USRP X310 to have 4 receivers.

Best Regards,
Piotr Krysik

W dniu 13.11.2018 o 13:08, Maria Jesus Cañavate Sanchez via USRP-users
pisze:
>
> Hi again,
>
> Thank you very much for your answer. I have bought two daughter boards
> UBX-160, is that enough to have 4 receivers at the same time?
>
> Thank you!
>
> Best regards,
>
> Maria Jesus
>
>


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

Re: [USRP-users] Number of receivers at the same time USRP X-310

2018-11-16 Thread Piotr Krysik via USRP-users

Hi,

TwinRx is Rx only card. Look at the spec here:
https://www.ettus.com/product/details/TwinRX

Regarding power measurement calibration this is how it could work (so
you can measure signal power entering Rx port of your USRP):

Connect to the USRP port an RF signal source with known power 'Px'
(let's assume it is a sine wave).

Then you can record this signal (i.e. with use of GNU Radio) and compute
it's uncalibrated power as Markus described it. In Octave/Matlab this
can be written as (you can use 'read_complex_binary' function that is
distributed with GNU Radio to read signal samples 'x'):

Px_uncal = sum(x.*conj(x))/length(x)

and then you can compute simple calibration factor:

c=Px/Px_uncal

Now you can use it to compute estimate of power 'Py' of another RF
signal 'y':

Py_uncal = sum(y.*conj(y))/length(y) 

Py = c * Py_uncal
===

The calibration factor factor 'c' will be true for some particular
frequency range (how wide depends on the frequency response of the
receiver) and at some range of input signal power. It depends also on
temperature and many other variables.

Best Regards,
Piotr Krysik

W dniu 15.11.2018 o 10:56, Maria Jesus Cañavate Sanchez pisze:
> Hi Piotr,
>
> Thank you for your answer.
>
> One last question, if you get the twinRX daughter cards to be able to
> use 4 rx at the same time, can you still have access to the 2 tx and 2
> rx when convenient? Or the 4 rx are fixed?
>
> Thank you very much in advance!
>
> Best regards,
>
> Maria Jesus
>
>
> On 13/11/2018 12:34, Piotr Krysik via USRP-users wrote:
>> Hi,
>>
>> No, it's not. Each of your UBX-160 has one Rx chain.
>>
>> BTW somehow it is common confusion that Tx/Rx and Rx2 ports can be used
>> to receive signals simultaneously. I have to explain this even to people
>> with professor degree in electronic engineering, that behind these ports
>> there is one Rx chain and there are switches on UBX/SBX/WBX/etc that
>> select to which of these ports this Rx chain is connected.
>>
>> As Fabian has written there are TwinRX daughter cards, each with two Rx
>> chains, that you can use on a USRP X310 to have 4 receivers.
>>
>> Best Regards,
>> Piotr Krysik
>>
>> W dniu 13.11.2018 o 13:08, Maria Jesus Cañavate Sanchez via USRP-users
>> pisze:
>>> Hi again,
>>>
>>> Thank you very much for your answer. I have bought two daughter boards
>>> UBX-160, is that enough to have 4 receivers at the same time?
>>>
>>> Thank you!
>>>
>>> Best regards,
>>>
>>> Maria Jesus
>>>
>>>

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

Re: [USRP-users] Reusing UHD transport to send signal samples between processes

2018-11-09 Thread Piotr Krysik via USRP-users

Hi Keith,

If I manage to make it anything more than just a cool idea, the code
definitely will be available publicly.

Best Regards,
Piotr Krysik

W dniu 08.11.2018 o 17:18, Keith k pisze:
> Hello Piotr
>
> I can't answer your question, but I'm wondering if you plan to make
> this project open source? I would find a tool like this very valuable.
>
> On Thu, Nov 8, 2018 at 10:48 AM Piotr Krysik via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hello everyone,
>
> I'm considering to create virtual SDR device based on UHD (as libuhd
> module) and virtual radio channel (probably a GNU Radio based
> program).
> The main aim is to enable (at least partial) testing of programs using
> without need to run actual hardware (i.e. to run base transceiver
> station and at digital signal level connect to it mobile stations -
> purely in software).
>
> I need some way to send digital samples between fake SDR devices and
> fake radio radio channel and I'm looking at different, already
> existing
> options. One of them is to reuse one of transports from UHD
> (https://files.ettus.com/manual/namespaceuhd_1_1transport.html). I'm
> trying to find something from what I can start and at the moment it
> doesn't seem to be straightforward (possibly because I don't know too
> much about how UHD transports work).
>
> So I decided to ask these questions here:
>
> 1. Is there some example how to use any of UHD transports to send
> signal
> samples, meta-data and control information (carriers, gains, etc.)
> from
> one process to another on the same host or over network (at the moment
> anything is good for me)?
>
> 2. If there is no, can such example be easily created?
>
> 3. If not - does it make sense to try to reuse UHD transports for the
> described purpose? Maybe there exists something more universal or
> maybe
> it's better to do it from scratch?
>
> --
> Best Regards,
> Piotr Krysik
>
> ___
> 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
>
>
>
> -- 
> -Keith Kotyk



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

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

2019-04-03 Thread Piotr Krysik via USRP-users

W dniu 03.04.2019 o 10:34, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I'm trying to do calibration of phase offsets between TwinRX channels.
>
> Configuration of X310 is following: two TwinRX'es, all sharing LOs from
> fist channel of the second TwinRX.
>
> The same signal is fed to all TwinRX channels through a RF splitter.
>
> What is expected is some additional group delay for TwinRX that gets LO
> signal through a cable from the other TwinRX.
> This group delay was compensated by using longer RF cables between
> splitter and RF inputs of TwinRX1 that uses external LOs from TwinRX2.
>
> However, there is also unexpected effect: there are +/-90 degree phase
> difference changes between channels of one TwinRX1 and TwinRX2 in
> function of frequency.
>
> Measurements were performed between 100MHz and 500MHz, and here are the
> results:
>
> 1. 128MHz: +90 degrees
> 2. 172MHz: -90 degrees
> 3. 245MHz: +90 degrees
> 4. 260MHz: -90 degrees
> 5. 340MHz: +90 degrees
>
> Here is example plot of phase difference fom channel 1 (TwinRX1) to
> channels 2 and 3 (TwinRX2): https://imgur.com/4C09MSf
> What I would expect (after compensation of LO cable length) was
> something (~) flat, but there are these phase jumps by +/-90 degrees.
>
> This effect can be included in calibration. But it would be best to
> know: where these phase jumps for different frequencies come from?
>
> Best Regards,
> Piotr Krysik
>
The frequencies here are carrier frequencies that are being set for each
channel. On each carrier frequency measurement is performed - with use
of sine wave or noise signal. Sample rate was 2MS/s.

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

[USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

2019-04-03 Thread Piotr Krysik via USRP-users

Hi all,

I'm trying to do calibration of phase offsets between TwinRX channels.

Configuration of X310 is following: two TwinRX'es, all sharing LOs from
fist channel of the second TwinRX.

The same signal is fed to all TwinRX channels through a RF splitter.

What is expected is some additional group delay for TwinRX that gets LO
signal through a cable from the other TwinRX.
This group delay was compensated by using longer RF cables between
splitter and RF inputs of TwinRX1 that uses external LOs from TwinRX2.

However, there is also unexpected effect: there are +/-90 degree phase
difference changes between channels of one TwinRX1 and TwinRX2 in
function of frequency.

Measurements were performed between 100MHz and 500MHz, and here are the
results:

1. 128MHz: +90 degrees
2. 172MHz: -90 degrees
3. 245MHz: +90 degrees
4. 260MHz: -90 degrees
5. 340MHz: +90 degrees

Here is example plot of phase difference fom channel 1 (TwinRX1) to
channels 2 and 3 (TwinRX2): https://imgur.com/4C09MSf
What I would expect (after compensation of LO cable length) was
something (~) flat, but there are these phase jumps by +/-90 degrees.

This effect can be included in calibration. But it would be best to
know: where these phase jumps for different frequencies come from?

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] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

2019-04-03 Thread Piotr Krysik via USRP-users

To answer my own question:
https://github.com/EttusResearch/uhd/blob/master/CHANGELOG#L226

it seems the answer is yes.

--
Piotr Krysik
W dniu 03.04.2019 o 12:34, Piotr Krysik via USRP-users pisze:
> Hi,
>
> W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
>> (...)
>> Keep in mind that it is not necessary to use LO-sharing to get a well
>> defined phase relation between the channels. Depending on your
>> frequency and bandwidth settings, it is possible to also achive this,
>> as all LOs are driven from a common 200 MHz reference clock.
>>
> Do you mean TwinRXes might have similar initial phase reset capability
> that UBXes and SBXes have?
>
> --
> Best Regards,
> Piotr Krysik
>
>
>> Best regards,
>> Fabian
>>
>> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>>> Hi Fabian,
>>>
>>> W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
>>>> Hi Piotr,
>>>>
>>>> we once had a very similar issue. But we also saw this on the same
>>>> frequency when switching between frequencies. Can you try this as
>>>> well? Just switch forth and back between two frequencies and just plot
>>>> one of them?
>>> I'm not sure I understand correctly what you mean. You mean that the
>>> result for a given frequency was not stable in your case across many
>>> measurements? In our case this situation was repeating, but the
>>> application doing the recording was restarted for each measurement.
>>>
>>>> As far as I remember the issue was because we were not using the
>>>> LO-Sharing. We were able to get everything running by using a C++
>>>> application and not gnuradio (I can see you are using python - which
>>>> is basically the same). There was a bug in gnuradio/python causing
>>>> this issue.
>>>> You can try to remove one of the LO-sharing cables while doing a
>>>> measurement and see if the phase suddenly starts to do crazy things
>>>> (the signal should also be lost). If that is not the case, you are not
>>>> actually using LO-sharing.
>>>>
>>> Do you know what this bug was exactly? GNU Radio didn't configure
>>> LO-Sharing the way it was specified?
>>>
>>> -- 
>>> 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] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

2019-04-03 Thread Piotr Krysik via USRP-users

Hi Fabian,

W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
> Hi Piotr,
>
> we once had a very similar issue. But we also saw this on the same
> frequency when switching between frequencies. Can you try this as
> well? Just switch forth and back between two frequencies and just plot
> one of them?

I'm not sure I understand correctly what you mean. You mean that the
result for a given frequency was not stable in your case across many
measurements? In our case this situation was repeating, but the
application doing the recording was restarted for each measurement.

> As far as I remember the issue was because we were not using the
> LO-Sharing. We were able to get everything running by using a C++
> application and not gnuradio (I can see you are using python - which
> is basically the same). There was a bug in gnuradio/python causing
> this issue.
> You can try to remove one of the LO-sharing cables while doing a
> measurement and see if the phase suddenly starts to do crazy things
> (the signal should also be lost). If that is not the case, you are not
> actually using LO-sharing.
>
Do you know what this bug was exactly? GNU Radio didn't configure
LO-Sharing the way it was specified?

--
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] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

2019-04-03 Thread Piotr Krysik via USRP-users

Hi,

W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
> (...)
> Keep in mind that it is not necessary to use LO-sharing to get a well
> defined phase relation between the channels. Depending on your
> frequency and bandwidth settings, it is possible to also achive this,
> as all LOs are driven from a common 200 MHz reference clock.
>
Do you mean TwinRXes might have similar initial phase reset capability
that UBXes and SBXes have?

--
Best Regards,
Piotr Krysik


> Best regards,
> Fabian
>
> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>> Hi Fabian,
>>
>> W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
>>> Hi Piotr,
>>>
>>> we once had a very similar issue. But we also saw this on the same
>>> frequency when switching between frequencies. Can you try this as
>>> well? Just switch forth and back between two frequencies and just plot
>>> one of them?
>>
>> I'm not sure I understand correctly what you mean. You mean that the
>> result for a given frequency was not stable in your case across many
>> measurements? In our case this situation was repeating, but the
>> application doing the recording was restarted for each measurement.
>>
>>> As far as I remember the issue was because we were not using the
>>> LO-Sharing. We were able to get everything running by using a C++
>>> application and not gnuradio (I can see you are using python - which
>>> is basically the same). There was a bug in gnuradio/python causing
>>> this issue.
>>> You can try to remove one of the LO-sharing cables while doing a
>>> measurement and see if the phase suddenly starts to do crazy things
>>> (the signal should also be lost). If that is not the case, you are not
>>> actually using LO-sharing.
>>>
>> Do you know what this bug was exactly? GNU Radio didn't configure
>> LO-Sharing the way it was specified?
>>
>> -- 
>> 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] Please add me to the mail list

2019-03-21 Thread Piotr Krysik via USRP-users

W dniu 21.03.2019 o 10:58, Diogo Botelho Ribeiro Marinho via USRP-users
pisze:
>
> I am using N310 and i would like to send my questions to the forum.
>
>  
>
> So far i am not able to do it.
>
>  
>
>
Hi Diogo,

I beg to disagree. From my perspective it looks that you are able to
send posts to the mailing-list.

I can even see your post from two days ago (without its subject however).

--
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] What makes sense and what doesn't in the way carrier frequency is set for TwinRX currently?

2019-03-23 Thread Piotr Krysik via USRP-users

Hi all,

Update to the previous post. Nate Temple on IRC pointed that what I
observe might be a result of a bug in recent UHD's, where co-channel
phase difference on TwinRX doesn't behave as expected.
Nate's advice was to go back to UHD 3.13, which I did (I took the top
from UHD-3.13 branch).

I did tests with original twinrx_usrp_source.py (where on
UHD_3.15.0.git-13-g52138314 I had problem with phase changes).
With UHD 3.13 I didn't need additional call to set_time_unknown_pps. The
co-channel phase differences were constant from one program running to
another without it.

So it seems the strange behavior of phase in signal coming from TwinRXes
might be a result of a bug that Nate was informing about.

--
Best Regards,
Piotr Krysik

W dniu 13.03.2019 o 14:48, Piotr Krysik via USRP-users pisze:
> Hello everyone,
>
> TwinRXes requires special treatment when setting frequency in order to
> keep co-channel phase differences across multiple executions of a
> program communicating with USRP.
>
> What exactly 'treatment' I mean can be seen for example here:
> https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L100
>
> or here:
>
> https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/apps/uhd_app.py#L298
>
>
> The procedure is following (correct configuration of LO export and LO
> sources is assumed):
>
> 1. set the frequency for the channel exporting LOs, and store result,
> 2. set the frequency for the rest of the channels using the result saved
> previously and POLICY_MANUAL for rf and dsp,
> 3. set the frequency again for all channels with use of timed commands.
>
> In uhd_app's constructor there is also call to set_time_unknown_pps
> between points 2 and 3. In twinrx_usrp_source.py set_time_unknown_pps is
> called before point 1. The placement of this function call after the
> first setting of the carrier frequency seems to be crucial. Without it
> there are random 180 degree changes of phase differences between
> channels from one run to another. And this issue can be observed for
> twinrx_usrp_source.py, because it calls set_time_unknown_pps before
> setting the frequency (checked on UHD_3.15.0.git-13-g52138314).
>
> I also changed different settings to see what effects they have. I
> didn't notice any effect of POLICY_MANUAL setting in point 2. Setting
> the frequency in regular way seems to work just as well. Also removing
> point 3 completely (setting freq. with use of timed commands) seems to
> not have any effect for TwinRX (I checked this with use of sine wave as
> the input signal, in case it is important).
>
> In the end what I did was configuring LO export/sources in GNU Radio and
> adding usrp.set_time_unknown_pps(..) at the end of the of the
> constructor. As a result co-channel phase differences were (~) constant
> across multiple runs.
>
>
> My question:
> 1. What is the rationale for all of the steps of frequency setting for
> TwinRX? Did I have luck that most of them didn't have any effect for me?
> 2. Why is the call to set_time_unknown_pps required at all? And why when
> it is called after the first setting of carrier frequency in all
> channels, it fixes the issue with 180 degree phase shifts from one run
> to another? If it's called before, it doesn't seem to have this positive
> effect.
>


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

Re: [USRP-users] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

2019-04-03 Thread Piotr Krysik via USRP-users

Hi,

After disconnecting LO cables signal on the daughter-board that imports
LOs disappears. So GNU Radio correctly configures distribution of LOs.
Also the +/- 90 degree changes happen completely deterministically in
given ranges of carrier frequencies.

So the question remains open: what is causing the issue described in the
first post of this thread?

--
Best Regards,
Piotr Krysik

W dniu 03.04.2019 o 12:15, Fabian Schwartau via USRP-users pisze:
> Hi,
>
> yes, the result for multiple measurements (start ups of the system) at
> a single frequency was different by multiples of 90°.
> We did not investigated the problem any further, but I am quite sure
> that gnuradio was not synchronizing the channels using the LO-sharing,
> although it was selected. So do the test I described. If you see that
> he is not using the LO-sharing, you know where to look further.
> Keep in mind that it is not necessary to use LO-sharing to get a well
> defined phase relation between the channels. Depending on your
> frequency and bandwidth settings, it is possible to also achive this,
> as all LOs are driven from a common 200 MHz reference clock.
>
> Best regards,
> Fabian
>
> Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
>> Hi Fabian,
>>
>> W dniu 03.04.2019 o 11:05, Fabian Schwartau via USRP-users pisze:
>>> Hi Piotr,
>>>
>>> we once had a very similar issue. But we also saw this on the same
>>> frequency when switching between frequencies. Can you try this as
>>> well? Just switch forth and back between two frequencies and just plot
>>> one of them?
>>
>> I'm not sure I understand correctly what you mean. You mean that the
>> result for a given frequency was not stable in your case across many
>> measurements? In our case this situation was repeating, but the
>> application doing the recording was restarted for each measurement.
>>
>>> As far as I remember the issue was because we were not using the
>>> LO-Sharing. We were able to get everything running by using a C++
>>> application and not gnuradio (I can see you are using python - which
>>> is basically the same). There was a bug in gnuradio/python causing
>>> this issue.
>>> You can try to remove one of the LO-sharing cables while doing a
>>> measurement and see if the phase suddenly starts to do crazy things
>>> (the signal should also be lost). If that is not the case, you are not
>>> actually using LO-sharing.
>>>
>> Do you know what this bug was exactly? GNU Radio didn't configure
>> LO-Sharing the way it was specified?
>>
>> -- 
>> 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] UBX coherence between TX and RX

2019-04-08 Thread Piotr Krysik via USRP-users

Hi all,

I looked at this thread and it reminded me of something.

Once we purchased few X310 with UBX160 daughter-boards.

One of them had some frequency offset on Tx channel, that decreased over
time it was running, but very slowly.

The daughter-board was then replaced by National Intruments (after some
adventures ;) ). The replacement one had exactly the same issue so it
was also replaced. The next one was ok. So it seemed it was some
manufacturing issue with UBX.

I don't know if it's the same issue (i.e. due to lack of data), but I
attach part of the report that was sent to National Instruments:
-phase offset of the received signal in relation to digital waveform for
a single X310 with UBX160 for all TX and RX combinations:
https://imgur.com/a/ODBtT4o
-schematic:
https://imgur.com/a/si9fJZp

I got also scripts that were used for recording and plotting that
figure. If you are interested I can post it somewhere.

What seems different from situation here is that for us it seemed the
effect wasn't depending on frequency (but I didn't do any extensive
tests and might not remember).

--
Best Regards,
Piotr Krysik

W dniu 07.04.2019 o 03:00, Freedman, Michael - 1008 - MITLL via
USRP-users pisze:
> I have switched and am currently running the release 3.14.0.0
>
> Sent from my iPhone
>
> On Apr 6, 2019, at 8:58 AM, Marcus D. Leech  > wrote:
>
> On 04/05/2019 11:43 AM, Michael R. Freedman wrote:
>>
>> Hello,
>>
>>
>> If I remove the DSP from the equation by setting the DSP tuning
>> policy to manual and assigning it to zero, I am coherent from tx to
>> rx on all frequencies.  I'm now beginning to think that the DSP is
>> doing it's tuning differently for tx and rx.  Or there is an
>> accumulated error in opposite directions for both.  Thoughts?
>>
>>
>> Leaving the DSP to zero is not a good solution however as there is
>> too much LO leakage.
>>
>>
> Could you try UHD 3.14.0.0?
>
> I think that you're using the -rc3 version at the moment.
>
>
>> Mike
>>
>>
>> On 03/27/2019 04:58 PM, Marcus D. Leech wrote:
>>> On 03/27/2019 04:48 PM, Michael R. Freedman wrote:

 This is on a single UBX card within a single USRP.


 ./uhd_usrp_probe --args=addr=192.168.40.100
 [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
 UHD_3.14.0.0-0-unknown
 [INFO] [X300] X300 initialization sequence...
 [INFO] [X300] Maximum frame size: 8000 bytes.
 [INFO] [X300] Radio 1x clock: 200 MHz
 [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
 0xF1F0D000)
 [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s)
 [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1294 MB/s)
 [INFO] [0/Radio_0] Initializing block control (NOC ID:
 0x12AD1001)
 [INFO] [0/Radio_1] Initializing block control (NOC ID:
 0x12AD1001)
 [INFO] [0/DDC_0] Initializing block control (NOC ID:
 0xDDC0)
 [INFO] [0/DDC_1] Initializing block control (NOC ID:
 0xDDC0)
 [INFO] [0/DUC_0] Initializing block control (NOC ID:
 0xD0C0)
 [INFO] [0/DUC_1] Initializing block control (NOC ID:
 0xD0C0)
   _
  /
 |   Device: X-Series Device
 | _
 |    /
 |   |   Mboard: X310
 |   |   revision: 6
 |   |   product: 30410
 |   |   mac-addr0: 00:80:2f:0a:ff:98
 |   |   mac-addr1: 00:80:2f:0a:ff:99
 |   |   gateway: 192.168.10.1
 |   |   ip-addr0: 192.168.10.100
 |   |   subnet0: 255.255.255.0
 |   |   ip-addr1: 192.168.20.100
 |   |   subnet1: 255.255.255.0
 |   |   ip-addr2: 192.168.30.100
 |   |   subnet2: 255.255.255.0
 |   |   ip-addr3: 192.168.40.100
 |   |   subnet3: 255.255.255.0
 |   |   serial: F5BE45
 |   |   FW Version: 6.0
 |   |   FPGA Version: 35.1
 |   |   FPGA git hash: 4c165a5
 |   |   RFNoC capable: Yes
 |   |  
 |   |   Time sources:  internal, external, gpsdo
 |   |   Clock sources: internal, external, gpsdo
 |   |   Sensors: ref_locked
 |   | _
 |   |    /
 |   |   |   RX Dboard: A
 |   |   |   ID: UBX-40 v2 (0x007c)
 |   |   |   Serial: 313C181
 |   |   | _
 |   |   |    /
 |   |   |   |   RX Frontend: 0
 |   |   |   |   Name: UBX RX
 |   |   |   |   Antennas: TX/RX, RX2, CAL
 |   |   |   |   Sensors: lo_locked
 |   |   |   |   Freq range: 10.000 to 6000.000 MHz
 |   |   |   |   Gain range PGA0: 0.0 to 31.5 step 0.5 dB
 |   |   |   |   Bandwidth range: 4000.0 to 4000.0 step 0.0 Hz
 |   |   |   |   Connection Type: IQ
 |   |   |   |   Uses LO offset: No
 |   |   | _
 |   |   |    /

Re: [USRP-users] Phase drift issue of N310

2019-03-14 Thread Piotr Krysik via USRP-users

Hi Ali,

The daughterboards have their own clock generators, but they are not
exactly 'independent'. At least they don't have to be, as they share the
same reference clock. Look at the block diagram:

https://kb.ettus.com/images/9/9d/USRP_N310_N300_DB_Schematic.pdf

and "Ref Clock" block. I don't have N310 and I know that reality can be
a bit far from expectations (i.e. look at my "What makes sense and what
doesn't in the way carrier frequency is set for TwinRX currently?" post).

But maybe the daughterboards can be configured to use that reference clock.


Best Regards,
Piotr Krysik

W dniu 13.03.2019 o 19:59, Ali Dormiani via USRP-users pisze:
> Hello,
>
> You sort of said the answer yourself:
>
> "two dboards are using independent reference clocks"
>
> RX0 and RX1 use the same LO while RX2 and RX3 use a different LO.
>
> I like to think of each N310 as two radios in the same box (when it
> comes to phase issues). Additionally, I think UHD/GNUradio start up RF
> components at run-time so all calibration needs to be preformed each
> time you run a flow-graph or C file?
>
> There are signal processing ways to mitigate this. Consider looking
> into ESPRIT or array shape calibration research.
>
> The hardware fix to this problem is feeding an external LO into each
> N310 dboard.
>
> Attached are some old results from our lab with an 8 TX 24 RX system
> set up indoors (all N310s). You can see that our DOA estimate in
> ESPRIT drifts badly (10 degrees or so) over about a second of data.
>
> The point I'm trying to make is, depending on your application, you
> can avoid buying external LO's, references, ect with some math effort.
>
> However, if you are looking for hardware I suggest Ettus Octoclocks
> for splitting and the following frequency synthesizer:
>
> https://www.valonrf.com/frequency-synthesizer-4400mhz.html
>
> Good luck with your endeavors,
>
> Ali
>
> On Wed, Mar 13, 2019 at 5:52 AM guowang qiu via USRP-users
> mailto:usrp-users@lists.ettus.com>> wrote:
>
> Hi all,
>
> There are two daughter boards in N310, the phase difference
> between channels of different dboards will drift rapidly.
>
> In my test, a B200 transmits single tone continuous wave to a
> 1-to-2 splitter, and the outputs of splitter are connected to
> input ports of RF0 and RF2 of N310.
>
> During the single program running, the signals received by the two
> channels should keep the phase difference approximately stable.
> But I observed that the phase drift of the two channels was very
> fast. Within a time span of 20 seconds, the phase difference
> varied by tens of degrees. Sense that two dboards are using
> independent reference clocks, not the same reference clock from
> mboard. By contrast, the phase difference between the two channels
> of x310 with two ubx is stable.
>
> Does anyone know how to explain this issue?
>
> Best regards,
>
> Damon
>
> ___
> 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] What makes sense and what doesn't in the way carrier frequency is set for TwinRX currently?

2019-03-13 Thread Piotr Krysik via USRP-users

Hello everyone,

TwinRXes requires special treatment when setting frequency in order to
keep co-channel phase differences across multiple executions of a
program communicating with USRP.

What exactly 'treatment' I mean can be seen for example here:
https://github.com/EttusResearch/gr-doa/blob/master/python/twinrx_usrp_source.py#L100

or here:

https://github.com/gnuradio/gnuradio/blob/master/gr-uhd/apps/uhd_app.py#L298


The procedure is following (correct configuration of LO export and LO
sources is assumed):

1. set the frequency for the channel exporting LOs, and store result,
2. set the frequency for the rest of the channels using the result saved
previously and POLICY_MANUAL for rf and dsp,
3. set the frequency again for all channels with use of timed commands.

In uhd_app's constructor there is also call to set_time_unknown_pps
between points 2 and 3. In twinrx_usrp_source.py set_time_unknown_pps is
called before point 1. The placement of this function call after the
first setting of the carrier frequency seems to be crucial. Without it
there are random 180 degree changes of phase differences between
channels from one run to another. And this issue can be observed for
twinrx_usrp_source.py, because it calls set_time_unknown_pps before
setting the frequency (checked on UHD_3.15.0.git-13-g52138314).

I also changed different settings to see what effects they have. I
didn't notice any effect of POLICY_MANUAL setting in point 2. Setting
the frequency in regular way seems to work just as well. Also removing
point 3 completely (setting freq. with use of timed commands) seems to
not have any effect for TwinRX (I checked this with use of sine wave as
the input signal, in case it is important).

In the end what I did was configuring LO export/sources in GNU Radio and
adding usrp.set_time_unknown_pps(..) at the end of the of the
constructor. As a result co-channel phase differences were (~) constant
across multiple runs.


My question:
1. What is the rationale for all of the steps of frequency setting for
TwinRX? Did I have luck that most of them didn't have any effect for me?
2. Why is the call to set_time_unknown_pps required at all? And why when
it is called after the first setting of carrier frequency in all
channels, it fixes the issue with 180 degree phase shifts from one run
to another? If it's called before, it doesn't seem to have this positive
effect.

--
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] Phase after Freq Hopping

2019-03-18 Thread Piotr Krysik via USRP-users

Hi Dominik

W dniu 18.03.2019 o 10:49, Patscheider, Dominik pisze:

> Hi Piotr Krysik,
>
> I wanted to achieve an stepped OFDM Radar. 
> To increase the baseband for the radar, I´m splitting the subcarrier and 
> transmit them on four center frequencies. 
> Thus it sends the first symbols on f0 (with an initial phase); afterwards 
> increasing the center freq to f1 and transmit the next symbols,...
> And obviously the initial phase is changing after reconfiguring the 
> frequency. If phase1, phase5, phase9,... phase2,phase6,... isn´t the same, 
> it´s not possible to measure any velocity.

If you can predict what USRP does with phase differences of the received
signal in relation to digital waveform, then you can compensate for it
by shifting phases of the received or transmitted signal.

> Secondly, the time commands to change the freq I knew but didn´t use right 
> now.
>
>
I doubt what you are trying to do (keeping knowledge of phase relations
after retuning analog RF front-end) can be done on USRPs without timed
commands and appropriate daughter-board.

--
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] TwinRX: +/-90 degree phase jumps between channels of different daughter-boards

2019-04-10 Thread Piotr Krysik via USRP-users

Hi Kevin,

I got inverted spectrum (that means sign of I or Q is changed) when I
only set the frequency with use of timed commands. I described the
ranges in the original post. We did measurements in 100-500MHz band. You
can see phase difference between two TwinRXes here:
https://imgur.com/4C09MSf

Slight change of frequency didin't seem to help. I.e. in whole
128-172MHz the phase difference was continuous, then there was ~90
degree discontinuity at 172MHz, then at 245MHz there was another with
opposite sign and so on.

I don't know what might be causing this. After looking at the diagram of
TwinRX there doesn't seem to be any circuit that might do such changes
of the LO phase. Maybe something in the FPGA. I'm puzzled...

Best Regards,
Piotr Krysik

W dniu 04.04.2019 o 23:00, Rigney, Kevin E via USRP-users pisze:
> Pitor:
>
> We've seen a similar issue and have worked around it by just using a slightly 
> different frequency. Can you post the frequencies that you're seeing it on? I 
> think Ettus should be able to duplicate. I saw an issue with spectral 
> inversion (I think I and Q are getting swapped somewhere) at 2.8GHz but not 
> 2.9GHz.
>
> -Kevin
>  
> On 4/4/19, 12:00 PM, "USRP-users on behalf of 
> usrp-users-requ...@lists.ettus.com"  behalf of usrp-users-requ...@lists.ettus.com> wrote:
>
> Hi,
> 
> After disconnecting LO cables signal on the daughter-board that imports
> LOs disappears. So GNU Radio correctly configures distribution of LOs.
> Also the +/- 90 degree changes happen completely deterministically in
> given ranges of carrier frequencies.
> 
> So the question remains open: what is causing the issue described in the
> first post of this thread?
> 
> --
> Best Regards,
> Piotr Krysik
> 
> W dniu 03.04.2019 o?12:15, Fabian Schwartau via USRP-users pisze:
> >Hi,
> >
> >yes, the result for multiple measurements (start ups of the system) at
> >a single frequency was different by multiples of 90?.
> >We did not investigated the problem any further, but I am quite sure
> >that gnuradio was not synchronizing the channels using the LO-sharing,
> >although it was selected. So do the test I described. If you see that
> >he is not using the LO-sharing, you know where to look further.
> >Keep in mind that it is not necessary to use LO-sharing to get a well
> >defined phase relation between the channels. Depending on your
> >frequency and bandwidth settings, it is possible to also achive this,
>     >as all LOs are driven from a common 200 MHz reference clock.
> >
> >Best regards,
> >Fabian
> >
> >Am 03.04.2019 um 12:05 schrieb Piotr Krysik via USRP-users:
> >>Hi Fabian,
> >>
> >>W dniu 03.04.2019 o?11:05, Fabian Schwartau via USRP-users pisze:
> >>>Hi Piotr,
> >>>
> >>>we once had a very similar issue. But we also saw this on the same
> >>>frequency when switching between frequencies. Can you try this as
> >>>well? Just switch forth and back between two frequencies and just plot
> >>>one of them?
> >>
> >>I'm not sure I understand correctly what you mean. You mean that the
> >>result for a given frequency was not stable in your case across many
> >>measurements? In our case this situation was repeating, but the
> >>application doing the recording was restarted for each measurement.
> >>
> >>>As far as I remember the issue was because we were not using the
> >>>LO-Sharing. We were able to get everything running by using a C++
> >>>application and not gnuradio (I can see you are using python - which
> >>>is basically the same). There was a bug in gnuradio/python causing
> >>>this issue.
> >>>You can try to remove one of the LO-sharing cables while doing a
> >>>measurement and see if the phase suddenly starts to do crazy things
> >>>(the signal should also be lost). If that is not the case, you are not
> >>>actually using LO-sharing.
> >>>
> >>Do you know what this bug was exactly? GNU Radio didn't configure
> >>LO-Sharing the way it was specified?
> >>
> >>-- 
> >>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] UBX coherence between TX and RX

2019-04-09 Thread Piotr Krysik via USRP-users

Hi Mike,

Let's keep the discussion on the mailing list. I attach the scripts as
they are quite small. There is however a data folder with two 4MB files
containing noise in complex short format. The version of the archive
with those files is here:
https://app.box.com/s/xfpwro8wybog4f1yo1l6yh665tg4sx0r

First you run:
./record.sh

then:
./show_figures.m

(you need to have octave installed for the second script).

Best Regards,
Piotr Krysik

W dniu 08.04.2019 o 18:30, Michael R. Freedman pisze:
> That would be wonderful if I could get your scripts to run.
>
>
> Thanks a bunch for the info!
>
>
> Mike
>
>
> On 04/08/2019 09:56 AM, Piotr Krysik via USRP-users wrote:
>> Hi all,
>>
>> I looked at this thread and it reminded me of something.
>>
>> Once we purchased few X310 with UBX160 daughter-boards.
>>
>> One of them had some frequency offset on Tx channel, that decreased over
>> time it was running, but very slowly.
>>
>> The daughter-board was then replaced by National Intruments (after some
>> adventures ;) ). The replacement one had exactly the same issue so it
>> was also replaced. The next one was ok. So it seemed it was some
>> manufacturing issue with UBX.
>>
>> I don't know if it's the same issue (i.e. due to lack of data), but I
>> attach part of the report that was sent to National Instruments:
>> -phase offset of the received signal in relation to digital waveform for
>> a single X310 with UBX160 for all TX and RX combinations:
>> https://imgur.com/a/ODBtT4o
>> -schematic:
>> https://imgur.com/a/si9fJZp
>>
>> I got also scripts that were used for recording and plotting that
>> figure. If you are interested I can post it somewhere.
>>
>> What seems different from situation here is that for us it seemed the
>> effect wasn't depending on frequency (but I didn't do any extensive
>> tests and might not remember).
>>
>> -- 
>> Best Regards,
>> Piotr Krysik
>>
>> W dniu 07.04.2019 o 03:00, Freedman, Michael - 1008 - MITLL via
>> USRP-users pisze:
>>> I have switched and am currently running the release 3.14.0.0
>>>
>>> Sent from my iPhone
>>>
>>> On Apr 6, 2019, at 8:58 AM, Marcus D. Leech >> <mailto:patchvonbr...@gmail.com>> wrote:
>>>
>>> On 04/05/2019 11:43 AM, Michael R. Freedman wrote:
>>>> Hello,
>>>>
>>>>
>>>> If I remove the DSP from the equation by setting the DSP tuning
>>>> policy to manual and assigning it to zero, I am coherent from tx to
>>>> rx on all frequencies.  I'm now beginning to think that the DSP is
>>>> doing it's tuning differently for tx and rx.  Or there is an
>>>> accumulated error in opposite directions for both.  Thoughts?
>>>>
>>>>
>>>> Leaving the DSP to zero is not a good solution however as there is
>>>> too much LO leakage.
>>>>
>>>>
>>> Could you try UHD 3.14.0.0?
>>>
>>> I think that you're using the -rc3 version at the moment.
>>>
>>>
>>>> Mike
>>>>
>>>>
>>>> On 03/27/2019 04:58 PM, Marcus D. Leech wrote:
>>>>> On 03/27/2019 04:48 PM, Michael R. Freedman wrote:
>>>>>> This is on a single UBX card within a single USRP.
>>>>>>
>>>>>>
>>>>>> ./uhd_usrp_probe --args=addr=192.168.40.100
>>>>>> [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
>>>>>> UHD_3.14.0.0-0-unknown
>>>>>> [INFO] [X300] X300 initialization sequence...
>>>>>> [INFO] [X300] Maximum frame size: 8000 bytes.
>>>>>> [INFO] [X300] Radio 1x clock: 200 MHz
>>>>>> [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
>>>>>> 0xF1F0D000)
>>>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1320 MB/s)
>>>>>> [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1294 MB/s)
>>>>>> [INFO] [0/Radio_0] Initializing block control (NOC ID:
>>>>>> 0x12AD1001)
>>>>>> [INFO] [0/Radio_1] Initializing block control (NOC ID:
>>>>>> 0x12AD1001)
>>>>>> [INFO] [0/DDC_0] Initializing block control (NOC ID:
>>>>>> 0xDDC0)
>>>>>> [INFO] [0/DDC_1] Initializing block control (NOC ID:
>>>>>> 0xDDC0)
>>>>>> [INFO] [0/DUC_0] Initializing block control (NOC ID:
>>>>>> 0xD0C0)
>>

Re: [USRP-users] Phase after Freq Hopping

2019-03-15 Thread Piotr Krysik via USRP-users

W dniu 12.03.2019 o 17:49, Patscheider, Dominik via USRP-users pisze:
>
> Hello ,
>
>  
>
> For a Radar I´m transmitting and receiving with the USRP X310 samples
> on different frequency steps.
>
>  
>
> For instance, after 4 frames I´m coming back to the first center freq
> and continue this a few times. Hope the following description helps…
>
>  
>
> f3       |phase4|   |…|
>
> f2      |phase3|   |…|
>
> f1       |phase2|   |phase6|   …
>
> f0    |phase1|   |phase5|
>
>     t -->
>
> According to the freq adjust every frame starts with a new phase.
>
> Phase 1 ≠Phase 5
>
>  
>
> Is there any possibility to get the same phase after returning to the
> same center freq? Phase 1=Phase 5, Phase 2 = Phase 6,…
>
>  
>
>
Hi Dominik,

Can you describe what you want to achieve exactly? Probably you need to
know phase relations because you want to do coherent processing of the
signal. But from your description I don't know:
-why on your ASCII art the signals transmitted on different frequencies
seems to be overlapped?
-which you part of it you want to process coherently?

I also often use USRPs for radar transmissions. Issues with predicting
initial phase difference of the received signal, in relation to digital
waveform that is being transmitted, are much easier to overcome when you
use timed commands to set the frequencies on Rx and Tx side
synchronously (if you use UBX or SBX daughter-boards).

Best Regards,
Piotr Krysik


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

[USRP-users] Adjusting VCTCXO of B210 with use of AD9361 DAC output

2019-04-21 Thread Piotr Krysik via USRP-users

Hello all,

I'm trying to implement better synchronization for SDR base GSM mobile
station (wiki of the project:
https://osmocom.org/projects/osmocom-bb-sdr-phy/wiki).

Currently the mobile station computes clock offset and applies
correction in software to a fractional resampler, in order to achieve
more accurate sample frequency synchronization in relation to a GSM BTS.
However doing this in software is still a bit awkward. It would be much
simpler (in terms of implementation and in terms of computations) to
have the correction applied at the hardware level. For example Lime chip
based designs (like LimeSDR or XTRX) have a DAC attached between FPGA
and VCTCXO, so it is possible to directly adjust the clock source frequency.

I noticed that AD9361 has DACs for controlling stuff and started to
think how to connect it to the VCTCXO tune input. Then I looked at the
B210 schematic and noticed there actually is a path from one of these
DAC outputs to the VCTCXO, but disconnected with use of missing R118
resistor:
schmatic: https://imgur.com/a/cgTfJ5G
pcb: https://imgur.com/a/NYhYxAb

My questions:
1. Is it possible to put a resistor (with some correct resistance) in
R118 place and not break AD9361 or ADF4001 or any other chip on B210?
2. If not - do you know what other circuit modifications might be needed?
3. Does anyone have experience with adjusting VCTCXO frequency though
AD9361 DAC (this is probably question to B210 designer)?

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] Adjusting VCTCXO of B210 with use of AD9361 DAC output

2019-04-23 Thread Piotr Krysik via USRP-users

W dniu 22.04.2019 o 18:17, Sylvain Munaut pisze:
> Hi Piotr,
> 
> The main issue is that the AUX DAC output swing is between 0.5v and 1V
>  (i.e. VDD_GPO-0.3v).
> That's not the right range at all to control the VCXO meaningfully.
> 
> Cheers,
> 
> Sylvain
> 

Thanks Sylvain for the answer. It's probably not worth the effort to
create some circuit that will amplify that DAC output - especially every
user would have to do this as well.

USRP B200mini looks much more appealing in comparison. Just checked the
schematics and it has separate DAC connected to the FPGA, intended for
controlling VCTCXO. I need to learn how to control it.

--
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] Problems with USRP X300 + PCI-Express Desktop Kit + Ubuntu 18.04

2019-04-17 Thread Piotr Krysik via USRP-users

Hi Nicola,

I just had exactly the same issue with UHD 3.14.0.0-72. Upgrading to
full 3.14 release of UHD (top of UHD-3.14 branch) solved the issue for me.

Best Regards,
Piotr Krysik

W dniu 04.02.2019 o 14:42, Michailow, Nicola via USRP-users pisze:
>
> Hi,
>
>  
>
> I am trying to connect a USRP X300 (1x UBX) to a PC using the
> PCI-Express Desktop Kit and I would like to ask for some help trying
> to make sense of the errors described below.
>
>  
>
...
> sdr@sdr-fujitsu-pc:~$ sudo /usr/local/lib/uhd/examples/benchmark_rate
> --rx_rate=100e6 --args resource=RIO0
>
>  
>
>   [INFO] [UHD] linux; GNU C++ version 7.3.0; Boost_106501;
> UHD_3.14.0.0-85-g33233e5c
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [00:00:00.11] Creating the usrp device with: resource=RIO0...
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [X300] X300 initialization sequence...
>
>   [INFO] [X300] Connecting to niusrpriorpc at localhost:5444...
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [X300] Using LVBITX bitfile
> /usr/local/share/uhd/images/usrp_x300_fpga_XG.lvbitx...
>
>   [INFO] [NIRIO] rpc_client stopping...
>
>   [INFO] [NIRIO] rpc_client stopped.
>
>   [INFO] [X300] Radio 1x clock: 200 MHz
>
>   [INFO] [GPS] No GPSDO found
>
>   [INFO] [0/DmaFIFO_0] Initializing block control (NOC ID:
> 0xF1F0D000)
>
>   [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1313 MB/s)
>
>   [INFO] [0/DmaFIFO_0] BIST passed (Throughput: 1315 MB/s)
>
>   [INFO] [0/Radio_0] Initializing block control (NOC ID:
> 0x12AD1001)
>
>   [INFO] [0/Radio_1] Initializing block control (NOC ID:
> 0x12AD1001)
>
>   [INFO] [0/DDC_0] Initializing block control (NOC ID: 0xDDC0)
>
>   [INFO] [0/DDC_1] Initializing block control (NOC ID: 0xDDC0)
>
>   [INFO] [0/DUC_0] Initializing block control (NOC ID: 0xD0C0)
>
>   [INFO] [0/DUC_1] Initializing block control (NOC ID: 0xD0C0)
>
>   [ERROR] [UHD] Exception caught in safe-call.
>
>     in max287x::~max287x() [with max287x_regs_t =
> max2871_regs_t]
>
>     at
> /home/sdr/nicola/uhd/host/lib/include/uhdlib/usrp/common/max287x.hpp:475
>
>   shutdown(); -> EnvironmentError: IOError: Block ctrl (CE_01_Port_40)
> packet parse error - EnvironmentError: IOError: Expected packet index:
> 1016 Received index: 1080
>
>  
>
...

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

Re: [USRP-users] Unable to detect X310 over pcie

2019-07-23 Thread Piotr Krysik via USRP-users

Hi all,

I have the same issue. I've checked everything in different computer
(disk with particular Ubuntu 16.04 installation, PCIexpress card and
PCIe cable) and everything worked fine.

What was left was that caused the issue was particular
motherboard+processor. I don't know if it is just this one but I suppose
the issue might be common to motherboards that have the same components
(i.e. PCIe controller or bridge) as this one. I'm attaching the result
of lspci.

Kailash, can you attach yours (and anyone who's got the same issue)?
Maybe we'll find a common element.

Best Regards,
Piotr Krysik


W dniu 11.06.2019 o 08:55, kailash kumar via USRP-users pisze:
> Hi,
>
> I am unable to detect X310 over pcie. I have installed uhd(v3.14.0.0)
> and compiled and installed RIO drivers as well. Below is my configuration:
>
> UHD RIO Installer version:
> niusrprio-installer-18.0.0
>
> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ sudo
> niusrprio_pcie start
> Making sure drivers are up to date...
> Module nikal is up-to-date
> Module nibds is up-to-date
> Module nistreamk is up-to-date
> Module NiRioSrv is up-to-date
> Module niusrpriok is up-to-date
> Loading: NiRioSrv niusrpriok
> Starting: niusrpriorpc
>
> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ lsmod |
> grep -i ni
> niusrpriok            417792  0
> NiRioSrv              942080  0
> nistreamk             131072  2 niusrpriok,NiRioSrv
> nibds                  57344  2 niusrpriok,NiRioSrv
> nikal                  98304  4 niusrpriok,NiRioSrv,nistreamk,nibds
>
> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ uname -r
> 4.19.48-48.lts2018
>
> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ ls /dev/ni/
> 'nistreamk:0\nistreamk\0'
>
> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ sudo
> netstat -anp| grep 5444
> tcp        0      0 0.0.0.0:5444           
>  0.0.0.0:*               LISTEN      1845/niusrpriorpc  
>
> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$
> uhd_usrp_probe --args "type=x300,resource=RIO0"
> [INFO] [UHD] linux; GNU C++ version 9.1.1 20190605
> gcc-9-branch@271943; Boost_106800; UHD_3.14.0.HEAD-0-g6875d061
> [ERROR] [UHD] Device discovery error: input stream error
> Error: LookupError: KeyError: No devices found for ->
> Device Address:
>     type: x300
>     resource: RIO0
>
> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 uhd]$ git status
> HEAD detached at v3.14.0.0
>
> Digging through uhd code
> lib/usrp/x300/x300_impl.cpp (x300_find_pcie ) ->  
> lib/usrp/x300/x300_impl.cpp
> (niusrprio_session::enumerate(rpc_port_name, dev_info_vtr)) ->
> lib/transport/nirio/niusrprio_session.cpp
> (nirio_status_chain(temp_rpc_client.niusrprio_enumerate(device_info_vtr),
> status)) ->  
> lib/transport/nirio/rpc/usrprio_rpc_client.cpp
>  (usrprio_rpc_client::niusrprio_enumerate(NIUSRPRIO_ENUMERATE_ARGS))
>
> out_args >> status; -> This returns status as -52012
>
> Thanks
> Kailash
>
> 

00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM 
Registers (rev 07)
00:01.0 PCI bridge: Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core 
Processor PCIe Controller (x16) (rev 07)
00:02.0 VGA compatible controller: Intel Corporation Device 3e92
00:12.0 Signal processing controller: Intel Corporation Cannon Lake PCH Thermal 
Controller (rev 10)
00:14.0 USB controller: Intel Corporation Cannon Lake PCH USB 3.1 xHCI Host 
Controller (rev 10)
00:14.2 RAM memory: Intel Corporation Cannon Lake PCH Shared SRAM (rev 10)
00:16.0 Communication controller: Intel Corporation Cannon Lake PCH HECI 
Controller (rev 10)
00:17.0 SATA controller: Intel Corporation Cannon Lake PCH SATA AHCI Controller 
(rev 10)
00:1c.0 PCI bridge: Intel Corporation Device a33d (rev f0)
00:1c.6 PCI bridge: Intel Corporation Device a33e (rev f0)
00:1f.0 ISA bridge: Intel Corporation H370 Chipset LPC/eSPI Controller (rev 10)
00:1f.3 Audio device: Intel Corporation Cannon Lake PCH cAVS (rev 10)
00:1f.4 SMBus: Intel Corporation Cannon Lake PCH SMBus Controller (rev 10)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Lake PCH SPI 
Controller (rev 10)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (7) I219-V 
(rev 10)
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express 
Gen 2 (5.0 GT/s) Switch (rev ba)
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI Express 
Gen 2 (5.0 GT/s) Switch (rev ba)
04:00.0 Ethernet controller: Intel Corporation I211 Gigabit Network Connection 
(rev 03)
05:00.0 Network controller: Intel Corporation Dual Band Wireless-AC 3168NGW 
[Stone Peak] (rev 10)
00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM 
Registers (rev 07)
DeviceName: Onboard - Other
Subsystem: ASRock Incorporation Device 3ec2
Flags: bus master, fast devsel, latency 0
Capabilities: 

00:01.0 PCI bridge: Intel Corporation Xeon E3-1200

Re: [USRP-users] Unable to detect X310 over pcie

2019-07-23 Thread Piotr Krysik via USRP-users

Hi again,

In addition to the previous post: in one of the posts about this issue
(there are many, but without solution) I've found result of lspci.

It was in the post titled "X310 PCIe Error enumerating NI-RIO devices":

00:00.0 Host bridge: Intel Corporation Device 591f (rev 05)
00:01.0 PCI bridge: Intel Corporation Device 1901 (rev 05)
00:02.0 VGA compatible controller: Intel Corporation Device 5912 (rev 04)
00:14.0 USB controller: Intel Corporation Device a12f (rev 31)
00:16.0 Communication controller: Intel Corporation Device a13a (rev 31)
00:17.0 SATA controller: Intel Corporation Device a102 (rev 31)
00:1c.0 PCI bridge: Intel Corporation Device a114 (rev f1)
00:1d.0 PCI bridge: Intel Corporation Device a118 (rev f1)
00:1d.1 PCI bridge: Intel Corporation Device a119 (rev f1)
00:1f.0 ISA bridge: Intel Corporation Device a143 (rev 31)
00:1f.2 Memory controller: Intel Corporation Device a121 (rev 31)
00:1f.4 SMBus: Intel Corporation Device a123 (rev 31)
01:00.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba)
02:01.0 PCI bridge: PLX Technology, Inc. PEX 8608 8-lane, 8-Port PCI
Express Gen 2 (5.0 GT/s) Switch (rev ba)
03:00.0 Signal processing controller: National Instruments PXIe/PCIe Device
06:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 15)

What is suspicious to me is the common "PLX Technology, Inc. PEX 8608"
PCIe bridge sold by Broadcom. I don't know yet if it has anything to do
with USRP connection.

Best Regards,
Piotr Krysik


W dniu 23.07.2019 o 11:26, Piotr Krysik via USRP-users pisze:
> Hi all,
>
> I have the same issue. I've checked everything in different computer
> (disk with particular Ubuntu 16.04 installation, PCIexpress card and
> PCIe cable) and everything worked fine.
>
> What was left was that caused the issue was particular
> motherboard+processor. I don't know if it is just this one but I suppose
> the issue might be common to motherboards that have the same components
> (i.e. PCIe controller or bridge) as this one. I'm attaching the result
> of lspci.
>
> Kailash, can you attach yours (and anyone who's got the same issue)?
> Maybe we'll find a common element.
>
> Best Regards,
> Piotr Krysik
>
>
> W dniu 11.06.2019 o 08:55, kailash kumar via USRP-users pisze:
>> Hi,
>>
>> I am unable to detect X310 over pcie. I have installed uhd(v3.14.0.0)
>> and compiled and installed RIO drivers as well. Below is my configuration:
>>
>> UHD RIO Installer version:
>> niusrprio-installer-18.0.0
>>
>> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ sudo
>> niusrprio_pcie start
>> Making sure drivers are up to date...
>> Module nikal is up-to-date
>> Module nibds is up-to-date
>> Module nistreamk is up-to-date
>> Module NiRioSrv is up-to-date
>> Module niusrpriok is up-to-date
>> Loading: NiRioSrv niusrpriok
>> Starting: niusrpriorpc
>>
>> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ lsmod |
>> grep -i ni
>> niusrpriok            417792  0
>> NiRioSrv              942080  0
>> nistreamk             131072  2 niusrpriok,NiRioSrv
>> nibds                  57344  2 niusrpriok,NiRioSrv
>> nikal                  98304  4 niusrpriok,NiRioSrv,nistreamk,nibds
>>
>> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ uname -r
>> 4.19.48-48.lts2018
>>
>> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ ls /dev/ni/
>> 'nistreamk:0\nistreamk\0'
>>
>> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$ sudo
>> netstat -anp| grep 5444
>> tcp        0      0 0.0.0.0:5444 <http://0.0.0.0:5444>          
>>  0.0.0.0:*               LISTEN      1845/niusrpriorpc  
>>
>> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 Downloads]$
>> uhd_usrp_probe --args "type=x300,resource=RIO0"
>> [INFO] [UHD] linux; GNU C++ version 9.1.1 20190605
>> gcc-9-branch@271943; Boost_106800; UHD_3.14.0.HEAD-0-g6875d061
>> [ERROR] [UHD] Device discovery error: input stream error
>> Error: LookupError: KeyError: No devices found for ->
>> Device Address:
>>     type: x300
>>     resource: RIO0
>>
>> [pretlist@clr-85a7812169e346e6b143a228fe1b9641 uhd]$ git status
>> HEAD detached at v3.14.0.0
>>
>> Digging through uhd code
>> lib/usrp/x300/x300_impl.cpp (x300_find_pcie ) ->  
>> lib/usrp/x300/x300_impl.cpp
>> (niusrprio_session::enumerate(rpc_port_name, dev_info_vtr)) ->
>> lib/transport/nirio/niusrprio_session.cpp
>> (nirio_status_chain(temp_rpc_client.niusrprio_enumerate(device_info_vtr),
>> status)) ->  
>> lib/transport/nirio/rpc/usrprio_rpc_client.cpp
>>  (usrprio_rpc_client::niusrprio_enumerate(NIUSRPRIO_ENUMERATE_ARGS))
>>
>> out_args >> status; -> This returns status as -52012
>>
>> Thanks
>> Kailash
>>


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

48 matches

Mail list logo