Ну да, - в описании в (пдф-е) файлы БД названы как manufacturers.txt (производители) и pgns.txt (собственно, база PGN-ов), а в реале они с расширением .dat. Видимо, в самом начале они были в обычной кодировке в текстовых файлах (т.е., прописаны в явном виде), однако, потом их "закрыли". И раскодировка производится в самой dll-ке.
Хотя о характере записей можно судить также по прилагающемуся файлу revision.2013.txt (ревизии по изменениям и дополнениям) за 2013 г. Там все в явном виде в текстовом формате (кстати, если это изменения действительно только за один год - то офигеть, - сколько их там много для одного года-то..)
Что касается "дорого - дешево" - смотря для чего. Думаю, что за два полноценных канала в исследовательских целях, да ещё и с довольно удобными прикладными интерфейсами и анализаторами и возможностью собственных программных разработок, хорошо задокументированных, $100, считаю недорого...
Кроме того, в таких профессиональных девайсах есть возможность установки LOM (listen only mode) - режим только прослушивания. Дело в том, что любой контроллер в сети обозначает свое присутствие, отсылая периодически обязательную служебную информацию (не путать со стандартными CAN-сообщениями), как бы обозначая свое присутствие. В режиме LOM контроллер никак не выдает своего присутствия, однако все слышит, что происходит в сети.
Далеко не во всех дешевых решениях вообще можно выйти в этот режим.
Точно не знаю как в авто-, но во многих случаях, сеть штатных девайсов просто отказывается общаться, при появлении "лишнего" участника, либо автоматически переходит в режим кодирования и т.д. и т.п.
К тому же - анализ самой шины на ошибки и проч..
Буквально на прошлой неделе знакомый диагност сканматиком не увидел гранту - я же, подкинув два проводка на два известных пина, получил лог, правда он ещё и показал большое количество ошибок самой шины, однако, это уже не сравнить с "Ааа! Все пропало - сканмат вообще ничего не видит! Что делать!:smile:"
Из минусов - как я уже писал, Marathon это клон IXXAAT. На работе у нас есть с десяток тех и других. При большой загруженности (например, подключено 4 двухканальных девайса, то есть, всего 8 каналов, - максимально возможное количество на 1 комп.), Marathon-ы часто начинают глючить, чего не скажешь об IXXAAT. Есть и ещё косячки не в пользу марафонов..
Но я уже говорил - цена IXXAAT - на порядки больше.
Кстати, вот скрин моих небольших опытов с J1939 - соединил два канала одного марафона между собой (2 и 7 пины) и получился простейший эмулятор - с одного канала посылаю, на втором смотрю расшифровку.. Прикольно!

Есть китайский CANalyst-II (Спасибо за наводку Juan7), за 70$ с доставкой. 2 канала, контроллер - SJA1000.
Протоколы: CAN2.0A/2.0B; iCAN; DeviceNet; CANopen; SAE J1939.
SDK присутствует.

Второй мой адаптер - CAN Hacker. Копия того, что делали немцы. Тоже SJA1000. В обоих адаптерах присутствует LOM.

На работе используем CAN BUS Analyzer Tool APGDT002 от Microchip.

Это еще один подводный камешек. 8) В тех авто, что смотрел - такого не видел. Видел только отказ в общении, но не на авто. Пните плз на пример с шифрованием. Интересно для общего развития. Кстати, а что может передаваться по сети в кодированном виде?

В таких случаях либо мультиметр, а лучше осциллограф и смотреть сигналы. Знаю пару примеров, когда EDC заваливал CAN-Lo при нормальном сигнале CAN-Hi. Еще были примеры несогласованной линии - ошибками плевало очень сильно.
Ниже - формы сигналов на линии.
http://tigach.narod.ru/is.files/image002.jpg

CAN-Hacker тоже не подарок, подвисает, глючит. Возможно из-за тормозной ATMega. В CANalyst-II что-то пошустрее.

Посмотрите лог отсюда, если так заинтересовал J1939.
[Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]
Там живые данные. Есть на чем поэскперементировать.

----------

Alexo, Еще хотел добавить про PCI/PCI-E<>CAN интерфейсы. Вы такие используете?
М.б. проблема не в адаптерах марафоновских а в South Bridge компа.

По поводу кодировки - знаю, что это применяется в, скажем так, спец. технике - помимо резервирования каналов, допустим, есть такое - период SINC -ов ( в CANopen - сети) в случае какой-либо нештатной ситуации на шине, например, сопротивление вышло за допустимые пределы (тут, кстати, и LOM не поможет) начинает изменяться по квази-случайному закону с большим периодом "квазийности", что сильно осложняет работу "посторонних" блоков, даже если им удалось внедриться в сеть под видом одного из штатных.
Там вариантов - куча, - есть даже алгоритмы, позволяющие вначале вычислить внедренные блоки, а затем перевести их в разные режимы вплоть до отключения.. Все зависит от характера и логики работы шины.
Конечно, не думаю, что все это используется в обычном автомобилестроении, однако, думаю, что некоторые наиболее критичные узлы или службы могут быть защищены чем-то подобным...

