Примерно год назад на этом форуме обсуждалась тема разработки "криптофона". Тема называлась "Проброс канала..." Предполагалась возможность создания ЗАС для обычного сотового.
У меня появилось (увы) свободное время, и эта задача не оставляла в покое. Через какое-то время стало понятно, что для ее решения необходим кодек совершенно необычного типа. Я попытался его изготовить на базе собственной гипотезы о формировании акустического сигнала в речевом аппарате.
Результаты первых (весьма несовершенных проб) представлены:
Исходный сигнал 128Кбит/сек - http://exfile.ru/482652
Сигнал после кодирования/декодирования с потоком 0.25 Кбит/сек, (приведенный к 128Кбит/сек после декодирования) здесь: http://exfile.ru/482653 (слышны погрешности интерполяции, но это уже в процессе устранения)
В данном случае поток- динамический, задержка не более 20 мсек, корреляция кластера и посылаемого фрагмента не хуже 0,975 (Пирсон).
Основное отличие от существующих кодеков заключается в том, что индивидуальные характеристики речи абонента изначально (один раз) отправляются в цифровом виде реципиенту. А дальше идет нормальный обмен с низкой скоростью. Это существенный недостаток, т.к. без этих данных на приемном конце будет голос без индивидуальных особенностей, либо чужой.
К достоинствам, как мне кажется, можно отнести работу исключительно во временной области, т.е. тестовая речь "нарезается" на куски-кластеры, они классифицируются, и получается новый "алфавит", который и передается. Приемник собирает сигнал, интерполирует что нужно, и подает на акустический тракт.
А для базовой задачи (криптофона) можно предложить передавать не цифру, а просто перепутанные кластеры. Т.к. в криптографии я понимаю мало, то предполагаю, что тов. Вернам здесь может быть уместен.
Я писал на почту ув. GeGel, но ответа не было. А форум я немножко захламляю в надежде неформальной экспертизы: нужен ли такой кодек, и для чего он может быть применен. Это важно, т.к. из меня программист как из говна пуля, и до реализации в реалтайме, да еще на смартфоновских процессорах, я это дело точно не доведу. А вкладываться фирмой в неоднозначные перспективы - неразумно.

Сообщение отредактировал Милливольт - Sep 21 2016, 11:27

Народ работает в этой теме (Voice over GSM): http://mttgroup.ch/

Спасибо, будем изучать.

Не получал от Вас ничего в последнее время, возможно, спам-бот резал.

Свой проект я более-менее довел до ума:
web: http://torfone.org/pairphone/indexru.html
github: https://github.com/gegel/pairphone
paper (EN): http://torfone.org/download/pp1a_doc.pdf

По наличию времени портирую код в отладку NUCLEO-STM32F446R с цифровой аудио-шиной к GSM-модулю Quectel M66, а пока код собирается gcc (Linux)/mingw(Windows) для PC с двумя аналоговыми аудио-интерфейсами (необходимо дополнительное USB- или Bluetooth- аудио).
Результаты тестирования на реальных GSM-каналах переменчивые. Например, в одном регионе между абонентами Life baseband-сигнал модема проходит отлично (BER=0.2%), а в другом - даже нет синхронизации (на линии включается дополнительное транскодирование, похоже, NB AMR, не смотря на то, что на обоих сторонах определяются GSM FR кодеки). Так что не все так просто, как рисуют китайцы.

Что касается упомянутого выше проекта, я с ним знаком (первая ссылка в моем paper, есть еще похожие работы, в том числе отечественные), но даный подход не может считаться криптографически надежным и по сути является шифрованием "от младшей сестры". Любые престановки имеют весьма малую фактическую длину ключа и позволяют легко восстановить исходный сигнал, имеющий очень четкую статистику для голоса.

Так что проблема надежного модема, пригодного для реальных GSM сжатых каналов, является теоретически сложной и пока открыта. Лично я считаю, что теоретическая оценка дата-емкости сжатого канала по ссылке 15 неверна, и вряд-ли удастся гарантированно надежно передать поток свыше 600bps. Так что вопрос упирается в исходник MELPE-600 или аналогичных по качеству кодеков.

А я уж было подумал, что Вы меня записали в апологеты старшего брата, в обскуранты и охранители Оруэлловских чудищ.

Насчет пригодного модема: ну, конечно, так. Надо дожимать до 300 и менее бит в секунду - тогда дело точно пойдет. Но существующая модель голосового тракта не способствует разработке таких кодеков.
Кстати, для голоса, характеристики которого записаны ранее и в передатчике и в приемнике, мне удалось получить поток (при дополнительном сжатии выходной цифровой последовательности) около 150 бит/сек (самому неудобно писать такое, бо не поверят). При этом качество не пострадало никак, за исключением замены низкоамплитудных участков сигнала "комфортным шумом".

Спасибо за комментарий, пошел читать Ваши ссылки.

Не хочу давать советы, но:
1. 0.2 - многовато. Для MELP 600, не более 10-3.
2. С BT мы намаялись, что дальше некуда. Может Вам повезёт. В ВТ для режима HF ( а он Вам и нужен) есть неприятный эффект пропадания отсчётов. Для модема это - приговор. Учитывая, что в GSM есть пропадание отсчётов, то делайте выводы. Кстати Вы говорили про джитттер, мне кажется вернее назвать проскальзованием отсчётов.

