Friday, May 17, 2024

Re: Discuss-gnuradio Digest, Vol 259, Issue 8

Thank you, Michael!

On May 17, 2024, at 14:34, Michael West <michael.eric.west@gmail.com> wrote:

Hi Walter/Moses,

I spent the last 10 years developing the UHD code for all the USRP devices, including the B210.  I can tell you definitively that there is no "pps_locked" sensor and the "ref_locked" sensor is valid for any clock source (internal, external, or onboard GPSDO) and it indicates that the PLL on the device is locked.  The "gps_locked" sensor indicates a lock to the GPS constellation when a GPSDO is installed on the device.  Just about any GPSDO devices will typically produce 10 MHz and PPS signals before the internal PLL is locked and regardless whether it is locked to a GPS constellation or not (it must for holdover mode when satellites are not visible).  The Octoclock-G has a 1GbE port and offers the "gps_locked" and "gps_time" sensors.  NMEA strings are available through the "gps_gpgga", "gps_gprmc", and "gps_servo" sensors on the Octoclock or onboard GPSDO modules.

Regards,
Michael E. West

On Fri, May 17, 2024 at 2:13 PM walter <walter@hacktuary.ai> wrote:
Hi Moses et al - 

I spend a lot of time working with B210s on a shared 10MHz clock and PPS source:  

  • Some cheap GPSDO products, e.g. from EBay, work - but it's not clear if they're using BeiDou (or other system) as opposed to (US) GPS, and 
  • Many that advertise 'four clock channels' actually have two square-wave signals paired with two sine wave signals - effectively two, not four, clock signals.
  • Given the price difference and value of my time, I broke down and got an NI Octoclock-G, which works great and has eight (each) PPS / Clock ports.   
  • For your use case, the $220 GPSDO EBay PPS/clocks may be fine - Mfr also claims you can special order a four-square-wave version. 
    • The main drawback with (my) $220 EBay GPSDO is having a single port for the (TTL) PPS signal: in practice,  providing the PPS signal to more than one radio requires creating a DIY ('distribute it yourself') circuit for the PPS - this can be sub-optimal, as discussed below.

Regarding 'lock':
  • I'm 98% certain that any USRP  `pps_locked` / `ref_locked` register is only valid when using an internal GPSDO for the B210 or higher-end units that have internal GPSDO - see 'caveat'. 
  • In this context 'lock' refers to lock-on-satellite, which is a property of the PPS/Clock unit, not the radio. 
  • The clock and pps signals are square waves / pulses, and do not have a method of coding lock status in the signal. 
  • Any external GPS unit will have LED indicators for 'lock' status.   Check them early and often  :-)
  • My $220 EBay GPSDO will produce PPS and 10MHz signals when **not** locked to a GPS signal, hilarity ensues.   
  • The Octoclock-G has a separate 10Gbps(?) ethernet port that can report NMEA data, which I presume would indicate loss-of-lock.  Since the B210 isn't network-enabled, taking advantage of the NMEA info requires setting up additional hardware / software.  I haven't tried it yet.

When using an external GPSDO/clock/pps with the B210, the [UHD: USRP Source (or Sink)] block settings should be:

              Sync   [[ Unknown PPS ]]   ** see CAVEAT: Internal GPSDO
 Mb0: Clock Source   [[ External    ]]       
  Mb0: Time Source   [[ External    ]]

  • External reference signals are the 'source-of-truth' when attached - so 'attached' or 'not attached' is the only status your're likely to get from your B210.  
    • I once forgot to connect one of the PPS/Clock cables while using the above settings, and got errors due to lack of signal.
  • In general, when using clock / PPS source - and in particular when distributing to multiple B210s - it's important to use identical high-quality cables of equal length for both 10MHz and PPS to all radio units.  
    • Having different transmission-delays for PPS and 10MHz signals reduces accuracy - this is why 'distribute it yourself' can be sub-optimal.
 
** CAVEAT Internal GPSDO: The use case for  "Sync  [[GPS Time on Next PPS]]"  applies *only* if you installed the internal B210 GPSDO board, which disables the B210 from using a shared external clock of any kind.   

Hope this helps.

.-- W

---------------

On May 17, 2024, at 07:19, Moses Browne Mwakyanjala <mbkitine@gmail.com> wrote:

Hi Marcus,

The external 10MHz did the trick. I have another related question which I think we can address here without opening a new ticket. The USRP B210 has a 1PPS port. However, I was not able to poll the status of the time source, "pps_locked". When I searched for a list of all onboard sensors, the only visible sensor was "ref_locked". Am I missing something? How can I use and poll the status of 1PPS?

Regards, Moses



On Wed, May 15, 2024 at 6:04 PM <discuss-gnuradio-request@gnu.org> wrote:
Send Discuss-gnuradio mailing list submissions to
        discuss-gnuradio@gnu.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
or, via email, send a message with subject or body 'help' to
        discuss-gnuradio-request@gnu.org

You can reach the person managing the list at
        discuss-gnuradio-owner@gnu.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Discuss-gnuradio digest..."


Today's Topics:

   1. USRP B210 Frequency Offset (Moses Browne Mwakyanjala)
   2. Re: USRP B210 Frequency Offset (Marcus D. Leech)


----------------------------------------------------------------------

Message: 1
Date: Wed, 15 May 2024 11:52:27 +0200
From: Moses Browne Mwakyanjala <mbkitine@gmail.com>
To: GNURadio Discussion List <discuss-gnuradio@gnu.org>
Subject: USRP B210 Frequency Offset
Message-ID:
        <CABYsGdmPhq54WArSY--5-7renj3PFrAhTOWucE_RsS8YpQ-yVQ@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"

I've encountered a consistent frequency offset of around 2ppm with my new
B210. Operating at a sample rate of 4 MSPS with the "internal" clock, all
calibrations were performed using a sine wave from an Agilent signal
generator.

Though seemingly minor, the 800Hz offset at UHF poses challenges in
receiving low-rate data from orbiting satellites. Is there an automated
method to approximate and mitigate this offset? Currently, I manually
adjust the frequency by subtracting the offset in ppm. However, I'm curious
if there are more sophisticated solutions available, excluding reliance on
GPS or a 10MHz reference.

Best regards,
Moses

[image: image.png]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/3082954d/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 33653 bytes
Desc: not available
URL: <https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/3082954d/attachment.png>


No comments:

Post a Comment