MH17

Информация о пользователе

Привет, Гость! Войдите или зарегистрируйтесь.


Вы здесь » MH17 » Крепость админа » Странный flightradar24


Странный flightradar24

Сообщений 151 страница 176 из 176

1

ОБНОВЛЕНО по результатам обсуждения темы на 27-06-2015

Хронология сообщений о позиции МН17, когда прекратилось поступление данных от ADS-B транспондера борта на сервер flightradar24:

- 17 июля, 19:00 мск - пользователь Angora_White на aviaforum.ru - территория РФ
- 17 июля, 19:35 мск - flightradar24 в своем twitter - район Кременчуга (380 км до места реального падения)
- 17 июля, 19:39 мск - flightradar24 в своем facebook - район Кременчуга (380 км до места реального падения)
- 17 июля, 20:26 мск - flightradar24 в своем facebook - район Торез-Снежное
- на текущий момент - архив данных flightradar24 - северная часть п. Снежное

Информация с российских ADS-B серверов о позиции прекращения данных транспондера МН17.

Данные flightradar24, российских ADS-B серверов на диаграмме.

Исходники для диаграммы (видео с flightradar24 playback):
http://www.youtube.com/watch?v=Tt92Ar0mTQs  - конечная позиция МН17 над лесным массивом восточнее Пелагеевки
http://www.youtube.com/watch?v=dGmmxGdusUw - конечная позиция МН17 над территорией РФ

Отметки flightradar24, российских ADS-B серверов и УВД РФ на карте местности в зоне катастрофы МН17

"Замешанные в деле" ADS-B приемники F-UKHH1 и F-UKCC1 на территории Украины.

Владелец приемника F-UKCC1 и возможности приемника по дальности (стр.2) и высоте (стр.3)

Примечание: На выложенных выше видео с flightradar24 playback видно, что данные с борта с позиции 49.32 33.57 начинают поступать через приемник F-UKHH1. Именно в этой позиции фр24 первоначально зафиксировал своими скринами в twitter и facebook отсутствие ADS-B данных от МН17.

Информация от Mike, владельца фр24:
RAW-данные из базы flightradar25:

https://pbs.twimg.com/media/BswkrwNIQAA6YT8.png

Mike 2014-07-28, 06:21
As stated many times now, the published data is the raw data from database and not from the web page.
Flightaware didn't have any data in this area. They have added one raw of data from unknown source manually afterwards (Они добавили одни RAW-данные от неизвестного источника вручную позже).
No matter how much we speculate, we will not get any answers before we have data from the black boxes.

То есть он сваливает, что Flightaware - г..., рисует вручную. Однако на вопрос о сомнительных данных своего приемника "radar id 5913" ссылается на какой-то предыдущий ответ, которого на форуме не существует:

Mike 2014-08-09, 19:27

Originally Posted by nakos
I agree that it seems strange that last position reported by FR24 is 22 km further ahead from debris field. Mike can you please confirm that "radar id 5913" means actual FR receiver in the area, not a codename for extrapolation bot:
https://pbs.twimg.com/media/BswkrwNIQAA6YT8.png

Please read for 4 posts up

Важный вывод (предварительный!) из всех "картинок" выше:
Онлайн-поступление данных в фр24 с МН17 прекратилось в районе Кременчуга, хотя ADS-B инфа с борта транслировалась вплоть до 13:20:03.
То есть, приемник F-UKHH1 (Сумы):
- или перестал передавать данные в фр24, хотя был включен и принимал их с борта, что подтверждается последующим появлением в базе фр24 данных по МН17 от него;
- или был вообще выключен, а впоследствии передал в фр24 вручную нарисованные данные по МН17.

Заслуживает внимания также появление в базе данных фр24 18 июля информации от приемника F-UKCC1 (id 1032), хотя она отсутствовала там 17 июля, на ее месте был записан экстраполированный курс МН17

151

meovoto
Ваши-то доводы мне понятны. Прочитав первый раз, я нанес две точки ADS-B и тут же с Вами согласился. (На рисунке - расстояние от первой координаты до Last FDR, как у меня намерилось и за сколько секунд боинг его пролетит при различных средних скоростях).
http://s8.uploads.ru/MoRJT.jpg

Мне непонятен ответ Бутблека.

И по-прежнему непонятно - вот у него самого желто-салатовым по карте написано и отдельно подчеркнуто, что данные ADS-B и радара на 13:19:12 отличаются ого-го как. Далеко за погрешности его же, Бутблека, прямоугольников (оценки точности нанесения данных радара).
Т.е. что - сервер Чехонин правильный. А радар и черный ящик - неправильный?
http://s9.uploads.ru/KXlhF.jpg

Но Бутблек так уверенно реагирует, что я и думаю - может что-то совсем-совсем не понимаю?

