Есть некие сигналы, принятые с эфира, кодированные FSK (это точно). Приняты с помехами и гармониками, поэтому стандартные средства анализа (ну, например, спектрограмма в sound forge) обламываются - показывают ровный спектр, из которого две частоты выделить не представляется возможным (явных горбов на спектрограмме нету, хотя сигнал почти прямоугольный).

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

Пробовал skysweeper, sound forge, adobe audition, везде дальше спектрограммы дело не продвинулось - непонятно им какие частоты там есть...

Кто-нибудь сможет прогой помочь или самописное писать?..
Пасиба заранее. :)

Да, забыл, пример сигнала можно посмотреть по адресу http://king2.kaluga.ru/files/Sound005.wav :)

Прямоугольные сигналы имеют очень большой спектр. В спектрограмме там ничто не найдеш.
Нужно смотреть так:






Первой логический символ продолжает 98 отчетов.
Второй логической символ продолжает 65 отчетов.

При честоту дискретизаций 44100 Гц получается:
Первой логический символ : 98/44100 =~ 0.0022222...сек. (2.2222... мсек) =~ 450 Гц
Второй логический символ : 65/4100 =~ 0,0014739...сек. (1.4739.. мсек) =~ 678 Гц

Baud Rate - здесь незнаю как определить. Каждой символ имеет разной продолжительности.

Вам нужно только определить которой символ будет лог. 0 и которой будет лог. 1
Если программа не хочет декодировать, можно в ручную в CoolEdit.

На слух кажется что ето 6 пакета которые повторяются.

king2



По меньшей мере там три частоты( 330, 450 и 680 Гц), и похоже это не fsk в своем обычном виде, откровенная прямоугольность импульсов может быть вызвана тем, что запись сделана с выхода дискриминатора, отсюда и масса нечетных гармоник, это может быть какой нибудь вид кодирования(типа манчестерского кода, но это не он, на первый взгляд), 6 полных одинаковых пакетов это верно, помех как бы не видно, на какой частоте принято? Случайно не в районе 433 Мгц?

Про широкий спектр прямоугольных импульсов понял, спасибо. Что-то подобное я и подозревал :) Я пока с обработкой сигналов не "на ты".

Есть ли способ превратить прямоугольный импульсы в синус? Может в каком-нить софте есть такое сглаживание?

По поводу ручного декодирования. Тут дело в том, что вручную я нашел "биты" как минимум трех длительностей (три частоты). Это-то меня и прибило :)

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

Сигнал снимался смикросхемы 31145 (аналог ее вроде бы rx3141, что ли), это, как я понял, специализированная мелкосхема для того, чтобы на вход ей подавать ПЧ, а на выходе получать сразу FSK (прямоугольный TTL).

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

Пока что предполагаю, что это какой-то хитрый трехчастотный FSK плюс трехуровневое кодирование сигнала (то есть не манчестер, не помню просто как называется кодирование).

Ладно, придется видимо самописный декодер писать специально под эту задачку. :)

Я, честно говоря, думал что получу от спектрограммы 2 базовых частоты и все будет ясно и прозрачно. Ошибался :)

Спасибо за помощь!

king2

По поводу частоты 433 Мгц уже тут была тема, http://www.radioscanner.ru/forum/index.php?action=vthread&forum=3&topic=17152

king2

Есть ли способ превратить прямоугольный импульсы в синус? Может в каком-нить софте есть такое сглаживание?

Есть конечно..., пропустить сигнал через ФНЧ с частотой среза по крайней мере не выше 700 Гц, но боюсь что это не улучшит ситуацию, фронты то разумеется сгладятся, но нужно ли это в данном случае?, если это просто вид кодирования, то для декодирования сглаживание фронтов только ухудшит ситуацию...

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

340 Гц ето преамбюлы каждого пакета! Нужны они для синхронизации!

Ramirez

Абсолютно верно... В принципе думаю, можно получить и битовый поток, но как всегда..., что дальше?

http://www.radioscanner.ru/uploader/2005/brelok.wav

Вот 1 пакет, в начале 3 периода 430 Гц для синхронизаций, потом я нашел 51 бита.

Данной wav получил из вашего, сделал 3 раз усиление на 300% и потом нормализация на 33%.

SergUA6
Дальше - декодер на PIC-е :)

Ramirez

в начале 3 периода 430 Гц

В начале 340-330 Гц


