As a previous poster has stated each adsb transmission is time stamped. I don't profess to know how FR24 aggregates its data (if indeed it does) but I can't see any advantage in them changing the transmitted timestamp. with multiple receivers/listeners I would expect that the first to reach FR24's server is used and the others discarded. The bottom line is that for each transmission received by FR24 the data will be correct for that timestamp.

Wanabee777 I would say the opposite, but they are an accountants aeroplane and gutless when heavy.I flew an A321 yesterday on a similar length route and the time to top of climb ((FL320) was over thirty minutes.

Air Crash Investigation, Russia Style!
 

From Associated Press via the New York Times:

(My emphasis added.)

Probably initially max REC would have been somewhere around FL330 so FL320 would be optimum, so if unavailable then FL300 is plausible. Then step up to 340/360 later enroute.

As others have said the 321 is gutless, surprisingly so.

aa73, you should refer to previous posts.

@engineless
 

from your source:

"An important note about the csv file. Rows are in time order based on when data was processed from each receiver and not necessarily in chronological order."

ADS-B does not have a native timestamp (ie one transmitted as part of the data packet).

Obviously at the point of reception one can be added by the receiver software and/or by the server that subsequently processes the data - but it doesn't originate from the aircraft and so cannot be assumed to be consistent between different receiving stations.

Do you notice that the starboard wing is inverted. Flap tracks clearly seen, and leading edge slat partially out, may be post crash damage must have fallen flat all there except wing tip fence.Then look at the photo of nose section has crush damage from below, yet the tail section is upright.

Source: https://twitter.com/Conflicts

Means nothing.

It's just how a journalist desires to use words.

The FAA also sieze records in the event of an accident. As do many other authorities.

Interpreting FR24 Data
 

I'm not an aviation professional (though I have performed engineering work on an IFR trainer and ground support systems for military avionics).

But I do know something about time series of discretely sampled data, and forensic analysis of sampled data records.

ADS was never intended to substitute for the FDR (we all know that, but ...).

ADS data can give a quite accurate portrayal of aircraft dynamics under conditions of near steady-state, or smooth gradual variation.

But the nature of these samples, as collected by FR24, makes them highly error-prone during sudden and extreme variations, such as the accident flight evidently experienced.

In recent years, we have seen cases in which the FR24 data indicated dramatic jumps in parameter values, which proved to be highly erroneous when compared with more reliable information.

Some commenters have already pointed out that certain sensors on which the ADS reports are based can give skewed readings under extreme conditions.

A big spike in the numbers is a reliable indication of ... a big spike in the numbers. Does it reveal what the aircraft was physically doing? Maybe ... maybe not.
_____________________________________________________

I have just confirmed that ADS-B (Downlink Format 17) does NOT include a time stamp, as others here have reported.

Accordingly, it seems that the FR24 time stamps are assigned by the FR24 receiving point and may be in error by one second or more.

This has some very important consequences. For one, FR24 samples sorted by time stamp might not correspond to the order in the aircraft sent the reports!

Also, it obviously means that any dynamic rate-of-change computation based on comparison of (supposedly) successive samples can be in error by hundreds (or even thousands) or percent.

Using such data to infer the dynamics of an airframe in a gross upset or other extreme maneuver is like ... walking blindfold while suffering vertigo.

Most Internet-connected PCs are synchronized to time.windows.com, which is not NTP.

Windows Time Service is "guaranteed" to only within five minute accuracy, although in practice it's usually accurate to within one minute on relatively modern PCs with reliable network connections.

ADS-B does not have a message timestamp, so typically the receiver hardware/software will add one or more timestamps.

There is no room in the 1090ES DF17 message format to transmit a full timestamp. More precise timing & location info requires both the transmitter and receiver to independently synchronize to UTC. There is a 1-bit flag in the DF17 format to indicate whether or not the transmitter is coupled to UTC.

I'm not an expert but if ADS-B does not have a native timestamp what is the point of including positional information if there is no time associated with it? why would that be done?

Only the last picture showing the fuselage is genuine, the others posted earlier in the thread are from Algeria 2014. I did point this out earlier, quoting the posts and giving the model and time of the crash, however quite rightly my post was 'moderated' and the pictures to which you quote are still here.

niether the crash site nor the data shown are consisent with an airframe drilling into the ground.

not in the timeframe from the data

You can easily work it out. the data shows at one stage a 25 deg heading change in something like 2 seconds.

So case closed ? No need for an investigation then ?

Topcliffe Kid, because there is no need with ADS-B. Its typically transmitted as part of 1090Mhz Extended Squitter. The box is interrogated, then sent back straight away. There is no latency. Same as ACAS (TCAS II) signals, same as Mode S.

The difference with ACARS is that there are significant latencies from how the signal is transmitted over VHF (POA, VDL Mode 2 or 4) or SATCOM, handled by a communications service provider, then re-transmitted to either an ops centre or ATC centre. There is not direct connection, so you need a timestamp in order to determine when exactly the message was sent.

This doc does a good job of explaining how busy the 1030Mhz and 1090 Mhz frequencies are and what is involved with Secondary surveillance and the like

Based upon the many pictures here:

Russia Plane Crash Debris Found in Egypt's Sinai Desert - NBC News

I don't see any sign of an explosive decompression. Admittedly, the pictures are not complete but I think it not probable that a bomb or a missile brought this plane down.

I can't get a real sense of the debris field so I can't comment of the the mid-flight break-up. I will say that the structural forces shown in this limited sample of debris suggest a flatter landing. The fact the tail is relatively intact suggest either the nose hit first or the tail broke off in flight.

edit: I also will note that on picture four that break looks clean, which may support the structural failure of the tail theory. Any structural engineers care to opine on that issue?

Normally both the transmitter and receiver are synchronized to UTC, so there is no need to send the time in the actual message.

Assuming the transmitter is coupled to UTC, it will send ADS-B messages in 0.2 second time slots. E.g, at 17:00:00.0, 00.2, 00.4, etc. The position sent will be interpolated to match these 200ms slots. E.g., at 00.35, the transmitter will calculate where the plane will be at 00.4, and then actually send the message out at 00.4. The receiver will do the reverse and determine the correct position and time to 200ms resolution.

If the transmitter is not coupled to UTC, the receiver accepts the position at the receiver's "current time".

There is one bit in the DF17 format that's used to determine if the transmitter is UTC-coupled or not.

Pax here. Can ask if it was day/ night with a clear horizon?

@Mr Optimistic
See picture in this thread of vis at the time...
Crash: Metrojet A321 over Sinai on Oct 31st 2015, disappeared from radar in climb over Sinai