Комментарии 32
В точности повторены мои эксперименты и такие же результаты…
Для передачи цифры из простых оказалась самой надежной CW + кодирование Хемминга.
Да, я хотел еще дописать про модуляцию OOK, по сути тот же CW, но в MultiPSK её нет, а делать через GNU Radio не хотелось.
Передача данных по воздуху осуществляется немного сложнее. Если посмотреть стандарт LTE (4G), то он занимает около 10 000 страниц. Если вы действительно хотите что-то передать по какой-то среде, придётся изучить множество теорий и технологий.
А, вот оно что! Спасибо, не знал. Думал, это совсем просто.
Ну, это немного сложнее, чем тыкать кнопочки в рандомной программе.
Если посмотреть стандарт LTE (4G), то он занимает около 10 000 страниц.

В случае передачи по воздуху работает принцип Неуловимого Джо — готовых протоколов передачи нет, т.к. применимость в общем-то отсутствует.

Но в качестве головоломки и развлечения, почему бы и не поэкспериментировать, тема вполне интересная.
По поводу применимости, в интернете обнаруживается масса различных проектов по передаче данных с помощью ультразвука.
В том числе и протоколы связи, например SoniTalk.
Возможно эти протоколы применимы не только для ультразвука.
сигнал проигрывается на ПК, и записывается смартфоном в другом конце квартиры
Многочисленные переотражения в квартире и относительно большая скорость передачи — большие потери как результат.
Так в этом и весь интерес, посмотреть как будет проходить сигнал в таких условиях.
Всё же передача по воздуху, вероятно, проще, чем в воде, можно ведь исключать многолучёвость и ослаблять фоновый шум за счёт использования направленных микрофонов.
Уменшите битрейт передачи — ошибки уменьшатся.
Еще может влиять то, что записываете на смартфон, в нем могут быть различные алгоритмы обработки звука которые мешают. Попробуйте на комьютер необработанный сигнал записать.
Я тоже экспериментировал с передачей данных по воздуху. Предел в моих условиях 1 бит за 10 мс, лучший результат получился с фазовой модуляцией (а самый «мелодичный» метод частотная модуляция, особенно если частоты подобрать на основе нот музыкальных).
При использовании фазовой модуляции можно формировать прямоугольный сигнал, высшие гармоники срезаются естественным образом. Проще писать демодулятор — детектор фазы (если потребуется переносить проект на микроконтроллер, например).
Вот пример с детектора фазы. Приемник генерирует свою опорную частоту и старается подстроить под принятый сигнал, передатчик меняет фазу на +-120 градусов (а приемник старается обеспечивать максимальную корреляцию входного и внутреннего сигнала). Из бонусов троичное кодирование, нулевое изменение +1 и -1. Можно передавать чуть более 1 бита за один раз. На картинке отклонение фазы на каждый отсчет квантования по времени. При изменении фазы входного сигнала внутренний генератор начинает подстраивать фазу на +-0.004 радиана.
image
Около 100 строк на Питоне, достаточно просто. Из математики поиск корреляции перемножением амплитуды сигналов. Хотя тут нужно еще нормализацию входного сигнала продумать, чтобы его амплитуда не влияла.
Как итог эксперимента отмечу, что передавать данные через воздух не сложно. Сложности начинаются при передачи данных на большой скорости или слабом соотношении сигнал/шум, для декодирования требуется уже более сложная обработка сигнала.
Вот эксперименты с частотной модуляцией, интервал 10 мс
image
интервал 28 мс
image
интервал 77 мс
image
При медленной передачи частоты видны «невооруженным глазом» на спектрограмме, при высокой скорости передачи всё сливается в кашу. И видно завал аудиотракта свыше 3300 Гц, многие устройства считают что передавать звуки на такой частоте не нужно и режут спектр ))
Из программ использовал Питон и Sound Forge (любой аудиоредактор что может спектрограммы строить).

Затухание сигнала, начатое на 3.3 кГц, где-то выше по частоте может и прекратиться.
Чтобы проверить возможности канала (источник+среда+приёмник), можно сделать запись тестового сигнала и посмотреть на его спектрограмму.
Вот для примера спектры моего тестового сигнала:


Тестовый сигнал, исходник


Тестовый сигнал, приём #1


Тестовый сигнал, приём #2

Передача данных с помощью звука — настолько глубокая задача, что заниматься ей можно практически бесконечно.
Помимо типа модуляции, на качество приёма влияет выбор несущей частоты, битрейта, громкости, фильтров. Даже от положения динамика и микрофона многое зависит.
Качество оборудования тоже важно. Если микрофон плохой, то для его успешного использования придётся хорошо постараться, настраивая алгоритмы обработки.
Как раз задачу принять и обработать сигнал с плохим оборудованием я как-то себе поставил. Относительно надёжно удалось принять сигнал на скорости 2600 бит/сек, микрофон от наушников находился на расстоянии нескольких сантиметров.
Если увеличивать расстояние, то, конечно, нужно понижать битрейт. Вдруг кто захочет проверить мой вариант алгоритмов кодирования/декодирования — я выложил его на Github — Vort / SoundTransceiver (версия 0.0.2 в релизах, ветка develop), код написан на C#, проверял только под Windows.
По поводу тестирования — короткие сообщения — не лучший выбор. Точнее, их тоже надо проверять. Но на длинных вылазят такие проблемы, которые на коротких не заметишь. Чтобы проверить побольше разнообразных комбинаций бит, можно использовать алгоритм PRBS. Для теста передачи по звуку мне хорошо подошли варианты PRBS9 (63 байта) и PRBS11 (251 байт).
Удивила картинка BPSK, у него же амплитуда должна быть постоянная? Сейчас больше похожа на амплитудную модуляцию.

Да, это амплитудная модуляция. Только амплитуда меняется не от 0 к 1, а от -1 к 1. Умножение же на -1 эквивалентно сдвигу фазы на 180°. То есть, выходит, это и фазовая модуляция тоже.

Умножение на +1 и -1 не меняет максимальной амплитуды, а на скриншоте огибающая для несущей частоты выглядит как синусоида. Я не могу понять почему так.

Могу только приблизительно пояснить. Если жёстко умножать на -1 или 1, то график сигнала будет часто "разрываться", из-за чего сигнал будет занимать всю доступную полосу частот. Поэтому сигнал перед отправкой (да и после приёма тоже) фильтруют. То есть, изменение от -1 до 1 происходит плавно, проходя через ноль. Можно вместо амплитуды менять непосредственно фазу, тогда "провалов" не будет. Но, как я понимаю, это не так удобно.

Да, если просто делать разрыв фазы без изменения амплитуды, получим довольно сильные выбросы на спектре, что и мешает другим сигналам, и зря расходует мощность передатчика.

Картинка

Аналоговый тракт передатчика сам вырежет лишнюю часть спектра. Если передатчик узкополосный, быстрые изменения фазы вообще будут проигнорированы, фаза не успеет изменится.
Если передатчик не ограничивает полосу, тогда да, будет помеха на соседних каналах.
Удивила картинка BPSK, у него же амплитуда должна быть постоянная?

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

Интересно такое же, но с fm модулятором провернуть. Фм радио пока есть в каждом смартфоне

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

Да, в теории это очень правильно. Но когда я попробовал реализовать эквализацию в своей программе, то столкнулся с проблемой "курицы и яйца". Для создания корректирующего фильтра нужно знать хотя бы часть корректно демодулированной последовательности. Но чтобы её получить в плохих условиях приёма, нужен корректирующий фильтр. Можно, конечно, добавить к сигналу известную последовательность бит и попробовать потом найти её (к примеру, корреляцией), но тратить биты данных жалко да и корреляция может не сработать по множеству причин. Усложнять интерфейс программы (добавлением процедуры тестирования канала) или лишаться возможности одностороннего обмена данными (чтобы экземпляры программы могли договориться о фильтре без участия пользователя) тоже не хотелось. Так что желающим реализовать у себя такой подход придётся хорошенько над ним подумать.

Можно, конечно, добавить к сигналу известную последовательность бит и попробовать потом найти её (к примеру, корреляцией), но тратить биты данных жалко
Когда обычный телефонный модем начинает соединение, то он тестирует линию на эхо-сигнал (на Хабре по-моему где то была статья про описание всех шагов при соединении), так и тут можно попробовать сделать «step response»(или что то подобное) импульсной характеристики комнаты.
Есть ещё ЛЧМ-модуляция, о которой в статье я не увидел упоминания. Её преимущество в том, что
а) именно для таких условий она и придумана,
б) равномерно заполняет всю доступную полосу частот.
При должной фантазии, контур котика наверное можно угадать
image

А что вы передавали? JPG? Если так, то понятно почему изображение такое вырвиглазное. Думаю BMP должно быть на порядок лучше.
Нет конечно, передавался сигнал без сжатия, SSTV работает по принципу факса.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.