А что стоит посмотреть, наверное это из кода понять можно, раз Вы уже подобрались к исходникам.
Про фразу Бутблека "Так только в зоне уверенного приема и последующей уверенной расшифровки пакетов с борта" - поскольку у нас цифра, то либо оно декодировалось, либо отбрасывается., я вижу два варианта.
1) Или не в каждом пакете передается полный набор (скорее всего так, сигналы идут с большей частотой, чем поступает соответствующая информация в транспондер. А передавать неверные (устаревшие) координаты - ни к чему.
2) Или пакет состоит из набора "пакетиков", каждый со своим контрольным числом, так что "на помойку" отправляется то, что не расшифровалось, а расшифрованная часть идет в дело.

Отредактировано uschen (2018-12-02 04:20:05)

152

uschen написал(а):

Про фразу Бутблека "Так только в зоне уверенного приема и последующей уверенной расшифровки пакетов с борта" - поскольку у нас цифра, то либо оно декодировалось, либо отбрасывается., я вижу два варианта.

Правильно. В результате в зоне неуверенного приема нормально раскодируются и не отбрасываются только некоторые пакеты координаты/высота (MSG 3) и скорость/курс (MSG 4), по наблюдениям разрыв между ними составляет от нескольких секунд до десятков секунд, хотя в зоне уверенного приема они "валят валом").

http://s9.uploads.ru/aiWdw.png

Судя по тому, что от 4245F8 раскодировались только короткие пакеты (MSG 8) "борт в воздухе", то предположительно он летел на границе зоны приема. А 4248F5 входил в зону уверенного приема. Можно попробовать получить отчеты по этим бортам, и проверить фактически.
В документах ICAO встречал, что одно сообщение должно иметь длину 1/128 секунды.

153

Альтерно, к Вам вопрос. Какие ADS-B данные (с какого источника) Киев предоставил в DSB, охватывают ли эти данные 13:20:03? И желательно пояснить, это Ваше мнение или достоверная информация.

154

bootblack
Но вот Вы мне и сейчас ничего не пояснили про 14 секунд и про длину Меовото...
Особенно про 14 секунд.
Сервер обманывает? Он получает координаты, держит их в себе до какого-то определенного пакета, и только тогда выдает эти координаты, приписывая к ним время этого долгожданного пакета?
Какое у Вас объяснение этой разницы в координатах в один и тот же момент времени - по радару и по Чехонину?

Отредактировано uschen (2018-12-04 04:41:50)

155

uschen, в случае МН17 {расстояние между координатами : на время между координатами = (приблизительно) скорость МН17} пока рассматриваю как случайное совпадение.

В целом основываюсь на:
1. По утверждениям владельцев сервером их компы ежечасно синхронизировались по NTP.
2. Мной лично неоднократно проверено наличие в аналогичных отчетах по рейсам разницы между координатами и временем в отметке "СТОП", которая на прежде всего интересна в случае МН17. Эта разница может быть от единиц секунд до десятков секунд в зависимости от конкретной ситуации раскодирования пакетов приемником. Что и логично, поскольку на выходе из зоны уверенного приема самыми последним всегда раскодируются короткие пакеты, то есть без координат или скорости.
3. Поскольку точку "СТАРТ" в отчетах невозможно также легко перепроверить наблюдением как точку "СТОП", то надо понять логику кода VRS. Она очевидна в части вывода информации для точки "СТОП" - из базы берутся все последние записи координат, скорости и тд независимо от времени их получения и время последнего пакета. А вот для точки СТАРТ заложены условия, пока не понял их логику и важна ли она.
Согласен, что в точке СТАРТ странным выглядят координаты западнее времени. Пока у меня одно объяснение - время в точке "СТАРТ" соответствует последнему пакету, заполнившему базу для вывода записи "СТАРТ". И это был пакет со скоростью и курсом, тоже длинный. Во время наблюдением за выходом из зоны уверенного приема были случаи, когда изменения скорости прекращались раньше, чем изменения координат. Возможно по причине, что скорость реально не изменялась, но иметь в виду надо.

Конечно, самый быстрый и правильный ответ дадут логи, но желающих делиться нет.

От МН17 было получено 18 пакетов пакетов. Из них 4 пакета с координатами/выстотой и 5 пакетов со скорость/курсом/верт. скоростью.

счетчики

/// <summary>
        /// Updates the counters of total messages for a flight.
        /// </summary>
        /// <param name="message"></param>
        /// <param name="flight"></param>
        private static void UpdateMessageCounters(BaseStationMessage message, BaseStationFlight flight)
        {
            switch(message.TransmissionType) {
                case BaseStationTransmissionType.IdentificationAndCategory: ++flight.NumIDMsgRec; break;
                case BaseStationTransmissionType.SurfacePosition:           ++flight.NumSurPosMsgRec; break;
                case BaseStationTransmissionType.AirbornePosition:          ++flight.NumAirPosMsgRec; break;
                case BaseStationTransmissionType.AirborneVelocity:          ++flight.NumAirVelMsgRec; break;
                case BaseStationTransmissionType.SurveillanceAlt:           ++flight.NumSurAltMsgRec; break;
                case BaseStationTransmissionType.SurveillanceId:            ++flight.NumSurIDMsgRec; break;
                case BaseStationTransmissionType.AirToAir:                  ++flight.NumAirToAirMsgRec; break;
                case BaseStationTransmissionType.AllCallReply:              ++flight.NumAirCallRepMsgRec; break;
            }

            if(message.Latitude == null && message.Longitude == null && message.GroundSpeed == null && message.Track == null && message.VerticalRate == null) {
                ++flight.NumModeSMsgRec;
            } else {
                ++flight.NumADSBMsgRec;
                if(message.Latitude != null && message.Longitude != null) ++flight.NumPosMsgRec;
            }
        }

