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

[Moses Browne Mwakyanjala]

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  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-requ...@gnu.org
>
> You can reach the person managing the list at
> discuss-gnuradio-ow...@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 
> To: GNURadio Discussion List 
> Subject: USRP B210 Frequency Offset
> Message-ID:
> <
> cabysgdmphq54warsy--5-7renj3pfrahtowuce_rss8ypq-...@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
> >
>
> --
>
> Message: 2
> Date: Wed, 15 May 2024 09:10:13 -0400
> From: "Marcus D. Leech" 
> To: discuss-gnuradio@gnu.org
> Subject: Re: USRP B210 Frequency Offset
> Message-ID: 
> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
> On 15/05/2024 05:52, Moses Browne Mwakyanjala wrote:
> > 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
> The on-board clock on a B210 is good to about 2.5PPM.  So, it's working
> as you would expect.
>
> There's nothing built in to the UHD API for this, because normally, if
> you care about clock accuracy beyond what the internal clock
>can supply, you use an external, better, clock.   GPSDOs are not very
> expensive these days, and you can pick up used
>10MHz OCXO units fairly cheaply as well...
>
>
> >
> > image.png
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/db078ea5/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/db078ea5/attachment.png
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> Discuss-gnuradio mailing list
> Discuss-gnuradio@gnu.org
> https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
>
>
> --
>
> End of Discuss-gnuradio Digest, Vol 259, Issue 8
> 
>

Re: Bursty transmissions with X310?

[Michael West]

Hi Ben,

The SOB signal is essentially ignored by the USRP Sink block.  If data is
sent, the SOB is assumed and data is transmitted even if the SOB is not
set..  TX samples not intended to be transmitted must not be sent to the
USRP Sink block.  The EOB, as Phillip pointed out, tells the USRP Sink not
to expect any more data so underruns are not detected.

Regards,
Michael E. West

On Thu, May 16, 2024 at 6:54 AM Ben Wiederhake
 wrote:

> Dear Philipp,
>
> thanks for your response!
>
> > from my experience with bursty transmissions the EOB tags are more to
> > tell the USRP to not expect any further samples (and not to scream
> > Underruns), rather than to switch of the transmission.
>
> Switching off the transmission is precisely what I want to do, in fact.
> If the TX path is still actively driving the antenna (to 0 V, to +1 V,
> to -1 V, doesn't matter), the RX sensitivity of the antenna is
> necessarily very bad. This RX/TX switch alone makes a difference of
> (very roughly) 20-30 dB in RX signal strength.
> So I really want to switch off that TX path.
>
> > I once implemented a custom "burst copy" block for this purpose as I
> > couldn't find one in the core lib [2] and this works well for my use
> > case (meanwhile i am using RFNoC which does not handle tx_eob tags, but
> > stopping the stream still works well).
> >
> > To time it, the sample with SOB should be delayed or have a "tx_time"
> > tag too.
>
> Thanks! I've tried to avoid the tx_time tag until now, so I'll
> experiment a bit based on your code and the tx_time tag.
>
> I was really hoping the USRP Sink would do all that "by itself". The
> timing is already implied by each sample's index in the sample stream,
> so the tx_time approach seemed like unnecessary effort to me, but
> apparently I'm overlooking something. I'll try it now.
>
> If you (or someone else) has any other ideas, or can tell me what I
> might be missing or doing wrong, I'm all ears.
>
> > If you don't rely on precise timing, you can also simply set the samples
> > between EOB and SOB to zero to achieve what you want I guess.
>
> I already tried that; this just leads to the TX path still being active,
> leading to the 20-30 dB loss I mentioned earlier.
>
> With regards,
> Ben Wiederhake
>
>

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

[Michael West]

Hi Moses,

The PPS input is just a trigger that is used to set the time on the
device.  There is nothing for it to lock to and currently nothing that
detects the presence of the signal.  Setting the clock and time source on
the USRP Sink/Source blocks to external and the Sync to "unknown PPS" will
sync the device time to the PPS signal.  More directly, you can use the
set_time_next_pps() and set_time_unknown_pps() methods to set the time on
the device to a specific time.

Regards,
Michael E. West

On Fri, May 17, 2024 at 7:21 AM Moses Browne Mwakyanjala 
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  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-requ...@gnu.org
>>
>> You can reach the person managing the list at
>> discuss-gnuradio-ow...@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 
>> To: GNURadio Discussion List 
>> Subject: USRP B210 Frequency Offset
>> Message-ID:
>> <
>> cabysgdmphq54warsy--5-7renj3pfrahtowuce_rss8ypq-...@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
>> >
>>
>> --
>>
>> Message: 2
>> Date: Wed, 15 May 2024 09:10:13 -0400
>> From: "Marcus D. Leech" 
>> To: discuss-gnuradio@gnu.org
>> Subject: Re: USRP B210 Frequency Offset
>> Message-ID: 
>> Content-Type: text/plain; charset="utf-8"; Format="flowed"
>>
>> On 15/05/2024 05:52, Moses Browne Mwakyanjala wrote:
>> > 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
>> The on-board clock on a B210 is good to about 2.5PPM.  So, it's working
>> as you would expect.
>>
>> There's nothing built in to the UHD API for this, because normally, if
>> you care about clock accuracy beyond what the internal clock
>>can supply, you use an external, better, clock.   GPSDOs are not very
>> expensive these days, and you can pick up used
>>10MHz OCXO units fairly cheaply as well...
>>
>>
>> >
>> > image.png
>> -- next part --
>> An HTML attachment was scrubbed...
>> URL: <
>> https://lists.gnu.org/archive/html/discuss-gnuradio/attachments/20240515/db078ea5/attachmen

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

[walter]

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  
> 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  > 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-requ...@gnu.org 
>> 
>> 
>> You can reach the person managing the list at
>> discuss-gnuradio-ow...@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 > >
>> To: GNURadio Discussion List > >
>> Subject: USRP B210 Frequency Offset
>> Message-ID:
>> > >
>> Content-Type: text/plain; charset="utf-8"
>> 
>> I've encountered a c

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

[Michael West]

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  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 
> 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  wrote:
>
>> Send Discuss-gnuradio mailing list submissions to
>> discuss-gnuradio@gnu.org
>>
>> To subscribe or unsubscribe via the World Wide Web,

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

[walter]

Thank you, Michael!

> On May 17, 2024, at 14:34, Michael West  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  > 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 >> > 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