----------

За ссылку спасибо, но я пока сам ещё до конца не понял, - что конкретно изучать, - пока ещё даже общая картина не сложилась - просто, пока интересно все подряд связанное с кан-технологиями.
Так что сказать, что J1939 как-то "по-особому" заинтересовал - не могу..

----------

Может быть.. Нет, платы мы не используем.

----------

Посмотрел ссылку - насколько я понял, там формирование базы из реальных логов, причем автоматизировано по-возможности. Вобщем-то, в плагине J1939 уже это есть. Как подключаться к его dll из своего софта и что туда передавать в качестве параметров, - тоже понятно...

У нас пару таких есть, для моделирования сети. Еще часто для отладки их используют.
А так в основном - CAN BUS Analyzer Tool для мониторинга и отправки комманд. И JTAG для внутрисхемной отладки/программирования.

Не совсем так. Там база формируется из XLS файла (файл на 17 странице в моем посте) от SAE. А база отчетов уже из реальных данных.

Файл пока не декодировал, так что трудно сказать. Что касается Вашего скрина с логами - очень похоже, что база у Вас полная и, возможно, старше моей. Т.е. с дополнениями. Сам файл можно скачать для ознакомления. Там описаны алгоритмы расчета параметров, для некоторых параметров - значащие биты.

У меня есть тот екселевский файл с параметрами (тогда ещё скачал). Но, пока, - говорю же, - не знаю в каком направлении "приложиться" более серьезно, в голове пока можно сказать "каша" от обилия информации. Приложиться, - в смысле и чтобы полезно было для знаний, и чтобы интересно по максимуму. Но и про реальный доход забывать нельзя (хотя прекрасно знаю, - начнешь думать преимущественно о марже - все! - лучше и не начинать, - ничего не получится..:cool:)
Сейчас вот почитываю форум rusefi (по Вашей ссылке), - например, интересно, что оттуда можно почерпнуть очень много по логике работы ECU. Для начала хотел бы для себя оценить сложность алгоритмов и объем информации..
То есть, у меня пока цели неуточненные..
Да, ещё и друг зовет вплотную заняться диагностикой (хотя бы на выходных). Тоже пока до конца не пойму - в каком, собственно, качестве? Бывают, конечно, моменты, где и я могу что-то подсказать (как в примере с Грантой), но опять же - пока для меня здесь больше.. не то чтобы неизвестного.., а не "уложившегося по своим полочкам" в голове, - так будет точнее:wink:...

СТО Выходного дня? :smile:
У меня примерно такая же фигня. Только еще один момент. Есть собственный МАЗ, что не свойственно для IT-шника, и сдаю его в аренду.

По поводу инфы - тут лучше определиться что именно нужно. Для меня интересен бортовой самописец/треккер. Для этого я ищу протоколы взаимодействия датчиков с ECU/EDC.
Работа самого блока пока не интересна, но думаю пригодится в дальнейшем.

Ну, он-то занимается постоянно - не просто диагностика, а ещё и ремонт, сигналки, парктроники и проч. Но у него много случаев, типа таких - звонит недавно: "Мазда 3-ка не заводится! По тем ошибкам, что выдавал сканер - отработал - заменил (откинул, что-то там ещё "колдовал") - ничего не помогает. Ты же "спец" по кану! Приезжай - поможешь!":smile:
Трудно объяснить, что все что в лучшем случае я могу дать - это некую доп. информацию, которую все равно "додумывать" придется и чуда не получится..
Да вот тоже - думаю эмуляторы - интересная тема. Однако, там протокол обмена даже не бОльшая часть. Главное - имитация алгоритмов работы. А это уже глубокими знаниями надо обладать..
Такие дела.:smile:

Скажу, как ремонтик, от кана две пользы:
-графики (балансировка топливоподачи, давление наддува....и то если нет подобного функционала в программе диагностики)
-запись лога в случае "плавающей неисправности" с последующим анализом лога

Полезная инфа - спасибо!..
Это взгляд, так сказать, "изнутри" - как я понимаю, специалиста, который непосредственно занимается ремонтом.
Хотелось бы услышать мнения о создании эмуляторов также (кто-то говорил тут, что занимался этим)
Интересно также мнение о создании универсального сканера-анализатора с возможностью постоянного САМОСТОЯТЕЛЬНОГО наращивания функционала с помощью интегрированных возможностей (не будучи при этом программистом)..

Ну текса так и делалась, цепляем логер и пишем дамп от дилерского тестера, потом разбираемя, что как и как активируется. Эмуляторы давно придуманы. А вот готовая фича, например ошибки стирать постоянно ;) [Ссылки могут видеть только зарегистрированные пользователи. Зарегистрироваться...]