Временные параметры радиосети - Страница 4

worldmasters · 28.02.2018, 15:07

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

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

Ну да. Изначально делал так что проснулся плюнул данные дождался ответа и спать. если не получилось то спать на 2 сек. Если в течении 10 раз передать не получилось то заглохли до следующего события. Результаты обработки событий в буфер до 20 значений.

Я все боюсь что во время прослушивания эфира в течении окна будет расходоваться энергия. датчик nRF24L01+. в даташите указано 13ма в приеме но не сказано сколько просто в режиме прослушки без фактического приема.
если это именно то значение потребления то это плохо. 20 устройств. допустим для каждого устройства 30 мс окно. То гарантированный промежуток должен быть около секунды. Мне кажется это накладно тратить впустую столько энергии.

Хотя наверное по другому вообще хрен получится сделать.

AR_Favorit · 28.02.2018, 15:19

Сообщение от mike-y-k

AR_Favorit для заказчика такого просто расчеты по имеющимся вариантам реализации с их оценочной стоимостью в производстве. И варианты по источникам питания. Обычно на второй итерации обсуждения находится разумный компромисс.
Для особо упёртых в долгую жизнь батарейки можно предложить РИТЭГ

- вполне для таких задач можно в габариты пары 6F22 уложится с ресурсом больше 10 лет.

Так о чем и речь. Запрошен совет с формулировкой "потребления электроэнергии надо экстремально свести к минимуму" - вот отсюда и вопрос, что конкретно в данном случае означает минимум. Где-то среднее потребление в 200 uA уже хороший результат, а где-то и 5 uA слишком много. А вот зная, какой уровень потребления допустим, уже можно говорить о вариантах аппаратного обеспечения, организации связи и т.д.

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

mike-y-k · 28.02.2018, 16:53

Пока мы тут обсуждаем сферические датчики без расчетов их профиля активности так все расплывчато и будет.
Надо бы так:
В зоне 1 датчик с контролем температуры и влажности. Диапазон температур 10…35°, влажности 10…75%. Событием считается отклонение температуры на 3° и/или влажности на 5%. Холостая периодичность опроса 1 час. Вероятность наступления события не чаще 5 раз в сутки.
Итого бюджет потребления за сутки при максимальном варианте:
(5+24)*(время приёма*ток приёма + время передачи*ток передачи)+ток сна*(86400-(5+24)*(время приёмам+время передачи)).
Ток в mA, время в s.
И так для каждого места установки и датчика.
Тогда получится некоторая уже конкретика.
Дальше уже просто по известным решениям отбор параметров и вычисление под них возможности и стоимости реализации.

Если таки nRF24L01+, то там ведь ещё и мозги какие-то должны быть со своим потреблением. Это всего-то приёмник-передатчик.
Для такого решения вполне себе 250k скорости хватит и с меньшей мощностью передачи. Это даст до 10mA экономии потребления при несущественном росте времени обмена. А вот потребление в режиме ожидания приёма видимо нужно просто измерять на плате. Даже неплохо свой профиль потребления в реальных условиях сделать.

Например CC1310 - MCU и приёмник-передатчик (SubGHz) в одном чипе:
48MHz ARM Cortex M3 2.5mA (48MHz)
RX 5.4mA
TX +10dbm 13.4mA
Standby 700nA
Shutdown 175nA
Это уже все, кроме потребления датчиков и периферии.
Частота канала ниже и ниже расходы на обмен данными.
Стоит просто посмотреть, там ещё CC430 есть и другие варианты для выбора.
Практически все готовы работать от CR2032 долго и счастливо.

AR_Favorit · 28.02.2018, 21:06

nRF можно и LE-шку взять, с мозгами. Но это не самый лучший выбор на сегодня, наверное))

worldmasters · 01.03.2018, 09:26

хм. почитал про CCхххх. Выглядит как всегда заманчиво, пока не начнешь осваивать. Можно будет рассмотреть для следующих версий продукта.
Сейчас пока NRF + PIC24 потому что среда и МК хорошо знакомы и имеется неплохой опыт разработки. С АРМами пока только здороваемся. )))

Хотелось опять вернуться к алгоритму сети. В общем то определился что опрашивать устройства хороший вариант в данном случае. Так получается что можно всех на один канал посадить.
Остался момент регистрации в сети. Вот тут ничего в голову не идет кроме варианта когда через рандомные промежутки времени невключенный в сеть модуль рассылает запросы на подключение пока какой нибудь из главных модулей не разрешит ему подключение.
Но пугает что это все даст в эфире много бесполезного шума.
Можно конечно также по запросу с головного устройства отправлять ответы но опять же если будет много устройств то они будут шуметь и мешать друг другу.
Может есть какие нибудь толковые алгоритмы??
Спасибо.

