Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Recovery of missing timestamps #57

Open
hangeza opened this issue Sep 2, 2021 · 0 comments
Open

Recovery of missing timestamps #57

hangeza opened this issue Sep 2, 2021 · 0 comments
Assignees
Labels
bug Something isn't working daemon Everything related to the daemon
Milestone

Comments

@hangeza
Copy link
Contributor

hangeza commented Sep 2, 2021

The UBXTimTM2 messages coming from the ublox receiver and containing the timestamps of the input signals at the ublox's interrupt pin are evaluated by the daemon and eventually sent out as data messages via MQTT. One such UBXTimTM2 message contains one timestamp for the rising edge and one for the falling edge, respectively, that occured during the last ublox measurement interval, i.e. 100ms in our case. Each edge is tagged with a "valid" bit to show that the edge actually occured.

Occasionally it happens that one of the two edges is missing (the valid bit is zero and the data field of the timestamp garbled in such cases) which may have the following reasons:

  1. Two pulses were incident during the measurement epoch of 100ms, where either the rising edge of the first pulse or the falling edge of the second puls was outside the epoch window. In this case, the falling edge appears to be before the rising edge, but both are valid
  2. One edge of a single pulse appeared in the current measurement epoch with the other one being outside. The valid flag will be unset for the "unseen" edge.

Assume that the rising edge is detected while the falling edge is not, because the pulse duration is long compared to the epoch interval, as in above case 2. This is actually the case, when the TIMEPULSE signal is selected for input (rate 1Hz, length 100ms).
The following code fragment in qtserialublox_processmessages.cpp is responsible for handling such cases, i.e. to recover a missing timestamp based on the information of the previously determined pulse length:

// try to recover the timestamp, if one edge is missing
if (!tm.risingValid && tm.fallingValid) {
tm.rising.tv_sec = tm.falling.tv_sec - lastPulseLength / 1000000000;
tm.rising.tv_nsec = tm.falling.tv_nsec - lastPulseLength % 1000000000;
if (tm.rising.tv_nsec >= 1000000000) {
tm.rising.tv_sec += 1;
tm.rising.tv_nsec -= 1000000000;
} else if (tm.rising.tv_nsec < 0) {
tm.rising.tv_sec -= 1;
tm.rising.tv_nsec += 1000000000;
}
} else if (!tm.fallingValid && tm.risingValid) {
tm.falling.tv_sec = tm.rising.tv_sec + lastPulseLength / 1000000000;
tm.falling.tv_nsec = tm.rising.tv_nsec + lastPulseLength % 1000000000;
if (tm.falling.tv_nsec >= 1000000000) {
tm.falling.tv_sec += 1;
tm.falling.tv_nsec -= 1000000000;
}
} else if (!tm.fallingValid && !tm.risingValid) {
// nothing to recover here; ignore the event
} else {
// the normal case, i.e. both edges are valid
// calculate the pulse length in this case
int64_t dts = (tm.falling.tv_sec - tm.rising.tv_sec) * 1.0e9;
dts += (tm.falling.tv_nsec - tm.rising.tv_nsec);
if (dts > 0 && dts < 1000000)
lastPulseLength = dts;
}

It is observed that in such cases, two timing messages are sent out by the daemon. One for the first UBXTimTM2 with only the rising edge, for which the falling edge is assumed to be by a time of pulse length later and one for the message with only the falling edge, where the rising edge is reconstructed to be by pulse length earlier.

The code should be modified such, that those dependent message-twins with the separated edges are detected and only one message with the combined info about the two time stamps is sent out.

@hangeza hangeza added bug Something isn't working daemon Everything related to the daemon labels Sep 2, 2021
@hangeza hangeza added this to the v2.1.0 milestone Sep 2, 2021
@hangeza hangeza self-assigned this Sep 2, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working daemon Everything related to the daemon
Projects
None yet
Development

No branches or pull requests

1 participant