[alx125 0]

Может, подскажет кто - неужели нельзя использовать SCO-канал для передачи данных?

 

Стандарт позволяет (про конкретный Ваш чип не скажу). Но!

Спецификация (Classic BT):

"Four packets are allowed on the SCO logical transport:

HV1, HV2, HV3 and DV. These packets are typically used for 64kb/s speech transmission but may be used for transparent synchronous data"

 

"The air coding by log PCM or CVSD may be deactivated to achieve a transparent synchronous data link at 64 kbits/s."

 

 

Скорость нужна немаленькая, хотя бы 115200 бит/с. Тот канал SCO, который я сейчас вижу, пересылает по 60 байт каждые 3,2 мс, вроде как, нормально, если пойдут через него raw-данные.

 

Это как раз не проблема, потерянные данные восстановит верхний протокол. К тому же там есть механизмы, улучшающие вероятность доставки пакетов, это и восстанавливающие коды FEC, и retransmission. Но гарантии доставки, как у ACL, нет, это понятно.

 

Если Вы будете использовать "восстанавливающие коды FEC, и retransmission", то где же тут у Вас гарантированная задержка (latency)?

Для Real Time, в этом случае, нужен существенный запас скорости.

:-)

Да и без "восстанавливающие коды FEC, и retransmission" макс. возможная скорость SCO может Вас не устроить.

[uriy 4]

С FEC задержка как раз будет гарантированная и фиксированная. Про retransmission в SCO никогда не слышал. Зачем это для звука?

[alx125 0]

С FEC задержка как раз будет гарантированная и фиксированная. Про retransmission в SCO никогда не слышал. Зачем это для звука?

 

Не удивительно, что не слышали. Спецификация про это молчит :-)

Но ТС написал , "потерянные данные восстановит верхний протокол".

Т.е. он это планирует взять на себя, а не на спецификацию стека BT возложить.

В принципе - рабочий подход.

Так реализовано было в Skype (по крайней мере до Microsoft).

Чтобы сократить накладные затраты TCP, передачи велись ч/з UPD-пакеты.

А доп.верхний уровень в случае необходимости запрашивал повтор.

 

Что же касается FEC-кодов ( Forward Error Correction, FEC, помехоустойчивое кодирование), то это решение добавляет избыточность в передачу и конечно же уменьшает скорость для payload.

Представьте на минуту, что он (код) выделил ошибку. То необходимо запросить (т.е. трафик в обратном направлении со всеми timeout-ами) повтор передачи. Какая уж тут гарантированная мин.задержка.

Если же код не только с обнаружением , но и с коррекцией ошибок, то там и избыточность передачи выше и кодирование сложнее.

А возможности коррекции ошибок очень даже ограничены. Например, можно исправить лишь 1-2 бита.

Именно поэтому SCO изначально ориентирован на речь, т.к. там мелкие проблемы в передаче сгладит ухо+мозг.

[gerber 7]

Механизм retransmission не подразумевает перезапрос данных - просто при его использовании данные передаются дважды, что увеличивает вероятность правильной доставки и не меняет гарантированную latency. Для retransmission отводится специальное окно в том же тайм-слоте, в котором передается основной пакет.

И таки да, согласен, в классическом SCO нет retransmission, и при использовании пакетов HV1-HV3 симметричная пропускная способность до 64 кбит/с.

Но начиная со спецификации 1.2 появился eSCO, где уже есть и retransmission, и скорость канала можно поднять до 288 кбит/c, при использовании пакетов EV5, и режим air coding = "transparent data". Вот в эту сторону и буду двигаться, благо CC2560 поддерживает eSCO линки.

Кому интересно - информацию можно поискать по ключевым словам "Using eSCO in Profiles", и Handbook of Networked and Embedded Control Systems