• Уважаемые посетители сайта esp8266.ru!
    Мы отказались от размещения рекламы на страницах форума для большего комфорта пользователей.
    Вы можете оказать посильную поддержку администрации форума. Данные средства пойдут на оплату услуг облачных провайдеров для сайта esp8266.ru
  • Система автоматизации с открытым исходным кодом на базе esp8266/esp32 микроконтроллеров и приложения IoT Manager. Наша группа в Telegram

TB-03F TLSR8253 - кто-нибудь пробовал "звуковые" возможности?

aloika

Active member
В SDK к чипу есть два проекта-примера - remote control, который по идее может записать звук, закодировать в ADPCM и передать его на другой девайс, прошитый проектом master_kma_dongle. А он, в свою очередь, уже может декодировать этот звук и передать на компьютер.
Я решил поковырять эти проекты. Сделал пока такую штуку - принимает звук с микрофона и передает по UART в ADPCM-кодировке. Передаются пакеты по 128 байт, формат такой (как в примере):

Код:
//byte2,byte1: predict;  byte3: predict_idx; byte4:adpcm data len
//byte5- byte128: 124 byte(62 sample) adpcm data
Т.е. 4 байта заголовок, 124 байта - данные.
Только я вот не пойму, почему 124 байта - написано 62 семпла? По идее должно же быть 248 семплов (4 бита на семпл)?

Также запросто можно передавать в характеристику BLE и получать, например, телефоном.

Теперь вопрос такой - как это прослушать? Я по-простому собрал из UART-а на компьютере все пакеты в файл, выровнял начало файла и открыл файл в Audacity. Ну... что-то там слышно, конечно, но присутствуют сильные шумы. Вот теперь гадаю, что с этим делать. Такое ощущение, что как-то Audacity расшифровывает файл неправильно. А может, зашифровывается файл неправильно.

Кому-нибудь эта тема интересна?

Прикрепил файл со звуком. Нужно в Audacity открывать его как RAW VOX ADPCM.
 

Вложения

  • 217.3 KB Просмотры: 2

pvvx

Активный участник сообщества
master_kma_dongle имеет в USB point для приема этого "звука"... нужен какой-то драйвер.
Но я не ковырял примеры от Telink - не было интереса...
 

aloika

Active member
Догадался я выводить через UART несжатый звук, на скорости 1000000 получается почти приемлемо. Для отладки. Присутствуют шумы (младшие биты АЦП?), также видны "тычки" при рекламе. Рекламу отключаю - тычки пропадают. Надо попробовать повесить на входы конденсторы 10 пФ, как у них на схеме этого пульта нарисовано. Со сжатием не разобрался, ума не хватает. Собрать пакеты в файл могу, а как этот файл расшифровать - надо бы программу написать на чем-нибудь, по известному алгоритму:

Код:
void adpcm_to_pcm (signed short *ps, signed short *pd, int len)
{
    int i;

    //byte2,byte1: predict;  byte3: predict_idx; byte4:adpcm data len
    int predict = ps[0];
    int predict_idx = ps[1] & 0xff;
//    int adpcm_len = (ps[1]>>8) & 0xff;

    unsigned char *pcode = (unsigned char *) (ps + NUM_OF_ORIG_SAMPLE);

    unsigned char code;
    code = *pcode ++;

    //byte5- byte128: 124 byte(62 sample) adpcm data
    for (i=0; i<len; i++) {

        if (1) {
            int step = steptbl[predict_idx];

            int diffq = step >> 3;

            if (code & 4) {
                diffq = diffq + step;
            }
            step = step >> 1;
            if (code & 2) {
                diffq = diffq + step;
            }
            step = step >> 1;
            if (code & 1) {
                diffq = diffq + step;
            }

            if (code & 8) {
                predict = predict - diffq;
            }
            else {
                predict = predict + diffq;
            }

            if (predict > 32767) {
                predict = 32767;
            }
            else if (predict < -32768) {
                predict = -32768;
            }

            predict_idx = predict_idx + idxtbl[code & 15];

            if(predict_idx < 0) {
                predict_idx = 0;
            }
            else if(predict_idx > 88) {
                predict_idx = 88;
            }

            if (i&1) {
                code = *pcode ++;
            }
            else {
                code = code >> 4;
            }
        }

        if (0 && i < NUM_OF_ORIG_SAMPLE) {
            *pd++ = ps[i];
        }
        else {
            *pd++ = predict;
        }
    }
}

ps - вход, pd - выход. Массивы с волшебными числами тоже есть:

Код:
static const signed char idxtbl[] = { -1, -1, -1, -1, 2, 4, 6, 8, -1, -1, -1, -1, 2, 4, 6, 8};
static const unsigned short steptbl[] = {
 7,  8,  9,  10,  11,  12,  13,  14,  16,  17,
 19,  21,  23,  25,  28,  31,  34,  37,  41,  45,
 50,  55,  60,  66,  73,  80,  88,  97,  107, 118,
 130, 143, 157, 173, 190, 209, 230, 253, 279, 307,
 337, 371, 408, 449, 494, 544, 598, 658, 724, 796,
 876, 963, 1060, 1166, 1282, 1411, 1552, 1707, 1878, 2066,
 2272, 2499, 2749, 3024, 3327, 3660, 4026, 4428, 4871, 5358,
 5894, 6484, 7132, 7845, 8630, 9493, 10442, 11487, 12635, 13899,
    15289, 16818, 18500, 20350, 22385, 24623, 27086, 29794, 32767   };

Помогите, кто может - хотя бы начало расшифровщика написать, а?
 

aloika

Active member
Эх, при рекламе тычки - это еще ничего. При соединении такие же тычки, то т.к. соединение происходит гораздо чаще, чем реклама, то такой ощутимый треск в звуке получается. Вход закорачиваю - треск пропадает, т.е. ловится наводка на внешнюю часть цепи - микрофон, конденсаторы. Непонятно, что с этим делать.
Еще наблюдения: при установке разрядности АЦП 8 бит - при закорачивании входа получается точный ноль. А при более высокой разрядности (10, 12, 14 бит) - остается шипение. Шум младших разрядов?
А кто-нибудь с цифровыми микровонами работал? Как оно? Лучше, чем с аналоговым?
 

pvvx

Активный участник сообщества
Эх, при рекламе тычки - это еще ничего. При соединении такие же тычки, то т.к. соединение происходит гораздо чаще, чем реклама, то такой ощутимый треск в звуке получается. Вход закорачиваю - треск пропадает, т.е. ловится наводка на внешнюю часть цепи - микрофон, конденсаторы. Непонятно, что с этим делать.
Удалять от антенной части и экранировать.
У чипа вроде есть отдельное питание для аналоговой части. Не смотрел как питание распределено в TB-03F...
 

aloika

Active member
Какая ещё реклама во время BLE соединения? Её можно включить, но принудительно - специальным вызовом процедуры включения в SDK.
Нет соединения - есть реклама, соединяюсь - нет рекламы. Звуковые данные-то я просто через UART получаю, а присоединяюсь - отсоединяюсь для эксперимента.
 

pvvx

Активный участник сообщества
В примере ble_sdk_multimode\vendor\8258_ble_remote используется
TL_AUDIO_MODE = TL_AUDIO_RCU_ADPCM_GATT_GOOGLE //GATT GOOGLE
Но я ничего не нашел по данному поводу. Есть только ASHA:

Считаю что проще передать поток и принять, парсить его в Chrome в js. Возможен и вывод на динамики.
Этот подход требует меньше ковыряний...
 

aloika

Active member
В примере ble_sdk_multimode\vendor\8258_ble_remote используется
TL_AUDIO_MODE = TL_AUDIO_RCU_ADPCM_GATT_GOOGLE //GATT GOOGLE
Да, я смотрел. От GATT_TELINK только заголовком пакета отличается. В мануале написано, что используется с Google TV Box, что бы это ни значило.


Считаю что проще передать поток и принять, парсить его в Chrome в js. Возможен и вывод на динамики.
Этот подход требует меньше ковыряний...
С передачей-то без проблем. Я ещё включил поддержку длинных пакетов, поэтому передается сразу по 128 байт за раз. Вот с приемом и расшифровкой сложнее, пока не умею. Надо поразбираться. Да, это гораздо удобнее будет - сразу можно видеть/слышать сигнал в реальном времени, чем через файл и аудиоредактор, как я сейчас делаю.
 

pvvx

Активный участник сообщества
С передачей-то без проблем.
А мне лень разбираться с накрученным примером от Telink. Там надо прикручивать какие-то кнопки и прочее, или покупать их специализированный модуль. А это всё занимает время, а итог всё равно выйдет нулевой, т.к. оно такое нафиг не сдалось.
Из того, что можно слепить по поводу микрофона, это наверно "Ok Google" и типа. Но для этого необходимо выкинуть всё лишнее из примера от Telink и/или более желательно - сляпать какой совместимый с уже имеющимися вариантами формата передачи и UUID.
Но вот описание "какого имеющегося" формата пока не найдено.
 