156

bootblack
Я правильно понимаю, что радиоприемника у Вас нет, только стоит программа и ловит сообщения, передаваемые другими серверами? Или каким-то одним конкретным сервером с приемником?
Я понимаю логику, что от последних координат до последнего сигнала может пройти с полминуты. Нет проблем.
С кодами разбираться ещё не пытался всерьёз, но понял так.
Есть функция, которая говорит, что получена долгота, есть то же про широту.
Нам надо одновременно получить и то и другое.
Если обе величины получены, то про каждую два варианта - расшифрована она или нет, сошлась ли контрольная сумма.
Если обе сошлись - мы эту широту и долготу пишем в начальную, если не было начальной, и в конечную всегда.
Время привязано однозначно, это время прихода сигнала по компьютерным часам.
Известно, что в 13:20:03 самолёт был в точке Last FDR, а по ads-b он был не ранее, чем в 13:19:12 в 16.3 километрах, т.е. в примерно 65 секундах полета.
Должен был там быть в 13:18:58, а был в 13:19:12.
Ну какое тут может быть объяснение, кроме спешащих часов компьютера с приемником???
Ещё раз.
Хозяин сервера утверждает, что в некоторой точке самолёт был не ранее 13:19:12.
А достоверно известно, что он там был в 13:18:58, плюс-минус пара секунд.
Верим хозяину сервера?
Я нет.
Что тут обсуждать?

Отредактировано uschen (2018-12-05 09:01:39)

157

uschen, вижу, Вы вообще далеки от обсуждения этого вопроса. Потому сложно обсуждать, а не

uschen написал(а):

Что тут обсуждать?

Самолет ежесекундно отправляет несколько сообщений, самостоятельно или по запросам радаров УВД.

Всего 8 типов сообщений

http://s8.uploads.ru/zcjmS.png

Сообщения несут такую информацию

http://s3.uploads.ru/EPhcv.gif

Видно, что координаты и высота приходят в MSG3. Скорость, курс, вертикальная скорость в MSG4.
Данные раскодированных сообщений замещают старые данные в базе.
В зоне неустойчивого приема разница во времени между раскодированными сообщениями существенна, от нескольких секунд до 20-30 секунд (после 30 секунд сервер рассматривает борт как утраченный). Поэтому данные базы не относятся к какой -то одной единой позиции борта, они растянуты по трассе, например, на 1-5 км. Последним обычно расшифровывается короткое сообщение, и это естественно не координатное MSG3. Время окончания отслеживания = время расшифровки этого последнего сообщения. В результате точка СТОП находится на упомянутые выше 1-5 км впереди координат, выведенных для этой точки в отчете.
Эта логика кодов сервера подтверждена наблюдениями. Для этого не надо иметь приемник, достаточно выйти на сайт VRS, например, http://vrs-russia.ddns.net:65000/Virtua … ktop.html#

Чтобы на 100% утвердительно сказать, что описанное выше для точки СТОП полностью подходит для точки СТОП МН17, надо разобраться с его точкой СТАРТ. Что пытаюсь и сделать. Пока время потрачено зря, потому что меня ткнули в коды не того сервера, который отслеживал МН17.

158

bootblack
Но время первого сигнала - это время первого сигнала, с координатами или нет - неважно, так?
Координаты могли поступить только позже, но никак не раньше, чем время первого сигнала, 13:19:12.
Но эти координаты соответствуют проверенному времени около 13:18:58!!!
Противоречие, нет?

159

uschen написал(а):

bootblack
Но время первого сигнала - это время первого сигнала, с координатами или нет - неважно, так?
Координаты могли поступить только позже, но никак не раньше, чем время первого сигнала, 13:19:12.

Если говорить об известных кодах создания базы для конкретного рейса, то ДА. А на входе в зону приемника разница во времени может быть существенной.

uschen написал(а):

Но эти координаты соответствуют проверенному времени около 13:18:58!!!

Да

Но не факт, что 13:19:12. есть время первого сообщения, инициировавшего создание базы рейса. По мнению программистов, посмотревших коды, нельзя исключать не выявленный при тестировании глюк системы по той причине, что для этого сервера обсуждаемые секунды не являются важным при реальном применении. На это могли просто не обращать внимание. Косвенное подтверждение наличию глюка можно получить, сравнивая реалтайм данные в момент входа рейса в зону приемника и отчет по этому рейсу - логику уже известных кодов не увидите.

