"Покрутил" ручку настройки одного из приемников виртуальной сети http://www.globaltuners.com и наткнулся на такую передачу.
Режим FSK2, разнос частот 850Hz (характерен для сетей NATО). Скорость передачи 75 бод.
Передача происходила сеансами с периодом порядка 100 mS (период в процессе передачи имел небольшие отклонения):


Увеличить

Интересен фрейм длиной 64 бита:


Увеличить

Наименьший по длине ( 8 бит) фрейм выглядит так:


Увеличить

В доступных учетах передачу не нашел.

cryptomaster АКФ вообще-то на одном сеансе явная 853 мс где-то, что ложится на KG-48 STANAG-4481 может какая тестовая или служебная прогонка шифратора, да и по паратмерам похоже.

Увеличить

Mesh
Спасибо за идею. Попробую понаблюдать эту частоту подольше.

cryptomaster
А в УКВ-диапазоне на этом сайте приемники работают?
Интересует 240-270 МГц.

mihalych7
Какие-то работают. Надо искать по списку.

cryptomaster

Обычный RTTY с двумя стопами. ВМС Нидерландов, узел Den Helder:

02a 04b 06a 08b 12a 16y

02a 04b 06a 08b 12a 16y pbb

02a 04b 06a 08b 12a 16y

02a 04b 06a 08b 12a 16y pbb

02a 04b 06a 08b 12a 16y 1415

anre_link Стопа два, сколько стартов и рабочих?

Mesh
Привет!
Один старт, пять информационных. RTTY однако. Плюс, два стопа. Итого, восемь!

anre_link Не получается однако. RTTY не обычный. Период в 106 мс с мелочью есть и это я видел, но один синхро и семь рабочих. Ни как не обычный RTTY. Картинку подальше чуть кину.

Увеличить
И я неправ, один синхро семь рабочих идут через блок, на картинке второй и четвёртый, но в целом блоки разные и не RTTY в том смысле, что два стопа один старт пять рабочих.

Mesh
Он немного кривой, такое бывает. Из-за "кусочно-рванной передачи" (к примеру, ручной передачи), или не соответствия скорости ровно 75 Бодам. Для меня ничего необычного.
1 делим на 75 получаем длительность посылки - 0,013333333333333333333333333333333. Умножаем на 8...
Получаем кадр передачи - 0,10666666666666666666666666666667. Итого передача 8 битная равна 106 мс. Один старт, пять информационных и два стопа.
один синхро и семь рабочих
А читабельный текст, как я получил с декодера RTTY? :)

anre_link Допустим передача или ручная или кусочно рваная, предлагаю посмотреть на второй блок, где синхро или чего там, точно выстроен в линию. Период 106 с копейками, вроде все под 8 бит ложится. Но как-то сомнительно что это ручник, то есть это точно не ручная работа. Кусочно рваная, может быть, проверить надо, хотя смысл не ясен. Пока мутняк. Читабельный текст? Ну да вроде есть что-то, но пока не убедительно, хотя сам текст вроде даже типо частот але или что-то такого. Пока в думках я. В поиске доков.

Вообще так подозрение что декодер просто вырывает те куски которые понимает, остальные просто или пропускает или не отображает. У вас кстати отображено как декодирование, весь файл вроде? Простой подсчёт показывает что в блоке если это RTTY c параметрами как указано, где-то 55 сиволов. В строке должно быть примерно столько ж. В декодированном почти в два раза меньше, то есть каждый второй символ не отображён, где-то что-то не так. Насчёт читабельности вопрос спорный, просто получен регулярный текст. Верный он или неверный вопрос спорный, думаю что неверный и это всё же не RTTY.

Mesh
Второй вариант - использование полторашного стопа. Он выражается в постоянном сдвиге передачи на один бит при накоплении его на демодуляторе. А насчет "рванности" это 100 процентов. При окончании блока информации используется в качестве холостого хода "нажатие" (определение связистов). Поэтому передачу можно идентиффицировать как блочную или к примеру, что каждый 25 знак используется с огромным стопом. Это не верное заключение.
Насчет передаваемой информации - это CARB (Channel Availability Reception System). В одной из веток обсуждалось. Не сомневайтесь... Очень убедительно.

