Сообщений в теме: 743

[nikr]

Неужели в наличии не нашлось? Я уж сам думал там по 60Р прикупить, пока от китайцев оказии нету.

В наличии нет - оббежал весь рынок. Есть только в одном месте под предзаказ по 59р мелкий опт.

Игорь, у вас таймаут на ответ от датчика какой стоит? Увеличить его можно? Похоже у меня не всегда успевает ответить - где то на пределе.

Ухищрения с обработкой АЦП через 500мс после окончания обмена не помогают. Сам модбас слейв похоже долго отрабатывает.
Правда я не отвечаю когда:
- чужой адрес
- не совпадают контрольные суммы присланная и вычисленная
- неизвестная датчику команда.

Скриншот - http://yadi.sk/d/jd3SENODAc8kP

у qModMaster таймаут аж 1 сек - поэтому гарантированно без ошибок проходит

[UL7AAjr]

В наличии нет - оббежал весь рынок. Есть только в одном месте под предзаказ по 59р мелкий опт.

Странно, на терраэлектронике написано, что есть в наличии и 152-е и 151-е.
 

Николай, у вас подозрительно много пакетов с неправильной контрольной суммой. И что интересно, это примерно половина от количества общих ошибок. Я так полагаю, что датчик не отвечает, из-за того, что тоже получает пакеты с неверной контрольной суммой. У меня ошибка CS может пару раз за весь день выскочит, и то много. У вас всегда так было или вы что-то с линией сделали?

Сейчас, после запроса к датчику, жду 20ms, и если во входном буфере COM порта нет данных, то считаю ошибку. Если первые два байта в ответном пакете неверные (ID и команда), то так же считаю датчик не ответившим и контрольную сумму не подсчитываю.

Я могу немного увеличить время ожидания ответа от датчика. Сильно много тоже нельзя, если датчиков много, пока до последнего очередь дойдет, уже пора первый опрашивать снова . В принципе, можно опрашивать не ответившие датчики повторно, после обработки всей очереди датчиков. Но сообщение об ошибке все-же надо выдать, для отладки и статистики.


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

[Sprinter]

Здравствуйте Роман! Заниматься производством датчиков пока не думал. Да и пока рановато об этом задумываться - сначала надо их обкатать, чтобы поработали какое то время. Статистику набрать, может что доработать придется. Вон вторая версия у Валерия уже лето обкатывается - пока все нормально. Я специально всю документацию выложил чтобы люди могли повторить. В вашем случае можно все лишнее просто не устанавливать. То есть оставить процессор, стабилизаторы, измерительную цепь и светодиод. Заливаете стандартную прошивку и светодиод начнет показывать цветом состояние почвы. Но должен огорчить - особо дешево тоже не получится. У нас в Москве Atmega386 в розницу стоит > 200р ну и еще мелочевки наберется.

Николай, вот мог бы, то повторил бы. Даже с великим удовольствием. Но отсутсвие свободного времени и необходимых знаний не позволяют этого сделать. Паяльником владею только на уровне "спаять два проводка". Схемы читать не умею, делать печатные платы тоже. Сомневаюсь, что в нашей местности легко найти требуемые запчасти. Мне проще быть тестером и я даже готов за это заплатить. Любой труд должен оплачиваться. Ваши наработки мне нравятся, но вот повторить их самому нет ни времени, ни возможности. Мне проще заработать и потратить на то что мне интересно. Я бы с радостью приобрел бы пару ваших последних версий датчиков работающих автономно. На данный момент мне не критично соединение с компьютером. В будущем возможно.
Лично мне сейчас нужно устройство, которое может определять влажность почвы. как-то сигнализировать об уровне этой влажности, питаться от собственного элемента питания (1,2В, 1,5В, 3В, 12В). Я изходя из этих задач выбрал себе не так давно Uniel UTV-63 + 2 дополнительных датчика (фото).
Задумка хорошая, исполнение не ахти.
Плюсы:
Красиво, удобно, с дисплеями. Датчики могут работать автономно от базовой станции и пищать о критически низком уровне влажности. Компактно довольно. Питается от батареек 2032 датчик и 3 АА станция. Станция может одновременно обслуживать 5 датчиков. На каждый датчик свой уровень влажности при котором оповещать можно выставить. В станции есть часы, будильник. Возможно выключение сигнала оповещения с вечера до утра. Показывает 5 маленьких пиктограмм на каждый датчик и одну большую либо какого-то выбранного либо в цикле гоняет все. Естественно беспроводное. Частота 433, кажется. Сама станция может как стоять на подставке так и вешаться на стену. В общем. Основные плюсы не так критичны.

А вот минусы.....
1. И самое неприятное - непонятная шкала. Всего четыре деления. Что на станции, что на датчике. 1- Очень сухо, 2- Сухо, 3 - Влажно, 4 - Очень влажно (мокро).
Чего куда и сколько не понять. В инструкции толком ничего не описано. Инструкция вобще кривая и не точная. На воздухе датчик показывает 1 деление. Один из датчиков воткнутый в речной песок сухой (есле пересыпать то пылит) показал 2 деления. Только один раз мне удалось на одном из датчиков выжать 4 деления. На 2-ух других только 3. При том что грунт везде одинаковый и проливалось хорошо. В поддон прилично вытекало. Возможно на данных датчиках показания сильно зависят от типа и состава грунта.

2. Нет описания интервалов работы датчика и его кнопки (как выяснилось - это кнопка перевода в автономный режим, при автономном режиме датчик сам пищит и моргает при уровне 1 и не общается со станцией)

3. Задержка смены данных на дисплее базовой станции не менее 5 минут. Хотя датчик передает данные минимум раз в минуту. Т.е. запищала станция, что полить надо. Идешь поливаешь. На датчике показания изменились, а станция еще минут 5 минимум может попискивать. Из-за таких больших интервалов сначала думал что устройство вобще не работоспособное. То датчики не видит, то еще что. 3 часа убил тыкая датчики туда сюда и пытаясь выяснить закономерность работы датчиков и станции. Пока не плюнул и не воткнул на ночь. Неделю не до них было, а потом выяснилось что все-таки работает. Фактически вот так оно настроено, тормознуто. На данный момент пользуюсь уже две недели. Посмотрим, что из этого выйдет.

[nikr]

Странно, на терраэлектронике написано, что есть в наличии и 152-е и 151-е.

Игорь, я в терру не ездил. У нас в районе Митино есть радиорынок - там и заказал.

Николай, у вас подозрительно много пакетов с неправильной контрольной суммой. И что интересно, это примерно половина от количества общих ошибок. Я так полагаю, что датчик не отвечает, из-за того, что тоже получает пакеты с неверной контрольной суммой. У меня ошибка CS может пару раз за весь день выскочит, и то много. У вас всегда так было или вы что-то с линией сделали?

Линию посмотрю -возможно терминатор неподходящий.
Может нам в обработку протокола заодно обработчик ошибок подписать. Там возвращается команда с установленным старшим битом и следующим байтом код ошибки. Какие нибудь основные ошибки обработать, а то сложно гадать.

Сейчас, после запроса к датчику, жду 20ms, и если во входном буфере COM порта нет данных, то считаю ошибку. Если первые два байта в ответном пакете неверные (ID и команда), то так же считаю датчик не ответившим и контрольную сумму не подсчитываю.

Я могу немного увеличить время ожидания ответа от датчика. Сильно много тоже нельзя, если датчиков много, пока до последнего очередь дойдет, уже пора первый опрашивать снова . В принципе, можно опрашивать не ответившие датчики повторно, после обработки всей очереди датчиков. Но сообщение об ошибке все-же надо выдать, для отладки и статистики.

Вы всегда ждете 20мс, а потом только обрабатываете? А если пакет раньше пришел, сразу на обработку не идете?

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

У меня по прерыванию RX заполняется буфер, а в основном цикле проверяется есть в нем что или нет, если есть идет разбор пакета и формирование ответного. Если буфер пустой занимаемся другими делами: АЦП, индикацией, перезаписью регистров.... Так что возможна ситуация, когда пакет пришел, а до его проверки дело еще не дошло. Все остальные функции датчика не связанные с протоколом линейные, без всяких циклов.Должны пролетать быстро. Ну разве что запись в EEPROM, но туда пишется только после команды в 3 регистре - то есть ветка редкая

[oduvan]

Провел эксперимент с сенсором - воткнул его в горшок со спатифиллумом на 100 мм это половина длины моего датчика(такая глубина горшка) перед этим залил хорошенько цветок и слил лишнее.
Далее проводил измерения каждый день вечером и записывал показания ацп.
Пока он был избыточно увлажнен показания стояли на отметке 130.
Через 4 дня они начали меняться:


Возник вопрос:
Как калибровать датчик, ведь на опорные показания влияет много факторов(состав земли, степень заглубления датчика, и прочее)???
Или же брать за 100% показания в воде, а за 0 на воздухе?

[UL7AAjr]

Игорь, я в терру не ездил. У нас в районе Митино есть радиорынок - там и заказал.

Да уж, вам в другой конец города - два дня с привалом ехать

Линию посмотрю -возможно терминатор неподходящий. Может нам в обработку протокола заодно обработчик ошибок подписать. Там возвращается команда с установленным старшим битом и следующим байтом код ошибки. Какие нибудь основные ошибки обработать, а то сложно гадать.

Проще в дополнительные регистры модбаса статистику работы датчика вывести. Сколько пакетов заметил, сколько предназначенных датчику, сколько с ошибочной CS и т.д.

Вы всегда ждете 20мс, а потом только обрабатываете? А если пакет раньше пришел, сразу на обработку не идете?

Ну так у Windows на COM порт входной буфер есть. Можно не спешить.

У меня по прерыванию RX заполняется буфер, а в основном цикле проверяется есть в нем что или нет, если есть идет разбор пакета и формирование ответного. Если буфер пустой занимаемся другими делами: АЦП, индикацией, перезаписью регистров.... Так что возможна ситуация, когда пакет пришел, а до его проверки дело еще не дошло. Все остальные функции датчика не связанные с протоколом линейные, без всяких циклов.Должны пролетать быстро. Ну разве что запись в EEPROM, но туда пишется только после команды в 3 регистре - то есть ветка редкая

Николай, тут кажется проблема не в этом. У вас когда датчик пакет на сервер отправляет, он же ни на что не отвлекается, правильно? А на сервер пакеты "битые" приходят. Или у вас ответ тоже по прерыванию работает?

[UL7AAjr]

Провел эксперимент с сенсором - воткнул его в горшок со спатифиллумом на 100 мм это половина длины моего датчика(такая глубина горшка) перед этим залил хорошенько цветок и слил лишнее. Далее проводил измерения каждый день вечером и записывал показания ацп. Пока он был избыточно увлажнен показания стояли на отметке 130. Через 4 дня они начали меняться: ... Возник вопрос: Как калибровать датчик, ведь на опорные показания влияет много факторов(состав земли, степень заглубления датчика, и прочее)??? Или же брать за 100% показания в воде, а за 0 на воздухе?

Сергей, свою мысль выскажу. Вы сами почти ответили на свой вопрос. Калибровать надо каждый датчик в "своей" почве. Заливаем до "упору" и ждем, пока показания АЦП не начнут расти. Это и есть 100%. А показания на воздухе можно принять как 0%. Если используете термокомпенсацию, то надо запомнить температуру, при которой вы задали значение АЦП как соответствующие 100% влажности. Я, например, так и делаю.

Если используете мое приложение - то все еще проще. Залейте по максимуму и подождите несколько дней, потом в приложении настройте параметры конвертора так, чтобы максимальные значения на графике за прошедший период стали равными 100%.

[nikr]

Лично мне сейчас нужно устройство, которое может определять влажность почвы. как-то сигнализировать об уровне этой влажности, питаться от собственного элемента питания (1,2В, 1,5В, 3В, 12В).

Роман, под батарейное питание мои датчики пока не подходят. В посте 410 Владимир давал ссылку на похожую конструкцию как раз с питанием от батарейки, правда у нее 1 порог после которого начинается звуковая индикация. Я собираюсь собрать одну такую посмотреть что как работает. Когда наиграюсь - могу прислать.

А вот минусы.....
1. И самое неприятное - непонятная шкала. Всего четыре деления. Что на станции, что на датчике. 1- Очень сухо, 2- Сухо, 3 - Влажно, 4 - Очень влажно (мокро).

На моих датчиках тоже не очень удобная индикация. Во второй версии из 3-х вспышек разных цветов ( получается 9 "делений"), в третьей 1 вспышка с плавным изменением цвета от красного к зеленому через желтый в зависимости от влажности - то есть влажность определить можно только очень приблизительно. Для батарейного питания больше подходит ЖКИ, как в наручных электронных часах.

[nikr]

Николай, тут кажется проблема не в этом. У вас когда датчик пакет на сервер отправляет, он же ни на что не отвлекается, правильно? А на сервер пакеты "битые" приходят. Или у вас ответ тоже по прерыванию работает?

В принципе не отвлекается, кроме системных часов.

Сегодня поэкспериментировал с осциллографом.

Длинна пакета от управляющей программы 8.5мс, уровни -2,7+3. Датчик отвечает всегда без пропусков через 3мс. Длинна пакета для вашей программы 6-7мс уровни -2,5 +0.4 причем для qModMaster длинна пакета бывает аж до 12мс.
Получается, что когда я посылаю ответный пакет, максимка при Tx=1 успевает переключаться на прием. при этом падает амплитуда пакета и возможно мусорится приемный буфер датчика. Поражает, что qModMaster ошибок не фиксирует вообще.
Наверное надо переходить на программное управление направлением передачи.

Игорь, таймаут у вас для моего датчика на пределе. Если брать пакет 8,5 задержка 3 ответ 8,5 как раз набегает 20мс. Может увеличить до 25мс, чтоб гарантированный запас был?

[UL7AAjr]

В принципе не отвлекается, кроме системных часов.

Уже теплее
 

Сегодня поэкспериментировал с осциллографом.

Длинна пакета от управляющей программы 8.5мс, уровни -2,7+3. Датчик отвечает всегда без пропусков через 3мс. Длинна пакета для вашей программы 6-7мс уровни -2,5 +0.4 причем для qModMaster длинна пакета бывает аж до 12мс.
Получается, что когда я посылаю ответный пакет, максимка при Tx=1 успевает переключаться на прием. при этом падает амплитуда пакета и возможно мусорится приемный буфер датчика. Поражает, что qModMaster ошибок не фиксирует вообще.

Удвоенная длина пакета может говорить о повторном опросе.
 

Наверное надо переходить на программное управление направлением передачи.

Игорь, таймаут у вас для моего датчика на пределе. Если брать пакет 8,5 задержка 3 ответ 8,5 как раз набегает 20мс. Может увеличить до 25мс, чтоб гарантированный запас был?

Николай, 20ms - это ошибка если ничего не пришло вообще в течении времени после отправки последнего байта запроса, только тогда ошибка фиксируется. Другими словами, надо в течении этого времени начать ответ.

Пересмотрел свой код, раньше тоже были проблемы с искусственными шумами в линии, проблема решилась поднятием ноги TX в режиме приема. Т.е. всегда после передачи, нужно поднимать TX.

 read mode.jpg   37.44К   18 Количество загрузок:

PS: В режиме экономии энергии, нужно не просто переключать драйвер 485 в режим приема, а переводить его в неактивное состояние, т.е. запретить и прием и передачу. Понадобится две ноги МК на управление драйвером.

[nikr]

Удвоенная длина пакета может говорить о повторном опросе.

Игорь, у вас по одному регистру за команду читается, а qModMaster сразу несколько запрашивает одной командой поэтому ответ длиннее получается.

Николай, 20ms - это ошибка если ничего не пришло вообще в течении времени после отправки последнего байта запроса, только тогда ошибка фиксируется. Другими словами, надо в течении этого времени начать ответ.

Ну значит мои ответы должны приходить так как через 3мс начинаю отвечать.
Игорь, а "нет ответа" по каким критериям формируется 20мс и чужой адрес или еще чего есть?

Пересмотрел свой код, раньше тоже были проблемы с искусственными шумами в линии, проблема решилась поднятием ноги TX в режиме приема. Т.е. всегда после передачи, нужно поднимать TX.

Получается канал передачи в max485 не отключается от линии при режиме приема? Вроде бы не должно такое быть.

Переделал управление направлением max485 от ножки МК амплитуда ответа увеличилась.
Воткнул пару датчиков в горшки линия КСПБ 4 х 0.5 питание на ней же.
http://yadi.sk/d/lA_nKMuGAn4Fv

один датчик с сенсором на разъеме, второй на проводочках.
датчики одинаковые прошивки тоже, а ошибки шлют по разному.

http://yadi.sk/d/_QSLBtMyAn4rq

на показания температуры почвы не смотрите там на одном подкорочено, а на втором lm-ки нет.

Загрузить сохраненный датчик из файла (.sns) в управляющей программе не удалось приложение выдает ошибку: "Error reading TSGDevice.FlushOn: Property FlushOn does not exist."

[UL7AAjr]

Игорь, у вас по одному регистру за команду читается, а qModMaster сразу несколько запрашивает одной командой поэтому ответ длиннее получается.

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

