Как передавать звук при помощи Meshtastic

Тип статьи:

Перевод

Источник:

Пару дней назад я разговаривал с другом о том, как работает Meshtastic. Он небрежно спросил: «А почему ты не можешь отправлять аудио?» Я объяснил, что пропускная способность просто недостаточна, поскольку устройство работает на низкоэнергетических частотах ниже 1 ГГц. Эти частоты дают нам потрясающий диапазон, но сопровождаются серьезными ограничениями по данным — речь идет о килобайтах в минуту, а не о мегабайтах в секунду, к которым мы привыкли в современных средствах связи.

Чуть позже я заметил в документации Meshtastic кое-что интересное — предустановленный режим для LoRa под названием SHORT_TURBO (описанный как «Самый быстрый, с самой высокой пропускной способностью, самым низким временем передачи и самым коротким радиусом действия. Использование в некоторых регионах запрещено из-за пропускной способности 500 кГц»).

Это заставило меня задуматься: если мы можем отправлять текст очень быстро (хотя «быстро» в терминах LoRa все еще не так быстро), почему мы не можем отправлять аудио или голосовые заметки?

Предыдущие обсуждения с разработчиками

Около года назад мы обсуждали вопрос передачи аудио с разработчиками Meshtastic, и, что вполне понятно, они не были в восторге от этой идеи. Представьте, что для отправки голосового сообщения нужно удерживать частоту в течение 30–60 секунд — это привело бы к сбою всей сети и сделало бы ее ненадежной, особенно с учетом того, как растет сообщество Meshtastic. Это могло бы серьезно ухудшить производительность для многих пользователей.

Разработчики указали, что LoRa была разработана для небольших, нечастых пакетов данных, а не для потокового мультимедиа. Стандартная конфигурация Meshtastic может допускать только 5–20 байт в секунду в зависимости от настроек и условий. Сравните это с примерно 8 килобайт в секунду, необходимыми даже для самого сжатого голосового аудио, и вы поймете проблему.

Но в то же время я очень хотел протестировать это. Я просто хотел посмотреть, сможем ли мы это сделать. Может быть, кто-нибудь придумает хороший способ оптимизировать это для производства в конечном итоге.

Первоначальный план

Учитывая эту задачу, я начал думать о подходах. Я, конечно, не хотел создавать собственную прошивку и приложение с нуля — это определенно вышло бы за рамки проекта на выходные.

Поэтому я подумал: если мы можем отправлять сообщения, то почему бы не преобразовать аудио в текст, отправить текст, а затем преобразовать его обратно в аудио? На бумаге это казалось выполнимым.

Будучи программистом-энтузиастом, я активировал свою подписку LLM за 20 долларов и приступил к работе. Я запросил код Python для взаимодействия с библиотекой Meshtastic, чтобы записывать голосовые заметки, преобразовывать их в текст и отправлять, планируя, что принимающий узел преобразует их обратно в аудио.

Ограничения библиотеки Meshtastic

Сразу после реализации решения я получил ошибку: сообщение превышает 256 байт. Это было ожидаемо — это ограничение, четко указанное в приложении iOS и везде, где нельзя отправлять длинные сообщения.

Ошибка возникла из-за проверок валидации библиотеки Python:

if len(encoded_message) > 256:
    raise Exception(f"Message exceeds maximum size of 256 bytes (was {len(encoded_message)} bytes)")

Я подумал: «Хорошо, может быть, если я смогу преодолеть ограничение библиотеки, устройство отправит его». Поэтому я проанализировал код библиотеки и удалил проверку валидации. Я записал голосовой образец, отправил его, и в журналах появилась запись «отправлено успешно». Но подождите — на другом конце ничего не было получено. Похоже, что в прошивке устройства также есть проверка.

Попытка с пользовательской прошивкой

После дополнительного изучения я обнаружил, что прошивка имеет константу Protocol Buffer, которая определяет длину сообщения. Определение protobuf в прошивке ограничивало размер сообщения:

/*
   * From mesh.options
   * note: this payload length is ONLY the bytes that are sent inside of the Data protobuf (excluding protobuf overhead). The 16 byte header is
   * outside of this envelope
   */
  DATA_PAYLOAD_LEN = 233;

Поэтому я поступил так, как поступил бы любой здравомыслящий человек — клонировал репозиторий, изменил значение DATA_PAYLOAD_LEN на 150000, перекомпилировал прошивку, перепрошил два устройства и попытался отправить еще одно сообщение.

Что произошло? Ничего — тот же результат. В журналах отображалось сообщение «сообщение отправлено успешно», но на принимающей стороне ничего не появлялось. После дополнительного исследования я обнаружил, что в стеке есть несколько уровней проверки.

Просто донельзя

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

Я подумал: «Хорошо, давайте преобразуем голосовую заметку в текст, разбиваем ее на части, чтобы она не превышала ограничение, и отправляем по частям с некоторыми метаданными, чтобы мы могли собрать ее по частям на другой стороне». С помощью моего LLM за 20 долларов я настроил несколько заранее определенных размеров частей и уровней сжатия.

Техническая реализация выглядела примерно так:

Запись аудио с помощью PyAudio с частотой 8 кГц, моно, 16-битный PCM.
Сжатие аудио с помощью различных алгоритмов сжатия:
«Очень низкое» качество: экстремальное сжатие MP3 со скоростью 8 кбит/с.
«Низкое» качество: сжатие MP3 со скоростью 16 кбит/с.
«Среднее» качество: сжатие MP3 со скоростью 32 кбит/с.
«Высокое» качество: сжатие MP3 со скоростью 64 кбит/с.
Разделить сжатые данные на фрагменты с заголовками метаданных:
Небольшие фрагменты: 150 байт полезных данных на сообщение.
Средние фрагменты: 200 байт полезных данных на сообщение.
Большие фрагменты: 230 байт полезных данных на сообщение.
Отправить каждый фрагмент как отдельное сообщение.
На принимающей стороне собрать фрагменты и воссоединить их, когда все будут получены
Распаковать и воспроизвести аудио

Добавить заголовки последовательности к каждому фрагменту:

VOICE|[total_chunks]|[chunk_number]|[compression_level]|[payload]

Тестирование подхода с использованием фрагментов

Я записал голосовую заметку с максимальным сжатием (качество «Очень низкое») и средним размером фрагмента. Система начала отправлять «1/27 фрагментов» и продолжала это делать. И что вы думаете? На другом конце я начал получать фрагменты! Через некоторое время на приемнике появился индикатор голосовой заметки.

Однако, когда я попытался ее воспроизвести, это просто разорвало мне уши — было очень много шума. Сжатие было слишком агрессивным, что привело к значительным аудиоартефактам. Поэтому я немного уменьшил сжатие до «низкого» качества и попробовал еще одну запись. На этот раз было около 200 чанков, поэтому на передачу ушло добрых минуту-две. Но потом она появилась на другом конце, и когда я нажал «воспроизвести»… голос прозвучал четко! Это сработало! Я действительно смог отправить аудио через Meshtastic.

Технический разбор того, что сработало лучше всего:

«Очень низкое» качество сжатия (8 кбит/с MP3)
«Небольшие» фрагменты (150 байт)
1-2-секундные голосовые сообщения давали около 50-60 фрагментов
Общее время передачи: примерно 30-120 секунд

Потенциал

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

Сейчас это не поддерживается приложением для iOS, но, тем не менее, это возможно! Это может перегрузить сеть, но суть в том, что мы можем это сделать. Нам просто нужно найти умный способ сделать это, сохранив справедливость сети Meshtastic для всех.

Ограничения

Код ни в коем случае не является стабильным. Иногда при больших размерах блоков, например 400, отправка начиналась, но на полпути принимающий узел переставал получать блоки. Я пробовал ждать подтверждений, но тогда отправка чего-либо занимала бы вечность.

