Message "Out of scope timestamp"

FlightAware ADS-B Flight Tracking
1

Morning all,

i saw just by chance on my Airsquitter in the Piaware log this message:

[2022-02-19 08:42 CET] mlat-client(404): Out-of-order timestamps: 1

Anything to consider or is this just a normal message coming up from time to time?
So far i can’t see any issues with the feed

2

This message will appear when there are not enough stations to synchronize MLAT with. When you get this message it usually will not state the number of stations it is synchronizing with on the status page. The longer it takes, the higher the counter will increment.
It will recover automaticly so no action needed (from my own expierence).

3

That’s wrong, nothing to do with the server.
It means the timestamps received by mlat-client from your receiver stepped backwards (0.2.11 of mutabilities mlat-client at least).
It’s expected to be increasing monotonically.

Might be the 24h GPS clock rollover, or hoever long that takes to roll over. Not sure if this will give a message or is catered for.

4

I learn something everyday on this forum, thank you.

I see the message in relation to a test site in my setup that loses MLAT sometimes and related that to the message.
Due to the test site (cheap reciever for testing purposes) it sometimes loses the sync with it’s neighbours, it has nothing to do with the serverside indeed.

5

Well on dump1090-fa 7 you really shouldn’t see that message otherwise something is wrong i believe.

                if (adjust <= timestamp) {
                    timestamp = timestamp - adjust;
                } else {
                    /* wrap it to the previous day */
                    timestamp = timestamp + 86400 * 1000000000ULL - adjust;
                }

                /* check for end of day rollover */
                if (self->want_events && self->last_timestamp >= (86340 * 1000000000ULL) && timestamp <= (60 * 1000000000ULL)) {
                    if (! (messages[message_count++] = make_epoch_rollover_event(self, timestamp)))
                        goto out; 
                } else if (self->want_events && type != '1' && !timestamp_check(self, timestamp)) {
                    if (! (messages[message_count++] = make_timestamp_jump_event(self, timestamp)))                                                                                            
                        goto out; 
                }

        /* check for very out of range value
         * (dump1090 can hold messages for up to 60 seconds! so be conservative here)
         * also work around dump1090-mutability issue #47 which can send very stale Mode A/C messages
         */
        if (self->want_events && message_len != 2 && !timestamp_check(self, timestamp)) {
            if (! (messages[message_count++] = make_timestamp_jump_event(self, timestamp)))                                                                                                    
                goto out;
        }

/* check if the given timestamp is in range (not a jump), return 1 if it is */
static int timestamp_check(modesreader *self, unsigned long long timestamp)                                                                                                                    
{
    if (is_synthetic_timestamp(timestamp))
        return 1;

    if (self->last_timestamp == 0)
        return 1;

    if (self->frequency == 0)
        return 1;

    if (self->last_timestamp > timestamp && (self->last_timestamp - timestamp) > 90 * self->frequency)
        return 0;

    if (self->last_timestamp < timestamp && (timestamp - self->last_timestamp) > 90 * self->frequency)
        return 0;

    return 1;
}

relevant code.

6

So i’ll go back on my previous statements, it not only complains for going backwards.

    if (self->last_timestamp > timestamp && (self->last_timestamp - timestamp) > 90 * self->frequency)
        return 0;

    if (self->last_timestamp < timestamp && (timestamp - self->last_timestamp) > 90 * self->frequency)
        return 0;

So this would trigger for example when you don’t receive anything for 90 seconds.
MLAT can’t sync with ADS-B messages.

But there can also be voltage issues of the voltage going to the SDR … or other USB issues which cause the mlat server to time you out.
But that usually doesn’t show via these messages.

1 Like
7

Thanks, would be an explanation.
Just checked the GPS log and it returned this:

19-02-2022 07:28:10(t) GPS stable for 10 seconds
19-02-2022 07:28:10(T) Time status changed to GPS

The device had an unexpected reboot at this time and the GPS signal required to synchronize again.
Maybe that’s the relation.

8

Thanks,

The reciever does only pick up on short range contacts so I wil ltry to see if there’s nothing picked up next time it reports this error.
Power issues on that pi have been checked and not reported.

9

This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.