Дальше - декодер на PIC-е :)

PIC то он конечно PIC, но нужно знать конкретное значение каждого бита... ;-)

Огромное всем спасибо!

Там действительно 6 пакетов, внутри кодирование длительностью импульса, пакеты разделены импульсами третьей длительности. Написал самопальный декодер, который принимает со звуковухи и декодирует.

Все получилось, структура даных внутри пакета понятна и проста.

Еще раз всем спасибо огромное!

king2

Не... так нечестно, плз пакет в студию(в виде 0 и 1), и его струтктуру по подробнее, завтра кто нить другой будет ковырять такое же... а тут глядишь и хелп под рукой...

Эээ.. во-первых, точные значения пока непонятны (и, возможно, не будут дальше расшифровываться), во-вторых, мне бы не хотелось в интернете светить эту информацию, ибо не хочется разных нежелательных для себя последствий.

king2

О!.., Вам конечно решать, но... тогда к примеру, программы инверсии спектра, как раз без "особых усилий на раз" позволяют услышать скрываемое...

внутри кодирование длительностью импульса
Точно, значит стандартная для подобных устройств OOK манипуляция.
king2
Если не затруднит, все-таки надпись на микросхеме напишите.

Собственно как и ожидалось, мало чего интересного из битового потока можно вывести, в зависимости от того что принимать за 0, а что за 1 получается последовательность из 51 бита или

101001111110011001011011110001000010111111100111111 или

010110000001100110100100001110111101000000011000000

если принять во внимание, что синхронизация осуществляется за пределами этих бит, то это галимая дата, если исходить из того, что нет больше ни каких ухищрений(это конечно условность, они могут и быть), то логично предположить что из 51 бита получаем 17 тетрад, то есть используется 8-миричная арифметика, что дает число из 17 восьмиричных цифр
101 001 111 110 011 001 011 011 110 001 000 010 111 111 100 111 111 = 51763133610277477(восмеричная система) для первого случая или

010 110 000 001 100 110 100 100 001 110 111 101 000 000 011 000 000 = 26014644167500300(восмеричная система) для второго

в принципе это может быть чистым ключем, потому что 17 значное восмеричное число имеет
2 251 799 813 685 247 значений в десятичной системе, что более чем достаточно...

p.s. Разумеется все это условно, так точное значение этих бит, подразумевает точное знание принципов конкретной реализации протокола брелок-базовый блок.

AOR
Надпись на мелкосхеме 31145, выпускает ее Toshiba. Спеков на нее я не нашел, но нашел на другую, которая является полным аналогом первой. Называется она RX3141, выпускается фирмой HiMARK.
Спеки лежат тут: http://www.metatech.com.hk/datasheet/himark/receiver/ific/RX3141.pdf

SergUA6
Пример битового потока с правильной ориентацией 0-1:

000101010011111000100101000110101111000000000101110.
Внутри лежит номер брелока по неясному алгоритму, номер нажатой кнопки, счетчик посылок.

king2

Остается верить Вам на слово, так как я понятия не имею, как кодируется и декодируется инфа в брелках, все что выше это декодирование в лоб...

SergUA6
А, вот Вы про что.

А больше никакого кодирования нет.... последние 16 бит - счетчик, первые сколько-то - номер брелока, посередине кнопки.. :(

В приведенной мною посылке позиция счетчика 32814 - просто последние 16 бит...

king2

Нет, я к тому, что у нас разные последовательности, это может быть в случае если разные брелки(по крайней мере я декодировал этот файл http://king2.kaluga.ru/files/Sound005.wav) или Вами или мной пакет неправильно декодирован...




p.s. Упс... забыл сказать, что в качестве образца взят файл Ramirez'а который "вырезан" из http://king2.kaluga.ru/files/Sound005.wav

SergUA6
Да, посылки разные, с разных брелоков.

Декодировали Вы почти правильно, больше никакой кодировки над этой там нет. Единственное, что короткие импульсы - это как раз нули, а длинные - единицы. В остальном все правильно.

Просто я декодировал со входа звуковухи, а не из wav-файла, видимо попался второй брелок. :)

king2

Ок, теперь полная ясность...

tnx.

p.s. Ну и это..., у меня бы язык не повернулся называть это FSK, производители чипа однако мыслят по другому... ;-)

Брелки которые пользуют Code Hopping при каждом нажатий код меняется.

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