A propos czasu uderzenia w brzozę

28.08.13, 18:56
podawanego w tabeli nr1 w załączniku technicznym nr 4, to jest on tam błędnie wpisany.

Opis______________________________________Czas_____Odległość
Brzoza oderwanie fragmentu lewego skrzydła | 06:41:02,8 | 855m

Strona 618 - spis zdarzeń z QAR-a

08:41:02.5 – zmniejszanie przeciążenia pionowego PRZECPION=0.84[g],
KURSMAGN=246[deg], PEDALYL=-17[deg],


Przyjmując, że parametry lotu zapisane przy TAWS37 niewiele się zmieniały, w szczególności prędkość względem terenu, to można oszacować, że lot od TAWS37_1931m od progu do brzozy_855m musiał trwać, przy prędkości Vgs=286.6 km/h = 79.6 m/s

t = (1931m-855m)/79.6m/s = 13,5 s

Czyli znając czas TAWS37 = 06:40:43 (UTC) można oszacować, że samolot osiągnął odległość brzozy o 06:40:56.5.

Znając przesunięcia czasowe między czasami rejestratorów można stwierdzić, że było to o:

6:40:56.5 wg czasu UTC

6:40:56.5 + 4h 00m 03.5s = 10: 41:00 wg czasu transkrypcji MAK (czas MSRP 64)

6:40:56.5 + 2h 00m 06.5s = 8:41:03 wg czasu transkrypcji IES.

czyli już później niż podano.

W rzeczywistości na tym odcinku samolot zwalniał, ze względu na późne przestawienie silników na ciąg startowy i jednoczesne duże zwiększenie kąta natarcia przy rozpaczliwej próbie nie wbicia się w ziemię tuż za BRL, które zwiększa opory czołowe samolotu (czyli mówiąc po samochodowemu przypadkiem wcisnęliśmy hamulec nie dodając gazu i samochód zwalnia).

Przyjmując średnią prędkość z TAWS37 i TAWS38:

Vxśr = (286,6km/h + 268,8km/h)/2 = 277,7 km/h = 77,1 m/s

Otrzymamy czas przelotu do brzozy wynoszący:

t = (1931m-855m)/77.1m/s = 13,95s

czyli

UTC = 6:40:43+13.95s = 6:40:56.95

MAK = 10:40:43 + 13.95s + 3.5s = 10:41:00,65s

IES = 8:40:43 + 13.95s + 6.5s = 8:41:03,45 s

Jeżeli spojrzeć na wykresy przeciążeń na wykresie MAK (jedyny wysokorozdzielczy dostępny ogółowi), to można tam odczytać:

___MSRP64______QAR+3.5s___Vias___Odl______Ny
10:40:59,445___8:41:02,445___270___932___1,34
10:40:59,570___8:41:02,570___270___923___1,34
10:40:59,695___8:41:02,695___270___914___1,34
10:40:59,820___8:41:02,820___270___904___1,34
10:40:59,945___8:41:02,945___270___895___1,28
10:41:00,070___8:41:03,070___273___885___1,31
10:41:00,195___8:41:03,195___272___876___1,28
10:41:00,320___8:41:03,320___271___867___1,34
10:41:00,445___8:41:03,445___270___857___0,85
10:41:00,570___8:41:03,570___270___848___1,25
10:41:00,695___8:41:03,695___270___838___1,34
10:41:00,820___8:41:03,820___270___829___1,19
10:41:00,945___8:41:03,945___270___820___1,07
10:41:01,070___8:41:04,070___270___810___1,34
10:41:01,195___8:41:04,195___270___801___0,21
10:41:01,320___8:41:04,320___270___792___0,30

MSRP64 - czas wg rejestratora MSRP64, przyrost czasu 125ms tak jak są zapisywane przeciążenia

Vias - zanotowana prędkość względem powietrza

Odl - odległości naliczane co 125ms (1/8s) od odległości TAWS37 z użyciem zanotowanych prędkości Vias


Powyższe nie wynika z fałszerstwa danych ale, między innymi, z BEZTROSKI kogoś z komisji, kto napisał:

Załącznik techniczny nr 4, strona 573 (21/93) u dołu.

"Z powyższych danych wynika, że czas MSRP jest opóźniony o 3.425 sekundy
w stosunku do czasu MARS-BM. Do dalszych analiz przyjęto opóźnienie 3 sekundy."


Powyższe zdanie zawiera dwa błędy:

a) Wprowadza prawie 0.5 sekundy przesunięcia w czasach zdarzeń

b) mówi nieprawdę o zależnościach czasowych pomiędzy zapisami parametrycznymi i głosowymi.

Drugi błąd wynika z przyjęcia, że czas QAR-a, którego zapisy mieliśmy najwcześniej jest tożsamy z czasem rejestratora głosowego A TAK NIE JEST.

