Jump to content

    

galjoen

Свой
  • Content Count

    834
  • Joined

  • Last visited

Everything posted by galjoen


  1. Анализируют ли стандартные CAN анализаторы ID и принятые данные, точнее ту часть данных и ту часть ID которые были приняты до установки доминанты (ошибки битстаффинга), в сети другими устройствами? Это чтобы по ID узнать полудохлый блок в сети. Если таких анализаторов нет, то есть какая то микросхема CAN интерфейса, которая точно позволяет это делать - pdf на неё смотрел, но тогда это мне не нужно было. А сейчас её тип вылетел из головы. А CAN интерфейс у МК - сильно упрощённый. На мой взгляд, навряд ли у какого из МК с CAN такая возможность есть. Но если есть, то это тоже вариант. Или уж свой самодельный CAN на базе ATmega48 доработать? Там это легко делается, но с передачей полученной информации проблема.
  2. Если одно из устройств по причине ошибки выставит 0 на TxCAN, то вся CAN сеть повиснет. Я понимаю, что от этого защищает Bus Off и WatchDog и т.п. Но если процессор собьётся/сгорит/(без питания останется), он может установить порты так, что выход, соответствующий TxCAN, станет 0 выдавать. От этого можно защитится аппаратно. Для ограничения времени существования доминантного уровня понадобятся 2 диода, 2 резистора и конденсатор. Можно и транзисторы/компараторы использовать конечно. В любом случае затраты небольшие, но и вероятность срабатывания защиты крайне мала. Хотя последствия тяжёлые могут быть. Кто-нибудь такую защиту у себя делает?
  3. Motorola 1773M

    Не могу найти информацию на микросхему: Корпус - SOP20 Значёк - Мотороловский Первая строчка - 1773M (M тут значит -40...+120 скорее всего) Вторая строчка - XAA9745 По идее это АЦП на 4 (или больше) каналов. Даже продают их, вроде как, но информации нет. Или я туплю?
  4. Задача передачи телеметрии от экскаваторов/бульдозеров/самосвалов в карьере в диспетчерскую. Сразу скажу, что GSM там нет, иначе было бы просто, а Ирридиум дорог. Вот подумываю о ZigBee, прочитал описание XBee. Но, насколько я понимаю, это не совсем то, т.к. сеть должна постоянно перенастраиваться - никаких роутеров, закреплённых в фиксированном месте, там быть не должно. Так же подумываю использовать только физику ZigBee, а всё остальное сделать самому (на базе готового стека, конечно). Получается, что в сети должны быть только broadcast сообщения т.к. маршруты будут постоянно меняться. И наличие координатора тут не имеет смысла. Понравился вариант на ATmega128RFR2, смущает только низкая максимальная выходная мощность передатчика. Какая реально дальность связи достижима? Или можно усилить? Про ограничения в курсе.
  5. Цитата(_3m @ Apr 12 2013, 12:29) Меняется только кан контроллер и драйвер. Вот пусть драйвер и проинициализирует контроллер в режим TTCAN, и никаких автоматических повторов уже не будет.
  6. Цитата(_3m @ Apr 12 2013, 10:42) В реализациях передатчиков я ни разу не видел таймаут на передачу Те, кто поддерживает TTCAN, т.е. синхронизацию времени между девайсами по CAN, не должны вообще повторов делать. А что мешает самому таймаут сделать?
  7. Я тоже не сторонник нестандартного, но тут сам случай нестандартный, похоже. Что то я в последнее время к 446 МГц склоняюсь т.к. там легально 0.5 Вт. НО скорость передачи крайне низкая, т.к. полоса узкая. Из-за этого получается, что время доставки секундами измерятся будет. А за это время топология уже может изменится, поэтому навряд ли LwMesh просто так без переделки заработает. Но подумаю ещё, кое-какие мысли есть. Да и задача видоизменяется похоже - уже про вагонетки заговорили.
  8. Цитата(Taradov Alexander @ Apr 9 2013, 19:43) Вы очень все усложняете. Я пытаюсь сделать так, чтобы ACK не потребовался. Т.е. броадкаст гарантировано был бы доставлен ко всем "живым" участникам сети, и при этом автоматически бы выяснилось кто "жив" в данный момент. Накладные расходы - отражённые от границ сети сообщения (от девайсов имеющих связь только с 1 участником сети), но их будет немного и они несут функцию ACK. Забыл написать - битовое поле у всех ретрансляторов постоянно складывается по AND с битовым полем в принятых сообщениях. ИМХО по затратам это получается лучше, чем 2 броадкаста - туда данные и назад ACK. А разруливание ситуации, когда был потерян ACK и девайс вновь посылает ту же посылку, требует введение ещё одного специального TAGа, кроме уже имеющегося (иначе ретрансляторы её зарубят). Кроме того, за счёт того же битового поля, передающие автоматически выясняют, что произошла коллизия и были испорчены 2-е или более одновременные передачи. В случае ZigBee это не важно, а если использовать только PHY 433 МГц, например, то может оказаться весьма актуально (насколько я понял, но могу и ошибаться - пока не докурил). Про то, что можно заводить запись на принятое сообщение, а не держать в памяти таблицу макс. возможного размера, понятно, я просто пытался изложить попроще. Не понятно только почему записи не вытесняются? Я так считаю, что они должны вытеснятся в том случае, если отправитель тот же, а счётчик (исходящий номер) больше (с учётом перехода FF-00). А вот в противоположном случае, если исходящий N меньше, чем в уже имеющегося записи от того же устройства, нужно просто игнорировать это сообщение - маловероятно, что счётчик (исходящий номер) увеличился более чем на 127, а мы за это время не слышали ни одного сообщения от этого девайса.
  9. ACK не панацея, даже наоборот. Там весьма времязатратный механизм получается, чтобы оба поняли, что пропало - сама посылка или ACK на неё (по TAGу). А в случае постоянно изменяющейся топологии это вообще может не сработать. Динамическая топология, вход/выпадение из групп - это оч. сложно и затратно, а главное практической пользы не принесёт, т.к. если связи с диспетчерской (через ретрансляторы) нет, то всё остальное бесполезно. С синхронизацией по времени проблем никаких - там GPS у каждого будет. Какой процессор использовать - большой разницы нет. ARM лучше тем, что ОЗУ достаточно имеет, а специализированный AVR - радио на борту. Если конечно такую частоту использовать. А вычислительной мощности, для вышеизложенного упрощённого алгоритма, у любого процессора с избытком. Меня больше интересует будет ли он работать?
  10. Цитата(Taradov Alexander @ Apr 9 2013, 02:54) А зачем ему это знать? В общих чертах опишу как я представляю представляю броадкаст между подвижными объектами. Вот мой домодощенный, упрощённый за счёт отказа от маршрутов (не хватит ОЗУ и вычислительной мощности), алгоритм (сделаны и ещё кое-какие упрощения для простоты восприятия): 1. У каждого девайса имеется свой жёсткий N. Допустим, в сети может быть не более 256 устройств, тогда этот N будет размером в 1 байт. 2. Каждый отправляющий присваивает сообщению TAG (для примера - 2 байта), состоящий из своего фиксированного номера (1 байт) и N-ра отправленной посылки (циклический сч-к, тоже 1 байт - в реале, конечно, не так примитивно, но писать много...). По этому TAGу ретрансляторы идентифицируют посылку. 3. В каждой посылке имеется битовое поле, число бит в котором соответствует макс возможному числу устройств в сети. Т.е. если в сети может быть максимум 256 устройств, то поле будет иметь размер 32 байта. И каждый бит жёстко соответствует N устройства. 4. Отправляющий сообщение, и каждый ретранслирующий его, сбрасывает бит, соответствующий своему N, в 0. Изначально, при отправке сообщения, все биты, кроме бита отправителя, =1 (тут возможна оптимизация, но пока не будем об этом). 5. Отправляющий сообщение так же работает как ретранслятор. 6. Если девайс видит, что у принятого и отправленного им сообщение отличается битовое поле, то он производит 2 ретрансляции. Первую сразу же, а 2-ю милисекунд через 5 (так же возможна оптимизация). 7. Таким образом сообщение будет циркулировать (ретранслироваться) по сети пока в нём не окажутся сброшенными все биты, соответствующие устройствам, которые хоть кто-нибудь слышит. А устройства, которые слышат других, а их никто не слышит, поймут сложившуюся ситуацию. 8. ACK при таком алгоритме не нужен. Сообщение гарантировано будет услышано всеми девайсами, присутствующими в сети, и вернётся к отправителю со сброшенными битами всех девайсов, получившись его. 9. Сколько времени каждый девайс должен хранить сообщение (идентифицируемое по TAGу) у себя в ОЗУ - пока не решил. Скорее всего - бесконечно. Т.е. зависит от объёма выделенного ОЗУ - новое сообщение от данного девайса затирает предыдущее. Тогда объём потребного ОЗУ будет зависеть от кол-ва устройств в сети, умноженного на макс размер сообщения (без оптимизации - заранее выделенная таблица). Девайс не должен слать след. сообщение (с другим TAGом) пока не получит предыдущее сообщение со сброшенным битом желаемого приёмника, или у него не закончится таймаут. Если в сети 256 девайсов и длина сообщения со служебными битами, такими как TAG (только 1 байт) и битовое поле, равна 128 байт, то нужно 256*128=32 кБ ОЗУ. Всё это в общих чертах, конечно, но надеюсь, что мысль понятна. Так же понятно, что при таком подходе кол-во ретрансляций, а значит и время бродкаста, будет весьма велико. Но такова плата за упрощённый алгоритм с гарантированной доставкой.
  11. Вот такая: http://www.aliexpress.com/item/Free-DHL-Sh.../390617103.html Но нужно всего 10 шт. Как искать, какой у них тип?
  12. Зато термопары с таким разъёмом (вилкой) дешевле чем $2 стоят. На том же али я 50 шт. за $65 купил. Правда тогда скидка была, а сейчас так продают: http://www.aliexpress.com/item/Type-K-Ther.../336590826.html Я вообще не понимаю откуда там такая цена за розетки взялась!
  13. Про сложность я уже понял. Поэтому вполне возможно, что так и придётся делать на Иридиуме. Но попытаться стОит... Без ретрансляции никуда - карьер это дырка глубиной метров 100, точнее несколько перемещающихся дырок, разделённых кучами пустой породы, которые возвышаются метров на 50 (тоже перемещаются со временем). Стационарный ретранслятор установить возможности никакой нет. Про Si4463 почитаю, спасибо за наводку. Расстояние небольшое, в районе 10 км, но рельеф крайне сложный. Однако, практически всегда, будет связь через ретрансляторы на самосвалах, вывозящих пустую породу.
  14. Цитата(Taradov Alexander @ Apr 7 2013, 23:41) Обычно аналоговые фронтенды дают +15 - +17 dB усиления. А что такое аналоговые фронтенды и где их взять? У XBee и DTK они используются? Там за счёт них такая высокая мощность получена? Понимаю, что это ламерский вопрос, но с радиосвязью до этого дело не имел. +15 Дб - это будет даже с избытком. А как там на 433 МГц? Там ведь разрешённая мощность, а значит и дальность, побольше. Цитата(Taradov Alexander @ Apr 7 2013, 23:41) Обычно для этого пакетам назначают счетчика, а на устройстве заводят таблицу, по которой определяют был ли уже обработан кадр с определенного адреса с определенным счетчиком. Счётчик - это присваивание отправляющим каждому сообщению своего TAGа? Да, конечно, такая таблица тоже должна быть, но по ней ретранслятор не может сделать вывод кто его слышит, и вообще слышит ли его кто-нибудь. Цитата(Taradov Alexander @ Apr 7 2013, 23:41) Зачем? Вероятность доставки броадкаста доствточно велика, так как его пересылают очень много устройств. Но на пути следования сообщения может встретится узкое место. Т.е. всего 1 ретранслятор между 2-мя группами устройств, да и у того связь на грани слышимости. Цитата(Taradov Alexander @ Apr 7 2013, 23:41) Это дофига даже для полноценных протоколов. LwMesh может хранить маршруты для 120 устройств в 1 кБ. 9 ретрансляций (7*9=63) максимум? Я то подумывал выделить в каждом сообщении битовое поле по числу устройств (128 устройств - 16 байт) - это позволит отправителю узнавать дошло ли его сообщение до адресата, т.е. отказаться от ACK вообще, но требует более продвинутый алгоритм работы ретрансляторов. Чтобы они понимали "туда" или "назад" идёт сообщение (по последовательности адресов ретрансляторов) и не делали излишних ретрансляций. Но что то слишком сложный алгоритм получается, и ОЗУ много нужно. А может что-нибудь и придумается...
  15. Скорость небольшая. От каждого объекта передаётся порядка 50 байт примерно раз в 10 сек, всего около 100 объектов. Но получается много ретрансляторов, а в случае броадкаста это напряжно. Обязательно нужно как то усиливать. Китайцы продают свои поделия типа DRF2617 и др. на базе CC2530, так у них реально до 500 м работает (четвертьволновая антенна в зеркале заднего вида самосвала) - пробовал. А параболы вообще на 8 км связываются, может и больше - дальше не проверял. Я понимаю, что оно не соответствует никакому стандарту (сконфигурировано на макс мощность). А уж как это Китайское чудо работает... Реально только броадкаст до 32 байт (причём обязательно без координатора в сети, а то всё заткнётся), да и то всё равно периодически затыкается без видимых причин, помогает только выкл/вкл питание (только за счёт этого и работает). Хотя такая тестовая системка (всего 6 подвижных и 1 неподвижный ZigBee) на Китайских изделиях уже успешно работает, но делать так - себя не уважать. XBee вроде тоже можно сконфигурировать на существенно бОльшую мощность, чем по стандарту, но с ним не экспериментировал. Опасаюсь, что работать не будет вообще - там похоже всё по стандарту сделано, в отличие от того, что у Китайцев. Хотя периодические выкл/вкл питания должны помочь (заново сконфигурируются), но тогда с ретрансляцией проблемы будут (ретранслятор неожиданно пропадать может). Но почему же у Атмела возможности увеличить мощность нет? Или я не нашёл? Честно признаться не специалист я в этом - как усилить даже не представляю. Ещё есть 433 мГц и др. варианты, но там пока вообще не смотрел... С LwMesh пока не разбирался. По прикидке планирую делать так: 1. У каждого девайса имеется жёсткий адрес 1 байт (хватит, более 256 устройств в сети точно не будет). 2. Передающий и каждый ретранслирующий добавляет в посылку свой адрес. 3. Если ретранслятор видит, что его адрес в посылке уже есть, то ретранслирует эту посылку ещё 2 раза. 4. Ещё ограничение по вложенности наверное придётся сделать. Не более 50 ретрансляций в посылке (по кол-ву добавленных адресов), например. 5. Возможно и оптимизацию по излишним ретрансляциям (если прямая связь есть) сделать, но придётся запоминать маршруты недавно ретранслированных посылок. Для этого ОЗУ может не хватить, его там 8 или 16 кБ всего. 6. То, что каждой посылке отправитель присваивает уникальный TAG (точнее не скоро повторяющийся), это само собой.
  16. Цитата(Слесарь @ Mar 26 2013, 19:10) Если кто знаком с разновидностями датчиков кислорода, просветите в чем я ошибаюсь, что больше подходит для моего применения, что можно почитать на эту тему, какие сигналы и какие режимы работы? Узкополостные Датчики Кислорода (УДК) переключаются при уровне кислорода в выхлопных газах менее 1%. Т.е. фактически позволяют поддерживать только стехиометрию, ну или небольшое отклонение от неё (хитрыми путями). Самые распространённые (и дешёвые) УДК бывают: 1. Без подогрева вообще (старые) - выход 1 провод или 2. 2. С непосредственным подключением подогревателя к сети 12 В - 4 провода. Сопротивление между 2-мя белыми проводами у таких УДК 8...12 Ом. 3. С управлением подогревом ЭБУ - тоже 4 провода. Но сопротивление между белыми порядка 3 Ом. У таких УДК 1 В (чуть менее) появляется при отсутствии кислорога в ОГ, но бывают и другие(более дорогие и редкие) УДК с выходом 5 вольт. Широкополосные Датчики Кислорода (ШДК): проводов более 4-х (минимум 6), управление подогревом - целая навороченная схема с постоянной автокалибровкой, цена раза в 4 выше, чем у УДК, а срок службы раза в 3 меньше, + цена схемы управления им порядка 6 тыр., но показывают реальное кол-во кислорода в ОГ, т.е. могут поддерживать не только стехиометрию. ИМХО, если устроит стехиометрия, то использовать самый обычный старый жигулёвский 10-ный УДК с сопротивлением между белыми проводами 8..12 Ом (измерить при покупке в магазине), ценой в районе 1000 руб. Ну или посложнее - тоже 10-ный УДК, но с управление подогревом (сделать простую схемку) - позволит работать в при более низкой т-ре ОГ и трубы (в районе 0..10 гр. Ц).
  17. Цитата(endeavor @ Nov 23 2011, 12:49) Вопрос, нужно ли для каждой функции создавать endpoint, или определить для себя 255 (или более) типов пакетов и обмениваться данными через готовый endpoint? Создавать endpoint не нужно. А лучше сначала почитать документацию по USB, HID и т.д., она ведь сейчас доступна - а уже потом задавать вопросы...
  18. Давным-давно тупо отредактировал реестр и всё работает: [attachment=62732:re10400.JPG]
  19. Нужен для промышленных целей. Вместо винта - CF. Из интерфейсов достаточно USB. Наверное можно даже без видеовыхода, хотя для отладки дисплей конечно нужен. Никаких шин (ISA, PCI и т.п.) тоже не надо. Процессор можно даже и 400 мГц. Желательно чтобы можно было поставить win, но вообще планируем использовать freeDOS. Пишу сюда т.к. поиск выдаёт что-то уж слишком навороченное. Или настолько обрезанное, что USB нет. М.б. кто что-то подобное использует и может подсказать где берёт.
  20. Разъём OBD MERCEDES AXOR

    Цитата(Энри @ Nov 9 2011, 23:33) Я про функции или если можно назвать это процессом диагностики "на ходу" имел ввиду. Параметризацию на ходу проводить, что ли? Ни один Камминзовский блок этого сделать не даст если обороты отличны от 0. Про другие не знаю. А запрашивать параметры можно. Вон Английский Мерфи (типа бортового компьтера для J1939) вовсю запрашивает, и ничего.
  21. Разъём OBD MERCEDES AXOR

    Цитата(Энри @ Nov 9 2011, 18:13) Да вот и самое "противное" в 11bit CANID, что непонятно откуда оно идет... Физически выяснить это не проблема - см. CAN хаб. Немного его модернизировать, подключить в разрыв и будет "слышно" сообщения приходящие только с определённой стороны. Цитата(Энри @ Nov 9 2011, 18:13) И какие уже машины покрыты? Работаем с Камминзом, с их гарантийщиками и эксплуатационниками (оф. дилерами по странам СНГ). А им, в первую очередь, интересны самые "большие" двигатели. Поэтому, более всего разработано ПО под их блок типа CM500, который ставится на двигатели объёмом от 19 до 72 литров. Там цена очень высока, $500000 60-ти литровый QSX-60 стоит, например. Вот и следят... У CM500 есть и J1587 и J1939 - под них и сделали. Ну и другие машины, у кого такие интерфейсы, работают без проблем. Все "американцы", например. Только без проприетарных параметров, конечно. Но всё равно очень много полезного у них есть, как правило. Цитата(Энри @ Nov 9 2011, 18:13) Насколько я знаю это очень опасно "на ходу". Насколько я слышал из семинаров. Для таких "опасающихся" есть вариант беcконтактного подключения к CAN. Т.е. на CAN провода одеваются клипсы и передача идёт через ёмкость. Понятно, что в этом случае ничего из сети запросить нельзя, но этого им и не требуется, как правило. Однако камминзовские гарантийщики напрямую подключаются, и ничего...
  22. Разъём OBD MERCEDES AXOR

    Цитата(Энри @ Nov 8 2011, 23:42) В зависимости от конфигурации авто (смотреть VIN по WIS'y), может быть много ценной для телематических блоков информации, а может и быть "0". Да, видимо этот Аксор в самой бедной комплектации... Уровень топлива ни меня ни владельца не интересует, хотя, если понадобится, найду без проблем - это самое простое. А вот уровень масла, например, интересен. Поэтому мне FMS не интересен, т.к. из полезных данных там только положение акселератора, т-ра кооланта и обороты. Меня интересует формат передачи ошибок и параметров для того, чтобы удалённо диагностировать эту машину. Можно и запросить там в CANе чего-нибудь, если это будет нужно, а главное, если ответят... На Сканиях (версии не помню), на MANах (TGA, TGX) и на некоторых других на диагностический разъём выведено что то своё проприетарное (видимо чтобы диагностику проприетарную покупали), а внутри стандартный J1939. Это потому, что КПП и другие узлы там стандартные и требуют стандартного протокола. А вопросы есть, конечно. С J1939 и J1587 вроде разобрался, всё работает, а к другим протоколам пока даже не приступал. В первую очередь интересны те, машин с которыми у нас много.
  23. Разъём OBD MERCEDES AXOR

    Цитата(Энри @ Nov 3 2011, 18:08) Что именно интересует по Merce? Там есть несколько шин, в основном 250 кбод Формат передачи данных, в т.ч. ошибок. Т.е. как передаются обороты, уровни, расход, давления, температуры, положения и т.д. А CAN шину я там только одну нашёл. Это на Акросе их несколько - как минимум 3 видел. Но там лог не снимал и скорость в шинах не измерял. А на Аксоре всего одна шина, да и параметров там, судя по логу, немного. Менее 20, навскидку. Хотя может какие-нибудь по запросу передаются. Наверно и на Аксоре будет 250 кбод, если там КПП автомат будет стоять (наверняка ведь стандартная, с управлением по J1939), но на этой машине чистая механика была.
  24. Цитата(GlueBF @ Oct 31 2011, 15:00) Каким образом произвести опрос конечной точки INTERRUPT IN USB-HID устройства? Самым обычным реадфиле. Вот только хэндл для креатфиле получить не так просто. По регистру нужно лазить, конечно, но несколько способов есть.
  25. Цитата(Taradov Alexander @ Oct 19 2011, 12:36) Легально - никак. Нелегально можно просто взять VID/PID от балды и надеяться, что все будет хорошо. Ставлю во всех своих USB устройствах VID=PID=bcdDevice=0. Такой VID не может быть никому распределён т.к. винда, да и другие ОС им неисправные устройства отмечает. Но всё отлично работает под всеми ОС, т.к. драйвер ставится по классу устройства. HID и MassStorage, например. На забугорных форумах говорят, что это вполне легально.