You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently as seen from the LNS, we just have a gateway time with a precision at second, this is limiting the ability to understand and monitor performance for a LNS owner. It's also limiting our ability to debug the RX windows potential problem and creates a doubt on it.
I would like to propose two things:
1 - On HPR add a metadate like HPR_RX_TIMEMS containing the HPR ms time base reception timestamp for each frame
2 - Make Duration fine_time_since_gps_epoch populated by HPR from fine timestamp provided by the gateway (ms scale)
Rq about the 2, I don't know what gatewary-rs push to HPR and if we have this, we have such information for POC data, so potentially it could be in the packet sent to HPR.
The text was updated successfully, but these errors were encountered:
disk91
changed the title
Getting time information for monitoring the device fleet activity
Getting packet fine time information for services / travel-time monitoring purpose
Jan 12, 2024
Currently as seen from the LNS, we just have a gateway time with a precision at second, this is limiting the ability to understand and monitor performance for a LNS owner. It's also limiting our ability to debug the RX windows potential problem and creates a doubt on it.
I would like to propose two things:
1
- On HPR add a metadate likeHPR_RX_TIMEMS
containing the HPR ms time base reception timestamp for each frame2
- Make Durationfine_time_since_gps_epoch
populated by HPR from fine timestamp provided by the gateway (ms scale)Rq about the
2
, I don't know what gatewary-rs push to HPR and if we have this, we have such information for POC data, so potentially it could be in the packet sent to HPR.The text was updated successfully, but these errors were encountered: