Your problem interested me enough that I went digging a little into the public INSPIRESat-1 / DAXSS code, and I think the raw SatNOGS frames could actually give you something more useful than just a large set of ground timestamps.
I found two things that may be relevant.
First, the public INSPIRESat-1 decoder exposes both the CCSDS secondary-header time (sh_coarse / sh_fine) and the DAXSS-specific daxss_time_sec field in the same beacon.
Then, in the DAXSS processing code itself, is1_daxss_beacon_read_packets.pro explicitly notes that the spacecraft time is “seconds since turn-on” and that DAXSS time, expressed in GPS seconds, should be used as the reference.
There is also an existing analysis script called plot_daxss_time_offset.pro whose purpose is literally to investigate DAXSS time offsets. It looks like the DAXSS team has already dealt with non-trivial timing corrections in the processing chain in the past.
That made me think that, once you get the raw frames, I would probably not start with only:
SatNOGS receive time - DAXSS time
I would first try to compare the rate of the two onboard clocks inside the same packets.
For two sufficiently separated beacons:
ΔSC = spacecraft_time_2 - spacecraft_time_1
ΔDAXSS = daxss_time_2 - daxss_time_1
and then inspect:
ΔDAXSS - ΔSC
over the mission, obviously splitting the data around spacecraft resets/reboots.
If that residual develops a slope, you have a fairly clean indication of relative drift between the DAXSS clock and the spacecraft clock, without yet involving ground-station clock accuracy, NTP/PPS quality, propagation delay, etc.
Then I would use the SatNOGS reception timestamp as the third reference and look at:
SatNOGS_rx_time - DAXSS_time
preferably grouped by station and by pass. That should help distinguish a genuine long-term onboard trend from station-dependent timing offsets.
So I think your request for the raw frames, rather than only an exported timestamp/DAXSS-time table, is actually quite important: keeping the CCSDS time fields, sequence counter and DAXSS time gives you more diagnostic leverage.
You may already have gone through this, but I thought it was worth mentioning because the existing DAXSS code suggests that timing offsets have been investigated before, and the SatNOGS beacon seems to contain enough information to separate at least part of the problem.
The script I found is here:
daxss_library/analysis/plot_daxss_time_offset.pro
I’d be very curious to see what the residuals look like once you have access to the full frame set.