попробовал удалять паузы квадратичным методом. Если энергия буфера меньше Тресхолда, то не отправляют его.
ну ты извращенец))
обычно измеряют средний уровень звука или пиковое значение звука... когда говорим в микрофон и средний уровень звука выше некого значения - автоматически включается передача.
т.к. только в момент максимальной громкости происходит искажение звука... поэтому когда я говорю в микрофон... я смотрю по индикатору... чтоб пиковое значение уровня громкости не превышало максимально допустимое значение...
в простейшем случае будет так:
Код:
// Функция для определения пиковое значение в заданном буфере int calculateEnergy(const uint8_t* buffer, int size) { int energy = 0; for (int i = 0; i < size; ++i) { if (buffer[i] > energy) {energy = buffer[i];} } return energy; // пиковое значение в заданном буфере }
Карма: 14
Рейтинг сообщений: 115
Зарегистрирован: Сб май 21, 2016 11:04:52 Сообщений: 2957 Откуда: Беларусь
Рейтинг сообщения:2
нашел вот такую тему, ужать в ADPCM, ужимает в половину https://github.com/pschatzmann/arduino-adpcm-xq Но надо разобраться как это зарядить под мои буферы, ну и затем придется раздекодить в яве, или может быть даже проще сишный udp сокет поднять.
да это я всё уже читал... но в железе не делал)) я пока не знаю где это использовать... у меня интернет 100 мбит безлимитка)) мне трафик экономить не требуется))
у меня другая проблема - ардуина работает слишком медленно... шифрование для звука не работает... а без шифрования передавать звук по интернету нельзя.
единственный вариант - подключить ардуину к компу по локалке... предавать звук по локалке достаточно безопасно)) на коме запущена java которая может работать в режиме ретранслятора... с шифрованием.
вторая java у меня запущена на телефоне... поэтому телефон тоже может работать в режиме ретранслятора... программа для компа и телефона - одинаковые)) но передавать звук по wi-fi без шифрования запрещено)) поэтому этот вариант отпадает))
Карма: 14
Рейтинг сообщений: 115
Зарегистрирован: Сб май 21, 2016 11:04:52 Сообщений: 2957 Откуда: Беларусь
Рейтинг сообщения:0
я вот давно заметил что в моих аудио файлах, которые как известно 8бит unsigned при открытии в программах реадакторах имеется отклонение центра от 0. С чем это может быть связано? Это мне нужно делители напряжение и фильтра подстроить на входе в А0?
Добавлено after 22 minutes 51 second: получается что значения тишины у меня с учетом моего формата 8бит Unsigned должны быть в районе 127 (7f) в то время как у меня значения тишины где -то если в hex 51,52,53,54 что в привычном десятичном соответсвует 81. Т.е нужно как-то увеличить амплитуду тишины. Скорее всего нужно это поправить делитем напряжения на входе в А0?
Добавлено after 57 minutes 16 seconds: Ну и вопрос из теории. Каким образом формируются сэмплы со значением ниже чем значение тишны?
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
для улучшения качества звука даже специально подмешивают шум к полезному сигналу... шум "размазывает" ошибку квантования... улучшая качество звука можно отдельно подавать шум на вход АЦП... или использовать внутренний шум самого АЦП... есть другие варианты))
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
уже лучше)) но лучше использовать младшие 8 разрядов и подавать на вход АЦП 1/8 питания... так чувствительность АЦП выше.. .и соответственно требуется меньше уровень сигнала...
ну и как там твой самодельный кодек ? качество звука проверил ?
Карма: 14
Рейтинг сообщений: 115
Зарегистрирован: Сб май 21, 2016 11:04:52 Сообщений: 2957 Откуда: Беларусь
Рейтинг сообщения:0
С кодеком тема такая. Начал я с того что переосмыслил свою миссию в этом мире и понял что новый кодек я не изобрету и нужно использовать опыт предшествующих поколений. Тут https://forum.arduino.ru/t/apnouta-avr3 ... -723/12895 мне помогли с поиском Апноутa AVR336, библиотеки обработки звука CCITT G.711, G.721, G.723. Там в архиве была утилита кодирования и декодирования. Но на вход нужно подавать 16бит звук, а у меня 8 бит. Я преобразовал свои 8бит записи к 16 бит и попробовал закодировать их и раскодировать утилитами из Апоноут. Но , к сожалению, восстановление получилось не очень качественным, а скорее сказать совсем неприямлимым при данных обстоятельствах, - ожидалось что-то получше. Надо будет повторить эти эксперименты , может это я сделать что-то нет или не так. Мало того при преобразовании 8бит в 16 бит там как я понял еще 2 бита забиватся просто нулями. Может и в этом была какая то проблема.
// Функция для преобразования 8 бит к 16 бит в заданном буфере void calculateEnergy(int size) { for (int i = 0; i < size; ++i) { buffer[i] = (buffer[i] <<4); } }
00001111 11110000 - это всего лишь +/- 16 значений максимум... из +/- 256 значений возможных... после такого преобразования звук будет очень тихий... в 16 раз тише... или в 256 раз тише... смотря как считать... по амплитуде или размаху)) в любом случае будет много шумов... поэтому так делать не рекомендуется))
кодеки... кодеки...
G.729 — обширно применяемый тип кодека, для скорости 8 Кбит/с. Согласно теории, речевой сигнал продолжительностью в секунду можно стопроцентно обрисовать (другими словами оцифровать, передать либо сохранить в цифровом виде и потом вернуть в начальный сигнал по цифровому представлению) цифровым потоком 60 б/сек. Мысль оцифровывать и передавать (либо сохранять) в цифровом виде не сам сигнал, а его параметр (количество переходов через ноль, спектральные свойства и др.), чтоб потом по этим характеристикам выбирать модель голосового тракта и синтезировать начальный сигнал, лежит в базе «вокодеров» (VOice CODER) либо «синтезирующих кодеков».
тема такая. Известно ,что udp пакет состоит из заголовка и данных. Мне нужно передать 4 бита дополнительной информацаии. Вопрос в том как это сделать Всадить 4 бита при отравки я думаю смогу. Как вашем плейере обработать этот момент. Я собираюсь использвоать первый 4 бита данных под свою информацию
Пришлось вернуться к этой теме , раз уж у меня есть подвижки по передаче звука по sim800;
вкинул в chatGPT:
Цитата:
в этом коде я цифрую звук и отправляю его через sim800 в виде udp пакетов. Мне нужно изменить заголовок Udp пакета перед отправкой. Как это сделать: вот мой код:
и вот что получил в ответ
Код:
void loop() { if (digitalRead(btnStart) == LOW) { digitalWrite(ledStart, HIGH); if (bufByteCount == 32 && bufWrite == 1) { // Assuming buf01 contains your audio data modifyUdpHeader(buf01, sizeof(buf01));
// Send the modified UDP packet myGsm.write(buf01, sizeof(buf01)); }
// Rest of your code... } else { digitalWrite(ledStart, LOW); } }
void modifyUdpHeader(byte* buffer, int bufferSize) { // Assuming the UDP header is 8 bytes long const int udpHeaderSize = 8;
// Modify the UDP header fields as needed // Example: Set source port to 1234 (2 bytes) buffer[0] = 0x04; buffer[1] = 0xD2;
// Example: Set destination port to 5678 (2 bytes) buffer[2] = 0x16; buffer[3] = 0xE6;
// Add more modifications as needed...
// Calculate new checksum if needed // Example: Set checksum to 0 (2 bytes) buffer[6] = 0x00; buffer[7] = 0x00; }
т.е он поменял первый 8 байт моего буфера данных и выдал это мне за изменение заголовка. Ну просто красавчик.
Добавлено after 2 hours 37 minutes 9 seconds: Ну вопрос снимаю, потому как в данной конфигурации отправвки UDP пакетов нет возможности получить доступ к заголовку. Есть мысль отправлять эти биты вместе с данными, а потому уже в программе клиете выделять эти байты
про изернет я в курсе уже. Но пока я про gprs рацию мечтаю с возможностью передачи комманд и дополнительных данных.
Добавлено after 2 minutes 43 seconds: Хотя.... есть у меня одна мыслишка. Роман, дайте схем и скетч для изернета. Счас я в деле ,может я тут быстренько спаяю все это дело.
Добавлено after 9 hours 3 minutes 5 seconds: gprs рация... мне не нужна... у меня нет gprs)) тогда уж лучше DMR рацию сделать... сейчас востребовано... известно где))
Добавлено after 17 minutes 54 seconds: но сначала попробуем передать звук с ардуины на комп... никада не передавал звук с ардуины на комп...)) схема спаяна... лежит на столе))
посчитаем примерно скорость передачи по интернету: по анализатору: ~680 пак/сек * 32 байт/пакет * 8 бит/байт = ~400 кбит/с... при частоте МК 8 мгц... значит ардуина будет передавать по интернету со скоростью примерно до 1 Мбит/c. нормально)) можно ещё чуть- чуть поднять скорость... но думаю для звука ~1 Мбит/c пока достаточно.
замечательно)) как и ожидалось... ардуина не может передавать звук по интернету "на лету"... наш изернет модуль немного туповат)) хотя самодельный изернет модуль может передавать звук по интернету "на лету"... но это уже другая история)) значит нужна буферизация... в остальном всё работает.
с помощью подстроечного резистора устанавливаем режим АЦП - Уст 0. у нас 8 бит звук... это 0...255... среднее должно быть 128 или 0х80 в шестнадцатиричной... смотрим анализатор...
видим сильный фон)) чувствительность АЦП высокая... сам звук мы пока не слышим... зато но мы его видим ! ))
теперь надо подкрутить программу на компе... и послушать. можно просто записать звук в файл... и послушать в плеере... но нам не надо в записи... мы же делаем IP-телефон... поэтому нам надо слышать поток ! ))
Добавлено after 1 hour 39 minutes 8 seconds: подкрутили программку))
1. из-за высокой чувствительности АЦП очень много шума... 2. из-за выбега частоты постоянный треск)) стабильность частоты RC-генератора МК оставляет желать лучшего)) что было ожидаемо...
с качеством звука проблема... много шума и помех...
далее идёт аналоговая часть... надо всё фильтровать... по питанию... экранировать... нужен отдельный стабилизатор изернет модуля и отдельный стабилизатор ардуины... ещё надо стабилизировать всё кварцем... и т.д. и т.п.
переключили АЦП на старшие 8 бит... добавили ФНЧ... так меньше чувствительность... соответственно меньше шумов... качество чуть лучше... ещё нужен нормальный микрофонный усилитель... с хорошей АЧХ... 300...3000 Гц...
в идеале бы лучше использовать 16 битный звук... ардуина может передавать 16 бит звук... вот только ардуина имеет АЦП всего 10 бит... что для высокого качества звука явно мало. но в целом схема рабочая))
передатчик звука работает на таймере 1. ШИМ можно сделать на том же таймере 1. но лучше использовать отдельный таймер... например таймер 0.
в отдельном таймере можно менять частоту... например сделать частоту не 8 кГц (как в таймере 1), а например сделать частоту 125 кгц. принцип простой: чем выше частота - тем выше качество звука на выходе ФНЧ.))
что у нас тут... передаём звук на комп по локалке...
а чтоб передавать звук по интернету нужно шифрование... проблема в том что ардуина слишком медленно шифрует... всего 700 байт/с при 8 мгц... или 1400 байт/с при 16 мгц...
а нам надо передавать поток как минимум 8000 байт/с... т.е. как минимум в 4 раза быстрей... это только на передачу... и ещё столько же надо на приём... итого: частота процессора "ардуины" должна быть как минимум в 8 раз больше)) или 128 мгц... с учётом времени оцифровки и другие операции... надо ещё быстрей)) вывод: для передачи звука по нитернету нам нужна типа ESP-32 с частотой до 240 мгц...
Добавлено after 12 minutes 14 seconds: без шифрования можно передавать звук только в пределах офиса))
тогда ардуина будет передавать звук на комп... а комп (он же шлюз) будет всё шифровать... так тоже работает)) тогда проблема с безопасностью частично решается... хотя и не полностью ))
Зарегистрирован: Вт мар 05, 2024 19:47:48 Сообщений: 6
Рейтинг сообщения:0
Доброго времени суток! Есть радиостанция с шумодавом, и стоит творческая задача записывать с нее звук (в качестве 16 бит 44.1 кГц) в момент открытия шумодава (когда горит светодиод, и 1-2 секунды спустя), при этом записывая каждый "сеанс" в отдельный файл на sd-карту. Также стоит задача №2 (творческая) - периодически вытаскивать эти файлы на смартфон через bluetoth.
Был выбор между маленьким смартфоном в качестве aio устройства, и ардуиной с необходимыми дополнениями. Захотелось повозиться с ардуиной, но ввиду отсутствия необходимого багажа знаний, я вынужден обратиться к уважаемым форумчанам за советом
Я сам новичок в микроконтроллерах, но примерно понимаю суть первой задачи - необходимо каким-либо образом "нормировать" сигнал для максимально возможного качества преобразования в АЦП (если это нормирование не происходит в самом аудиомодуле), далее передать его кодеку(аудиомодулю), далее по I2S(?) шине передать байты ардуине, которая должна периодически проверять состояние шумодава, и в случае его открытия - скидывать данные на sd карту.
Возникают следующие вопросы: 1) Как часто можно создавать файлы на sd карте? Если делать это каждые 1-2 секунды, никакого затыка не будет? 2) Как расчитать, хватит ли аппаратных возможностей конкретного контроллера не только на запись звука по сигналу открытия шумодава, но еще и на передачу данных с sd карты через bluetoth модуль по запросу от смартфона? Собственно это самый главный вопрос, ибо не хочется ошибиться с покупкой ненужного для данного проекта железа.
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 35
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения