My Groundstation clock vs Satellite clock

bali · September 27, 2026, 10:11am

i make new topic for this interesting case (for me )

i set up my ground station with time that source only from gnss pulse (PPS / gps clock). you can look the tutorial here

chronyc sources -v

  .-- Source mode  '^' = server, '=' = peer, '#' = local clock.
 / .- Source state '*' = current best, '+' = combined, '-' = not combined,
| /             'x' = may be in error, '~' = too variable, '?' = unusable.
||                                                 .- xxxx [ yyyy ] +/- zzzz
||      Reachability register (octal) -.           |  xxxx = adjusted offset,
||      Log2(Polling interval) --.      |          |  yyyy = measured offset,
||                                \     |          |  zzzz = estimated error.
||                                 |    |           \
MS Name/IP address         Stratum Poll Reach LastRx Last sample               
===============================================================================
#? GPS                           0   4   377    15   +135ms[ +135ms] +/-  101ms
#* PPS                           0   4   377    14  -1354ns[-2138ns] +/-  242ns

then my station decode the honghu-2 satellite, based on this community post

my station until i write this post , successfully decode this satellite on 2 observations
this and this

the decoded telemetry show the on board clock of satellites (i guess)

that time in unix timestamp. convert it

timestamp.py.txt (206 Bytes)

python3 timestamp.py 
Enter a Unix timestamp: 1790457916
2026-09-26 21:25:16 UTC

and what interesting , see the time when my gr_satellites decode this frame:

2026-09-26T21-25-14 UTC → my gs
2026-09-26 21:25:16 UTC → satellite

that is 2 second difference.

my groundstation 2 second faster than satellites time.

ok hold here.

i look on network, and found other satno that success decode , @PE0SAT 31 groundstation. on metadata these jan groundstation used airspy sdr. but i dont know if these using gpsdo or no. using ntp or pps as source clock. what i know , jan station that using gpsdo only station 21, but currently it not serve on freq 400 mhz.

on jan station, the gs clock and honghu clock is same

python3 timestamp.py 
Enter a Unix timestamp: 1790438892
2026-09-26 16:08:12 UTC

that make me confuse. what you think? maybe you can try it on your groundstation. i repost the satyaml here

name: HONGHU-2
norad: 58555
data:
  &tlm Telemetry:
    telemetry: csp
transmitters:
  19K2 FSK downlink:
    frequency: 401.6120e+6
    modulation: FSK
    baudrate: 19200
    deviation: 4800
    framing: AX100 ASM+Golay
    data:
    - *tlm

fredy · September 27, 2026, 10:39am

Two quick questions that may affect what you observe:

Is the satellite synced through GNSS?
When and how often is the satellite synced?

bali · September 27, 2026, 12:04pm

ah. good insight. thank you @fredy .

bali · September 27, 2026, 1:43pm

i found satellite clock on this observations from 69015 - FrontierSat

poke @platypus

the satellite clock is earlier around 25 s compare with my gs.

platypus · September 28, 2026, 5:33am

Well that’s pretty nifty, nice!

We’re pushing a firmware upgrade/addition to sync frequently from the onboard GNSS receiver to get more precise timing syncs. Helpful to know your station is a good one to check whether that’s working. I’ll check back in a week after it’s in use!

bali · September 30, 2026, 4:15am

Kostka satellite

1790738854 = 2026-09-30 03:27:34 UTC

platypus · October 2, 2026, 4:28pm

On FrontierSat - This observation (https://network.satnogs.org/observations/15092424/) shows a notable improvement regarding the time sync since we enabled GNSS time syncing every 10 minutes.

# Message body
1790909555000+0000524381_G [A:OBC:INFO]: Heartbeat: Datetime: 2026-10-02T030119.381Z_G, Uptime: 398295424 ms

# Data file with timestamp
data_obs/2026/10/2/2/15092424/data_15092424_2026-10-02T03-01-12_g0

# Full message hex data: c2a28a0003313739303930393535353030302b303030303532343338315f47205b413a4f42433a494e464f5d3a204865617274626561743a204461746574696d653a20323032362d31302d3032543033303131392e3338315a5f472c20557074696d653a20333938323935343234206d730aef2cc2b1

Note that the satellite’s report time vs. the SatNOGS reported time is off by 7 seconds; I think this might be a limitation/bug/feature in GNU Radio and the flowgraphs.

Now, if we look at it based on the recording start time and how far that log message is into the file:

# Recording start time:
2026-10-02 02:55:34

# Duration into ogg recording (based on askew_demod_from_file command)
"time_in_file_ms": 341177.917

# Recording start time (2026-10-02 02:55:34) + duration (341177.917)
2026-10-02 03:01:15.177 UTC

That’s only off by 4 seconds, so better. Still not great though - seems that the GNU Radio/SatNOGS architecture limitations strike again.

Here’s the decoder I mention: GitHub - parker-research/askew-radio-tools: DSP demodulator for AX100 Mode 5 radio packets, and more, written in Rust · GitHub

openlinkcustody · October 4, 2026, 11:02pm

Hi Bali, all, this thread made me try something: checking station clocks against each other, with no satellite clock involved.

When stations owned by different people decode the same frame, byte for byte, they heard the same transmission. Their receive times should agree to within milliseconds (plus SatNOGS’s 1-second timestamp resolution). So a station whose times are consistently away from the others probably has a clock offset.

I ran it on 12 hours of public SatNOGS data from today:

128 observations, 42 stations heard shared transmissions
281 transmissions decoded identically by 3 or more stations
almost every station agreed with the others at 0 seconds (within the 1 s resolution)
two stations were about 6 to 7 seconds off, but each was based on fewer than 10 frames, so that’s a hint to check, not a verdict
Two things that tripped me up, in case anyone tries this:

Many satellites repeat the exact same beacon bytes minutes later. You have to split those into separate transmissions, or you get fake offsets of hundreds of seconds.
With only two stations you can’t tell which clock is wrong, so it only uses transmissions heard by 3 or more, and solves all the offsets together so one wrong clock doesn’t shift its neighbours.
This complements what you’re doing: your GNSS-disciplined station is a good reference for the satellite clock, and this checks stations against each other. The script is open source (Apache-2.0) if you want to try it for your own station:

github.com/BSVKey/open-downlink-custody

bin/clocks.mjs

main

#!/usr/bin/env node
// Compare station clocks using frames that several stations decoded byte for byte.
//
//   node bin/clocks.mjs --run runs/<dir> [--run runs/<dir2> ...] [--gap 10] [--json]
//
// Reads the signed station receipts of one or more runs (verify them first with
// bin/verify.mjs if they came from someone else) and prints each station's offset
// from the consensus of the other stations that heard the same transmissions.
import { readdirSync, readFileSync } from "node:fs";
import { join } from "node:path";
import { compareClocks } from "../lib/clocks.mjs";

const argv = process.argv.slice(2);
const runs = [];
let gap = 10, json = false;
for (let i = 0; i < argv.length; i++) {
  if (argv[i] === "--run") runs.push(argv[++i]);
  else if (argv[i] === "--gap") gap = Number(argv[++i]);
  else if (argv[i] === "--json") json = true;
}

This file has been truncated. show original

If anyone wants a report for their station ID, reply here and I’ll run it.