Wrong timestamp sample for SensorGPS.msg

[adrianrr94-alt]

Greetings,

I am implementing an UKF for a drone with delay compensation and I realized that the field timestamp_sample of the message SensorGPS.msg looks incorrect, and thus I cannot fuse the updating correctly.
I have found the following issues:

1. There is a huge difference between the timestamp sample and the timestamp of the message.
2. The sample timestamp is the same in consecutive message, why is the data published again if it is the same sample?
3. The timestamp_sample is decreasing instead of increasing.

Please find below the output echoing the topic:

timestamp: 1716551917338873
timestamp_sample: 1716551400058872
device_id: 10813445
lat: 244364943
lon: 546138945
alt: 3191
alt_ellipsoid: -24508
s_variance_m_s: 0.11500000208616257
c_variance_rad: 0.7475395202636719
fix_type: 4
eph: 0.23800000548362732
epv: 0.3880000114440918
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.027000000700354576
vel_n_m_s: 0.027000000700354576
vel_e_m_s: 0.003000000026077032
vel_d_m_s: -0.015000000596046448
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107126750189
satellites_used: 28
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0

timestamp: 1716551917441887
timestamp_sample: 1716551400058872
device_id: 10813445
lat: 244364942
lon: 546138945
alt: 3168
alt_ellipsoid: -24531
s_variance_m_s: 0.1300000101327896
c_variance_rad: 0.7475398182868958
fix_type: 4
eph: 0.23800000548362732
epv: 0.3880000114440918
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.023000001907348633
vel_n_m_s: -0.01600000075995922
vel_e_m_s: 0.017000000923871994
vel_d_m_s: -0.01900000125169754
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107126875189
satellites_used: 27
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0

timestamp: 1716551917624890
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364942
lon: 546138944
alt: 3138
alt_ellipsoid: -24561
s_variance_m_s: 0.1080000028014183
c_variance_rad: 0.7475400567054749
fix_type: 4
eph: 0.23800000548362732
epv: 0.3880000114440918
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.024000000208616257
vel_n_m_s: 0.023000001907348633
vel_e_m_s: -0.007000000216066837
vel_d_m_s: -0.02500000037252903
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127000189
satellites_used: 28
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0

timestamp: 1716551917825881
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364942
lon: 546138943
alt: 3133
alt_ellipsoid: -24566
s_variance_m_s: 0.08100000023841858
c_variance_rad: 0.7475403547286987
fix_type: 4
eph: 0.24000000953674316
epv: 0.39100003242492676
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.04200000315904617
vel_n_m_s: -0.00800000037997961
vel_e_m_s: -0.04100000113248825
vel_d_m_s: -0.023000001907348633
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127250188
satellites_used: 28
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0

timestamp: 1716551917937042
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364943
lon: 546138943
alt: 3113
alt_ellipsoid: -24585
s_variance_m_s: 0.08100000023841858
c_variance_rad: 0.7475405335426331
fix_type: 4
eph: 0.24000000953674316
epv: 0.39100003242492676
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.04800000041723251
vel_n_m_s: 0.003000000026077032
vel_e_m_s: 0.04700000211596489
vel_d_m_s: 0.032999999821186066
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127375188
satellites_used: 27
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0

timestamp: 1716551918072862
timestamp_sample: 1716551400058863
device_id: 10813445
lat: 244364943
lon: 546138943
alt: 3107
alt_ellipsoid: -24592
s_variance_m_s: 0.09800000488758087
c_variance_rad: 0.7475407719612122
fix_type: 4
eph: 0.24000000953674316
epv: 0.3920000195503235
hdop: 0.7400000095367432
vdop: 1.0499999523162842
noise_per_ms: 62
automatic_gain_control: 0
jamming_state: 1
jamming_indicator: 13
spoofing_state: 1
vel_m_s: 0.030000001192092896
vel_n_m_s: 0.012000000104308128
vel_e_m_s: -0.02800000086426735
vel_d_m_s: 0.006000000052154064
cog_rad: 0.8297291398048401
vel_ned_valid: true
timestamp_time_relative: 0
time_utc_usec: 1718107127500188
satellites_used: 27
heading: .nan
heading_offset: 0.0
heading_accuracy: 0.0
rtcm_injection_rate: 0.0
selected_rtcm_instance: 0

I have been checking how the timestamp of the GPS is handled within the PX4 code, should I subtract to the timestamp the fix delay between the GPS and the IMU so it can be properly fused?

Thanks!