На главную страницу сайта
· Наш магазин · Объявления · Рейтинг · Статьи · Частоты · Копилка · Аэродромы · Live!
· Файлы · Диапазоны · Сигналы · Музей · Mods · LPD-форум · Клуб · Радиостанции
На сайте: гостей - 74,
участников - 5 [ Gvozdenis, toxa1983, briz, un8fr, sasha555]
 · Начало · Опросы · События · Статистика · Поиск · Регистрация · Правила · FAQ · Галерея ·
 Форум —› Главный раздел —› Прием LRPT погодных снимков со спутника Meteor-M2 
Различные приборы, оборудование, спутниковые и радиотелефоны!


Усилители сигнала и мощности

Усилители сотовой связи

Металлоискатели

Радионяни и видеоняни

Измерители КСВ и мощности
 Страница:  ««  1  2  ...  136  137  138  139  140  141  142  143  »»Поиск в теме
Автор Сообщение
TSSDR
Участник
Offline2.4
с сен 2013
Ростов-на-Дону
Сообщений: 549

Дата: 25 Авг 2019 12:59:47 · Поправил: TSSDR (25 Авг 2019 13:30:22) #  

Artlav
Задержка должна быть от 0, 2048 до 2048 х 35 в зависимости от ветки.
Ничего по отношению к предыдущему в этом плане не изменилось.
Покажите код. Помогу чем смогу.
Из доков
mur
Участник
Offline0.0
с апр 2019
Мурманск
Сообщений: 16

Дата: 25 Авг 2019 13:56:12 · Поправил: mur (25 Авг 2019 14:19:43) #  

Artlav
Спасибо что вы развиваете свой проект.
Artlav
Вся моя система работает на orange pi+ и debian 9 x86_64.
Есть еще один проект.
dbdexter-dev
У парня тоже возникли проблемы с декодером.
Может у вас все получится и будет счастье приема Meteor M2-2 :)
Реклама
Google
Artlav
Участник
Offline1.0
с мар 2017
Москва
Сообщений: 14

Дата: 25 Авг 2019 15:54:25 #  

TSSDR
На входе уже синхронизованные данные, после удаления маркеров:


const
inter_branches=36;
inter_delay=2048;

procedure deinterleave(raw:pbytea;sz:integer);
var src:array of byte;
pos,i,s:integer;
begin
setlength(src,sz);
move(raw[0],src[0],sz);

for i:=0 to sz-1 do begin
s:=inter_branches-1-(i mod inter_branches);
pos:=i+s*inter_delay;
if pos<sz then raw[pos]:=src;
end;
end;


[i]Ничего по отношению к предыдущему в этом плане не изменилось.

Если верить dbdexter-dev, то добавилось ещё дифференциальное кодирование.
И правда, записи 72к стали расшифровываться, когда я его добавил.
Так что всё же подозреваю, что не всё тут так чисто.
TSSDR
Участник
Offline2.4
с сен 2013
Ростов-на-Дону
Сообщений: 549

Дата: 25 Авг 2019 19:15:41 #  

Artlav
Форматы передачи не полностью идентичны. Но в части перемежителя изменений нет.
Отправил пример в личку.
hhrhhr
Участник
Offline1.0
с авг 2013
Новгород Великий
Сообщений: 14

Дата: 25 Авг 2019 19:48:51 · Поправил: hhrhhr (25 Авг 2019 19:52:13) #  

