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 <[email protected]>
> 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 <[email protected]
> <mailto:[email protected]>> wrote:
>> Send Discuss-gnuradio mailing list submissions to
>> [email protected] <mailto:[email protected]>
>>
>> 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
>> [email protected]
>> <mailto:[email protected]>
>>
>> You can reach the person managing the list at
>> [email protected]
>> <mailto:[email protected]>
>>
>> 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 <[email protected]
>> <mailto:[email protected]>>
>> To: GNURadio Discussion List <[email protected]
>> <mailto:[email protected]>>
>> Subject: USRP B210 Frequency Offset
>> Message-ID:
>> <cabysgdmphq54warsy--5-7renj3pfrahtowuce_rss8ypq-...@mail.gmail.com
>> <mailto: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>