mike-y-k · 01.03.2018, 10:44

worldmasters, подключение к сети отдельная процедура, решаемая или на уровне прошивки или отдельной процедурой подключения.
Кнопка/перемычка/состояние первого включения и команда ведущему сканировать на предмет новичков. Дальше никаких проблем с нормальным алгоритмом работы.
У ковбоев конечно есть свои проблемы, но вот с поддержкой разработки у них как-то лучше, чем у Nordic.
А для приведённого освоение по большей части адаптацией готового примера станет, как собственно и для большинства их изделий.

Для алгоритма обмена очень неплохо нарисовать временную диаграмму рабочего цикла с учётом всех состояний датчика - просыпание, засыпание, переход от RX к TX и обратно, RX, TX,…
Из неё будут точно понятны все временные характеристики и потребление.
Добавить туда временную нестабильность (по максимуму) для вычисления гарантированного окна сеанса одного датчика.
Продумать процедуру коррекции временной нестабильности для датчика.
Продумать процедуру пересинхронизации и изменению интервалов при добавлении датчиков.
Продумать процедуру холостого опроса и допустимого числа холостых опросов для датчика - типа 1 раз в час обязательно, остальное при наличии изменений.
Продумать процедуру калибровки и коррекции хода внутреннего таймера/часов для минимизации ошибки отсчёта времени.
Минимизация ошибок отсчёта времени сократит время пребывания датчиков в активном состоянии, что хорошо скажется на потреблении

.
Собственно все процессы сначала на бумаге с небольшими экспериментами для уточнения.

worldmasters · 07.03.2018, 15:30

Добрый день. Начал расчеты по времени.
Получаетс что головной модуль должен включатся каждые 25 мс. где в среднем 8мс передача запроса и оставшееся время ожидание ответа от датчика.
С каждым фреймом можно передавать текущее значение внутреннего таймера и время затраченное на отправку предыдущего пакета ну или рассчитывать среднее время отправки. Тогда достаточно будет удаленным устройствам поймать один запрос и по нему синхронизировать внутренний генератор часов.

Одна проблема возникла. Устройства и головной модуль работают от разных кварцев. головной модуль работает на частоте 12MHz а удаленные модули на частоте 16Mhz.
И получается что предделителями настроить на равные промежутки никак не получается.

Что можно придумать кроме замены кварца?

mike-y-k · 08.03.2018, 03:35

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

makakus · 08.03.2018, 20:25

Прочитал тему по диагонали, много времени нету. Я правильно понимаю, что датчики в сети реализованные на nRF24L01 периодически просыпаются, ожидая приёма от мастера? И ждут, ждут, потребляя ток... и это безобразие?
nRF24L01 тем и хороши, что в них реализована такая замечательная вещь, как АСК payload. Мой датчик не включается для приёма. (приёмник включен постоянно, там всё есть) Когда нужно, он отсылает свой пакет, получает подтверждение, внутри которого может быть инфа. Обрабатывая её, мой датчик инициализируется, устанавливает параметры в своих кишках и т.д. Всё очень быстро, в мануале прекрасно всё написано.
Почему нет?

worldmasters · 09.03.2018, 13:13

Сообщение от mike-y-k

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

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

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

Прочитал тему по диагонали, много времени нету. Я правильно понимаю, что датчики в сети реализованные на nRF24L01 периодически просыпаются, ожидая приёма от мастера? И ждут, ждут, потребляя ток... и это безобразие? ?

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

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

nRF24L01 тем и хороши, что в них реализована такая замечательная вещь, как АСК payload. Мой датчик не включается для приёма. (приёмник включен постоянно, там всё есть) Когда нужно, он отсылает свой пакет, получает подтверждение, внутри которого может быть инфа. Обрабатывая её, мой датчик инициализируется, устанавливает параметры в своих кишках и т.д. Всё очень быстро, в мануале прекрасно всё написано.
Почему нет?

Знаю про ACK Pay .. не знаю насколько хороша она в данном случае.
Хорошо головной датчик включаем постоянно только на прием. Постоянно обновляя ACK Pay.
Случилась ситуация когда все 10 датчиков проснулись и хотят передавать данные .. Что дальше?? Будут долбиться на один канал?
Вариант с пайпами я тоже оставил потому что все равно придется переключаться между частотами и пока мы слушаем одну частоту другие шесть датчиков долбятся и тратят энергию?
Это не безобразие?