[USRP-users] 2x N200 GPSDO PPS relative drift

[Stephan Esterhuizen via USRP-users]

Hi All,

I have two N200 USRPs with Jackson-Labs Firefly 1A GPSDO. I'm doing a very
basic test, where I have a common active GPS antenna split 2 ways (with DC
block on one N200 GPS antenna port). I then watch the 1PPS from each GPSDO
on a scope, and unfortunately see the PPS drift by as much as 14
microseconds per second relative to each other. When this offset reaches
about 1.5-2.0 milliseconds, I see the PPS relative offset "snap" down to a
few micro seconds error, but then they immediately start drifting apart
again.

The N200 GPSDO reports they're locked. I wrote some quick python code to
query sensors:

--
FIRST N200:
--
[INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev
0.929
[INFO] [USRP2] Setting references to the internal GPSDO
GPS lock status: locked
GPS_GPGGA:
$GPGGA,095011.00,.x,N,.x,E,1,10,0.9,320.7,M,46.9,M,,*6C
GPS_SERVO: 18-11-09 3888 94089 21.81 2.08E-11 13 10 6 0x0
GPS epoch time: 1541757012 seconds
Ref: locked


--
SECOND N200
--

[INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev
0.929
[INFO] [USRP2] Setting references to the internal GPSDO
GPS lock status: locked
GPS_GPGGA:
$GPGGA,095027.00,.x,N,.,E,1,08,1.1,317.9,M,46.9,M,,*63
GPS_SERVO: 18-11-09 2948 12 796.02 9.59E-09 13 8 2 0x326
GPS epoch time: 1541757029 seconds
Ref: locked



At this point, it might be a question for Jacksonlabs, since I'm not really
using any N200 functions except for reading back the Ublox GPS NMEA strings.

Has anyone seen this kind of behavior before?

I'm suspecting the GPS_SERVO field might shed some light, but don't quite
know how to read it.

Thanks for any pointers

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

[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 
> 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] 2x N200 GPSDO PPS relative drift

[Robin Coxe via USRP-users]

Hi Stephan.  Your issue looks similar to one that has been previously
reported.   The Hardware Sustaining Engineering team is currently
investigating.

Would it be possible for you to try powering the GPSDO module from a lab
supply instead of plugging it in to the N210 motherboard and checking if
your issue still persists?
That would help us determine if you are experiencing the same problem.
Another helpful measurement would be to measure the voltage drop of the 6V
wall wart when the GPSDO IS powered by the N210 motherboard.

We will keep you and list updated on the progress of the investigation.

-Robin


On Fri, Nov 9, 2018 at 3:06 AM Stephan Esterhuizen via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Hi All,
>
> I have two N200 USRPs with Jackson-Labs Firefly 1A GPSDO. I'm doing a very
> basic test, where I have a common active GPS antenna split 2 ways (with DC
> block on one N200 GPS antenna port). I then watch the 1PPS from each GPSDO
> on a scope, and unfortunately see the PPS drift by as much as 14
> microseconds per second relative to each other. When this offset reaches
> about 1.5-2.0 milliseconds, I see the PPS relative offset "snap" down to a
> few micro seconds error, but then they immediately start drifting apart
> again.
>
> The N200 GPSDO reports they're locked. I wrote some quick python code to
> query sensors:
>
> --
> FIRST N200:
> --
> [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev
> 0.929
> [INFO] [USRP2] Setting references to the internal GPSDO
> GPS lock status: locked
> GPS_GPGGA:
> $GPGGA,095011.00,.x,N,.x,E,1,10,0.9,320.7,M,46.9,M,,*6C
> GPS_SERVO: 18-11-09 3888 94089 21.81 2.08E-11 13 10 6 0x0
> GPS epoch time: 1541757012 seconds
> Ref: locked
>
>
> --
> SECOND N200
> --
>
> [INFO] [GPS] Found an internal GPSDO: Jackson-Labs, FireFly , Firmware Rev
> 0.929
> [INFO] [USRP2] Setting references to the internal GPSDO
> GPS lock status: locked
> GPS_GPGGA:
> $GPGGA,095027.00,.x,N,.,E,1,08,1.1,317.9,M,46.9,M,,*63
> GPS_SERVO: 18-11-09 2948 12 796.02 9.59E-09 13 8 2 0x326
> GPS epoch time: 1541757029 seconds
> Ref: locked
>
> 
>
> At this point, it might be a question for Jacksonlabs, since I'm not
> really using any N200 functions except for reading back the Ublox GPS NMEA
> strings.
>
> Has anyone seen this kind of behavior before?
>
> I'm suspecting the GPS_SERVO field might shed some light, but don't quite
> know how to read it.
>
> Thanks for any pointers
>
> Stephan
> ___
> 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] Test clock syncronization

[Sneha vasan via USRP-users]

I am currently trying to check synchronization of usrp b210 device  using
octoclock.

So when I am trying to execute ./test_clock_synch which is included in
examples, I am seeing the following error,
why it is not able to detect device?
Can anybody tell me how I can do this??


:/usr/local/lib/uhd/examples$ ./test_clock_synch --usrp-args serial=313FA99
linux; GNU C++ version 5.4.0 20160609; Boost_105800;
UHD_003.010.001.HEAD-0-gc705922a


Creating the Clock device with:
Error: LookupError: KeyError: No devices found for ->
Empty Device Address


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

Re: [USRP-users] Test clock syncronization

[Marcus D. Leech via USRP-users]

On 11/09/2018 11:13 AM, Sneha vasan via USRP-users wrote:
I am currently trying to check synchronization of usrp b210 device  
using octoclock.


So when I am trying to execute ./test_clock_synch which is included in 
examples, I am seeing the following error,

why it is not able to detect device?
Can anybody tell me how I can do this??


:/usr/local/lib/uhd/examples$ ./test_clock_synch --usrp-args 
serial=313FA99
linux; GNU C++ version 5.4.0 20160609; Boost_105800; 
UHD_003.010.001.HEAD-0-gc705922a



Creating the Clock device with:
Error: LookupError: KeyError: No devices found for ->
Empty Device Address


Regards



You'll need to give the address of your Octoclock as well.




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

Re: [USRP-users] N310 time offset between TX RF Outputs

[Serge Malo via USRP-users]

Hi all,

I have made another test today, I want to report the results here.

*Issue #1*
I have modified the tx_timed_samples example, simply such that it transmits
on both channels of the X300.
Using a frequency of 1.57542GHz for both channels, I was able to measure on
a scope a time offset of 320ns between RF A and RF B.
Technically, Ettus R&D should be able to reproduce this offset easily.

*Issue #2:*
Yesterday, I wrote that "timed commands" seemed to be broken with UHD
3.13.1.0 RC1. Here are more details:
"timed samples" do work correctly with the UHD example tx_timed_samples.
However, "timed samples" do not work with the UHD example benchmark_rate.
You can reproduce the problem this way, on a X300, connected to an
Octoclock:
1) Change the value of INIT_DELAY to 5.0s
2) Recompile benchmark_rate, and try this command:
./benchmark_rate --args addr=192.168.40.2 --tx_rate=2500 --tx_cpu=sc16
--ref=external --pps=external --channels=0,1

You will see that the TX starts immediately, instead of at time 5.0s.

Please, let us know if you aware of those issues, and if you need help to
reproduce or investigate them.

Best regards,
Serge


On Thu, 8 Nov 2018 at 23:59, Marcus D. Leech via USRP-users <
usrp-users@lists.ettus.com> wrote:

> On 11/08/2018 03:13 PM, Serge Malo via USRP-users wrote:
>
> Hi all,
>
> Thanks for the extra comments Mark.
>
> Just to be clear: I'm not talking about phase offset between RF Outputs,
> but only time offset.
> (Once time offset is fixed, we will try to have phase-coherent RF outputs).
>
> I have made other measurements today, here are the results.
> I'm transmitting a signal at 1.57542GHz, and a second signal at 1.2276GHz.
> Sample Rate on N310: 25.6Msps (MCR of 153.6Mhz)
> Sample Rate on X300: 25.0Msps (MCR of 200Mhz)
> Using External Clock and External PPS from Octoclock
> 1) Using X300 (RF A and RF B) and UHD 3.10.3.0, we see les than 3ns time
> offset (See image here: link
> 
> )
> 2) Using X300 (RF A and RF B) and UHD 3.13.1.0 RC1, we see 7300us time
> offset (See image here: link
> 
> )
> 3) Using N310 (RF 0 and RF 2) and UHD 3.13.1.0 RC1, we also see 7300us
> time offset.
>
> Important: the "timed commands" seem to be broken in UHD 3.13.1.0, either
> for X300 or N310.
> When we change the time_spec of the first "send" call, the time at which
> the samples are transmitted does not change. For example, I tried to set
> tie_spec to 10s, but the Tx starts right away. This was working correctly
> with UHD 3.10.3.0
>
> Let me know if you have ideas I could try.
>
> Best regards,
> Serge
>
> Serge:
>
> The fact that this affects both X310 and N310 is a bit disturbing--the
> device-side codebase is quite different on the two boxes.  I'm engaging
>   Ettus R&D internally to see if this can be reproduced.
>
>
>
>
> On Thu, 8 Nov 2018 at 14:44, Mark Wagner  wrote:
>
>> Here's a google drive link with images of the phase drift between rx4 and
>> tx 1&2, and tx 3&4
>>
>> https://drive.google.com/open?id=1Bg6F0WHzzwVhpFBlrlfqJgpGg9JtTczH
>>
>> On Thu, Nov 8, 2018 at 11:32 AM Mark Wagner 
>> wrote:
>>
>>> Hi guys,
>>>
>>> Maybe I could jump in and share some related results. My group has been
>>> developing a MIMO system with N310 units. We did a test sounding recently
>>> where we sent 4, length 4096, orthogonal multitone signals from the
>>> transmitters to the receivers and processed the data by finding the channel
>>> response between each transmitter and receiver pair (16 in total) and
>>> recording the magnitude and phase of the arrival spikes between each pair.
>>>
>>> We took several seconds of data and processed it in length 4096 chunks
>>> (around 1500 chunks in total) and looked at the phase difference between
>>> transmitter pairs as time progressed. Since transmitters 1 and 2 are
>>> sharing an LO and our setup was not moved during the sounding we expected
>>> to see a constant phase difference between transmitters 1 and 2 and a
>>> single receiver (same with tx 3 and 4), but we saw some drift. Worse yet,
>>> not all LO sharing pairs drifted in the same way, some didn't drift much at
>>> all while some drifted in linear or non-linear patterns.
>>>
>>> If you're all fine with me breaking the rules I can attach some png
>>> images of what we recorded so you can see what it looks like. Later this
>>> week we'll repeat the experiment but leave the machines running longer to
>>> see if the drift diminishes as the machines run longer.
>>>
>>> Cheers,
>>> -Mark
>>>
>>>
>>>
>>>
>>>
>>> On Thu, Nov 8, 2018 at 9:03 AM Daniel Jepson via USRP-users <
>>> usrp-users@lists.ettus.com> wrote:
>>>
 Hi Serge,

 Are you measuring the phase offset between the TX0 and TX2 signals in a
 steady-state case, or the time difference in the start of those signals?

 In the former case, your results could be im