160

bootblack
Т.е. надо допустить гипотезу, что время первого, второго, третьего... (и так 14 секунд) сигнала может не записаться вообще.
И хотя сигнал с координатами уже получен, правильно расшифрован, данные по координатам уже внесены в базу, т.е. там появилась новая запись, а вот времени первого сигнала еще не установлено?
А где можно посмотреть коды правильной, т.е. той, что была на Чехонине, системы?

161

uschen написал(а):

Т.е. надо допустить гипотезу, что время первого, второго, третьего... (и так 14 секунд) сигнала может не записаться вообще.

Время регистрации сервером первого сообщения = время начала рейса ПРИ ЗАПИСИ В БАЗУ ДАННЫХ. Вопрос в том, что за время "13:19:12" вывелось в точке СТАРТ.
И в этом деле делить расстояние между координатами на 65 секунд наблюдения - самое бессмысленное занятие.
Опираться на совпадение 14 секунд в начале и в конце также бессмысленно, потому что для этого необходимо допустить, что первым сообщением было координатное сообщение. Но это исключено. Достаточно понаблюдать за рейсами на сайте VRS, чтобы понять это.

Отредактировано bootblack (2018-12-05 18:47:10)

162

bootblack написал(а):

И в этом деле делить расстояние между координатами на 65 секунд наблюдения - самое бессмысленное занятие.

Ну мы можем поступить по-другому.
Можно замерить расстояние от этой начальной координаты до Last FDR, получим 16.3 км. Поделить это на скорость 253 м/с, получим что-то около 65 секунд.
Итак - в базу данных занесены начальные координаты. В какой момент времени это произошло? Ну никак не раньше, чем в базу данных занесена сама запись?
Значит координаты были записаны никак не ранее 13:19:12 по часам сервера.
Но на самом деле транспондер самолета передал их в 13:18:58!
Разница минимум 14 секунд.
Что же удивительного, что последний сигнал ads-b, переданный в 13:20:03 был записан сервером в 13:20:17 - с той же разницей в 14 секунд.

Вы говорите, что запись создана раньше, не в 13:12:19. Но на скриншоте она так отображена?
А вот 13:20:17 - правильно отображена?
Почему Вы не доверяете скриншоту, когда смотрите в ту его часть, где 13:19:12 и доверяете соседним пикселям, где 13:20:17?

Чем дальше, тем непонятнее становится.
А Вы еще хотели отослать meovoto  с его вопросом, пока он не последит полгода за работой различных ads-b серверов.
Зачем ждать полгода?

Отредактировано uschen (2018-12-06 13:10:14)

163

uschen, ниже представлено моё видение ситуации, тск ab ovo. Я покопался в кодах, плюс соответствующих комментариях их автора на его сайте ( http://www.virtualradarserver.co.uk ), и, надеюсь, удовлетворю Ваше любопытство.

bootblack, можете относиться к моему эссе, как угодно. Возражения рассматриваются, если Вами будут предъявлены аргументы одного уровня с моими суждениями. То есть, с образцами открытого исходного кода, которые противоречат моим выводам. Пустотелые аргументы, типа "по мнению программистов, просмотревших коды", не принимаются. :)

Поехали!  :rain:

Сервер VRS может прослушивать поступающие сообщения, - через сетевое подключение или с помощью последовательного порта 30003, - представленные тремя форматами. Принято обозначать их аббревиатурами SBS3, Port30003 и Beast. Последний, ко всему прочему, включает три текстовых формата и один бинарный.

Как бы то ни было, но сообщения всех форматов проходят обработку (прослушивание) с помощью одного и того же объекта (интерфейса) открытого исходного кода (ОИК) - он именуется IListener.

Ссылка (для «заумных»  %-) ) на его описание, а также свойства, методы и события (по сути, это только отправная точка, дальше надо копать и копать  :D ):

http://www.virtualradarserver.co.uk/Sou … 7f843b.htm

Но, по сути, этот интерфейс только предоставляет классы ОИК, и всю последующую работу по извлечению байтов и их декодированию осуществляют другие объекты ОИК.

Непосредственно прослушивают входящие каналы, переводя потоки бинарных сообщений в байты (посредством библиотечных классов), интерфейсы ITcpListenerProvider (сетевое подключение) и ISerialListenerProvider (последовательное подключение).

Сответственно, декодирование осуществляют интерфейсы ISbs3MessageBytesExtractor, IPort30003MessageBytesExtractor и IBeastMessageBytesExtractor, тоже с помощью соответствующих библиотечных классов.

В итоге, все полученные сообщения, включая часть из них, не относящихся к формату Port30003 (raw и текстовые Beast), таки ретранслированы в него, и далее реализуется следующая нумерованная цепочка вызовов методов его обработки (ссылку на ОИК я уже предоставлял, поэтому любой желающий – и «заумный»! - может удостовериться в справедливости нижеописанного):

