Timestamps off by ~2.5 hours, use_gnss_time does nothing

[Victorsoeby]

I am currently running the driver, and trying to do some time synchronization. First and foremost, i need the Septentrio to output correct timestamps, which it isn't at the moment. I have set the use_gnss_time: true which from my understanding should take the time i get from the satellites, and use this as the timestamp in the header of all the ROS messages that the driver creates.

This is not the case however, as when i do a "ros2 topic echo /pvtgeodetic --field header" i get something like this:

---

stamp:
sec: 1731667491
nanosec: 800000000
frame_id: gnss

stamp:
sec: 1731667491
nanosec: 900000000
frame_id: gnss

Where the actual UTC time is 1731659021, which means that the driver is publishing timestamps that are ~2.5 Hours into the future, at least if https://www.utctime.net/utc-timestamp is correct. Note that this experiment is done when i am outside, and i can see in the web-interface that i have established PVT.

I get the same effect when i start the driver indoors (where the web-interface says NO GNSS PVT), where i shouldn't have any timestamps at all, as i specifically tell it not to use the ROS timestamp.
Here is my ros2 param dump:

ros2 param dump /septentrio_gnss_driver
/septentrio_gnss_driver:
ros__parameters:
activate_debug_log: false
ant_aux1_serial_nr: Unknown
ant_aux1_type: Unknown
ant_serial_nr: Unknown
ant_type: Unknown
att_offset:
heading: 0.0
pitch: 0.0
aux1_frame_id: aux1
configure_rx: true
custom_commands_file: ''
datum: Default
device: tcp://192.168.3.1:28784
frame_id: gnss
get_spatial_config_from_tf: false
imu_frame_id: imu
ins_initial_heading: auto
ins_spatial_config:
ant_lever_arm:
x: 0.0
y: 0.0
z: 0.0
imu_orientation:
theta_x: 0.0
theta_y: 0.0
theta_z: 0.0
poi_lever_arm:
delta_x: 0.0
delta_y: 0.0
delta_z: 0.0
vsm_lever_arm:
vsm_x: 0.0
vsm_y: 0.0
vsm_z: 0.0
ins_std_dev_mask:
att_std_dev: 5.0
pos_std_dev: 10.0
ins_use_poi: false
insert_local_frame: false
latency_compensation: true
leap_seconds: -128
local_frame_id: odm
lock_utm_zone: true
login:
password: ''
user: ''
multi_antenna: true
ntp_server: true
ntrip_settings:
caster: ''
mode: ''
rx_has_internet: false
rx_input_corrections_serial: ''
rx_input_corrections_tcp: 0
osnma:
keep_open: true
mode: 'off'
ntp_server: ''
poi_frame_id: b_l
poi_to_arp:
delta_e: 0.0
delta_n: 0.0
delta_u: 0.0
polling_period:
pvt: 100
rest: 500
ptp_server_clock: false
publish:
aimplusstatus: true
attcoveuler: true
atteuler: true
auto_publish: false
basevectorcart: false
basevectorgeod: false
diagnostics: false
exteventinsnavcart: false
exteventinsnavgeod: false
extsensormeas: false
galauthstatus: false
gpgga: false
gpgsa: false
gpgsv: false
gprmc: false
gpsfix: true
gpst: false
imu: false
imusetup: false
insnavcart: false
insnavgeod: false
localization: false
localization_ecef: false
measepoch: false
navsatfix: false
poscovcartesian: false
poscovgeodetic: true
pose: false
publish_only_valid: false
pvtcartesian: false
pvtgeodetic: true
tf: false
tf_ecef: false
twist: false
velcovcartesian: false
velcovgeodetic: true
velsensorsetup: false
qos_overrides:
/parameter_events:
publisher:
depth: 1000
durability: volatile
history: keep_last
reliability: reliable
/tf:
publisher:
depth: 100
durability: volatile
history: keep_last
reliability: reliable
receiver_type: gnss
rtk_settings:
ip_server_1:
id: ''
ip_server_2:
id: ''
ip_server_3:
id: ''
ip_server_4:
id: ''
ip_server_5:
id: ''
ntrip_1:
caster:
caster_port:
id:
keep_open:
mountpoint:
password:
rtk_standard:
send_gga:
tls:
username:
version:
ntrip_2:
id: ''
ntrip_3:
id: ''
serial_1:
port: ''
serial_2:
port: ''
serial_3:
port: ''
serial_4:
port: ''
serial_5:
port: ''
serial:
baudrate: -1
hw_flow_control: 'off'
stream_device:
tcp:
ip_server: ''
port: -1
udp:
ip_server: ''
port: -1
unicast_ip: ''
use_gnss_time: true
use_ros_axis_orientation: true
use_sim_time: false
vehicle_frame_id: b_l
vsm_frame_id: vsm

[thomasemter]

Hi @Victorsoeby ,

I am sorry, but I could not reproduce your problem right away. On my system it shows correct stamps:

I observed that the time on the website you mentioned did drift off quite quickly. Maybe that could be the reason? I have good experiences with this site.

[thomasemter]

I also checked indoors and I get timestamps @ 0 with use_gnss_time = true and nothing is published if I additionally set publish.publish_only_valid to true as is intended.