FMS i TAWS mają czas satelitarny UTC brany z odbiorników GPS

MSRP64 (rejestrator parametrów technicznych lotu) ma czas ustawiany ręcznie przez mechanika pokładowego przed każdym lotem

MARS BM (rejestrator rozmów) zapisuje znaczniki czasowe pochodzące z MSRP64

QAR podsłuchuje dane cyfrowe przesyłane w MSRP64 pomiędzy blokiem przetwarzania (UP-2-2) a magnetofonem pancernym MŁP-14-5.

Ze względu na sposób kodowania czasu w MSRP64 i danych organizacyjnych (czas, data, numer lotu, numer samolotu) przesyłanych w blokach trwających 5 sekund (10 ramek pomiarowych) QAR dostaje i zapisuje dane z MSRP64 z opóźnieniem ok. 3s

Powyższe rzuca ponure światło na profesjonalizm badawczy komisji Millera.

Już nie wiadomo co gorsze fałszerstwo czy brak profesjonalizmu matematycznego :((



Wiedząc, że czas uderzenia w brzozę wynosił w rzeczywistości

8:41:03,445

a czas TAWS38 6:40:59 (UTC) = 10:41:02,5 (MAK) i 8:41:05,5 (IES)

Można policzyć średnią prędkość na odcinku BRZOZA i TAWS38

Vxśr = (855m-709m)/(5.5s-3.445s) = 71,05 m/s = 255,8 km/h

co już jest bardziej realną prędkością I ZAPEWNIAJĄCĄ LOT, A NAWET WZNOSZENIE SAMOLOTU, niż wyliczane poprzednio:

Vxśr = (855m-709m) / (5.5s-2.8s) = 54,07m/s = 194. 7km/h

czy

Vxśr = (855m-709m)

co jest poniżej prędkości przeciągnięcia, wynoszącej, przy masie samolotu 78 ton i locie na klapach 36 stopni: 204 km/h

Prędkości zanotowane przy TAWS38:

Vgs=268,8 km/h - prędkość względem terenu wyliczana przez odbiorniki GPS I TO JEST WARTOŚĆ co najmniej o 1s wcześniejsza niż dany moment, ze względu na to, że odbiorniki
podają dane tylko raz na sekundę.

Vias=254,3 km/h - prędkość względem powietrza zmierzona z różnicy ciśnienia dynamicznego i statycznego

Vtas=258,2 km/h - prędkość rzeczywista względem powietrza (skorygowana)

Jak widać prędkości zanotowane przy TAWS38 (zmierzone Vias i Vtas) są bardzo zbliżone do tej wyliczonej z POPRAWNYCH czasów przelotów.

===========================================================

Widać w powyższym jak beztroskie obcięcie ułamka a także ogólny bałagan w określeniu poprawnych relacji czasowych spowodowało GRUBY błąd określenia prędkości lotu na feralnym odcinku.


    • zuzkazuzka111 Re: A propos czasu uderzenia w brzozę 28.08.13, 20:33
      Powyższe rzuca ponure światło na profesjonalizm badawczy komisji Millera.
      Już nie wiadomo co gorsze fałszerstwo czy brak profesjonalizmu matematycznego :((


      Zdecydowanie gorsze jest fałszerstwo.
      I to jest fałszerstwo. Od samego początku.
      • absurdello Niestety to jest brak profesjonalizmu i niedbals- 29.08.13, 11:08
        two a nie fałszerstwo i to jest jeszcze gorsze jeżeli spojrzeć na kaliber sprawy. Skoro takie jest w sprawie śmierci prezydenta, to co mogą oczekiwać w swoich sprawach szeregowi obywatele ? Strach się bać.
        • zuzkazuzka111 Re: Niestety to jest brak profesjonalizmu i niedb 29.08.13, 12:03
          absurdello napisał:

          > two a nie fałszerstwo i to jest jeszcze gorsze jeżeli spojrzeć na kaliber spraw
          > y. Skoro takie jest w sprawie śmierci prezydenta, to co mogą oczekiwać w swoich
          > sprawach szeregowi obywatele ? Strach się bać.

          Niestety to z pewnością jest fałszerstwo.

          Ale skoro twierdzisz, że niedbalstwo... Skąd taki zwrot po trzech latach bicia absurdalnej piany.
    • ae911truthorg Dać głupkowi kalkulator. 29.08.13, 14:29
      Powiedz na ten tem coś Artymowiczowi, albo nieomylnemu mankowi - towarzyszowi Amielina.
      Za przeproszeniem, nasikają na twój grób.
      Ale rachuj, rachuj, udawaj inteligentnego.
      Już wiesz gdzie są rewersy w stenogramie MAK ?
      Uuuuuj biduniu, w kalkulatorze tego nie ma ?
      Może sprawdź SMS-y.
      • absurdello Oddziel sympatie polityczne od techniki !!! 30.08.13, 12:20
        Technika ma tę miłą zaletę, że prawa nią rządzące są jak dotąd (a mam nadzieję, że i na zawsze) niezależne od tego czy tych kto w danej chwili dzierży (-żą) ster rządów.

        A wstydzić to może się ten ANALityk co napisał poniższe, a co zawiera trzy błędy: jeden wynikający z niedoczytania a drugi chyba z miernej wiedzy analitycznej, a trzeci z wymieszania wartości.

        Załącznik techniczny nr 4, strona 573 (21/93) u dołu.

        "Z powyższych danych wynika, że czas MSRP jest opóźniony o 3.425 sekundy
        w stosunku do czasu MARS-BM. Do dalszych analiz przyjęto opóźnienie 3 sekundy."

        Błąd 1, to to, że wymieszano MSRP64 z QAR-em.

        Błąd 2, to niedopuszczalne "zaokrąglenie" ofsetu czasowego w dół, przez obcięcie części
        ułamkowej.

        Błąd 3, zmiana kierunku opóźnienia.

        A zależności są takie, że przypomnę:

        FMS i TAWS mają czas satelitarny (UTC) podawany z odbiorników GPS

        MSRP64 (parametryczny) - ma czas ustawiany ręcznie, przez mechanika pokładowego przed każdym lotem. Ze względu na sposób kodowania czasu w zapisach może wystąpić kilkusekundowe przesunięcie pomiędzy czasem wpisanym (tylko godziny i minuty) a tym jaki zostanie wpisany na taśmie (teoretycznie nie więcej niż 5s)

        MARS BM - dostaje znaczniki czasowe z MSRP64, więc jego czas MUSI być zgodny z rejestratorem parametrycznym.

        QAR zapisuje dane przesyłane do magnetofonu MŁP-14-5 (ten w kontenerze pancernym) i musi dekodować czas przesyłany w ciągu cyfrowym co, przy specyficznym systemie kodowania czasu wymusza przechwycenie kilku pierwszych ramek danych by skompletować informacje o czasie, a każda ramka, to kolejne 0.5s opóźnienia. Do tego jeszcze dochodzi
        czas kompresji danych (prawie 10 krotna) do formatu QAR-a

        IES korzystał ze ścieżki czasu QAR-a, bo jego zapisy mieliśmy kilka dni po katastrofie.

        Wystarczy porównać czasy zapisane w TAWS z czasami jego alarmów dźwiękowych w transkrypcjach (godziny sprowadziłem do jednej bazy, by było lepiej widać zależności sekundowe)

        Alarm___UTC_________MAK________IES
        T34___06:40:03___06:40:06,7___06:40:09,6
        T35___06:40:29 ___06:40:32,4___06:40:35,4
        T36___06:40:36 ___06:40:39,4___06:40:42,3
        T37___06:40:43 ___06:40:46,6___06:40:49,5

        Średnie opóźnienie czasu MSRP64 (transkrypcja MAK) względem czasu UTC:

        tofs_MAK = (3.7s+3.4s+3.4s+3.6s)/4 = 3,525 s

        Średnie opóźnienie czasu QAR (transkrypcja IES) względem czasu UTC:

        tofs_IES = (6.6s+6.4s+6.3s+6.5s)/4 = 6,45s

        czyli przesunięcie pomiędzy transkrypcjami IES i MAK wynosi:

        6.45s-3.525s = 2.925s ~ 3s


        Dodatkowo należy uwzględnić przy wszelkich obliczeniach, specyfikę wyznaczania pozycji zapisywanej przy alarmach TAWS, a wyliczanej przez FMS-a.

        Zanotowana przy danym alarmie TAWS, wcale nie oznacza, że to jest pozycja DOKŁADNIE z tej godziny jaka jest przy nim podana !!!

        Moment wystąpienia alarmu jest asynchroniczny względem zmian kolejnych sekund zegara.
        W momencie wystąpienia alarmu do logu zapisywane są aktualne wartości:

        - czasu
        - pozycji
        - inne parametry

        Tyle, że moment "fotografowania" mógł nastąpić równie dobrze tuż po zmianie sekundy, np.

        z 6:40:58 na 6:40:59

        jak i do 0.99999 s po tej zmianie, a w obu przypadkach zapisany zostanie czas 6:40:59, ZA TO POZYCJA BĘDZIE INNA, BO TĘ FMS WYLICZA SOBIE 10 razy na sekundę, czego zapis czasu nie uwzględnia.

        FMS dostaje DOKŁADNE pozycje tylko raz na sekundę, bo tak to przesyłają odbiorniki GPS.

        FMS sztucznie zagęszcza informacje o położeniu wyliczając 10 razy na sekundę przybliżoną pozycję na podstawie pozycji dokładnej oraz prędkości względem terenu i kierunku lotu wysyłając potem do TAWS-a pozycję przybliżoną nazwaną:

        "Present Position Latitude" i Present Position Longitude

        Czyli TAWS dostaje taki ciąg, przykładowo w okolicach TAWS34 (dla uproszczenia pominę
        dane kierunkowe)

        6:40:43,0 - Pozycja dokładna z GPS
        6:40:43,1 - Pozycja szacowana1 = Poz dokładna + 0.1s *Vgs
        6:40:43,2 - Pozycja szacowana2 = Poz. szacowana1 + 0.1s * Vgs
        6:40:43,3 - Pozycja szacowana3 = Poz. szacowana2 + 0.1s * Vgs
        6:40:43,4 - Pozycja szacowana4 = Poz. szacowana3 + 0.1s * Vgs
        6:40:43,5 - Pozycja szacowana5 = Poz. szacowana4 + 0.1s * Vgs
        6:40:43,6 - Pozycja szacowana6 = Poz. szacowana5 + 0.1s * Vgs
        6:40:43,7 - Pozycja szacowana7 = Poz. szacowana6 + 0.1s * Vgs
        6:40:43,8 - Pozycja szacowana8 = Poz. szacowana7 + 0.1s * Vgs
        6:40:43,9 - Pozycja szacowana9 = Poz. szacowana8 + 0.1s * Vgs

        6:40:44,0 - Pozycja dokładna z GPS
        6:40:43,1 - Pozycja szacowana1 = Poz dokładna + 0.1s *Vgs
        6:40:43,2 - Pozycja szacowana2 = Poz szacowana1 + 0.1s *Vgs
        itd.

        Czas zapisywany przy alarmie jest czasem z momentu odczytu pozycji dokładnej ale pozycja zapisana może być jedną z 10 wartości z czasu od 6:40:43.0 do 6:40:43.9.

        Niestety producent TAWS-a nie wpadł na pomysł by notować, z której 1/10 sekundy pochodzi wyliczona pozycja, a zaokrąglenie czasu do całych sekund powoduje duży błąd w wyliczeniach

        Przykładowo dla lotu na odcinku TAWS38 (709m) i brzoza (855m) wpływ rzeczywistego czasu zapisu pozycji 709m widać jak niżej:

        Vxms = (855m-709m)/dt
        Vxkmh = Vxms*3.6

        Brzoza_855___TAWS38_709___dt_____Vxms____Vxkmh
        06:40:57,0 ____06:40:59,0____2,0____73,00____262,8
        06:40:57,0 ____06:40:59,1____2,1____69,52____250,3
        06:40:57,0 ____06:40:59,2____2,2____66,36____238,9
        06:40:57,0 ____06:40:59,3____2,3____63,48____228,5
        06:40:57,0 ____06:40:59,4____2,4____60,83____219,0
        06:40:57,0 ____06:40:59,5____2,5____58,40____210,2
        06:40:57,0 ____06:40:59,6____2,6____56,15____202,2__pr. przec. dla 78ton i klap 36
        06:40:57,0 ____06:40:59,7____2,7____54,07____194,7
        06:40:57,0 ____06:40:59,8____2,8____52,14____187,7
        06:40:57,0 ____06:40:59,9____2,9____50,34____181,2

        We wszystkich przypadkach TAWS zapisze przy TAWS38 godzinę 6:40:59 ale jeżeli położenie nie pochodzi z dokładnie z tej godziny, to wyliczenia prędkości odcinkowej będą z błędem +/-40 km/h jak widać z powyższych wyliczeń.

        A jeszcze trzeba uwzględnić, że w końcówce lotu prędkość się zmieniała w dół więc i dokładność wyznaczania pozycji samolotu z zanotowanych wartości jest obciążona różnymi błędami.


        Nie wiem kto robił "analizy" i wyciągał wnioski w raporcie Millera ale chyba to nie był wzorowy uczeń ;))) Nawet to, że wpisano czasy QAR-a jako czasy UTC świadczy, że nie odrobił lekcji ;)
        • ae911truthorg Z obowiązku, przypomnij że to wina pilotów. 30.08.13, 12:29
          Przesunięcie fraz masz na wykresie Rachowskiego. Jest zmienne od 0do 12 sekund.
          Te swoje porachowane 3 sekundy możesz...chociaż, lepiej nie.

          Jak nie umiesz czytać wykresu, to odłóż kalkulator, bo sobie krzywdę zrobisz.
Pełna wersja