1. private void ProcessPort30003MessageBytes(ExtractedBytes extractedBytes)

///Переводит байты сообщения, полученного по каналу Port30003, в выходной объект сообщения и помещает его в очередь фонового потока.

(...var translatedMessage = _Port30003MessageTranslator.Translate(port30003Message);
... _MessageProcessingAndDispatchQueue.Enqueue(new MessageDispatch() { Port30003MessageEventArgs = new BaseStationMessageEventArgs(translatedMessage)...)

2. ///Вызывается, когда фоновый поток извлекает сообщение из очереди сообщений.

private void MessageQueue_MessageReceived(BaseStationMessageEventArgs args)
(...TrackFlight(args.Message); ...)

3. private void TrackFlight(BaseStationMessage message)

///Либо открывает новую запись в таблице базе данных полётов (если самолёта нет в списке отслеживаемых), либо модернизирует уже существующую. Создаёт переменную метода, содержащую текущее время и дату получения сообщения на обработку.

Новая запись открывается, если в коллекции _FlightMap записей полётов flightRecords не обнаруживается идентификатор самолёта Icao24, содержащийся в полученном сообщении message:

if(!_FlightMap.TryGetValue(message.Icao24, out flightRecords))

Тогда:

(...var localNow = Provider.LocalNow;
... flightRecords.Flight = CreateFlight(localNow, flightRecords.Aircraft.AircraftID, message.Callsign);
  ...)

Если же самолёт имеется в списке отслеживаемых, поле StartTime таблицы базы FlightsTable данных остаётся неизменным, а вот поле EndTime локальной переменной flight подготавливается к перезаписи в эту таблице, получая текущее значение локального времени:

(...var flight = flightRecords.Flight;
... flight.EndTime = localNow;)

4. private BaseStationFlight CreateFlight(DateTime localNow, int aircraftId, string callsign)

///Подготавливает запись в таблицу полётов базы данных, присваивая полю StartTime локальной переменной result значение текущего локального времени localNow.

(...var result = new BaseStationFlight() {
... StartTime = localNow, ...}
_Database.InsertFlight(result);...)

5. public void InsertFlight(BaseStationFlight flight)

/// Продолжает подготовку записи в базу данных полётов, включая и интересующие нас поля StartTime и EndTime таблицы данных полёта FlightsTable .

(...flight.StartTime = SQLiteDateHelper.Truncate(flight.StartTime);
flight.EndTime = SQLiteDateHelper.Truncate(flight.EndTime)
...)

Последний оператор,

SQLiteDateHelper.Truncate(...)

производит перевод системного формата времени в формат базы данных.

(...public static DateTime Truncate(DateTime dateTime)
return new DateTime(dateTime.Year, dateTime.Month, dateTime.Day, dateTime.Hour, dateTime.Minute, dateTime.Second)...)

6. private static void UpdateFirstLastValues(BaseStationMessage message, BaseStationFlight flight, FlightRecords flightRecords)

/// Если производится запись в таблицу FlightsTable данных полётов для первого сообщения от самолёта, заполняются все её поля (First и Last), если же сообщение не первое (First поля – не «нулевые»), обновляются лишь те поля, которые отвечают текущему состоянию полёта (Last).

7. if(_Connection != null) flight.FlightID = _FlightTable.Insert(_Connection, _TransactionHelper.Transaction, _DatabaseLog, flight);

///Непосредственно осуществляет запись в таблицу данных полёта FlightsTable и возвращает её (записи) ID, и далее, с этим индификатором, запись вносится в текущую карту отслеживаемых полётов:

_FlightMap.Add(message.Icao24, flightRecords);

Вывод: в полях StartTime и EndTime таблицы FlightsTable базы данных сервера, на самом деле, как и извещают комментарии автора кода в ОИК, – это было доведено мною до общего форумного сведения изначально, - содержится локальное UTC-время фиксации получения сервером первого сообщения типа BaseStationMessageType.Transmission (суть «MSG») от конкретной станции наблюдения (StartTime), и, соответственно, локальное UTC-время фиксации получения сервером последнего сообщения типа «MSG» (EndTime).

То есть, при этом совершенно неважно, с каким «содержанием» (любая из 8 комбинаций передаваемых параметров полёта) было принято первое (последнее) сообщение «MSG», так как идентификатор ICAO24 имеется в любом из них.

И, разумеется, никакого ожидания получения какой бы то ни было «комплектации» сервером «полных» мифических «пакетов» данных некой последовательности сообщений, с последующей фиксацией в поле StartTime таблицы FlightsTable момента возникновения этого несуществующего «события» им не производится.

Чтд. :)

164

uschen написал(а):

Ну мы можем поступить по-другому.
Можно замерить расстояние от этой начальной координаты до Last FDR, получим 16.3 км. Поделить это на скорость 253 м/с, получим что-то около 65 секунд.
Итак - в базу данных занесены начальные координаты. В какой момент времени это произошло? Ну никак не раньше, чем в базу данных занесена сама запись?
Значит координаты были записаны никак не ранее 13:19:12 по часам сервера.
Но на самом деле транспондер самолета передал их в 13:18:58!
Разница минимум 14 секунд.
Что же удивительного, что последний сигнал ads-b, переданный в 13:20:03 был записан сервером в 13:20:17 - с той же разницей в 14 секунд.

Вы говорите, что запись создана раньше, не в 13:12:19. Но на скриншоте она так отображена?
А вот 13:20:17 - правильно отображена?
Почему Вы не доверяете скриншоту, когда смотрите в ту его часть, где 13:19:12 и доверяете соседним пикселям, где 13:20:17?

Чем дальше, тем непонятнее становится.
А Вы еще хотели отослать meovoto  с его вопросом, пока он не последит полгода за работой различных ads-b серверов.
Зачем ждать полгода?

Отредактировано uschen (Сегодня 13:10:14)

Проследить за работой различных серверов имеет вполне конкретный смысл - там можно наглядно увидеть что "Время старта:" ВСЕГДА более раннее, чем время нахождения самолета в точке "Начальная долгота:"/"Начальная широта:".  И разница составляет вплоть до зафиксированных мной 90 секунд (возможно, может быть и больше). Мной не выявлено ни одного случая, чтобы этой разницы не было, или она исчислялась в единицах секунд. Что и логично, поскольку в зоне неуверенного приема координатные пакеты, а они самые длинные, расшифровываются проблематично.
Если Вы выявите расхождение в 0-5 секунд, возможно и пересмотрю свою версию. А пока остаюсь при

bootblack написал(а):

И в этом деле делить расстояние между координатами на 65 секунд наблюдения - самое бессмысленное занятие.
Опираться на совпадение 14 секунд в начале и в конце также бессмысленно, потому что для этого необходимо допустить, что первым сообщением было координатное сообщение. Но это исключено. Достаточно понаблюдать за рейсами на сайте VRS, чтобы понять это.


Далее

meovoto написал(а):

И, разумеется, никакого ожидания получения какой бы то ни было «комплектации» сервером «полных» мифических «пакетов» данных некой последовательности сообщений, с последующей фиксацией в поле StartTime таблицы FlightsTable момента возникновения этого несуществующего «события» им не производится.

Это было мое предположение до вникания в коды сервера.

Вывод: в полях StartTime и EndTime таблицы FlightsTable базы данных сервера, на самом деле, как и извещают комментарии автора кода в ОИК, – это было доведено мною до общего форумного сведения изначально, - содержится локальное UTC-время фиксации получения сервером первого сообщения типа BaseStationMessageType.Transmission (суть «MSG») от конкретной станции наблюдения (StartTime), и, соответственно, локальное UTC-время фиксации получения сервером последнего сообщения типа «MSG» (EndTime).
То есть, при этом совершенно неважно, с каким «содержанием» (любая из 8 комбинаций передаваемых параметров полёта) было принято первое (последнее) сообщение «MSG», так как идентификатор ICAO24 имеется в любом из них.

Согласен с этим как с заложенным алгоритмом записи в базу. Но

bootblack написал(а):

По мнению программистов, посмотревших коды, нельзя исключать не выявленный при тестировании глюк системы по той причине, что для этого сервера обсуждаемые секунды не являются важным при реальном применении. На это могли просто не обращать внимание.

То есть рассматриваемые коды красивы, но не исключено, что в не рассматриваемых кодах есть глюк. Который мог проявиться, например, в связи "transponder data became unreliable at 13:18Z (position N48.28 E38.08)".

Как вариант могло быть и так, как вчера "летел" борт

http://s7.uploads.ru/s3qHZ.jpg

165

bootblack написал(а):

Как вариант могло быть и так, как вчера "летел" борт

Линия, проведенная через две ads-b координаты очень точно указывает в LastFDR.
http://s7.uploads.ru/lKFy2.jpg

Расстояние поточнее - 16200 метров. Если взять среднюю скорость 254 м/с, то это 63.8 секунды. А кто мешает среднюю скорость побольше взять? (В отчете я графика скорости не нашел, только ускорение).
Время наблюдения отобразилось 65 секунд.  А может 65.49? Тогда небольшой промежуток на сигналы без координат остается: 65.5-63.8=1.7 секунды.
Вы исходите из своих наблюдений. Для Ваших трасс, вашей местности. Для Вашего приемника.
А проверять-то надо - для той хитрой погоды, как минимум.

Отредактировано uschen (2018-12-07 02:39:25)

166

uschen, если в результате собственных наблюдений

bootblack написал(а):

Вы выявите расхождение в 0-5 секунд, возможно и пересмотрю свою версию.

Для наблюдения не нужен ни собственных приемник, ни собственная местность. Выходите, например, на http://vrs-russia.net:65000/VirtualRadar/desktop.html# и поехали. Чтобы не ждать с моря погоды как Конюхов вход самолета в зону приемника, запускаете одновременно fr24. Как только самолет появится в зоне, быстро щелкаете по его иконке (иконка станет желтой) и смотрите на выведенные данные

http://sh.uploads.ru/1GnyA.jpg

Видите 01 минуту 26 секунд и 27 сообщений. Ну и какое может быть деление расстояния на 65 секунд?

Чтобы щелкая и прощелкать, организуйте запись экрана, так намного легче анализировать. Меняйте места наблюдения - Сочи, Дальний Восток, Сибирь, .... Ростов. И выявите расхождение не более 0-5 секунд

167

bootblack
Я чего-то не понимаю.
Вы говорите, что в случае mh17 стартовое время сервер отобразил неправильно?
Или что?
По поводу полутора минут задержки - надо посмотреть алгоритм отображения самолёта на карте, может они начинают показывать иконку только набрав статистику.
А может под Донецком работали глушилки и потому ранние сигналы не проходили.
А может гроза.
В любом случае, для Вашей версии - сбой на сервере - нужно двойное совпадение.
Одни и те же координаты по Чехонину и по радару отличаются на 14 секунд.
Прекращение сигналов - тоже 14 секунд.
И пусть Ваши программисты покажут место, где может глюкануть. Странно, что его автор не исправил, столько релизов...

168

uschen написал(а):

По поводу полутора минут задержки - надо посмотреть алгоритм отображения самолёта на карте, может они начинают показывать иконку только набрав статистику.

Здесь уже неоднократно ссылались на коды VRS серверов. Согласно их логики, если она выполняется ровно так, как написано, то разница между выводимыми координатами и временем (время раньше по трассе, чем координаты) естественна. В основном она более 10 секунд, доходит до полутора минут как в примере выше. Это что выявил я. Согласно же этим кодам зеркальная разница (время позднЕе по трассе, чем координаты) невозможна.

uschen написал(а):

Вы говорите, что в случае mh17 стартовое время сервер отобразил неправильно?

Да. Пока не понятно почему неправильно.

uschen написал(а):

А может гроза.

Этот фактор влияет на раскодирование приемником, а не на запись сервером.

uschen написал(а):

А может под Донецком работали глушилки и потому ранние сигналы не проходили.

Судя по недавнему петлянию борта, как вариант, возможно. Тем более что было сообщение о неустойчивой работе транспондера в 13:18Z. Но в этом случае странно, что фиктивные координаты попали прямо на трассу боинга. Низка вероятность.

uschen написал(а):

И пусть Ваши программисты покажут место, где может глюкануть. Странно, что его автор не исправил, столько релизов...

Это не так просто. Глядя на коды не выявишь. Для этого есть тестировщики, которые создают разные ситуации. Но и им нужно додуматься, что это за ситуация. Тестируют обычно для стандартного применения. Думаете, кто-то до этого мог заметить, что в отчете время опережает координаты, если такое имело место? фигвам :) Можно заметить только, если делать запись текущего рейса с часами, а потом сравнить с выведенным отчетом https://cloud.mail.ru/public/MNF3/Ab7SWpT5E Кому это надо было и для чего? Не случись упавший боинг.

