Цитата:

Сообщение от kovigor

передавать данные по проводам питания

PLC модем - вполне реально. Но это потребует микропроцессора в каждом переферийном устройстве.

Добрый день. Есть идея. У каждого устройства есть уникальный адрес. По этому адресу каждое устройство считает задержку отправки данных. Мастер устройство передает сигнал запроса всем сразу, а подчиненные отвечают после задержки, пропорциональной собственному адресу. Мастер ждет данные, зная максимальную задержку. Как-то так...

Цитата:

Сообщение от witaly_k

Добрый день. Есть идея.

Идей не счесть.
"Не счесть алмазов в каменных пещерах.
Не счесть жемчужин в море полудённом."

Тогда такая идея: все датчики/регуляторы лезут в эфир абсолютно случайно, т.е. псевдослучайно. Завести генератор случайных чисел. При таком подходе головному устройству в принципе не нужно даже слать запросы. Только собирать данные и отсылать уже адресные команды на включение/отключение нагрева и т.п.

Вероятность коллизий будет незначительная, если случайность "качественная". Если же и запортятся где-то данные - для проверки этого есть CRC. Нужно только оценить точно время RX главного устройства с учётом прерывания от НС-12 и его обработки (опустошения буфера приема микроконтроллером). А дальше устроить корреляцию между случайными числами, полученными каким-либо способом, и моментом отправки для датчиков - чтобы не чаще минимального времени, нужного для приема данных головным устройством. Да просто перемножать число и константу.

И относительно ZigBee. Годах в 2012-13 использовали модули украинского производства http://embee.ua. Модемы на плату обходились совсем не дорого, если покупать прямо у производителя. Они их собирали на распространенных тогда чипах Ember, есть модули с UFL разъёмами. На чём собирают сейчас не знаю. Работали модули стабильно, у меня даже остались где-то, и отладочная плата, и ПО. Ребята тогда старались.

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

Эти задержки связаны с тем, что в ZigBee сети передается море сервисной информации, а влезть физически в стек протоколов производителей этих чипов невозможно. Я как-то считал и получалось, что на переданный байт полезной информации в сети всего из трёх точек выходило 8-10 байт "пустого трёпа" между роутером и конечными устройствами. Правда включая шифрование и специфические настройки.

Видимо, некоторые форумчане на уловили смысл моей идеи. Объясню подробнее. Например, скорость 115200, в посылке 10 байт, время передачи - 0,87 мс. Для удобства округлим до 1 мс, но если нужно, можно еще увеличить. Это будет базовая задержка. В программе каждого подчиненного устройства есть адрес 1, 2, 3,... и функция, которая после сброса считает свою задержку = адрес * 1 мс. При широковещательном запросе каждое подчиненное устройство отвечает данными с задержкой между запросом и началом ответа (той, которую посчитали). Если устройств 50 штук, то через 51 мс все устройства по очереди ответят мастеру. Затем возможно отправить очередной запрос. Или команду управления конкретному подчиненному устройству. Общее время обмена данными меньше на время отправки запроса каждому устройству, т.е. получается примерно в два раза быстрее. Случайностей (или псевдо случайностей) быть не может.

antonydublin, Коли перефийное устройсво имеет индивидуальный адрес, то зачем вся эта псевдослучайность. Целесообразней опрашивать их по адресу....

Цитата:

Сообщение от witaly_k

Видимо, некоторые форумчане на уловили смысл моей идеи.

Поверьте, witaly_k, Вашу идею поняли все, заглянувшие в эту ветку форума. Идея хорошая, имеет право на реализацию. Такой принцип можно назвать "на первый десятый рассчитайсь!". Принцип правильный на столько же, на сколько очевидный, разграничение по времени. Но нужна команда "К бою товсь!" (простите за аналогии).

Цитата:

Сообщение от witaly_k

Случайностей (или псевдо случайностей) быть не может.

Вот тут Вы излишне категоричны. Если у Вас есть триггер, провоцирующий конечные устройства на ответ, то случайности ни к чему, очевидно.

Но представьте, что головное устройство (концентратор), работает только на приём. Только RX. А конечные устройства только TX. И организовать очередь по времени возможности нет: на конечных устройствах нет ни часов RTC, ни механизмов синхронизации устройств между собой.

В такой ситуации передача устройствами данных случайным образом, (ну когда нет триггера и арбитра-времени), тоже имеет право на реализацию.

Собственно, эта идея не моя. Натолкнулся в какой-то англоязычной книге. Но это касалось проводных линий связи со множеством ведомых устройств, когда каждое может хаотично занять линию на определенное время и отвалиться. Там приводился математический аппарат для оценки коллизий и задержек при озвученных выше условиях. Это была книга из 1970х, начала цифровой эры.

Цитата:

Сообщение от lllll

antonydublin, Коли периферийное устройство имеет индивидуальный адрес, то зачем вся эта псевдослучайность.

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

Идею witaly_k топикстартер оценит, уверен. Озвученную мной идею можно положить в копилку. Наподобие рекомендаций протянуть провод, или использовать PLC модем в топике, который называется "Соединить несколько приборов по радиоканалу".

Оффтопим, господа lllll и kovigor :-).
А вообще, интересная тема.
Надеюсь, схемопай расскажет как вышел из ситуации. Я считаю, что нужно "добивать" то железо, которое есть в наличии и с которым знаком. В данном случае модули HC-12.

Да вот, kovigor прав на счет диапазона 433МГц. Загажен. Хотя бы 868МГц или 2,4ГГц. Правда 2,4ГГц тоже местами плотно забит. Но все зависит от того, где происходит обмен. Завод в городе или нет, что работает в цеху и т.д.

2.4GHz и для него готовую технологию (BT) я не случайно посоветовал. Как минимум, там уже решена проблема тех же коллизий и гораздо лучше обстоит дело в случае с зашумленностью благодаря частотным перескокам. Да, дороже, но зато сертифицировано, отработано, отлажено и разработано профессионалами, съевшими на этом деле не одну собаку. А эти модульки на 433 МГц для задачи ТС - явное баловство. А в случае с масштабированием такой сети будет вообще катастрофа.
Если уж так хочется 433 МГц и проект серьезный, я бы взял готовые радиомодемы, тот же Невод-5 ...

Заказал с али E43-433T13S
Тут в основном все как и в HC-12 , но есть возможность устанавливать адрес устройству