Ну значит мои ответы должны приходить так как через 3мс начинаю отвечать.
Игорь, а "нет ответа" по каким критериям формируется 20мс и чужой адрес или еще чего есть?

Прием ответа выглядит так:

после передачи запроса ждать 20ms
если получен байт и он совпадает с кодом опрашиваемого датчика то
если получен байт и он совпадает с кодом отправленной команды то
если получен байт длины данных то
если удалось загрузить данные то
если загружена контрольная сумма то
проверить контрольную сумму, если не совпадает, то взвести флаг ошибки CS и выйти
только в случае совпадения контрольной суммы будет результат "ответ получен"

вот на всякий случай кусок кода чтения регистров.

 read_code.jpg   89.91К   5 Количество загрузок:

Получается канал передачи в max485 не отключается от линии при режиме приема? Вроде бы не должно такое быть.

Да странно как-то, но ошибки у меня резко после этого упали.

Переделал управление направлением max485 от ножки МК амплитуда ответа увеличилась.
Воткнул пару датчиков в горшки линия КСПБ 4 х 0.5 питание на ней же.
http://yadi.sk/d/lA_nKMuGAn4Fv

один датчик с сенсором на разъеме, второй на проводочках.
датчики одинаковые прошивки тоже, а ошибки шлют по разному.

http://yadi.sk/d/_QSLBtMyAn4rq

на показания температуры почвы не смотрите там на одном подкорочено, а на втором lm-ки нет.

Ну так и процент ошибок с контрольной суммой резко упал. Я попробую перед ожиданием ответа датчиков входной буфер COM порта почистить, может там какой мусор набитсья успевает. Добавлю отладочный код, чтобы знать какой байт пришел не так и пришел ли вообще. Если завтра не успею, то уже только в четверг, у нас праздники, уеду из города.

Странные у вас растения какие-то

Загрузить сохраненный датчик из файла (.sns) в управляющей программе не удалось приложение выдает ошибку: "Error reading TSGDevice.FlushOn: Property FlushOn does not exist."

Возможно датчик сохраненный в файл был "влажность/температура", а загрузка производилась в "универсальный" датчик, у него действительно нет свойства "уровень включения полива" (FlushOn).

[UL7AAjr]

Николай, я добавил отладочные сообщения в приложение.
https://docs.google....dit?usp=sharing

Еще не плохо бы выделить регистр ModBus на датчике, где хранить количество пакетов с ошибочной контрольной суммой.

 

Игорь, спасибо. Завтра вечером попробую и заодно регистр добавлю. Сейчас я на даче.

[nikr]

Николай, я добавил отладочные сообщения в приложение.
Еще не плохо бы выделить регистр ModBus на датчике, где хранить количество пакетов с ошибочной контрольной суммой.

Вот что получилось http://yadi.sk/d/WoAY5eCCB3F9R - теперь бы это все расшифровать.

Регистр завел под CS 40007 - в нем по нулям, то есть пакеты приходят к датчику не битые.

[UL7AAjr]

Таак...уже более-менее понятно. Расшифровка сообщений CS error: ошибка контрольной суммы пакета ID <>: неверный код датчика ID timeout: датчик не начал передачу в течении таймаута CMD <>: неверная команда (ID был правильный) Николай, похоже на сильный шум в линии при приеме данных от датчика. Ошибки все время разные, и я очень сомневаюсь, что вы неверно отправляете назад ID датчика или код команды. Это точно что-то не так в оборудовании. У вас, кстати, в адаптере 485 случайно защитный диод на входе не стоит? Я его пока не выкусил, не мог уверенно данные от датчика принимать.

[nikr]

ID timeout вообще штука невероятная так как пропусков в передаче вообще не было смотрел по осциллографу - отвечает всегда. А если датчик обрежет кусок последнего байта в пакете, не может ваша программа это интерпретировать по разному? Надо попробовать задержку поставить при переключении с tx на rx. Схему адаптера не рисовал, но по внешнему осмотру ft232, изолятор adum5401 и 8-и ножка с маркировкой m42 - похожа на интерфейс 485 ну и по мелочи обвязка всякая.

 

 

При отправке сообщения проверяю Tx буфер и когда он пустой раньше переключал максимку на прием. а теперь поставил задержку в 1,5 символа. Ситуация не изменилась - дело не в этом. Заодно попробовал питание датчикам по отдельному проводу подавать результат тот же.

[UL7AAjr]