169

bootblack написал(а):

Но в этом случае странно, что фиктивные координаты попали прямо на трассу боинга. Низка вероятность.

Гроза может "затенять" сигнал, вышел из тени - сразу хороший.
Глушилка - вместо обратного квадрата получаем разность обратных квадратов - шумового сигнала и сигнала транспондера, т.е. обратный куб - зависимость от расстояния. Что-то тут я перемудрил. Просто требуется превышение мощности сигнала  над порогом, а это могло произойти, когда  Боинг был сильно ближе к приёмнику,, чем без глушилки, соответственно и дальше мощность сигнала будет расти быстрее. Если предполагаемая разница между первым расшифрованным сигналом и сигналом с координатами, от 10 секунд до полутора минут, почему бы не допустить в таком случае возможность задержки менее двух секунд?

Если просто глушат эфир - создают помехи приему, то это не может повлиять на правильность определения координат. "Петляния" получаются, когда подменяют сигналы GPS-ГЛОНАСС. У нас в этом случае такси из-под Кремля попадают во Внуково.

bootblack написал(а):

Это не так просто. Глядя на коды не выявишь. Для этого есть тестировщики, которые создают разные ситуации.

Эти сервера работают не первый год, тестировщиков тьма.
"Это может глюкануть" - не довод.

