Интерком система (возможно на nRF24L01+)

[vj-nike]

Мяу всем! Вопрос возник. Гуглил. Не первый день. Ответов нет.
Итак, обо всём по порядку:
Нужна мне система (желательно не Mumble сервер на Raspberry Pi и т.п.) для коллективного общения: один главный и 4-6 второстепенных; ощущение полного дуплекса обязательно - главный говорит постоянно, но не должен пропускать комментарии ведомых; дальность - в пределах одного спорткомплекса/стадиона/открытой площадки; минимальная задержка звука; помимо голоса от главного ко второстепенным должны отправляться служебные команды включающие светодиоды.

В идеале, хотелось бы сделать всё на доступных в продаже модулях, но то в идеале...
Думал сделать по Wi-Fi отправляя UDP пакеты, но, кажется, что без софтового смешивания не получится..
Наткнулся на видео

Спойлер

Понравились модули nRF24L01, но не понравилось ардуиновское АЦП. Понимаю, что голос нужно компрессировать, чтобы уши у людей не отпали.. Для этих целей полез искать кодеки. Приглянулся VS1053, который может кодировать в AAC или OGG. Потом увидел MAX9860, никто им не пользовался?
Но вдруг понял что ничего не могу придумать с одновременной работой такого числа приёмо-передатчиков...
Логика у меня такая - все устройства должны либо иметь по 2 приёмо-передатчика, работающих в симплексном режиме или nRF24L01+ должны успевать перестраиваться на с частоты приема на частоту отправки с такой скоростью, чтобы абоненты не слышали прерываний. Но, в любом случае, главный модуль вещает на своей частоте, её слушают товарищи второстепенные... А дальше? Какую частоту должен слушать главный? Как не допустить коллизий? Или стоит главному поочередно отправлять разрешения всем второстепенным на передачу на вторую частоту, таким образом каждый n пакет полученный на базе будет от каждого n-ного второстепенного.. Но как это всё смешать так, чтобы казалось чтобы они синхронно говорят? Если так делать, то все второстепенные тоже должны будут последовательно получать все пакеты и раскладывать их, чтобы слышать друг-друга..
Или сделать так: Главный вещает на частоте f1, слушает f2, f3, .., fn. Приёмников в базе стоит по количеству второстепенных. Второстепенные слушают f1 и вещают каждый на своей частоте. Каждый приёмник отправляет принятый поток на свой декодер, а уже аналоговый звук смешивается и поступает главному в уши и... в передатчик f1, чтобы ведомые тоже слышали друг-друга. Но тут встает вопрос о засорении эфира и дичайшей задержке... Или ведомые должны вещать на общей частоте, но разделять потоки как-то с помощью адресации MultiCeiver? А как в итоге, всё-таки, получить общий звуковой поток одновременно говорящих?
Много букв, много вопросов, извините. Накипело.

Последний раз редактировалось vj-nike Чт окт 05, 2017 09:01:46, всего редактировалось 1 раз.

[Jemchug]

vj-nike писал(а):

Но тут встает вопрос о засорении эфира и дичайшей задержке...

Никакой задержки не будет.
Приемники и передатчики аналоговые.



Хотя и ГЛАВНОМУ можно взять такой же пульт, как и у всех, а базовая станция будет автономная.
Команды на светодиоды можно передавать используя поднесущую, например 30 кГц. Ухом её будет не слышно. Вот на ней и можно будет передавать еще и команды.

Понятно, что это прошлый век и все это можно сделать в цифре, но программисты в данный раздел или не хотят идти, а возможно ничего в этом не понимают.
Вот попробуйте в эту тему обратиться.
viewtopic.php?f=62&t=105290&p=3198174#p3198174
Они там так расхваливают ARM, но не знают куда его применить.
Принцип тот же.
При передачи нужно объединить потоки, но теперь уже не аналоговые, а цифровые и передать, а при приеме эти цифровые потоки снова разделить.

Вложения

дуплекс.JPG

(30.84 KiB) Скачиваний: 997

[vj-nike]

Jemchug писал(а):

Никакой задержки не будет.
Приемники и передатчики аналоговые.

Я в программировании несказанно продвинутей, чем радиопередающих устройствах. И не потому что бог программирования..
Аж строшновато стало от аналоговых приёмников и передатчиков, а еще от [сказано шёпотом]диплексора[/сказано шёпотом]...
Продаются ли готовые модули, чтобы не заниматься тонкой настройкой без осциллографа?
И ещё вопрос - а как быть с передачей служебной информации? Светодиодами второстепенных, всё-же, моргать хотелось бы...

Последний раз редактировалось vj-nike Чт окт 05, 2017 16:38:31, всего редактировалось 1 раз.

[roman.com]

Приемники и передатчики аналоговые... Команды на светодиоды можно передавать используя поднесущую, например 30 кГц...

Это не серьёзно))

программисты в данный раздел или не хотят идти, а возможно ничего в этом не понимают.

Тут ходят все кому не лень..))

nRF24L01+ должны успевать перестраиваться на с частоты приема на частоту отправки

У nRF24L01+ время перестойки 130 микросекунд.)) У других модулей примерно тоже... в пределах ~80...160 микросекунд.

строшновато стало от аналоговых приёмников и передатчиков, а еще от диплексора...

Забудьте))

Как не допустить коллизий?

Можно так:
https://ru.wikipedia.org/wiki/Token_ring
Цитата: Сети с передачей маркера перемещают по сети небольшой блок данных, называемый маркером. Владение этим маркером гарантирует право передачи.
Но лучше по другому)) - по команде главного.

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

Все сидят на одной частоте, используя Мультиплексирование с разделением по времени (TDM).
https://ru.wikipedia.org/wiki/Мультипле ... _.28TDM.29

Если так делать, то все второстепенные тоже должны будут последовательно получать все пакеты и раскладывать их, чтобы слышать друг-друга..

Да. Главный и все второстепенные будут последовательно получать все пакеты используя буферизацию данных.

Но как это всё смешать так, чтобы казалось чтобы они синхронно говорят?

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

Для начала надо прикинуть скорость передачи у каждой точки (главный и второстепенных) - Bitrate / kbit/s. Зависит от кодека.
Затем вычислить таймслот и вычислить суперкадр.
Затем добавить время переключения (прием/передача) + дополнительные расходы...)) Типа так:

1.jpg

(125.18 KiB) Скачиваний: 492

После этото смотрим, успеет ли nRF24L01+ это всё передать)) И какая для этого нужна скорость передачи...
И нужна ли гарантированная доставка пакетов или нет. Для гарантированной доставки пакетов (с автоповторами) скорость нужна соответственно больше...
Наверное основная сложность - куча буферов на каждой точке...

[vj-nike]

И нужна ли гарантированная доставка пакетов или нет.

Не нужна. Если делать подтверждение, то при обрыве связи передатчик будет пытаться повторить, пока не достучится до приёмника, а это задержка. Лучше пусть голос оборвётся, чем придёт с опозданием. То же и светодиодов касается.

Для начала надо прикинуть скорость передачи у каждой точки (главный и второстепенных) - Bitrate / kbit/s. Зависит от кодека.

По даташитам:
VS1053b: OGG Vorbis - bitrate up to 500kbit/sec, AAC - bitrate <=96, 132, 144, и выше kbit/sec for 2 channels
MAX9860: не нашел ничего похожего на битрейт..
nRF24L01+: 250kbps, 1 and 2Mbps air data rate

Наверное основная сложность - куча буферов на каждой точке...

Для управления кодеком и трансивером нужен МК. Если Atmega328 (Arduino Pro Mini) будет мало, то попробую STM32F103C8T6.

[roman.com]

светодиоды - это мелочи)) для светодиодов выделяется один байт в общем потоке.. да и всё))

VS1053b: OGG Vorbis - bitrate up to 500kbit/sec, AAC - bitrate <=96

Это дофига..)) Вам музыку слушать или передавать голосовые команды? ))

https://ru.wikipedia.org/wiki/IP-телефо ... 0.BA.D0.B8
Скорость без сжатия голоса 64 килобит/с. Цитата: Некоторые кодеки практически не сжимают голос, оставляя его на уровне импульсно-кодовой модуляции (то есть 64 килобит/с).
Хотя у меня выходило миниму 128 kbit/sec, PCM-256, без кодеков)) С частотой дискретизации 16 кГц качество звука удовлетворительное ( https://ru.wikipedia.org/wiki/Частота_дискретизации ). На меньшей частоте у меня сильные искажения (биения гармоник). Динамическое сжатие не использовал, нет смысла. Там и так ограничение 256.. выше звук обрезается.. как в обычной рации)) А для 64 kbit/sec и меньше нужен кодек... пока не придумал))

Впринципе AAC - bitrate <=96 в nRF24L01+(250kbps, 1 and 2Mbps) влезит (на макисмальной скорости). Но лучше на 250kbps, дальность больше.

Мультиплексирование:

Мастер - Data ...... ...... ...... ...... ...... ...... ......
Слейв1 - ....... Data ...... ...... ...... ...... ...... ......
Слейв2 - ....... ...... Data ...... ...... ...... ...... ......
Слейв3 - ....... ...... ...... Data ...... ...... ...... ......
Слейв4 - ....... ...... ...... ...... Data ...... ...... ......
Слейв5 - ....... ...... ...... ...... ...... Data ...... ......
Слейв6 - ....... ...... ...... ...... ...... ...... Data ......
Слейв7 - ....... ...... ...... ...... ...... ...... ...... Data

Cуперкадр: Data Data Data Data Data Data Data Data

Синхронизация всех слейвов по первому пакету мастера. Далее слейвы работают по своему таймеру:

Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data...

Или по прерыванию от Data предыдущего слейва..)) Впринципе большой разницы нет.

AAC - bitrate <=96 х 8 = 768 kbps. Это дата. Плюс расходы nRF24L01 (преамбула, адресс, CRC-16). Плюс задержка nRF24L01 SPI - 10 Мbps. Плюс задержка в самом МК (буферизация, запись в массив).

Короче, надо точно посчитать... должно влезть))

[vj-nike]

roman.com писал(а):

светодиоды - это мелочи)) для светодиодов выделяется один байт в общем потоке.. да и всё))

VS1053b: OGG Vorbis - bitrate up to 500kbit/sec, AAC - bitrate <=96

Это дофига..)) Вам музыку слушать или передавать голосовые команды? ))

У Ворбиса нет жестких предустановок по битрейту и частоте дискретизации, а у AAC есть. Поэтому у первого "До 500kbps", а у второго целая таблица соответствия битрейта и частоты дискретизации.

Добавлено after 8 minutes 16 seconds:

roman.com писал(а):

Синхронизация всех слейвов по первому пакету мастера. Далее слейвы работают по своему таймеру:

Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data...

Короче, надо точно посчитать... должно влезть))

В принципе, логика формирования общего потока ясна. Все по очереди на одной частоте выдают свои пакеты. Ок. Я даже вижу логику как начать слушать каждому клиенту того отправителя, которого он хочет. Но только одного.. Почему-то мне кажется, если этот поток "как есть" воткнуть в ЦАП, то получится белиберда.. Или я не прав?

Вложения

vs1053-1.PNG

(119.97 KiB) Скачиваний: 495

[roman.com]

Все по очереди на одной частоте выдают свои пакеты.

с указанием номера пакета, что бы все устройства в стеи знали от кого пришёл пакет и соответственно в какой буфер (массив) этот пакет пихать.

Почему-то мне кажется, если этот поток "как есть" воткнуть в ЦАП, то получится белиберда..

)) Про это я и говорю (выше):

Наверное основная сложность - куча буферов на каждой точке...

буфер (массив), всего 7 штук отдельных массивов в каждом устройстве. Соответсвтенно на выходе 7 штук ЦАП. А далее микшер на 7 входов и один выход. Будем слушать всех одновременно. ))

теоретичеки можно запихнуть всё в один ЦАП.. предварительно вычислив среднее значение от всех массивов... типа синтезируем один сложный сигнал, как сумму(разность) всех сигналов. Получим обычное наложение звуков в одном канале. Только возможны дополнительные искажения, так как сигнал у нас дискретный, а н еаналоговый, как в микшере.. А может быть и не критично.. не знаюю))
Хотя, в компьютере стоит звуковая карта и можно слушать кучу звуков одновременно с одного ЦАП... и всё нормально))

[vj-nike]

roman.com писал(а):

Соответсвтенно на выходе 7 штук ЦАП. А далее микшер на 7 входов и один выход. Будем слушать всех одновременно. ))

На Алике VS1053 стоит $6-7 . Не наш метод..

roman.com писал(а):

теоретичеки можно запихнуть всё в один ЦАП.. предварительно вычислив среднее значение от всех массивов... типа синтезируем один сложный сигнал, как сумму(разность) всех сигналов. Получим обычное наложение звуков в одном канале. Только возможны дополнительные искажения, так как сигнал у нас дискретный, а не аналоговый, как в микшере.. А может быть и не критично.. не знаюю))
Хотя, в компьютере стоит звуковая карта и можно слушать кучу звуков одновременно с одного ЦАП... и всё нормально))

В компьютере на ЦАП звуковой карты подаётся синтезированный программно сигнал. Т.е. сведение звука идет или программно или специальными чипами на крутых звуковушках.. Но спасибо за идею. Попробую погуглить как средствами МК можно смикшировать AAC или OGG.

[roman.com]

сведение звука идет или программно или специальными чипами на крутых звуковушках..

у меня простая звуковушка.. всё программно))

как средствами МК можно смикшировать AAC или OGG

ну можно и программно, если скорость процессора позволяет))

А если подать на вход МК непрерывный поток данных, последовательно со всех 7-ми каналов, то свести/разделить каналы можно с помощью МК.
я для эксперимента пробовал простой ЦАП на быстрой ШИМ ( https://ru.wikipedia.org/wiki/Цифро-ана ... 0.90.D0.9F ) Ещё добавил интерполяцию ( https://ru.wikipedia.org/wiki/Интерполяция ) ( нахождения промежуточных значений величины по имеющемуся дискретному набору известных значений.) и стало совсем хорошо)) Частота ШИМ выше, качество выходного сигнала лучше))

А для сведения/разделения сигналов пробовал простой демультиплексор, подключал вход демультиплексора к таймеру ШИМ, а управление демультиплексор к другим выводам МК. ( https://ru.wikipedia.org/wiki/Демультиплексор ). А в качестве микшера использовал обычные резисторы)) Примерно так:

1.jpg

(180.16 KiB) Скачиваний: 493

Короче .. получился простой бюджетный вариант)) Для простой голосовой связи пойдёт)) Для высокого качества лучше брать специализированные микросхемы, со встроенными АЦП, ЦАП, кодеком.. и т.д. и .т.п))

[abc]

Кодек ADPCM делался лет 15 назад на PIC-е, работающем на 4 MHz.
Речь звучала отлично.

---
Упс, ошибочка вышла. 21 год :)
http://archive.eetasia.com/www.eetasia. ... S=DOWNLOAD