Протокол связи для радио модулей HC-12

[CraCk]

Продолжаю мучать радио модули НС-12.
Предыдущаю тема http://forum.flprogwiki.ru/viewtopic.php?f=18&t=1374
Новою тему решил создать так как ModBus c НС-12 работает, но есть много недостатков. По этому нужно какой то беспроводной протокол для работы с такими модулями.
Недостатки работы по ModBus
1) Большая частота опроса слейвов. Если ее уменьшит до 10сек и больше, тогда получаем сильное опоздание реакции слейвов на команды управления
2)При большой частоте опроса. Используя радио модули с мощностью 100мвт при одном мастере и 10 слевов будет получать нехилое облучение и глушение частоты 433мгц.
3)При большой частоте опроса. Невозможно сделать систему энерго независимой.
4)Нет никакого шифрование данных.

Теперь что нужно от беспроводного протокола.
1)Адресация модулей.
2)Пингование радио модулей на присутствие в сети 1-5мин. Если нет в сети после нескольких запросов создавать уведомление.
3)Центральный модуль оправляет в эфир сообщение. Все модули клиенты слушают. Но только один модуль принимает команды и обрабатывает их, в которого совпал адрес сообщение и его собственная адреса.
4) Шифрование может быть
AES http://forum.flprogwiki.ru/viewtopic.php?f=18&t=626
либо диалоговая защита
http://forum.flprogwiki.ru/viewtopic.php?f=18&t=1320
+ мануал http://we.easyelectronics.ru/Soft/kript ... dera.html 
5) Контроль доставки данных
6) Данные от клиентов, это срабатывание концевиков и отправка температуры.
7) Данные от центрального блока, это пингование отправка команды управление разной халтурой в гараже, сарае, огороде.

Сам пробовал создавать протокол с помощью стандартных средств в Флпроге отправляя в UART строки. Все очень громоздко и получается криво.
Потом нашел блоки пользователя Boroda за что ему спасибо. Но это не полноценный протокол.

Из готовых протоколов боле меные адекватный. Но нет шифрования.
http://www.pjon.org/

Вариант использовать WirtualWire и EasyTransfer но нужно блоки пользователя. Но нет шифрования
http://pikabu.ru/story....3636262
http://pikabu.ru/story....3639880
http://majordomo.smartliving.ru/Main/ArduinoVirtualWire

Еще понравились протоколы которые использовал Симплер для NRF24.

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

[Boroda]

Большая частота опроса слейвов. Если ее уменьшит до 10сек и больше, тогда получаем сильное опоздание реакции слейвов на команды управления

Странно. Модбас мастер читает слейвов с заданным периодом, но если в мастере изменилась переменная которая должна отправляться (например изменили уставку для удаленного термостата), то эта команда должна немедленно отправляться слейву, не дожидаясь периода опроса.

Добавлено (20.02.2017, 00:09)
---------------------------------------------
А вот если на слейве поменялись данные, то мастер не сразу об этом узнает. Тут модбас проигрывает.

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

Но может произойти ситуация, когда три слейва одновременно захотят передать сообщение (например произошел БАХ и выбило все стекла и двери с датчиками). Тут поможет многократная передача с обратной связью, рендомным периодом и минимальной длиной посылки. Отправляют одновременно и ни один не получил ответа от мастера, а дальше включается в работу рендомный период передачи от 200мс до трех секунд (у каждого свой и меняется при каждой передаче). Костыльно, но должно работать.

Да и опрос датчиков от мастера можно не делать. Парнишке делал домашний климат с шестью радиодатчиками на nRF24, период передачи от датчика к мастеру от 1 до 15 минут. Уже пару-тройку лет работает и ничего. Мастер ничего не спрашивает, датчики живут своей жизнью и кидаются в эфир посылками с запросом обратной связи от мастера (до 16 посылок). Если датчик не передал информацию в течении двух периодов, то мастер выдает аварию. Период передачи задается с мастера в сообщении обратной связи. Чтоб датчики каждый раз не прошивать, залез в мастера по модбасу и поменял, а датчик при следующем сеансе связи узнает новый период общения.

[CraCk]

Тут модбас проигрывает.

Согласен.

Опрос слейвов надо сделать с определенным периодом. Слейв знает, когда в следующий раз его опросит мастер

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

