Перейти к содержанию
    

SDI-12 протокол: есть ли PC софт какой-нибудь для общения/проверки?

Здравствуйте!

 

Речь идет о протоколе SDI-12

На первый взгляд, ниша та же что у Модбаса- сенсоры и датчики.

 

Думал, что и с поддержкой тоже как с Модбасом- куча мала софта и приложений, в том числе халявных для тестирования.

Но вот с удивлением обнаружил, что в интернете очень мало чего-то практического. Например, не нашел ни одной софтины, с помощью которой можно опросить сенсор. Хотя протокол в поддержке тривиален, но есть нюансы в виде жесткого тайминга и некоторых режимов (конкурентные измерения, например)

 

Может быть, кто-то сталкивался с этим протоколом и может посоветовать где кроме гугла посмотреть?

 

Буду благодарен любым хорошим советам, про софт/железо/ресурс для разработки своих девайсов на эту шину....

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

про софт/железо/ресурс для разработки своих девайсов на эту шину....

IMHO, обычный TTL UART, только переведенный в OpenDrain 12V-16V.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

IMHO, обычный TTL UART, только переведенный в OpenDrain 12V-16V.

Угу. и имеющий очень жесткий тайминг, например, совершенно определенное время между стартовым брейком и первым байтом, жестко лимитированные таймауты при подготовке ответа и при "расщепленном" ответе и прочие заморочки, на соответствие которым и хочется свой прибор проверить. И пока что ломает покупать для этого SDI-12 Verifier за 800 зеленых.

А так да, полностью с Вами согласен, физический уровень прост :)

 

Я уж не говорю, что режим 7E1 кое-кто из производителей контроллеров уже выкинул и аппаратно не поддерживает, но это уже мелочи, четность при таких скоростях хоть в столбик обрабатывать можно.

 

P.S. млин, вот пишу, а опять тряхнуло балла 3-4. чето часто, второй раз за месяц.... уже и со стула лениво вставать.... Ага, вижу. Эпицентр 4.9, значит точно под 3.5 у нас...

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Угу. и имеющий очень жесткий тайминг, например, совершенно определенное время между стартовым брейком и первым байтом, жестко лимитированные таймауты при подготовке ответа и при "расщепленном" ответе и прочие заморочки,

Посмотрел SDI Data recorder flow chart

Фтопку!!!

За протоколы с жесткими таймингами во времена писюков и многозадачных ОС разработчиков нужно передавать в руки Святой Инквизиции дабы огнем, водой и дыбой объяснить грешникам всю пагубность жестких таймингов.

Изменено пользователем _3m

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Посмотрел SDI Data recorder flow chart

Фтопку!!!

За протоколы с жесткими таймингами во времена писюков и многозадачных ОС разработчиков нужно передавать в руки Святой Инквизиции дабы огнем, водой и дыбой объяснить грешникам всю пагубность жестких таймингов.

Ну, Modbus-RTU тоже имеет жесткий тайминг (правда, "помягче" чем SDI-12), но это не мешает его применять. Причем с серьезными отступлениями от стандарта, но продолжая называть это Модбасом, и все довольны. Но понимание наличия отступлений от стандарта у всех пришло ко мне не сразу, предварительно нужно почувствовать стандарт, понять его, написать его поддержку- после этого чужие отступления от буквы закона легко обнаруживаются.

Подозреваю, что и с этим SDI-12 тоже подобное творится и реализуют с отступлениями, но это мне станет понятно через пару лет пользования :)

И да, тайминг это нечто, у меня в Винде в С++Билдере Sleep(15) дает задержку от 9 до 20 миллисекунд. Ладно что больше, но почему настолько меньше бывает.... Просто пример, понимаю что можно извратиться и сделать как надо.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Ну, Modbus-RTU тоже имеет жесткий тайминг (правда, "помягче" чем SDI-12), но это не мешает его применять. Причем с серьезными отступлениями от стандарта, но продолжая называть это Модбасом, и все довольны.

Вообще то мешает и сильно особенно в случае когда применяем сторонние внешние устройства modbus RTU с непредсказуемой капризностью к соблюдению протокола. Хост писюк естественно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так почему ASCII не взяли? сам постоянно хочу на ASCII переползти, но вот не склеивается организационно, везде есть именно RTU.

Хотя мне не мешает. Работает у меня RTU и через 3G каналы.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Если вдруг кто-то когда-то озадачится чем-то подобным, докладываю к чему пришли:

 

Купили готовое устройство, SDI-12 Verifier. Де-факто на него ссылаются производители SDI-12 совместимых устройств как на некий минимальный "тест на совместимость", то есть если им проверено и работает- то таки соответствует спецификации шины SDI-12.

Уже потестил- работает как и должно, согласно документации. Лично мое мнение- оно стОит своих денег, если занимаетесь разработкой и нужно убедиться в правильности реализации протокола.

 

Разработчик (он же продавец)- дружелюбен, быстро и внятно отвечает на вопросы.

Кстати, можно и поговорить с ним об изменении способа доставки с быстродорогой UPS на стандартную дешевую USPS без трекинга, порядка 100 баксов экономии.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...