Николай, возможно дело все-таки в качестве сигнала. Если амплитуда недостаточная, COM порт может пропустить начало передачи. Это объясняет пропуск начала ответа (ID timeout) ответа от датчика. Не помешало бы сравнить амплитуду сигнала от компьютера и от датчика. Для теста можно попробовать заставить датчик непрерывно передавать определенный байт и читать порт на стороне компьютера не переключая направление передачи. По хорошему, я бы вообще не трогал направление передачи и ни на что не отвлекался в момент ответа датчика. У меня в качестве драйвера на датчике не Maxim, а ADM3485 трехвольтовый. Хотя разницы никакой не вижу. В то-же время пробовал всячески поменять настройки буфера COM порта и управление направлением передачи. В любом случае ошибки не появлялись. PS: А скорость передачи точно рассчитана? Может в настройках предделителя что-то не так?

[nikr]

Игорь, Амплитуда от компа и от датчика 4в, правда присутствует цифровой шум в линии 0,4в. Скорее всего в этом шуме все дело. По описанию протокола RS485 разница АВ 200мв уже является сигналом.

Провел эксперимент с передачей в цикле команды 01 ( 8 байт), ответ датчика (6 байт).
Цикл получился такой:
команда с компа 8 байт - 8,5мс ( для скорости 9600 погрешность + 2,4%)
пауза между пакетами 2,8мс
ответ датчика 6 байт - 6,2мс ( для скорости 9600 погрешность - 0,8%)
принудительная пауза переключения max485 на прием 1,5 байта 1,05мс. (расчетное значение 1,5мс).
Так получается что эта пауза все же полезна но на 1 мс больше, чем нужно.
Я ее формирую в момент обнуления буфера TX и как видно из эксперимента пакет еще продолжает передаваться 0,5мс.

[UL7AAjr]

Николай, а откуда шуму то взяться? Если датчики отключить он все равно останется? У меня амплитуда еще ниже, драйвер в датчиках трехвольтовый ADM3485, а вот шума со сколько-нибудь значимой амплитудой вообще не наблюдаю. Что-то у меня есть подозрения, что шум может быть в линии из-за частых переключений на прием/передачу. Со скоростью все нормально. А вот по поводу переключения направления. В USART контроллере МК STM8 есть бит TXE (transfer data register empty), по которому можно писать новые данные в регистр для отправки. Так вот он означает, что данные из регистра данных на отправку перемещены в сдвиговый регистр и можно записать новые данные на отправку, но это не означает, что данные уже переданы. За сигнал о завершении передачи отвечает другой бит TC (transfer complete). Я так полагаю, что на вашем МК такая же картина. И если ориентироваться на TXE, то всегда надо подождать пока данные из сдвигового регистра в линию уйдут. Ну а если по TC, то можно не ждать, а сразу переключить на прием.

[nikr]

Николай, а откуда шуму то взяться? Если датчики отключить он все равно останется? У меня амплитуда еще ниже, драйвер в датчиках трехвольтовый ADM3485, а вот шума со сколько-нибудь значимой амплитудой вообще не наблюдаю. Что-то у меня есть подозрения, что шум может быть в линии из-за частых переключений на прием/передачу.

Шум шел по питанию . На столе полно всяких проводов да и источник отфильтрован был слабенько. Но похоже на RS485 он влияния не оказывал, так как разницу потенциалов А-В не перекрывал. На всякий случай отфильтровал, чтобы глаза не мозолил. На передачу теперь переключаю, когда начинаю отправлять пакет, а в обратную сторону когда весь пакет ушел + пауза в 1,5 байта для гарантии.

Со скоростью все нормально. А вот по поводу переключения направления. В USART контроллере МК STM8 есть бит TXE (transfer data register empty), по которому можно писать новые данные в регистр для отправки. Так вот он означает, что данные из регистра данных на отправку перемещены в сдвиговый регистр и можно записать новые данные на отправку, но это не означает, что данные уже переданы. За сигнал о завершении передачи отвечает другой бит TC (transfer complete). Я так полагаю, что на вашем МК такая же картина. И если ориентироваться на TXE, то всегда надо подождать пока данные из сдвигового регистра в линию уйдут. Ну а если по TC, то можно не ждать, а сразу переключить на прием.

Ага, в атмеге тоже так же.

Странно, что qModMaster ошибочных пакетов не находит. Погонял в цикле через него 1000 пакетов с частотой 1 раз в секунду ни одной ошибки......
Надо его будет на часок запустить для статистики.