SatNOGS received timestamps have strange precise behaviour

I’m a satellite operator (FrontierSat). Huge fan of SatNOGS!

In the SatNOGS Data Exports (from SatNOGS DB – the ones that get emailed to you), can someone explain what the timestamp column means? They sometimes seem to align very closely with the timestamps from the satellite’s beacon packets (after a fresh time sync), but sometimes there’s several beacons that have the same SatNOGS timestamp, and sometimes the packets are out-of-order.

It almost seems to vary by ground station. Has it recently changed between client versions?

1 Like

screenshot pls

The timestamp in the exported frames file is the reception time of the frame as set by the ground station. From my experience, however not fully researched and analyzed, the accuracy of the timestamp may vary from some (milli-)seconds to a couple of minutes in SatNOGS Network stations, unfortunately I have no idea for 3rd party observers.

Unfortunately for some months we had an issue that affected some Network’s stations and made them to send frames with wrong timestamps (not UTC time but local time timestamp). You can read more about it in Important bug-fix for SatNOGS Network stations with version >2.0.0. Maybe this could be the reason of seeing frames out-of-order.

With more details, for example from which stations you got out-of-order data, is this consistent etc, we may be able to analyze this situation and find out what causes this problem.

2 Likes

Thanks Fredy, that clarification helps a lot.

Looking at this from the satellite-operations side, I would avoid treating the exported SatNOGS timestamp as the spacecraft event time.

I would rather see it as reception metadata: “this is when this ground station reported receiving/decoding this frame”, with all the caveats that come with station configuration, client version, time sync, upload path, and so on.

For an operations dataset I would try to keep a few things separate:

  • the timestamp inside the beacon, if the spacecraft provides one
  • the spacecraft frame counter / sequence counter, if available
  • the onboard time-sync state
  • the SatNOGS observation id
  • the station id
  • the SatNOGS reception timestamp

Then the ordering rule becomes a conscious choice instead of an implicit assumption.

For example, if a frame counter is available, I would probably trust that first for ordering frames from the spacecraft. If the beacon has an onboard timestamp, I would only trust it as event time if the packet also gives enough confidence that the onboard clock was actually valid at that moment.

The SatNOGS timestamp is still very useful, but I would use it mainly as ground-side evidence: which station saw the frame, during which observation, and at what reported reception time.

That also makes strange cases easier to debug. If frames look duplicated or out of order, I would first check whether the effect is station-specific, whether it matches a local-time/UTC offset, whether it only happens for certain observations, and whether the spacecraft counter still behaves monotonically.

The UTC/local-time issue you linked is a good example of why this matters. The RF reception may be perfectly good, while the metadata around the received frame can still affect how the mission team interprets the data later.

So, practically, I would not collapse everything into one “timestamp” field in the FrontierSat processing pipeline. I would preserve the reception context around each frame and only derive a mission-level event time after applying explicit rules.

3 Likes

Would you mind posting what these exports look like?

As far as I know, anyone with an account can export the data (e.g., from https://db.satnogs.org/satellite/GGCH-4346-1583-9419-5634#data).

Sample attached here for convenience of any onlookers.

I’ve asked over in that other thread what client versions are affected by the bug. Will see how closely it correlates to the weirdness.

GGCH-4346-1583-9419-5634-5862-20260529T214541Z-all.csv (438.5 KB)

A minimal way of looking at the strangeness is to filter to frames starting with “C2A28A0001” (that is, all beacon packets). Beacons on FrontierSat are nominally sent 20-21 seconds apart (or a multiple thereof). There are many cases where the beacon packets show with SatNOGS Timestamps of <2 seconds apart.

2 Likes