aloika

Active member
А мне лень разбираться с накрученным примером от Telink. Там надо прикручивать какие-то кнопки и прочее, или покупать их специализированный модуль.
Я оттуда кусками нужное надергал в отдельный проект, теперь никаких кнопочек, сразу передает после включения и всё. Могу сюда скинуть. К модулю нужно только два конденсатора припаять, микрофон и резистор.
(только у меня там не причесано ничего, по файлам раскидано не очень логично. но работает.)
 

pvvx

Активный участник сообщества
Я ещё включил поддержку длинных пакетов, поэтому передается сразу по 128 байт за раз.
Почему не 237 байт за раз?
Даже по прошлой ссылке:
  • иметь расширение длины данных LE [BT Vol 6, Part B, Sec 5.1.9] с полезной нагрузкой не менее 167 байтов.

Если соберете и кинете куда пример (пусть бинарник для TB-03F), который только передает со входа микрофона при соединении, выкинув всё лишнее - могу покопать js для приема "энтого потока".
 

aloika

Active member
Почему не 237 байт за раз?
Там так: 992 байта - размер незашифрованного пакета, это равно 496 семплов (16 бит на семпл). Далее этот пакет сжимается алгоритмом ADPCM в 4 раза, итого получается 248 байт данных. Эти 248 байт делятся на 2 пакета по 124 байта, к каждому пакету с его начала добавляется 4 байта заголовка. Итого каждый пакет 128 байт. Вот эти 128 байт и передаются за раз. Это в GATT_TELINK. А в других вариантах (особенно в новой SDK) - там по-разному, в зависимости от алгоритма кодирования и еще по каким-то причинам.

Если соберете и кинете куда пример (пусть бинарник для TB-03F), который только передает со входа микрофона при соединении, выкинув всё лишнее - могу покопать js для приема "энтого потока".
Сейчас всё проверю ещё раз и скину пример.
 

pvvx

Активный участник сообщества
Там так: 992 байта - размер незашифрованного пакета, это равно 496 семплов (16 бит на семпл). Далее этот пакет сжимается алгоритмом ADPCM в 4 раза, итого получается 248 байт данных. Эти 248 байт делятся на 2 пакета по 124 байта, к каждому пакету с его начала добавляется 4 байта заголовка. Итого каждый пакет 128 байт. Вот эти 128 байт и передаются за раз. Это в GATT_TELINK.
Это всё имеется в описании (pdf) к SDK.
А в других вариантах (особенно в новой SDK) - там по-разному, в зависимости от алгоритма кодирования и еще по каким-то причинам.
Естественно - начали адаптировать к имеющимся форматам от Google и т.д. Но что-то их пока не найти в открытом доступе... А регистрироваться для каждой фигни в разных структурах = потерять немерянно времени и не имеет никакого смысла. В современном мире личные данные и прочие предоставляемые данные дороже уходящей ценности денег. А за регистрацию не платят и ничего ценного не дают :)
 

aloika

Active member
Вот бинарник (прикреплен).

Схема подключения микрофона такая:

1638469325231.png

Если PC1 и PC0 замкнуть - в приходящих пакетах будут нули (так видно, что не случайные данные идут). Микрофон какой-то тут типа EM6050 китайского производства noname.
 

Вложения

aloika

Active member
О, в целом работает! Спасибо! Только график быстро заполняется данными и начинает все тормозить до полной остановки. Надо бы ограничить количество точек на графике. А так очень похоже на звук:
1638472729217.png

Вот эта высокая редкая "шерсть" - моменты радиосвязи.
 

pvvx

Активный участник сообщества
В пакете есть какой заголовок? Тогда его, наверно, надо отрезать...
 

aloika

Active member
Бегло просмотрел - ну и телинк свой вариант предлагает (ещё и с кучей разных под-вариантов). Но суть-то та же - есть передатчик, есть приемник. Приемник воткнут в USB, и есть драйвера, которые видят его как аудиоустройство. Телинк даже ту же Audacity рекомендует для тестов. А вот если бы на приемном конце не нужен был бы спец-приемник - вот это было бы здорово. Какой нибудь стандартный драйвер (?), который сразу бы понимал, что подключено BLE-аудио и добавлял в существующие аудиоустройства.

С другой стороны, есть BT Classic, заточенный в том числе и под аудио, т.е. как бы вопрос решен еще давно.
 
Сверху Снизу