и если ему надо будет срочно передать информацию, а ждать опроса еще долго, то он ее передаст.

Этого как раз и не хватает в Модбасе.

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

Такой вариант будет самый надежный по доставке сообщения.

Да и опрос датчиков от мастера можно не делать.

Идеальный вариант чтобы не напрягать мастера опросами слейвов.

Нарыл еще интересные мысли как делать опрос датчиков в сборе с NRF24 для экономичного энергопотребления
http://blog.sci-smart.ru/2014/02/nrf24l01.html

Понравилась еще беспроводная система охраны. Конечно на Ардуино такой енергоефективности не добиться. Но хотя б чтоб работало боле мение надежно.

[Boroda]

Чем мне не нравятся nRF24L01+:

1. Много ног отбирает у МК.
2. Постоянно виснет. Даже с фильтрами по питанию, с батарейным питанием и т.д. без видимых на то причин. Без кондеров 100uF+0,1uF на ножках разъема вообще ловить нечего. Приходится инициализировать раз минуту.
3. Дальность связи. Приходится дремелем отрезать часть платы с антенной и припаивать 3см МГТФа.
4. Варианты с усилителем PA+LNA при активной передаче на максимальной мощности дохнут как мухи. Менял эти мощные на nRF905 - небо и земля по дальности и выживаемости.

Как дела обстоят с HC-12? Там ведь МК стоит с непонятной китайской прошивкой. Пробовали в него загнать кривую конфигурацию?

[CraCk]

Как дела обстоят с HC-12?

Дал ответ здесь с nRF24L01+ тоже намучился 5 штук валяется. После экспериментов они почему то перестали работать, для меня это был сплошной кошмар. Тем более только учусь электронике.
По запуску НС-12 проблем нет. Подключил и работает. Только из партии 3шт. один бракованный попался. Радиус действия модуля был 10см. Открыл спор китаец вернул деньги.

Пробовали в него загнать кривую конфигурацию?

Мне кажется что их невозможно убить кривой конфигурацией. Есть даже программка конфигуратор http://thebackshed.com/forum....fig.zip

Там ведь МК стоит с непонятной китайской прошивкой.

Да стоит STM. Прикиньте если б flprog поддерживал STM процессоры, тогда можно загонять вообще свои прошивки. И творить чудеса.

[golowa70]

Недостатки работы по ModBus1) Большая частота опроса слейвов. Если ее уменьшит до 10сек и больше, тогда получаем сильное опоздание реакции слейвов на команды управления

Можно период синхронизации не увеличивать, а программно включать/выключать опрос конкретного слэйва при помощи блока "'Активность слэйва ". То есть опрашивать слэйв исключительно по мере необходимости, хоть по таймеру раз в минуту, хоть по событию(нажатие кнопки и т.д.

Добавлено (21.02.2017, 09:58)
---------------------------------------------

2)При большой частоте опроса. Используя радио модули с мощностью 100мвт при одном мастере и 10 слевов будет получать нехилое облучение и глушение частоты 433мгц.

Настройте HC-12 на другой канал,например на 100 , это 473 MHz

Добавлено (21.02.2017, 10:08)
---------------------------------------------

3)При большой частоте опроса. Невозможно сделать систему энерго независимой.

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

Добавлено (21.02.2017, 10:17)
---------------------------------------------

4)Нет никакого шифрование данных.

Это не есть гуд, так как кто-то может перехватить данные о температуре в вашем сарае ))))))
А если серьезно есть необходимость в шифровании,тогда нужно смотреть в сторону всевозможных KeeLog и работать с SI4463 напрямую

Добавлено (21.02.2017, 10:22)
---------------------------------------------

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

Это всё есть в Модбас

Добавлено (21.02.2017, 10:34)
---------------------------------------------

5) Контроль доставки данных

Контроль целостности данных(CRC) заложен в модбас,а контроль доставки можно реализовать программно ,но нужно будет поковыряться.

Добавлено (21.02.2017, 11:16)
---------------------------------------------

6) Данные от клиентов, это срабатывание концевиков и отправка температуры.

Если слэйвы без исполнительных устройств ,так тогда можно использовать одностороннюю связь используя например библиотеку "VirtualWire" или Manchester

[CraCk]

программно включать/выключать опрос конкретного слэйва

Хорошая идея.

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

А как мастер будет знать когда слейв проснулся, для проведение опроса?

севозможных KeeLog и работать с SI4463 напрямую

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

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

Если слэйвы без исполнительных устройств ,так тогда можно использовать одностороннюю связь используя например библиотеку "VirtualWire" или Manchester

И в конечном результате получим новый протокол. Сам такое реализовать не могу. Буду надеется когда наши гуру программисты обзаведутся такими модулями может тогда что то придумают на С. А пока эта тема, будет просто так поболтать.

[golowa70]

А как мастер будет знать когда слейв проснулся, для проведение опроса

А он не будет знать, он будет попадать)))). Допустим слэйв просыпается раз в секунду на одну секунду, а мастер опрашивает например с периодом 250 миллисекунд, так вот при любом раскладе как минимум три раза мастер успеет опросить слэйв. Если нужна более быстрая реакция на события, тогда уменьшаем интервалы. Не идеально, но как вариант.

Добавлено (22.02.2017, 10:42)
---------------------------------------------
Мои полевые испытания HC-12 не увеньчались успехом, маловата дальность на скорости 19200. Теперь смотрю в сторону RFM23BP, это Si4432 с усилителем на 1Ват.

[Boroda]

мастер опрашивает например с периодом 250 миллисекунд

А потом Вас вычислят хозяева машин, стоящих на парковке у дома и придется Вам быстро убегать!

Добавлено (22.02.2017, 14:44)
---------------------------------------------
Сделаете частоту выше 433 - приедут к Вам дядечки и попросят пройти с ними. За 433 больше 10мВт тоже могут докопаться.

Добавлено (22.02.2017, 15:35)
---------------------------------------------

Мои полевые испытания HC-12

Как модуль определяет конец посылки?

Передаете строку "123456789", ждете 50мс и передаете строку "123". Что будет на другом конце канала связи?

Добавлено (22.02.2017, 15:59)
---------------------------------------------
Нашел:
FU1 - период пакетов 25мс, скорость RS любая, скорость RF 250кбод, 100м.
FU2 - период пакетов 500мс, скорость RS 1200-4800бод, скорость RF 250кбод, 100м.
FU3 - период пакетов 80мс, скорость RS любая, скорость RF 5..236кбод, 100..1000м.
FU4 - период пакетов 1000мс, скорость RS 1200бод, скорость RF 500бод, 1800м.
Период указан для одного байта в пакете.
Для вычисления периода передачи можно использовать формулу:

Период = (период для 1 байта) + (1000/Х)*(длина пакета), где Х - скорость в бод.

[CraCk]

а программно включать/выключать опрос конкретного слэйва при помощи блока "'Активность слэйва ".

Все таки при большой задержке опроса например 5мин. Слейв не сможет вовремя передать аварию.

А потом Вас вычислят хозяева машин, стоящих на парковке у дома и придется Вам быстро убегать!

Сделаете частоту выше 433 - приедут к Вам дядечки и попросят пройти с ними. За 433 больше 10мВт тоже могут докопаться.

Вот по этому стандартный модбас не катит.
Еще нашел сопряжение pjon + HC12 . Но я в этом дуб дубом.

[golowa70]

Сделаете частоту выше 433 - приедут к Вам дядечки и попросят пройти с ними. За 433 больше 10мВт тоже могут докопаться.

Волков бояться, в лес не ходить)))
А вообще для задач топикстартера беспроводной модбас не очень подходит.

Добавлено (25.02.2017, 00:23)
---------------------------------------------

Как модуль определяет конец посылки?

Передаете строку "123456789", ждете 50мс и передаете строку "123". Что будет на другом конце канала связи?

Спасибо за идею. У меня контроллер DeepSea с одной стороны и ноут с родной скадой с другой, соединенные по модбас через HC-12, когда начинается пропуск пакетов, значит связь на грани дальности.

[golowa70]

Нашел:
FU1 - период пакетов 25мс, скорость RS любая, скорость RF 250кбод, 100м.
FU2 - период пакетов 500мс, скорость RS 1200-4800бод, скорость RF 250кбод, 100м.
FU3 - период пакетов 80мс, скорость RS любая, скорость RF 5..236кбод, 100..1000м.
FU4 - период пакетов 1000мс, скорость RS 1200бод, скорость RF 500бод, 1800м.
Период указан для одного байта в пакете.
Для вычисления периода передачи можно использовать формулу:

Период = (период для 1 байта) + (1000/Х)*(длина пакета), где Х - скорость в бод.

Если Вы об этом

Добавлено (25.02.2017, 00:28)
---------------------------------------------
То это вестимо.
Мне ниже 2400 скорость не подходит

Добавлено (25.02.2017, 00:31)
---------------------------------------------

Все таки при большой задержке опроса например 5мин. Слейв не сможет вовремя передать аварию

Так вот и я говорю, беспроводной модбас не очень подходит для Вашей задачи.

Добавлено (25.02.2017, 00:34)
---------------------------------------------

Еще нашел сопряжение pjon + HC12 . Но я в этом дуб дубом.

Посмотрим.
А вообще если будут желающие тестировать, попробую сделать блоки под si4432 из библиотеки Rf22.

Добавлено (25.02.2017, 00:40)
---------------------------------------------

FU4 - период пакетов 1000мс, скорость RS 1200бод, скорость RF 500бод, 1800м.

Скорость RF в данном случае всегда будет больше, чтобы чип успевал обрабатывать буфер, потому как FIFO не безразмерный )))

Добавлено (25.02.2017, 00:54)
---------------------------------------------
Я бы для подобных целей использовал cc1101. Делал как то пару проектов на них, работают нормально.

[CraCk]

если будут желающие тестировать, попробую сделать блоки под si4432 из библиотеки Rf22

Где вы раньше были?     Я уже hc-12 накупил.

[golowa70]

Где вы раньше были?     Я уже hc-12 накупил.

Посмотрел на PJON, выглядит заманчиво, по свободе попробую. Если не пойдёт, есть ещё библиотека RadioHead, она тоже может с uart работать.

[golowa70]

Я уже hc-12 накупил.

Попробуйте эти блоки,отправка и прием четырех байт .По проводам  работает , а по воздуху пока нет возможности проверить.Скорость 9600, через софтовый уарт пины 10,11 .

[CraCk]

Попробуйте эти блоки,отправка и прием четырех байт

Попробовал. Передаю аналоговое значение из анал. входа.  Работает. Но есть проблема. Во время работы если ресетнуть приемник второй раз. После первого ресета соединение восстанавливается. Тогда невозможно восстановить связь. И выход fail на трансмитере не сигнализирует о том что нет ответа от приемника. Приходиться перезапускать трансмитер. Аж после этого уже приемник начинает что то принимать. Можно как то исправить?
В общем не плохо получилось. Очень мало занимает памяти и пинов МК. А какой Вы пример использовали для блоков. Есть что еще улучшать?

[golowa70]

Попробовал. Передаю аналоговое значение из анал. входа.  Работает. Но есть проблема. Во время работы если ресетнуть приемник второй раз. После первого ресета соединение восстанавливается. Тогда невозможно восстановить связь. И выход fail на трансмитере не сигнализирует о том что нет ответа от приемника. Приходиться перезапускать трансмитер. Аж после этого уже приемник начинает что то принимать. Можно как то исправить?
В общем не плохо получилось. Очень мало занимает памяти и пинов МК. А какой Вы пример использовали для блоков. Есть что еще улучшать?

Это при проводном соединении или по воздуху?
Какая частота отправки данных?

[golowa70]

Во время работы если ресетнуть приемник второй раз. После первого ресета соединение восстанавливается. Тогда невозможно восстановить связь. И выход fail на трансмитере не сигнализирует о том что нет ответа от приемника. Приходиться перезапускать трансмитер.

Добавлено (06.03.2017, 17:47)
---------------------------------------------
В примере при нажатии на кнопку пиикает пищалка на стороне передатчика сигнализируя подтверждение принятия пакета приёмником, и инвертируется светодиод на D13 со стороны приёмника.

[CraCk]

Это при проводном соединении или по воздуху? Какая частота отправки данных?

Модули НС-12. Пробовал 500мс 2000мс. При 2000мс не всегда теряется связь на втором отключение ресивера. Иногда на четвертом, иногда на шестом разе, уже может трансмитер переставать передавать данные.

[golowa70]

Пробовал 500мс 2000мс. При 2000мс не всегда теряется связь на втором отключение ресивера. Иногда на четвертом

Попробуйте с блоками из 18го сообщения. Они чуток переделанные.