Вот основные технические ограничения, с которыми я столкнулся:

Проблемы с надежностью: без надежной системы подтверждения часто терялись фрагменты.
Перегрузка сети: отправка нескольких фрагментов подряд приводила к перегрузке сети.
Временные ограничения: для передачи 10-секундного аудиоклипа требовалось 1–2 минуты.
Влияние на батарею: непрерывная передача значительно сокращала срок службы батареи устройства.
Качество звука: даже при «низком» качестве звук был заметно сжат.
Сокращение дальности: в режиме «SHORT_TURBO» дальность значительно сокращалась.

Возможно, можно было бы реализовать что-то похожее на то, что используется в FTP или HTTPS, чтобы продолжить загрузку с того места, где она была прервана. Опять же, я выхожу за пределы того, для чего был разработан Meshtastic.

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

Еще один момент, который следует учитывать, — это то, что аудиоданные довольно велики для LoRa. Так что забудьте о чем-либо большем, чем 5-10 секунд приемлемого качества. Стоит ли это того? Вы можете получить большую пропускную способность при меньшем диапазоне, но тогда почему бы просто не использовать УВЧ- или ВЧ-радио?

Хотите попробовать сами?

Если вы любите приключения и хотите поэкспериментировать с голосовыми сообщениями через Meshtastic, я разместил приложение для проверки концепции на GitHub: https://github.com/TelemetryHarbor/meshtastic-voice-messenger

Важно: это исключительно доказательство концепции, не предназначенное для использования в производстве. Передача данных ненадежна и служит в первую очередь для демонстрации возможности.

Особенности Meshtastic Voice Messenger:

Запись голосовых сообщений настраиваемой длины.
Сжатие аудио с использованием различных настроек качества.
Разделение больших сообщений на фрагменты для передачи.
Сборка полученных фрагментов в полные аудиосообщения.
Воспроизведение полученных голосовых сообщений
Отправка тестовых сообщений для проверки связи
Подробная регистрация для отладки

Требования:

Python 3.7+
Устройство, совместимое с Meshtastic (например, T-Beam, Heltec, LilyGo)
Необходимые пакеты Python: meshtastic, pyaudio, numpy, tkinter

Быстрая настройка:

— Склонируйте репозиторий:

git clone https://github.com/TelemetryHarbor/meshtastic-voice-messenger.git
cd meshtastic-voice-messenger</code><br>
 — Установите необходимые пакеты:<code>pip install meshtastic pyaudio numpy

— Подключите устройство Meshtastic через USB

— Запустите приложение:

python app.py

Помните: чтобы голосовые сообщения работали, приложение должно быть запущено как у отправителя, так и у получателя. Также имейте в виду, что в ходе обширных испытаний я обнаружил, что качество сжатия «Очень низкое» и размер фрагмента «Маленький» (150 байт) обеспечивают наилучший баланс между качеством звука и надежностью передачи.

Заключение

Мне было просто любопытно, и у меня было свободное время на выходных, поэтому я решил попробовать что-нибудь интересное. Это может стать началом для некоторых плагинов или новых инструментов для Meshtastic. Потенциал есть, даже если практическое применение может быть ограниченным.

Хотя эта концептуальная проверка демонстрирует, что передача голоса технически возможна, для внедрения в производство потребуется:

Более эффективные алгоритмы сжатия.
Улучшенные механизмы исправления ошибок и восстановления.
Улучшенная логика подтверждения и повторных попыток.
Оптимизированное использование полосы пропускания.
Интеграция с протоколом Meshtastic на более глубоком уровне.

Кто знает, какие еще возможности мы можем открыть, продолжая расширять границы этой увлекательной технологии? Если вы заинтересованы в участии в этом эксперименте или у вас есть идеи по его улучшению, не стесняйтесь создавать форк репозитория и отправлять пул-реквесты!

meshtastic мануалы

—

27.10.2025