bootblack написал(а):

зеркальная разница (время позднЕе по трассе, чем координаты) невозможна.

И именно этот довод - основной против 13:20:17 в качестве реального времени последнего сигнала.
(Первый сигнал борта - это самый первый сигнал, в котором удалось расшифровать номер борта?)

Отредактировано uschen (2018-12-09 15:49:30)

170

uschen написал(а):

Эти сервера работают не первый год, тестировщиков тьма.
"Это может глюкануть" - не довод.

Выше объяснял, что в данном случае в качестве тестировщиков выступили мы и только благодаря тому, что помимо VRS есть позиция для 13:19:12 от ростовской Индры, в результате чего увидели разницу между позицией боинга в 13:19:12 и координатами, выведенными с меткой времени 13:19:12.
Людям, которые пользуются VRS, это не нужно тысячу раз. Большинство из них даже не знает о естественном сдвиге между "Время старта" и "Начальные координаты".

Вы может оставаться при своем мнении, я же останусь при своем. Тем более что вижу достаточно других оснований предполагать пикирование целого боинга до 13:20:17.

171

bootblack
А всё же, на что именно указывали программисты, говоря "может глюкануть"?

172

uschen написал(а):

bootblack
А всё же, на что именно указывали программисты, говоря "может глюкануть"?