Re: [USRP-users] Ettus x310 shutoff delay when using low sample rate

[Michael West via USRP-users]

The delay is from the time it takes to drain the DMA FIFO.  The DMA FIFO
default size is 32 MB.  It can be controlled through the property tree or,
if using RFNoC, through the DMA FIFO block control.  The time to drain is a
simple function of size and sample rate.

We have been making improvements in the clearing/flushing during
initialization, but there may still be some bugs to work out.

Regards,
Michael

On Tue, Oct 30, 2018 at 8:36 AM Daniel May via USRP-users <
usrp-users@lists.ettus.com> wrote:

> Marcus,
>
> Thanks for the info. Waiting is what we do now, but it's not ideal.
>
> The "skip_dram=1"argument fixes the issue for low sample rates, but causes
> underflows for higher sample rates, as expected.
>
> Thanks,
> Daniel
>
>
>
> On Tue, Oct 30, 2018 at 10:25 AM Marcus D. Leech via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> On 10/30/2018 10:42 AM, Daniel May via USRP-users wrote:
>>
>> Is there a way to query the amount of data in the FIFO so that I can wait
>> until it clears?
>>
>> I don't believe so.
>>
>> You could simply wait an amount of time, based on empirical data, that is
>> commensurate with your sample rate.
>>
>> But the whole "the next run causes fatal errors" thing does need to be
>> investigated, I agree.
>>
>>
>>
>> On Tue, Oct 30, 2018 at 9:37 AM Rob Kossler  wrote:
>>
>>> The DRAM is 2GB, I think.
>>>
>>> On Tue, Oct 30, 2018 at 10:34 AM Daniel May 
>>> wrote:
>>>
 Thanks, I'll give that a try. I thought it might be the FIFO clearing,
 but it takes longer than I would expect. There's only 512kB of FIFO,
 correct? It takes up to several seconds to finish at a 1 Msps rate.

 Restarting the radio before Tx completes causes the radio to enter an
 unrecoverable error state. This is a UHD or Firmware bug, correct?

 Thanks,
 Daniel

 On Tue, Oct 30, 2018 at 9:12 AM Rob Kossler  wrote:

> It sounds like the DMA FIFO is just emptying out.  For fast sample
> rates, the FIFO empties quickly, but for slow sample rates, it empties
> slowly.  Perhaps you could supply the arg "skip_dram=1" so that the
> streaming goes directly to the DUC rather than through the FIFO.  This 
> will
> probably work fine for slow sample rates (i.e., perhaps a FIFO is not
> needed for such rates).
> Rob
>
> On Mon, Oct 29, 2018 at 4:17 PM Daniel May via USRP-users <
> usrp-users@lists.ettus.com> wrote:
>
>> All,
>>
>> Can anyone else reproduce this issue and/or suggest a solution?
>>
>> This is happening over the Ethernet interface as well. Application
>> exits, Tx light stays on, relaunching application causes X310 to enter an
>> unrecoverable state and requires power cycling. It looks like an issue 
>> with
>> initializing DMA. Tested using v3.13.0.1.
>>
>> Thanks,
>> Daniel
>>
>> On Wed, Oct 10, 2018 at 10:55 AM Andrew Toomey via USRP-users <
>> usrp-users@lists.ettus.com> wrote:
>>
>>> All,
>>>
>>>
>>>
>>> I am using an Ettus x310 over PCIe and am noticing that there is a
>>> delay from when my program finished sending to the radio and when the 
>>> radio
>>> tells me that transmission as ended ( the red Tx light turning off).
>>>
>>> As I bump up the sample rate I notice this delay decreases until it
>>> is nonexistent. Is this intended behavior or have I done something 
>>> wrong in
>>> my tests? The procedure to test this is listed below:
>>>
>>>
>>>
>>> 1.   Download a copy of the official UHD example scripts from
>>> https://github.com/EttusResearch/uhd/tree/master/host/examples
>>>
>>> 2.   Ensure that UHD is installed correctly on your testing
>>> device and build the example programs above
>>>
>>> 3.   Run the following command “ ./tx_waveforms - -rate=100
>>> - -freq=15
>>>
>>> 4.   Stop the program at any time (how long the radio is
>>> running does not affect the delay)
>>>
>>> 5.   Observe the radio and notice that the red light under the
>>> Tx/Rx port is still lit on the RF A channel
>>>
>>> 6.   If you start another transmission while the light is still
>>> red, the console output contains hundreds of thousands of L’s and the 
>>> radio
>>> will not receive data until the USRP object is recreated.
>>>
>>>
>>>
>>> I am also curious if there is a hard stop functionality for this
>>> radio. All the examples I have seen send an End of Burst packet but is
>>> there a way to completely halt the radio without doing this?
>>>
>>>
>>>
>>> Thanks for the help!
>>>
>>> Andrew
>>> ___
>>> USRP-users mailing list
>>> USRP-users@lists.ettus.com
>>> http://lists.ettus.com/mailman/listinfo/usrp-users_lists.ettus.com
>>>
>>