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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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