anre_link Поуторных посылок не обнаружено. Так что этот вариант отпадает. Пока мутняк. Чешу репу, ищу доки или вашей правоты или неправоты.

Mesh
Количество переданных символов и отображенных при демодуляции не соответствует лишь потому, что в такой точности не было необходимости.
Декодеры rtty очень капризны, если что-то не то подать будет "сбой" или потеря синхронизации. В данном случае, этого у меня не наблюдалось.

anre_link Ок, сейчас картинки подготовлю, будете разваливать версию свою сами. :) Мутняк в передаче реальный.

anre_link Логично предположить что идет сначала длинный стоп, а потом как это принято в телеграфии передача которая начинается со старта? Если предположить что в начале длинный старт то ещё хуже. Картинка первый блок.

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

Mesh
Все таки Вы заставили меня демодулировать эту "фигню". Ну чего там особенного? Что периодически с использованием некоторых знаков применяется 7 битный знак, а следом за ним обязательно идет 9 битный знак (три стопа), как компенсатор. Вот и весь секрет!

anre_link Я про обычный RTTY, он не обычный. Вы полагаете что в семи битных знаках ничего нет просто так они?

Mesh
Я этой "фигней" сыт по горло. Ничего "тайного" и "значащего" в этом нет.

anre_link Понятно. То есть не услышать мне, что да типо это не обычный телетайп, а с переменной длинной слова, и что декодинг этого как обычного телетайпа 50% инфы просто не отображает? Тайное там чего или нет, это вопросы другого сорта. Я ж не для того что б вас там как-то укорить, просто нужна ясность, в словах это обычный RTTY её нет. Сейчас вроде понятно, но требует проверки. :)

Mesh

что декодинг этого как обычного телетайпа 50% инфы просто не отображает?
Извините, но декодирование данного сигнала проходит 100%, а не 50, 70 или 80%. Как бы Вам хотелось... Если бы Вы регулярно, кроме анализа еще и поиском занимались бы, тогда бы не так удивлялись... Еще бы не такого насмотрелись!
Это 8 битный RTTY с применением на определнных символах 7 битного знака с последующей компенсацией 1 бита в стопе следующего знака. Я повторяюсь... Смотрите выше. Или Вы признаете ответ, ТОЛЬКО ОДИН:"Это необычный RTTY"?

P.S.: Отметьте для себя количество стопов и их вариации на качество приема информации на приемной стороне не влияют... Апппаратура приемная или нормально написанные декодеры "глотают" это не жуя. Находя старт и выдирая последующие пять бит. Разнообразие стопов в различных передачах обусловлено, как правило различными техническими особенностями приемно-передающей аппаратуры и их согласования.

Mesh
anre_link
Понаблюдал за этим сигналом: работает, видимо, круглосуточно, точнее частота в режиме USB 4278 кГц.
Все же это, как подсказал anre_link, передача RTTY с дополнительными компенсирующими стоповыми посылками, преобразующими 7-битовый формат в 8-битовый. Т.е., передающаяя аппаратура рассчитана на 8-битовый формат, куда "втиснули" 7-битовую передачу. Продекодировал передачу в режиме ЧМ, получил битовый поток, который вручную исправил, удаляя "лишние" нули и получил старт-стопную передачу RTTY:



Это же после демодулятора Code 300-32 (сегодня утром):

02a 04b 06a 08b 12a 16y pbb

02a 04b 06a 08b 12a 16y

02a 04b 06a 08b 12a 16y pbb

02a 04b 06a 08b 12a 16y

02a 04b 06a 08b 12a 16y pbb

02a 04b 06a 08b 12a 16y

02a 04b 06a 08b 12a 16y pbb

02a 04b 06a 08b 12a 16y

Saved decoder text at: 8:59:53 2009.06.28.
---------------------------------------
Baudrate: 75 Shift: 850 Center: 2035

Интересно назначение такой передачи, если передаваемая информация почти не изменилась со вчерашнего дня? CARB (Channel Availability Reception System) - информация о "занятости" каналов?

anre_link cryptomaster Ну и классно, вроде разобрались. Тогда ещё уточним малёхо. В сухом остатке получается, это стандартный телетайп, со стопом разной длины? Длина стопа варьируетая от 1 до 3 правильноя я понял? Что в итоге значит это телетайп с одним стартом, пятью рабочими и одним стопом? То есть реально нет там ни каких востьми и девяти битовых символов, и возможно никто ничего никуда не втискивал, просто рваная передача как и указывал anre_link просто изначально не верно определён стоп и длительность символа не 106.6 мс, а 93.3 мс? Или чего-то не так?

Mesh
Возможно "стоп" полуторный, а система не может толком принять его за один ноль или за два нуля...?

cryptomaster Да как-то натянуто, что ж там совсем идиоты получается. Потом принимать-то нужно всё равно надёжно. А вот один старт, пять рабочих, один стоп чудесно и великолепно ложится на надёжный приём без натяжек, просто между символами пауза или один или два такта и по моему даже и больше, вы ж тоже свели удаляя нули к этому формату 1-5-1 или нет?

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

cryptomaster Не погодите, вы можете сказать какой формат у вас в итоге получился? 1-5-1 или 1-5-2? Как это не влияет, если у меня декодер в формате 1-5-2, а стопоый то один то их два то их три, то когда стоп один это срыв синхры, то что там декодер усматривает не один стоп а 1.02 и "решает" что это два стопа, ничего не меняет. Сигнал хороший качественный, как только будет стоп 0.99 этот декодер понесёт пургу. А нормальный в режиме 1-5-1 не понесёт. Вот и всё. Ничего не мутно, если признать что формат 1-5-1, а всякие мутности именно от упорного нежелания разобратся. Вроде уже ясно подходим к реальному положению вещей, а странно, с каким-то упорством всё возвращают назад типо формат 1-5-2 и точка, только потому что это декодится, причём вводятся какие-то мутняки навроде там вообще-то 1-5-2 но иногда "вставляют" 1-5-1 и потом для "компенсации" 1-5-3, вот уж где мутняк конктреный, за каким можно узнать это делать? Если есть отличное логическое обьяснение всех приколов без всяких мутняков, это формат 1-5-1. Удивляюсь я иногда честное слово, ведь никто не говорит что все тупые, и никто не стал тупым от того что ошибался или обшибся. Если мне докажут что там реально 1-5-2, я чего буду упратся что ли? Но это не доказательство Это 8 битный RTTY с применением на определнных символах 7 битного знака с последующей компенсацией 1 бита в стопе следующего знака. это реальный мутняк. Ну так где-то.

Mesh
В процессе корректировки я довел до формата 1-старт, 23456 - код, 7 - стоп. Затем "отсек" старт и стоп, оставив 5-битовый код. Далее, программой ViewBin, декодировал кодом "5-18". Таким образом, некорректированный сигнал имеет, по меньшей мере, один стоповый бит. Удиненные "стопы" телеграфный аппарат воспринимает как "несинхронную" передачу, т.е. аппарат "ждет" (неограниченное время) "стартовый" бит для дальнейшего декодирования. Вопрос только один: откуда берутся эти дополнительные "стопы".

cryptomaster Ок, принято 1-5-1 что и требуется доказать. Тогда имеем, реально обычный телетайп, но не с форматом 1-5-2 как совершенно бездоказательно сказал anre_link, а с абслютно точно форматом 1-5-1. Передача асинхронная, незапрещено, причины, кто его знает их много, может опрос каких кагналов, источников, нет данных - пропуск, это уже не так важно. Важно другое, и это плохо, никому нельзя верить, с чего anre_link решил, что там 1-5-2? Получается ни с чего, просто так, захотелось, подумалось. Нигде он не выказал и тени сомнений, просто банально утверждал и всё. В коде-300 походу режим "baudot" работает с одним стопом, это прикольный ход разработчиков гарантирует пофигизм к длине стопа, уж короче однго бита не будет, а больше ну и ладно, наверно anre_link и повёлся на это, решив, правда не понятн с чего, что там два стопа. Разобрались и хорошо, теперь понятно что там нет ни каких мутняков с "вставками" и "компенсациями". Ну так где-то.
.

Mesh
Все верно, полностью с Вами согласен!