Если бы они знали это глядя на коды, так и тестировать не надо. А владелец VRS сервера на вопрос "почему координаты раньше Время старта:" ответил - Тoгдa тoлькo json пaрсить в рeaльнoм врeмeни.

173

Для тех, кто на других форумах читает о всуе упомянутом Чехонине.
Речь идет о двух частных российских ADS-B серверах, аналогичных fr24, установленных на личных компах двух физлиц, проживающих в разных регионах РФ - один на Каспийском море, другой на Черном море.
Приемники частных лиц, аналогичные приемникам fr24, передают принятые с бортов ADS-B пакеты напрямую на эти серверы в реальном времени без задержек, за исключением проблем с доступом в интернет.
На серверах стоит синхронизация времени с мировым. По утверждению владельцев серверов проблемы синхронизации исключены, что и подтверждается отмеченной ниже разницей в 1 секунду между двумя независимыми друг от друга компами.
Оба эти сервера записали последние поступившие к ним ADS-B пакеты с МН17 в 13:20:17 и 13:20:18 - http://forumfiles.ru/files/0014/75/e6/50669.jpg

174

http://mh17.forum.camp/viewtopic.php?id … p=31#p2565

С этим постом солгасен. Темное дело. Вместо нормальных по-секундных ADS-B данных нам подсовывают цифры из playback.

Ралив, нужна ссылка на первоисточник этой таблицы.
http://sd.uploads.ru/LvjpY.jpg

175

bootblack написал(а):

нужна ссылка на первоисточник этой таблицы.

http://mh17.forum.camp/viewtopic.php?id … p=31#p2566

РВШ, спасибо.

> https://mh370.radiantphysics.com/2019/0 … king-data/

More precise tracking data has recently become available that gives new insights about how MH370 was flown just before the transponder was disabled near the waypoint IGARI. The data was broadcast by the aircraft and received by a Malaysian ATC receiver at Terengganu. It is similar to the data that has been previously available from the aircraft tracking site FlightRadar24, except that the spacing between data points is shorter, and the data are the raw values that were actually broadcast by the aircraft. As a result, more details about the flight can be extracted.

The new tracking data was transmitted by the aircraft’s Automatic Dependent Surveillance – Broadcast (ADS-B) system, which broadcasts the GPS-derived position and altitude, as well as other parameters, as often as about every one-half of a second. Because of the inherent accuracy of GPS, the ADS-B position is more accurate than the traditional radar systems, which derive the position from the timing and angular direction of received signals from the aircraft using a rotating antenna.

A file containing the ADS-B data for MH370 is available here.

И предполагал по структуре таблицы, что это не из fr24. Из УВД. Ну и отлично! Из текста видно, что и по МН370 fr24 тоже отделывался по-минутным playback. Ок. Допустим, в июле 2014 года база данных fr24 не сохраняла полную информацию, поступающую на сервер от наземных приемников, как это было позднее в случае катастрофы над Синаем. Я в этом очень сомневаюсь, но допустим, что от fr24 можно было ожидать максимум playback. Но ADS-B данные от наземных приемников упоминаются и в предварительном отчете DSB

http://s8.uploads.ru/iWCI9.png

и в финальном отчете DSB

http://sd.uploads.ru/d0vAs.png

Эти данные являются незначительной мелочью и поэтому их не включили в приложение к отчету?
Нет, здесь явно что-то нечисто!

176

Освежил старую инфу в новом виде

http://forumfiles.ru/files/0014/75/e6/75374.jpg

Это не даст ответ, когда борт перестал вещать ADS-B пакеты, но поддержит на плаву прежний вопрос, что в базу fr24 вмешивались вручную и
или в базе были данные от F-UKCC1, но playback посчитал их второстепенными и не выводил 17 июля
или данные от F-UKCC1 передали позже для корректировки базы
После 18 июля playback принудительно заставили использовать данные F-UKCC1.
Зачем? 
:dontknow:
Может быть ее корректировали, чтобы playback не выдал неожиданный ребус да и вообще в базе не осталось посекундной информации о координатах, которые F-UKCC1 с донецкой крыши должен был принимать устойчиво.


Вы здесь » MH17 » Крепость админа » Странный flightradar24