[Ruslan1 17]

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

 

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

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

 

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

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

 

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

 

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

[DmitryM 0]

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

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

[Ruslan1 17]

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

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

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

 

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

 

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

[_3m 9]

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

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

Фтопку!!!

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

Изменено 16 октября, 2013 пользователем _3m

[Ruslan1 17]

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

Фтопку!!!

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

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

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

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

[_3m 9]

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

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

 

[Ruslan1 17]

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

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

[Ruslan1 17]

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

 

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

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

 

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

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