кто нибудь пытался использовать данные из файлов *.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 (контрольным точкам) :((((

куда вообще можно (и можно ли) сообщать об ошибках, предожениях, пожеланиях по "официальным" декодерам?
hhrhhr
Участник
Offline1.0
с авг 2013
Новгород Великий
Сообщений: 14

Дата: 25 Авг 2019 20:46:53 #  

p.s.
к слову, одно наиполезнейшее "свойство" 70 канала для целей геопривязки можно использовать уже сейчас. достаточно прочитать значения time1 и t_year в первом пакете, чтобы получить параметр RoughStartTimeUTC для M2_LRPT_Decoder или для скрипта загрузки ближайшего TLE-файла по выбранной дате-времени.
Artlav
Участник
Offline1.0
с мар 2017
Москва
Сообщений: 14

Дата: 25 Авг 2019 22:04:23 #  

Итак, поддержка нового Метеора в medet добавлена.
https://github.com/artlav/meteor_decoder

Для 72к надо -diff, для 80к -diff -int.
Плюс обновил APIDы по умолчанию.
marquis
Участник
Offline5.0
с окт 2006
Москва
Сообщений: 5738

Дата: 25 Авг 2019 22:15:49 #  

hhrhhr
Artlav
Читая ваши сообщения, вспоминаешь, что находишься на радиоТЕХНИЧЕСКОМ форуме )

Для простых смертных: вышла новая версия LRPTdecoder v.54. Предыдущая так и не смогла "побороть" черные полосы на снимках с М2-2. Посмотрим, как новая справится:

https://web.facebook.com/groups/Satellite.apt.group/permalink/1247205522129547/
hhrhhr
Участник
Offline1.0
с авг 2013
Новгород Великий
Сообщений: 14

Дата: 25 Авг 2019 23:12:14 #  

Artlav
пока у вас пыл не угас — нет ли желания добавить возможность сохранения 70 канала (аналог APID70=yes)?
happysat77
Участник
Offline0.0
с авг 2019
Нидерланды
Сообщений: 14

Дата: 25 Авг 2019 23:36:00 #  

M2 LRPT декодер V54:

- Улучшен режим 80К.

http://happysat.nl/LRPT_Decoder_v54.zip
Artlav
Участник
Offline1.0
с мар 2017
Москва
Сообщений: 14

Дата: 25 Авг 2019 23:56:11 #  

hhrhhr
добавить возможность сохранения 70 канала

Так, а я немного не в теме. Что надо оттуда сохранять?
Сейчас я из него только бортовое время беру.

Ещё смутно помню, что пару лет назад я пытался декодировать что-то на тему отслеживания передвижения песцов по арктике, но не уверен с этого ли спутника.
hhrhhr
Участник
Offline1.0
с авг 2013
Новгород Великий
Сообщений: 14

Дата: 26 Авг 2019 00:24:16 #  

Artlav
а я немного не в теме. Что надо оттуда сохранять?

гмм... у вас в функции progress_image есть строка if apd=70 then exit;. в процедуре parse_70(p:pbytea;len:integer) вы именно оттуда берёте часы-минуты-секунды, весь же "блок" или "пакет" занимает ровно 128 байт. вот его бы, вместе с остальными его товарищами, и хотелось бы в итоге получить.
Artlav
Участник
Offline1.0
с мар 2017
Москва
Сообщений: 14

Дата: 26 Авг 2019 03:22:01 #  

hhrhhr
весь же "блок" или "пакет" занимает ровно 128 байт. вот его бы, вместе с остальными его товарищами, и хотелось бы в итоге получить.
Тобишь просто их сбрасывать в отдельный файл, подряд, не декодируя?
Счас добавлю...
TSSDR
Участник
Offline2.4
с сен 2013
Ростов-на-Дону
Сообщений: 549

Дата: 26 Авг 2019 08:44:08 #  

Посмотрим, как новая справится
На самом деле от декодера тут мало зависит.
Для перемежителя необходимо точное согласование символьной скорости на большом промежутке времени(даже при пропадании сигнала). Иначе выпадение или добавление даже одного бита приводит к полной непригодности всех накопленных в буфере данных.
Олег добавил функцию восстановления потерянных бит, но в потоке перемежителя практически отсутствует информация которая поможет точно восстановить сколько бит утеряно, посему результат работы этой функции не гарантирован. Алгоритм моего демодулятора не способен выдать требуемую стабильность. Он синхронизируется по принимаемому сигналу и при его отсутствии или низком уровне возможны сбои. Плюс возможная потеря данных на свистке и USB. Вообщем с данным демодулятором от проблем с 80К вряд ли полностью избавимся. Надо менять алгоритм демодулятора.
UA1CFM
Участник
Offline1.0
с окт 2018
Кириши
Сообщений: 29

Дата: 26 Авг 2019 14:23:26 #  

M2.2 переключился на 137.100
happysat77
Участник
Offline0.0
с авг 2019
Нидерланды
Сообщений: 14

Дата: 26 Авг 2019 20:47:37 #  

M2 LRPT декодер V55:

- Исправление геореф.

Альфа - угол обзора камеры
Дельта - смещение линии

С помощью Delta отцентрируйте береговую линию на изображении.
Затем, изменив Alfa, вы можете расширить / сжать изображения в строке.

При выборе дельты имейте в виду, что изменение 1 приведет к сдвигу примерно на 1 км.

Пример:

[GEO]
RoughStartTimeUTC=26-8-2019
TleFileName=D:\SDR\Meteor\LRPT_Decoder\M2-2.txt
Alfa_M2=110.8
Delta_M2=32
Alfa_M22=110.8
Delta_M22=32


http://happysat.nl/LRPT_Decoder_v55.zip

Спасибо Олегу.
AlDiF
Участник
Offline1.3
с окт 2014
Москва
Сообщений: 135

Дата: 26 Авг 2019 23:21:50 #  

Доброго времени суток!
Завтра, примерно в 8:40 - 8:45 на Метеоре 2-2 отключим передатчик М. Это в рамках испытаний, никаких проблем с бортом нет. Включим через 2-3 витка. Частота, режим работы и каналы те же, что и сейчас. Через пару дней начнем подключать ИК каналы в разных комбинациях.
Всем удачи. Спасибо за вашу увлеченность и информацию!
hhrhhr
Участник
Offline1.0
с авг 2013
Новгород Великий
Сообщений: 14

Дата: 27 Авг 2019 00:13:52 · Поправил: hhrhhr (27 Авг 2019 00:33:20) #  

M2 LRPT декодер V55:
- Исправление геореф.


ура! с десятой попытки подобрал значения для М2-2
Alfa_M22=110.0
Delta_M22=-4.8


.


дальше нужно подбирать десятыми, если возникнет такая потребность.
hhrhhr
Участник
Offline1.0
с авг 2013
Новгород Великий
Сообщений: 14

Дата: 27 Авг 2019 01:20:57 #  

как говорят, если вам интересен процесс получения таких картинок с геопривязкой.

1) после M2_LRPT_Decoder v55 нужны картинка и список GCP.

2) потребуется пакет утилит GDAL

3) .gcp файл необходимо переделать из строчного формата "X Y Lat Lon..." в линейный формат "-gcp X Y Lon Lat...".
вот скрипт на Lua, который дополнительно фильтрует контрольные точки.
запуск: lua gcp2gdal.lua <filename.gcp> [sparse_x [sparse_y]], по умолчанию разреживает сетку до 50 точек по горизонтали и 200 точек по вертикали.
на выходе файл filename.gcp.gcps

4) для внедрения списка GCP во временный файл используется утилита gdal_translate:

gdal_translate --optfile <filename.gcp.gcps> -of GTiff <input_image> <output.tiff>

для уменьшения размера полученных TIFF-ов можно добавить опции -co "COMPRESS=LZW" -co "PREDICTOR=2" -co "NUM_THREADS=ALL_CPUS"

5) самое интересное — перепроецирование. для начала нужно определить с "центром". это могут быть координаты центра снимка (если вы, как и я, используете чужие данные) или координаты вашего приёмника. после определяемся с нужной проекцией в формате PROJ и используем утилиту gdalwarp для итогового колдунства. пример cmd-файла для Windows:

rem исходная проекция, без её указания gdalwarp не работает. эллипсоид взят из ПЗ-90
set S_PROJ="+proj=longlat +a=6378136 +b=6356751 +no_defs"

rem целевая проекция, здесь - ортографическая с центром в lat_0 и lon_0
set T_PROJ="+proj=ortho +lat_0=45 +lon_0=-75 +x_0=0 +y_0=0 +a=6378136 +b=6356751 +units=m +no_defs"

rem фильтры в порядке увеличения качества: near, bilinear, cubic, cubicspline, lanczos...
set RESAMPLE=lanczos

rem параметры перепроецирования, 'tps' обязателен!
set WARP_OPT=-r %RESAMPLE% -tps -overwrite -dstalpha

rem запуск
gdalwarp %WARP_OPT% -s_srs %S_PROJ% -t_SRS %T_PROJ% "output.tiff" "output_ortho.tiff"


на выходе имеем output_ortho.tiff в выбранной проекции с геопривязкой, на который уже можно накладывать любые векторные данные при помощи утилиты gdal_rasterize. сами данные можно безвозмездно скачать отсюда — https://www.naturalearthdata.com/downloads/ , три варианта детализации.
sakhalin2004
Участник
Offline3.1
с апр 2012
г.Оха Сахалинской области
Сообщений: 728

Дата: 27 Авг 2019 01:30:37 #  

hhrhhr
Спасибо за ЛикБез... :)
_Hack_
Участник
Offline1.4
с сен 2015
Тверь
Сообщений: 172

Дата: 27 Авг 2019 09:23:41 #  

Коллеги, добрый день.
54-я версия декодера у всех так отрабатывает? Или только у меня:

-

-


На выходе без изменений:
27.08.2019_09.08_MSK_Метеор-М2_Тверь
marquis
Участник
Offline5.0
с окт 2006
Москва
Сообщений: 5738

Дата: 27 Авг 2019 10:17:25 #  

_Hack_
Доброе утро. В 12.30мск ожидается перезагрузка ФЦП на М2.
f5rhe
Участник
Offline0.0
с июл 2019
La Rochelle ouest france
Сообщений: 21

Дата: 27 Авг 2019 13:05:27 #  

Hack
Quel est l usage du ftp ???
AlDiF
Участник
Offline1.3
с окт 2014
Москва
Сообщений: 135

Дата: 27 Авг 2019 13:25:47 #  

Перезагрузка прошла, картинка восстановилась. Спасибо за информацию!
AlDiF
Участник
Offline1.3
с окт 2014
Москва
Сообщений: 135

Дата: 27 Авг 2019 13:31:38 #  

Примерно в 13:50 восстановим сигнал на М-2-2 на 137.1
f5rhe
Участник
Offline0.0
с июл 2019
La Rochelle ouest france
Сообщений: 21

Дата: 27 Авг 2019 13:35:04 #  

la 54 eme version fonctionne bien....
happysat77
Участник
Offline0.0
с авг 2019
Нидерланды
Сообщений: 14

Дата: 27 Авг 2019 18:14:38 · Поправил: happysat77 (27 Авг 2019 18:15:33) #  

Благодаря hhrhhr использование значения -4,8 для M-N2-2 ставит все границы в идеальное положение!

http://happysat.nl/Meteor_M-N2-2/comp-UTM-2019-8-27-14-28-27-211_RGB.jpg
_Hack_
Участник
Offline1.4
с сен 2015
Тверь
Сообщений: 172

Дата: 27 Авг 2019 20:35:51 #  


Hack
Quel est l usage du ftp ???

Коллеги, добрый вечер.
Чего то не пойму, что от меня интурист хочет. Заранее спасибо.
f5rhe
Участник
Offline0.0
с июл 2019
La Rochelle ouest france
Сообщений: 21

Дата: 28 Авг 2019 08:14:15 · Поправил: f5rhe (28 Авг 2019 08:18:34) #  

hack
cher amis
dessole je ne parle pas russe
je me suis mal exprimé,vous parler de remise en route du ftp sur M2
à quoi sert le ftp ,, forward transfert protocole..merci
marquis
Участник
Offline5.0
с окт 2006
Москва
Сообщений: 5738

Дата: 28 Авг 2019 08:57:55 #  

f5rhe
Bonjour. Hier, des bandes noires ont été notées sur les images du M2. Il a fallu redémarrer le Shaper de flux numérique à bord du satellite. En russe - формирователь цифрового потока (ФЦП).
Реклама
Google
 Страница:  ««  1  2  ...  136  137  138  139  140  141  142  143  »» 

Создавать сообщения могут только зарегистрированные участники форума.
Войти в форум :: » Логин » Пароль
Начало
Средства связи, рации. Купить радиостанции Motorola, Yaesu, Vertex, приемники, антенны.
Время загрузки страницы (сек.): 0.136; miniBB ®