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
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:
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
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:
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.
The text was updated successfully, but these errors were encountered:
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:
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:
muondetector/source/daemon/src/qtserialublox_processmessages.cpp
Lines 618 to 645 in 1f94441
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.
The text was updated successfully, but these errors were encountered: