Мяу всем! Вопрос возник. Гуглил. Не первый день. Ответов нет. Итак, обо всём по порядку: Нужна мне система (желательно не Mumble сервер на Raspberry Pi и т.п.) для коллективного общения: один главный и 4-6 второстепенных; ощущение полного дуплекса обязательно - главный говорит постоянно, но не должен пропускать комментарии ведомых; дальность - в пределах одного спорткомплекса/стадиона/открытой площадки; минимальная задержка звука; помимо голоса от главного ко второстепенным должны отправляться служебные команды включающие светодиоды.
В идеале, хотелось бы сделать всё на доступных в продаже модулях, но то в идеале... Думал сделать по Wi-Fi отправляя UDP пакеты, но, кажется, что без софтового смешивания не получится.. Наткнулся на видео Спойлер Понравились модули nRF24L01, но не понравилось ардуиновское АЦП. Понимаю, что голос нужно компрессировать, чтобы уши у людей не отпали.. Для этих целей полез искать кодеки. Приглянулся VS1053, который может кодировать в AAC или OGG. Потом увидел MAX9860, никто им не пользовался? Но вдруг понял что ничего не могу придумать с одновременной работой такого числа приёмо-передатчиков... Логика у меня такая - все устройства должны либо иметь по 2 приёмо-передатчика, работающих в симплексном режиме или nRF24L01+ должны успевать перестраиваться на с частоты приема на частоту отправки с такой скоростью, чтобы абоненты не слышали прерываний. Но, в любом случае, главный модуль вещает на своей частоте, её слушают товарищи второстепенные... А дальше? Какую частоту должен слушать главный? Как не допустить коллизий? Или стоит главному поочередно отправлять разрешения всем второстепенным на передачу на вторую частоту, таким образом каждый n пакет полученный на базе будет от каждого n-ного второстепенного.. Но как это всё смешать так, чтобы казалось чтобы они синхронно говорят? Если так делать, то все второстепенные тоже должны будут последовательно получать все пакеты и раскладывать их, чтобы слышать друг-друга.. Или сделать так: Главный вещает на частоте f1, слушает f2, f3, .., fn. Приёмников в базе стоит по количеству второстепенных. Второстепенные слушают f1 и вещают каждый на своей частоте. Каждый приёмник отправляет принятый поток на свой декодер, а уже аналоговый звук смешивается и поступает главному в уши и... в передатчик f1, чтобы ведомые тоже слышали друг-друга. Но тут встает вопрос о засорении эфира и дичайшей задержке... Или ведомые должны вещать на общей частоте, но разделять потоки как-то с помощью адресации MultiCeiver? А как в итоге, всё-таки, получить общий звуковой поток одновременно говорящих? Много букв, много вопросов, извините. Накипело.
Но тут встает вопрос о засорении эфира и дичайшей задержке...
Никакой задержки не будет. Приемники и передатчики аналоговые.
Хотя и ГЛАВНОМУ можно взять такой же пульт, как и у всех, а базовая станция будет автономная. Команды на светодиоды можно передавать используя поднесущую, например 30 кГц. Ухом её будет не слышно. Вот на ней и можно будет передавать еще и команды.
Понятно, что это прошлый век и все это можно сделать в цифре, но программисты в данный раздел или не хотят идти, а возможно ничего в этом не понимают. Вот попробуйте в эту тему обратиться. viewtopic.php?f=62&t=105290&p=3198174#p3198174 Они там так расхваливают ARM, но не знают куда его применить. Принцип тот же. При передачи нужно объединить потоки, но теперь уже не аналоговые, а цифровые и передать, а при приеме эти цифровые потоки снова разделить.
Никакой задержки не будет. Приемники и передатчики аналоговые.
Я в программировании несказанно продвинутей, чем радиопередающих устройствах. И не потому что бог программирования.. Аж строшновато стало от аналоговых приёмников и передатчиков, а еще от [сказано шёпотом]диплексора[/сказано шёпотом]... Продаются ли готовые модули, чтобы не заниматься тонкой настройкой без осциллографа? И ещё вопрос - а как быть с передачей служебной информации? Светодиодами второстепенных, всё-же, моргать хотелось бы...
Приемники и передатчики аналоговые... Команды на светодиоды можно передавать используя поднесущую, например 30 кГц...
Это не серьёзно))
Jemchug писал(а):
программисты в данный раздел или не хотят идти, а возможно ничего в этом не понимают.
Тут ходят все кому не лень..))
vj-nike писал(а):
nRF24L01+ должны успевать перестраиваться на с частоты приема на частоту отправки
У nRF24L01+ время перестойки 130 микросекунд.)) У других модулей примерно тоже... в пределах ~80...160 микросекунд.
vj-nike писал(а):
строшновато стало от аналоговых приёмников и передатчиков, а еще от диплексора...
Забудьте))
vj-nike писал(а):
Как не допустить коллизий?
Можно так: https://ru.wikipedia.org/wiki/Token_ring Цитата: Сети с передачей маркера перемещают по сети небольшой блок данных, называемый маркером. Владение этим маркером гарантирует право передачи. Но лучше по другому)) - по команде главного.
vj-nike писал(а):
Но, в любом случае, главный модуль вещает на своей частоте, её слушают товарищи второстепенные... А дальше? Какую частоту должен слушать главный?
Если так делать, то все второстепенные тоже должны будут последовательно получать все пакеты и раскладывать их, чтобы слышать друг-друга..
Да. Главный и все второстепенные будут последовательно получать все пакеты используя буферизацию данных.
vj-nike писал(а):
Но как это всё смешать так, чтобы казалось чтобы они синхронно говорят?
Главный и все второстепенные должны быть синхронизированы с главным. Все будут брать данные из буфера, по команде главногои подавать на микшер (микшер может быть автоматичекий, для разных спец эффектов)).
Для начала надо прикинуть скорость передачи у каждой точки (главный и второстепенных) - Bitrate / kbit/s. Зависит от кодека. Затем вычислить таймслот и вычислить суперкадр. Затем добавить время переключения (прием/передача) + дополнительные расходы...)) Типа так:
После этото смотрим, успеет ли nRF24L01+ это всё передать)) И какая для этого нужна скорость передачи... И нужна ли гарантированная доставка пакетов или нет. Для гарантированной доставки пакетов (с автоповторами) скорость нужна соответственно больше... Наверное основная сложность - куча буферов на каждой точке...
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
И нужна ли гарантированная доставка пакетов или нет.
Не нужна. Если делать подтверждение, то при обрыве связи передатчик будет пытаться повторить, пока не достучится до приёмника, а это задержка. Лучше пусть голос оборвётся, чем придёт с опозданием. То же и светодиодов касается.
roman.com писал(а):
Для начала надо прикинуть скорость передачи у каждой точки (главный и второстепенных) - 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
roman.com писал(а):
Наверное основная сложность - куча буферов на каждой точке...
Для управления кодеком и трансивером нужен МК. Если Atmega328 (Arduino Pro Mini) будет мало, то попробую STM32F103C8T6.
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
светодиоды - это мелочи)) для светодиодов выделяется один байт в общем потоке.. да и всё))
vj-nike писал(а):
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 писал(а):
VS1053b: OGG Vorbis - bitrate up to 500kbit/sec, AAC - bitrate <=96
Это дофига..)) Вам музыку слушать или передавать голосовые команды? ))
У Ворбиса нет жестких предустановок по битрейту и частоте дискретизации, а у AAC есть. Поэтому у первого "До 500kbps", а у второго целая таблица соответствия битрейта и частоты дискретизации.
Синхронизация всех слейвов по первому пакету мастера. Далее слейвы работают по своему таймеру:
Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data Data...
Короче, надо точно посчитать... должно влезть))
В принципе, логика формирования общего потока ясна. Все по очереди на одной частоте выдают свои пакеты. Ок. Я даже вижу логику как начать слушать каждому клиенту того отправителя, которого он хочет. Но только одного.. Почему-то мне кажется, если этот поток "как есть" воткнуть в ЦАП, то получится белиберда.. Или я не прав?
Все по очереди на одной частоте выдают свои пакеты.
с указанием номера пакета, что бы все устройства в стеи знали от кого пришёл пакет и соответственно в какой буфер (массив) этот пакет пихать.
vj-nike писал(а):
Почему-то мне кажется, если этот поток "как есть" воткнуть в ЦАП, то получится белиберда..
)) Про это я и говорю (выше):
roman.com писал(а):
Наверное основная сложность - куча буферов на каждой точке...
буфер (массив), всего 7 штук отдельных массивов в каждом устройстве. Соответсвтенно на выходе 7 штук ЦАП. А далее микшер на 7 входов и один выход. Будем слушать всех одновременно. ))
теоретичеки можно запихнуть всё в один ЦАП.. предварительно вычислив среднее значение от всех массивов... типа синтезируем один сложный сигнал, как сумму(разность) всех сигналов. Получим обычное наложение звуков в одном канале. Только возможны дополнительные искажения, так как сигнал у нас дискретный, а н еаналоговый, как в микшере.. А может быть и не критично.. не знаюю)) Хотя, в компьютере стоит звуковая карта и можно слушать кучу звуков одновременно с одного ЦАП... и всё нормально))
теоретичеки можно запихнуть всё в один ЦАП.. предварительно вычислив среднее значение от всех массивов... типа синтезируем один сложный сигнал, как сумму(разность) всех сигналов. Получим обычное наложение звуков в одном канале. Только возможны дополнительные искажения, так как сигнал у нас дискретный, а не аналоговый, как в микшере.. А может быть и не критично.. не знаюю)) Хотя, в компьютере стоит звуковая карта и можно слушать кучу звуков одновременно с одного ЦАП... и всё нормально))
В компьютере на ЦАП звуковой карты подаётся синтезированный программно сигнал. Т.е. сведение звука идет или программно или специальными чипами на крутых звуковушках.. Но спасибо за идею. Попробую погуглить как средствами МК можно смикшировать AAC или OGG.
сведение звука идет или программно или специальными чипами на крутых звуковушках..
у меня простая звуковушка.. всё программно))
vj-nike писал(а):
как средствами МК можно смикшировать AAC или OGG
ну можно и программно, если скорость процессора позволяет))
А если подать на вход МК непрерывный поток данных, последовательно со всех 7-ми каналов, то свести/разделить каналы можно с помощью МК. я для эксперимента пробовал простой ЦАП на быстрой ШИМ ( https://ru.wikipedia.org/wiki/Цифро-ана ... 0.90.D0.9F ) Ещё добавил интерполяцию ( https://ru.wikipedia.org/wiki/Интерполяция ) ( нахождения промежуточных значений величины по имеющемуся дискретному набору известных значений.) и стало совсем хорошо)) Частота ШИМ выше, качество выходного сигнала лучше))
А для сведения/разделения сигналов пробовал простой демультиплексор, подключал вход демультиплексора к таймеру ШИМ, а управление демультиплексор к другим выводам МК. ( https://ru.wikipedia.org/wiki/Демультиплексор ). А в качестве микшера использовал обычные резисторы)) Примерно так:
Короче .. получился простой бюджетный вариант)) Для простой голосовой связи пойдёт)) Для высокого качества лучше брать специализированные микросхемы, со встроенными АЦП, ЦАП, кодеком.. и т.д. и .т.п))
Сейчас этот форум просматривают: Сукгей и гости: 19
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения
Вход
Регистрация
Правила
FAQ
Поиск
. Не наш метод.. 
