sat: use hubble_internal_time_drift_get() for drift compensation#197
sat: use hubble_internal_time_drift_get() for drift compensation#197ceolin wants to merge 2 commits into
Conversation
Add an internal API to compute the device drift based on TDR to shift computed pass start back by half the drift window in hubble_next_pass_get(). Signed-off-by: Flavio Ceolin <flavio@hubble.com>
github-actions
Bot
requested review from
HongNguyen635,
buckleypaul and
hunterhubble
HongNguyen635
left a comment
HongNguyen635
left a comment
There was a problem hiding this comment.
Just 1 minor comment, otherwise this looks good to me.
Split the single pass timestamp into `start` and `culmination` so callers know both when to begin transmitting and when the satellite is overhead. The pass duration is now derived from the satellite transmission period (base retries + drift-compensation retries times the retransmission interval), exposed via the new hubble_internal_sat_transmission_period_get() helper. The drift compensation previously applied only in hubble_next_pass_get() is now also applied in hubble_next_pass_region_get() for consistency. Signed-off-by: Flavio Ceolin <flavio@hubble.com>
| transmission_period_s = | ||
| hubble_internal_sat_transmission_period_get() / 1000U; | ||
|
|
||
| pass->duration += transmission_period_s; |
There was a problem hiding this comment.
I feel like I'm missing sometihng. This somehow doesn't feel right to me. For region, we already have the duration that sat passes over a region right? hubble_internal_sat_transmission_period_get will give you the number of retries. But this total retries is not right. Aren't we supposed to somehow do this:
total retries = duration / retries_period?
For single point prediction, it makes sense to call hubble_internal_sat_transmission_period_get, but for a region, we know that the retries period (even with no clock drift) is 160s, and the duration for a region could be longer than that.
Since we don't control the transmission period for region, I feel like the math for single point prediction doesn't apply here.
There was a problem hiding this comment.
We don't know the number of retries but we need to accommodate the situation were the device is located in the boundary of the region, if the device is in the boundary we can't simply wake up in the culmination time. This applies the same semantics, splitting the period of a single point transmission between the beginning and end the of the region. Remember that we calculate the duration based on the culmination time of when the sat enters and exits the region.
There was a problem hiding this comment.
right you mentioned about the culmination time and I keep forgetting that the time sat enter/exit is at culmination. This makes sense then.
2 participants
Add an internal API to compute the device drift based on TDR to shift computed pass start back by half the drift window in hubble_next_pass_get().