caxapa.ru :: Не хочу догадываться, спрашиваю у тех то хочет и может объяснить в чем ошибка.

iizerg (16.01.2013 17:46, просмотров: 181) ответил Хитрый Китаец на ИМХО, никак. Обмен в радио и в проводе асинхронен, догадайтесь, что будет без буферизации. На низком уровне можно поковырять параметры QoS L2CAP(их там всего пяток). На уровне RFCOMM можно квитироваться сигналами RTS|CTS.

Не хочу догадываться, спрашиваю у тех то хочет и может объяснить в чем ошибка. Устройство на WINCE с одной стороны (где у него квитирование сигналами RTS|CTS?), BTM-180 с другой стороны. WinCE отправляет пакет 8 байт. Пакеты отправляет непрерывно, задержка между пакетами 1мС. На приемной стороне вижу "склейку" пакетов по 2 шт. подряд время между "склейками" колеблется от 10 до 25 мС. В каком месте переделать и что именно переделать?

Ответить

- При хорошем протоколе склейка не проблема. - Vladimir Ljaschko(16.01.2013 18:21)
  - На хорошем протоколе протоколе пока остановились. - iizerg(16.01.2013 21:42)
    - Это Модбас имеется ввиду? - Vladimir Ljaschko(16.01.2013 21:55)
      - Нет, Модбас пойдет уровнем выше. iizerg(300 знак., 16.01.2013 22:02)
        
        может проще всё-таки RTU->ASCII->Bluetooth->ASCII->RTU сделать, раз уж оверхед допускается? А там глядишь просто на ASCII перейдёте и всё, только для старых устройств преобразователь RTU/ASCII останется. Перезапросы блютузу вроде не нужны - koyodza(17.01.2013 18:51)
        
        Не совсем понимаю зачем первая часть "RTU->ASCII->Bluetooth" ? мастер может давать любой протокол. iizerg(125 знак., 17.01.2013 19:04)
        
        да, правильно. Тем более если мастеру пофиг, а пропускная способность достаточная, я бы так и делал. В мастере на всякий случай лучше иметь возможность работать хоть с ASCII, хоть с RTU - koyodza(17.01.2013 19:08 - 19:12)
        
        Не очень понимаю, Vladimir Ljaschko(170 знак., 16.01.2013 23:00)
        
        Так выглядит отправка одинарных запросов мастера и ответ на них слейвом. iizerg(35 знак., 17.01.2013 18:47)
        
        Одинарный запрос мастера 8 байт. Склеенный пакет выглядит как одна посылка длинной 16 байт. iizerg(125 знак., 17.01.2013 18:44)
        
        Не станет. Блютузный протокол сам бьёт посылку на пакеты, причём о размере пакетов стороны договариваются друг с другом в зависимости от глубины буфера. - Shura(16.01.2013 23:04)
        
        Логично. Тогда проще каждый пакет Модбаса в свою обертку и пусть все подряд склеивает - разрывает. - Vladimir Ljaschko(16.01.2013 23:42)
        
        Аффтар принял вполне логичное (ИМХО) решение - на повышенной скорости гнать всё скопом, а на приёмной стороне парсить и раздавать как положено. - Shura(16.01.2013 23:45)
- Переделать в ДНК. Зачем вы взяли модуль с буферизацией, аппаратным контролем целостности пакетов и автоматической перепосылкой? Берите самый простой - получите абсолютный реалтайм и ебитесь дальше с ошибками сами. - Shura(16.01.2013 18:02)
  - Мы взяли - то что можно было быстро взять для старта. iizerg(372 знак., 16.01.2013 21:51)
    - Весь реалтайм регулируется QoS L2CAP, командами управления HCI Host_Buffer_Size, Set_Host_Controller_To_Host_Flow_Control, сигналы управления модемом DTR,RTS передаются по каналу управления RFCOMM. Вам придется подбирать их комбинацию под свои Хитрый Китаец(294 знак., 17.01.2013 12:38)
      - Спасибо за объяснение. Позже появится время - будем пробовать вариант полностью через HCI. текущий момент - внешний контроллер будет выполнять реалтайм и парсинг клееных пакетов. - iizerg(17.01.2013 18:50)
    - Через HCI можно сделать практически реалтайм, но в таком случае всё равно ошибки вам придётся окучивать самостоятельно - Shura(16.01.2013 22:04)

Мобильная и беспроводная связь