кто нибудь пытался использовать данные из файлов *.70 или их же, но пропущенные через M22TelemetryUnpaker? сразу покажу проблему:
картинка получена в QGIS с проекцией
+proj=ortho +lat_0=49.71923977153 +lon_0=10.175498425043 +x_0=0 +y_0=0 +a=6378136 +b=6356751 +units=m +no_defs из записи пролёта M2-2 2019-08-24 в 13:37:14 (
IQ-файл, 80K OQPSK.)
это попытка решения в лоб — использование списка GCP (контрольных точек) из M2_LRPT_Decoder с задействованной секцией
[GEO]. к слову, хоть бы кто намекнул, что для включения генерации этого списка нужно прописывать параметр
RoughStartTimeUTC в
локализованном виде. в инструкциях "из интернета" дату пишут как MM-DD-YYYY, или DD-MM-YYYY, видел даже MM/DD/YYYY, что и подсказало, что для России нужно использовать DD.MM.YYYY.
список прогоняется через простенький скрипт, который построчно формирует из *.jpg.gcp список контрольных точек для
модуля привязки растра в QGIS или для прямого использования в утилите
gdal_translate из GDAL, получается как-то так:
[code]оригинал:
0 0 39,1400527954102 29,0547142028809
10 0 39,1261596679688 28,5500087738037
20 0 39,1111297607422 28,0761051177979
30 0 39,0952033996582 27,6295413970947
.points для QGIS:
mapX,mapY,pixelX,pixelY,enable,dX,dY,residual
29.054714202881,39.14005279541,0,0,1,0,0,0
26.807228088379,39.061393737793,50,0,1,0,0,0
25.070505142212,38.970878601074,100,0,1,0,0,0
23.656953811646,38.877986907959,150,0,1,0,0,0
список аргументов для gdal_translate:
-gcp 0 0 29.054714202881 39.14005279541 -gcp 50 0 26.807228088379 39.061393737793 -gcp 100 0 25.070505142212 38.970878601074 -gcp 150 0 23.656953811646 38.877986907959[/code]
но что в QGIS, что вручную через gdal-утилиты (gdal_translate для создания GeoTIFF и gdalwarp для перепроецирования) получается картинка как в начале поста: небольшое смещение в центре снимка и значительное смещение ближе к краям, причём в сторону уменьшения долготы. то есть просто равномерно "ужать" фото нельзя.
после появления M22TelemetryUnpaker глянул на формат файлов *.70. в принципе, наполовину разобрался:
[code]struct packet {
// big endian!
char hex[64]; // некие данные
uint32 time1; // здесь и далее, число секунд прошедших с 2016-01-01 00:00:00
uint16 t_year; // год начала "эпохи", обычно 2016
uint16 t_days; // число дней прошедших с 2016-01-01 00:00:00
uint32 time2; //
uint32 time3;
float L0; // очень похоже на кватернион, хранящий вращение
float L1;
float L2;
float L3;
uint32 time4;
double X; // ECEF, координаты
double Y; // ось x направлена от центра эллипсоида в точку 0°N 0°W (центр)
double Z; // y — в 0°N 90°W (восток), z — в 90°N (север)
uint32 zero; // конец пакета ???
}[/code]
если представить 70-й канал как однобайтную картинку, то она выглядит вот так:
вот левая половина и есть эти "некие данные". прослеживается в них некая упорядоченность, но пока не возьму в толк какая.
вот
"программа" на Lua, а вот
табличка без "неких данных". и вот тут возникает куча вопросов.
для начала, можно обратить внимание, что в одном пакете присутствуют четыре разные отметки времени, не считая года и количества дней. предполагаю, что это время получения следующих за отметкой данных.
то, что в M22TelemetryUnpaker обозначено как L0,L1,L2,L3 очень похоже на кватернион,
используемый для хранения вращения, то есть выполняются следующие равенства:
[code]
q.w^2 + q.x^2 + q.y^2 + q.z^2 = 1.0
2arccos(q.w) = 2arcsin(sqrt(q.x^2 + q.y^2 + q.z^2))
[/code]
опять же, предполагаю, что это положение самого спутника в конкретный момент времени, но относительно чего? центра эллипсоида, его радиус-вектора, нормали к поверхности или может расположения центра управления в Москве?..
перехожу к координатам. вопросы были к выбранной системе координат, но методом тыка получилось, что параметры земного эллипсоида из ПЗ-90 (
ПЗ-90.11) и алгоритм перевода XYZ в геодезические координаты оттуда же как нельзя лучше совпадают с алгоритмом, применённым в M22TelemetryUnpaker. но совпадение совпадением, однако даже положение спутника на орбите никак не совпадает с любыми программами, которые рассчитывают орбиту используя TLE-параметры.
на примере картинки из начала поста, непонятки:
* файл .70 содержит 315 записей, конечное время минус начально равно 421 сек.
* данные идут почти всегда с интервалом в 1 секунду, однако имеются лакуны в 1-2 секунды (не считая отсутствия сигнала вообще). утилита весьма странно пытается их заполнить (пример я приводил ранее, как минимум высота скачет на несколько километров), однако в итоговый файл записывается не 421 секунда, а только первые 315. вероятно, банальная опечатка, но без исходников трудно судить о корректности этого действия.
* по данным NORAD апогей и перигей равны
815 и
813 км. ФГБУ "НИЦ "Планета" считает, что высота М2 равна 832 км. алгоритм из ПЗ-90 с учётом полярного сжатия Земли (~21 км) выдаёт высоты от
819 до
824.5 км для фото из начала поста.
* так как XYZ-координаты, предположительно, отсчитываются от центра Земли, то для спутника с практически круговой орбитой расстояния от этого центра должны быть почти равны друг другу. если расчитать длину вектора
(0,0,0)(X,Y,Z), то получается расстояние от
7186 до
7189 км, 3 км разница для пролёта над европейской частью. если взять примеры пролета над экватором, там почему-то выходит около 2 км, а в полярных областях — до 5 км разницы. почему?..
* если попробовать рассчитать орбитальную скорость спутника (
dV/dT, где
dV=sqrt(dX^2 + dY^2 + dZ^2)), то она составляет от
7528 до
7537 км/с, а из формулы орбитального движения
V = sqrt(GM/R) выводится высота спутника от
7017 до
7033 км.
плюс ко всему, спутник снимает не ровно в надире, а с некоторым смещением точки "фокуса", что, получается, и приводит к значительным искажениям генерируемым M2_LRPT_Decoder-ом GCP (контрольным точкам) :((((
куда вообще можно (и можно ли) сообщать об ошибках, предожениях, пожеланиях по "официальным" декодерам?