Позволю себе добавить, что величина джиттера прямо пропорционально (как ни странно) радиочастотному качеству работы (в простейшем случае - расстоянию от соты до телефона). Наши инженеры уверены, что в данном случае гадит собственная ППРЧ канала, но достоверного эксперимента поставить пока не удалось.
Дополнительным подтверждением может быть тот эффект, что у нас (транстелефонная ЭКГ) при плохой GSM связи первым делом слетает синхронизация FSK посылок...

По радиочастотной тематике не я не спец. Могу только сказать, что из Европы, Прибалтики и Кавказа, при тестировании, модем работает вполне устойчиво. Два два часа до дачи в Подмосковье на машине - хорошо. Если настройки M66 выставлены правильно, то ошибки возникают после пропадания вокодерных кадров в самой сети. Я делали пакетную передачу, это не классический модем.

MELP600 у меня, к сожалению, нет, не могу оценить. MELP1200 вполне толерантен к 2*10-2.



Да, BT только в качестве гарнитуры. Для линии подойдет USB-аудиокарта.



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



А какая у Вас модуляция используется, если не секрет?

Могу лишь сказать, что одна из стандартных. Тут дело не в конкуренции, просто не вольно мы можем выпустить джина из бутылки. Это весьма специфическая область на бытовом уровне не применимая. Посудите сами как после качественного голоса в обычном мобильном выглядит речь на 1200 и тем более 600 bps? Тем не менее эта проблематика, думаю, имеет право на жизнь. Можно долго спорить на какую скорость можно выйти, но мой опыт показал, что практически всегда гарантированно достигается 800bps. Да, 1200+ хорошо работает если на приеме и передаче установлен EFR, не вопрос. НО! сеть не всегда не предоставляет такой режим. FR- практически всегда.

Всем доброго времени суток!
Очень интересная тема здесь обсуждается! Такие мизерные битрейты просто обескураживают, автору респект!
Но почему-то у меня возникла ассоциация с фильмом "В круге первом", там разрабатывали шифрованную телефонию для Сталина.
Мне кажется, что использование криптографии в телефонной связи - вещь весьма специфическая и вряд ли во-первых необходимая для 99 процентов населения, а во-вторых безопасная с точки зрения заинтересованности в личности шифрующихся индивидуумов соответсвующих органов. Поэтому, для кого китайцы разрабатывают свои крипто-девайсы, не совсем понятно. Ну это мое ИМХО, возможно, я чего-то не понимаю в жизни.

К сожалению, Вы совершенно правы. Разработка подобных вещей для гражданского применения и бессмысленна, и грозит неприятностями в случае успеха. Не знаю побудительных мотивов ув. GeGel, а у меня их два: в случае успеха получится великолепный компрессор для ЭКГ, позволяющий к тому же при необходимости передать через любой(!) акустический канал фрагмент Холтеровской записи в условиях, описанных ( http://tredex-company.com/ru/kak-rabotaet-telecard ). Второе - простое любопытство: речь ведь энергетически неоптимальна как вследствие узкой базы сигнала, так и высокого пик-фактора (эволюция не довела до совершенства). А низкобитрейтовый оптимизированный для канала связи сигнал будет иметь более высокий энергетический потенциал линии. И это может быть интересно для радиолюбительской связи.

1. Научно-техническое творчество - абсолютная ценность, тут и обсуждать нечего.

2. Такие вещи полезны для общества как естественный противовес против тотального перевеса в игре одного субъекта по отношению к другим субъектам.

Очень интересная ИМХО тема, жаль что заглохла.

Тоже сейчас занимаюсь передачей/приемом голоса с помощью вокодера и RFM96.

В качестве вокодеров использую собственные моды на базе Codec2 и MELP.
У Codec2 битрейт 300 бит/с, у MELP 600 бит /с.

В первом варианте: дальность больше, качество речи ниже.
Во втором наоборот.

Ссылка на тему в другом форуме (на подобие дневника): http://vrtp.ru/index.php?showtopic=27904&st=90

Вопрос аудитории: можно ли радиолюбителю физ-лицу купить проприетарные кодеки на DSPINI и работать с сорцами под NDA?

Спасибо за ссылку, очень интересно.
Справедливое (по Вашей ссылке) замечание о неуниверсальности решения с предварительной отправкой "алфавита" в цифровой форме.
Пытаюсь обойти эту трудность - сделать алфавит универсальным. Пришлось отказаться от иллюстраций во временной области - звук, увы, в этом случае становится "вокодерным".
В общем, для любительской связи, как мне кажется, дело может оказаться перспективным. Здесь есть важная деталь: для нешифрованной речи нет смысла стремиться к сверхнизкому битрейту: главное, чтобы сигнал помещался в отведенной полосе и имел более низкий пик-фактор, чем речь. Кроме того, если удастся реализовать на приеме "идеального наблюдателя" плюс нечувствительность к пропаданию пакетов, то энергетический выигрыш в цифровой радиолинии может быть больше, чем у сверхнизкоскоростных кодеков.
Результаты экспериментов для скорости 800 бит/сек и разных вероятностей ошибки (модуляция - двухчастотная FSK, требуемая полоса - 400...2400Гц). Слова, понятное дело, выбраны несуществующими для оценки разборчивости.

1. Исходный кодированный/декодированный сигнал http://exfile.ru/483068
2. Ошибка 1*10-1 http://exfile.ru/483065
3. Ошибка 5*10-1 http://exfile.ru/483066
3 Ошибка 8*10-1 http://exfile.ru/483067




Сообщение отредактировал Милливольт - Nov 6 2016, 10:53