l.c.

Дабы логически завершить поднятую тему... Я не знаю, сколько народу сошло с ума пытаясь решить эту проблему, ибо тянется она, судя по форумах, лет пять минимум. Упущу сколько было просмотрено форумов, но результат печален - на чипах BC04 эту фишку выключить нельзя. Никак нельзя. Хоть и написано в доке на новый фирмварь что можно, но на самом деле - нельзя. Это ответ инженера CSR. А вот на BC-05 и последующих - вроде без проблем. Благо, проект был не денежный а больше для самообразования и делался в свободное время...

Приветствую всех. Возникла задача заставить BC04 прикинуться на USB не чем нибудь, а PL2303 от Prolific (USB to COM) Прикинуться удалось. Изваяние опознано системой (XP) и устройством для которого это все делается, драйвера установлены. Для передачи данных открыто два ендпоинта в bulk режиме. Данные с bluetooth в usb едут без проблем. А вот с приемом с usb конкретная грабля - каждая порция данных падает с дополнительным байтом в начале. Это циклический счетчик, я так понимаю, связанный именно с гарантированной доставкой в bulk режиме и служит для отслеживания повторной передачи порции данных. Но какого он падает мне в данные, разве это не дело драйверов csr отрезать его?...ну этот вопрос скорее риторический. Да все бы ничего пока передача идет малыми порция. Тогда сообщение MESSAGE_MORE_DATA содержит только одну порцию данных и счетчик можно откусить. Но когда плотность потока возрастает, данные уже приходят пачками например 13 байт где на самом деле 1+1 и 1+10 и различить где счетчик уже нельзя. Пробовал входящий стрим мапить через SourceMapHeader, говорит нет хидера, размер ноль. Попробовал сцепить потоки через TransformSlice с отрезанием первого байта. Данные поехали но криво. Что именно криво пока не выяснил. Результат выглядит странно - если например в терминалке (использую TeraTerm) включить передачу большого файла без подтверждения с другой стороны, то передача идет рывками с очень большой паузой, что наводит на мысль о проблеме именно с usb. Как вариант осталось отправить поток на kalimba и там попробовать что-то сделать, но это уж как-то слишком, так что будет на закусь :) Остался без закуси, калимбы то в BC04 нету... :( Ну и собственно вопрос - кто имел дело с usb в BC04, отзовитесь, что я делаю не так?

Поскольку WT12 сделан на CSR BC04, то вопрос скорее к CSR. Порядок чтения/записи описан в даташите на чип. Но наверно этого будет мало. В сети есть несколько проектов где народ анализировал протокол программатора. https://github.com/Frans-Willem/CsrUsbSpiDeviceRE http://jernej87.blogspot.com/2012/10/csrs-...l-analysis.html думаю из исходников первого проекта можно выудить необходимое.

Вставлю свои 5 коп.: ST L5973D http://www.st.com/internet/analog/product/63225.jsp

Питаю от лабораторного источника питания, все чисто :( Правда при включении сигнала падает потребление на 1мА. В общем, как я понимаю, это тупо брак :(

Всем привет. Может кто сталкивался и сможет пояснить. Купил партию микросхем 120 штук, которая ведет себя дивным образом. Передатчики работаю нормально, один приемник тоже. Но стоит на второй приемник подать активный сигнал по rs232 (RTS в моем случае), как чип падает в ступор и передатчики вырубаются. При этом на низковольтных выходах приемников сигналы в норме, фронты четкие. Напряжение на конденсаторах тоже нормальные. Если повышать питающее напряжение и пробовать передавать данные, то примерно при 4.5 на выходе передатчика начинают появляться зубцы в тех местах где должно быть +7в. Зубцы тем выше чем больше подряд единиц. При 4.8 сигнал становится нормальным и все начинает работать. Потребление нормальное 1-2 мА, чип не греется. Маркировка четкая, не краской а гравировкой. Другие ST3232, купленные в другом месте, немного отличаются маркировкой (шрифт, размер логотипа), работают без проблем. PS. Если на входы поставить последовательно резисторы 1к, то чип начинает работать уже гдето с 3.6 вольта, но имхо это не решение ибо не понятно сколько оно так будет жить. PS2. Конденсаторы с1 0.22uF с2-4 1uF, bypass 0.1uF. Пробовал и все 0.1 и 10uF - результат такой же Ктонить может прокоментировать?

Понял, спасибо что отозвались. Тогда и я попробую ;)

Народ, а L10 кто пользовал уже? Грабли есть? Ато M10 кости обмыли уже, а про этот - тишина...

Да, забыл сказать, я пользовал только уровень сигнала - rssi. Имхо для палочек самое то. А в ber в данном случае надобности не вижу. А палочки... ну у меня их 5 было, по 20 процентов на штуку. И условие вида if (sq > 80) 5 палочек else if (sq > 60) 4 палочки ... else if (sq > 0) 1 палочка else нет сигнала

ну я не мудрствовал лукаво... согласно описанию на CSQ 0: -113 dBm or less 1: -111 dBm 2...30: -109... -53 dBm 31: -51 dBm or greater 99: not known or not detectable решил примерно преобразовать в проценты. сделал так: if (csq >= 99) sq = 0; else { if (csq >= 31) sq = 100; else { sq = csq + 3; sq *= 3; } } +3 в строчке sq = csq + 3; можно заменить на +1 или +2 чтобы подвинуть рабочую область (3 - 93% и 6 - 96% соответственно)

Всем привет. Дело в следующем. Есть торговый терминал и модем на базе Sagem HiLo NC. Терминал использует свой стек IP. Стек, можно сказать, проверенный временем. COM-порт полный. Выполняется вход в GPRS (ATD*99...) и подымается PPP сессия, после чего, на всякий случай, контролируется и DCD сигнал. Сокеты открываются/закрываются по надобности... Так вот с не установленной пока закономерностью с некоторого момента сокеты открываться перестают. При этом DCD присутствует, PPP поднят. Если сбросить DTR (модем настроен рвать связь по его падению), модем переходит в командный режим и PPP можно поднять опять, и данные бегают как надо. Перепрошить на 9-ю версию все устройства пока возможности нет, да и хочется разобраться в происходящем. Детальные тесты проведу с понедельника а пока собственно вопрос - у кого-то такое было?