Ничего нового не изобрели)) В старых сотовых телефонах приёмник работал так же. У них даже зелёный светодиод мигал каждую секунду (полторы) - это включался приёмник и опять уходил в сон.
Так же работали и домашние радиотелефоны... Panasonic... DECT... и даже рации так работали)) Короче ничего нового.
С таким же успехом можно подключить nRF24L01 , которая будет просыпаться каждые несколько миллисекунд отправлять пакет мастеру и опять уходить в сон. nRF24L01 даже круче будет)) я подавал пинание на nRF24L01 с любого пина МК. У меня nRF24L01 не просто уходила в сон а вообще отключалось питание nRF24L01. При этом потребляемый ток nRF24L01 был 0 микроампер ! ))
мастер может посылать пакеты в CC1101 раз в час, и все это время датчик будет потреблять 35 мкА, включая микроконтроллер в нем, который тоже будет спать глубоко-глубоко. а NRF сама по себе ничего отправить не может, поэтому впридачу к ее 14 мА каждые несколько миллисекунд надо прибавть еще минимум 5 мА потребления МК.
при этом если двум датчикам приспичит одновременно что-то послать, мастер на оба плюнет, чего в случае с CC1101 быть не может по определению... а так все хорошо, прекрасная маркиза. особенно когда сеть состоит из 3 узлов, включая мастера, а не из 30 или, тем паче, из 300.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
у меня вот собранный ещё в середине осени девайс на nRF24L01+ (всё время включенный, но большую часть времени - в PowerDown, только иногда выходящий на передачу) до сих пор работает от той же самой пары AA полудохлых.
Это вообще ни о чём... Всё зависит от отношения времени - радио модуль активный/не активный. Цифры в студию ! ))
Добавлено after 26 minutes 13 seconds:
ARV писал(а):
мастер может посылать пакеты в CC1101 раз в час, и все это время датчик будет потреблять 35 мкА
35 мкА потребляет НЕПРЕРЫВНО - это дофига !!!))
ARV писал(а):
NRF сама по себе ничего отправить не может
А ей и не надо. За неё все сделает МК.
ARV писал(а):
поэтому впридачу к ее 14 мА каждые несколько миллисекунд надо прибавть еще минимум 5 мА потребления МК.
Ничего подобного ! )) У меня nRF24L01 не просто уходила в сон а вообще отключалось питание nRF24L01. При этом потребляемый ток nRF24L01 был 0 микроампер ! )) Остаётся только один МК. А потребляемый ток МК в режиме глубокого сна - 3...5 мкА. Хотя и ток МК можно уменьшить... Добавить пару транзисторов в схему для внешнего таймера - мультивибратора))
ARV писал(а):
при этом если двум датчикам приспичит одновременно что-то послать, мастер на оба плюнет, чего в случае с CC1101 быть не может по определению... а так все хорошо, прекрасная маркиза. особенно когда сеть состоит из 3 узлов, включая мастера, а не из 30 или, тем паче, из 300.
Ну и что. Вероятность коллизии при отправки пакета раз в час - крайне низкая. Для борьбы с коллизиями есть ACK. Ничего страшного не случится, если с первого раза пакет не дойдёт и МК повторит передачу. Просто увеличится потребляемый ток в два раза (т.к. время передачи пакета с повтором увеличится в два раза). Но, повторяю, при передачи пакетов один раз в час вероятность коллизии крайне мала. Сейчас даже почитаем сколько точно))
если вам нужна экономичность, то надо искать приёмопередатчики, которые в режиме приема потребляют микроамперы, а не извращаться с тем, что жрет, как не в себя.
ваша идея все равно нежизнеспособна, т.к. при некотором количестве слейвов мастер все равно будет все пакеты сбрасывать, поскольку из-за коллизий не сможет разобраться в них.
в том же эзернете вполне нормально обработка коллизий например реализована. сотня хостов, разнесенных на расстояние до 500 метров, вполне себе уживается при активном обмене (до 10 мбит/с).
или вот вариант: CC1101https://amperkot.ru/products/radiomodul ... 48604.html - этот модуль может сам просыпаться по наличию радиосигнала, скорость поменьше, но экономичность побольше, а для передачи данных датчика скорость не так важна. в спячке вроде как 0,5 мкА потребляет
нет, не может сам просыпаться:
Цитата:
The optional Wake on Radio (WOR) functionality enables CC1101 to periodically wake up from SLEEP and listen for incoming packets without MCU interaction.
при этом:
Цитата:
Low current consumption (14.7 mA in RX, 1.2 kBaud, 868 MHz)
проснуться процом, дернуть модуль, послушать и уснуть - какбы небольшая проблема, проц в экономичном режиме кушает на порядок меньше радиомодуля.
само собой лошадиный. но речь о том, что логика "мастер командует, слейвы все время слушают и исполняют" даже с таким лошадиным током не реализуема. ultra low power - они либо десятки мА кушают, либо - сугубо приемники со смешными -50..-60dBm по входу...
а слать мастером постоянно, в надежде что слейв таки именно в этот момент проснется, услышит и ответит - так себе идея.
Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ очень важен контроль процесса заряда и разряда для избегания воздействия внешнего зарядного напряжения после достижения 100% заряда. Инженеры КОМПЭЛ подготовили список таких решений от разных производителей.
Для начала ещё раз внимательно все прочитали даташит CC1101. В двух словах: CC1101 в режиме WOR: -работает только RC-генератор (кварцевый генератор и встроенный процессор - отключены). -RC-генератор через каждые несколько миллисекунд включает блок приёмника (кварцевый генератор и встроенный процессор - по прежнему отключены). -если блок приёмника обнаруживает сигнал то включаются кварцевый генератор и встроенный процессор. CC1101 переходит в режим приёма и обработки пакета. -в режим приёма и обработки пакета потребляемый ток 14 mA. -в режиме WOR, когда работает только RC-генератор, который каждые несколько миллисекунд кратковременно включает блок приёмника - потребляемый ток 35 микроампер. Думаю разобрались))
NiTr0 писал(а):
в том же эзернете вполне нормально обработка коллизий например реализована. сотня хостов, разнесенных на расстояние до 500 метров, вполне себе уживается при активном обмене (до 10 мбит/с).
Коллизии были только в старом изернет 10 мбит/с , который работал по коаксиальному кабелю в режиме симплекс. Топология - общая шина. В новом изернете 10 мбит/с и 100 мбит/с коллизий нет от слова совсем)) Новый изернет 10 мбит/с и 100 мбит/с работает работает в режиме дуплекс. Топология - звезда. С изернетом разобрались))
Коллизии есть в старом Wi-Fi. Там все дружно слушают одну частоту и пытаются передать кому как вздумается. Без общей синхронизации. В новом Wi-Fi 6 (теперь он так называется) коллизии... свели к минимуму. Тем все устройства синхронизированы (только те что поддерживают Wi-Fi 6). Теперь там другие коллизии... Например когда одно устройство Wi-Fi 6 не видет другое устройство Wi-Fi 6 и пытается передавать пакеты... Но это уже другая тема)) С Wi-Fi разобрались))
Теперь считаем потребляемый ток NRF. -время передачи пакета NRF ~1,2 мс. (при скорости 250 кБит/c один бит - 4 мкс) (преамбула 8 бит + адрес 40 бит + Data 256 бит + CRC 16 бит = 1,2 мc) (+ PLL 0,13 мс + SPI МК + обработка пакета = 1,5 мс) NRF: TX = 1,5 мс, RX = 1,5 мс Итого: 3 мс
Если передавать пакеты каждую минуту: 1 минута = 60 секунд. Отношение активный/не активный = 60 / 0,003 = 20.000 Потребляемый ток NRF (1 пакет каждую минуту) = 12 mA / 20.000 = 0,0006 mA. (Или 0,6 микроампер).
Вывод: при передачи пакетов каждую минуту общий потреблямый ток NRF составляет 0,6 микроампер !!! ))
Обратите внимание NRF отправляет пакет мастеру TX = 1,5 мс и получает от мастера подтверждение доставки пакета RX = 1,5 мс. Гарантированная доставка пакетов с общим током потребления NRF = 0,6 микроампер !!! )) Круто)) А если отправлять пакеты один раз в час ?
0,6 микроампер / 60 минут = 0,01 микроампер !!! ))
Дальше посчитайте сами))
На сколько нам хватит батарейки ? Батарейка Duracell 2 шт ёмкостью грубо 500 mA/час. 500 mA/час / (1 пакет каждую минуту) 0,0006 mA = 833.333 часов работы. или 34.722 дня работы. или 95 лет работы.))
Скорее батарейка просто сдохнет от старости))
Вероятность коллизии. Какова вероятность коллизии при передачи одного пакета каждую минуту (отношение активный/не активный = 1/20.000) ? Если в схеме два датчика, то вероятность того что они нажнут передавать одновременно = 1/20.000. Нормально. Если в схеме 1000 датчиков, то вероятность того что они нажнут передавать одновременно = 1/20. Нормально. Вообще то вероятность считается не так... Там всё через графики и коэффициенты... Ну да ладно)) Реально в схеме не будет 1000 датчиков. Максимум ~20 штук. )) Поэтому предлагаю вообще забить на коллизии)) Достаточно простого ACK для гарантированной доставки пакетов.
На самом деле всё зависит от трафика. Если устройств мало (<1000) и время передачи один раз в минуту - то коллизии пофигу)) Важно ещё добавить во все устройства генератор случайных чисел. Чтобы все устройства передавали пакеты через случайное время. Чтоб не было "зацикливания коллизий" Точно так же как сделано в старом Wi-Fi или старом изернет. Тогда всё будет хорошо))
Компания EVE выпустила новый аккумулятор серии PLM, сочетающий в себе высокую безопасность, длительный срок службы, широкий температурный диапазон и высокую токоотдачу даже при отрицательной температуре.
Эти аккумуляторы поддерживают заряд при температуре от -40/-20°С (сниженным значением тока), безопасны (не воспламеняются и не взрываются) при механическом повреждении (протыкание и сдавливание), устойчивы к вибрации. Они могут применяться как для автотранспорта (трекеры, маячки, сигнализация), так и для промышленных устройств мониторинга, IoT-устройств.
патаму шо у нас схема с ультра низким потреблением. ))) питание на МК поступает от внешнего генератора импульсов (на полевых транзисторах). в нормальном состоянии питание на МК и NRF отсутствует.
то питание МК включается каждую минуту (мультивибратор на полевых транзисторах): датчик протечки передаёт мастеру: -протечки нет... -протечки нет... -протечки нет...
ARV писал(а):
есть третий участник процесса?
есть - вода)) при попадании воды питание МК включает постоянно (питание МК через полевой транзистор): -протечка !... -протечка !... -протечка !...
Аналогично с датчиком сигнализации на дверь... и с датчиком температуры за окном... и т.д. и т.п.
Таким образом МК и NRF потребляют ток только при передачи пакета "всё нормально" или при срабатывании датчика. В остальное время питание на МК и NRF отсутствует.
В новом изернете 10 мбит/с и 100 мбит/с коллизий нет от слова совсем)) Новый изернет 10 мбит/с и 100 мбит/с работает работает в режиме дуплекс. Топология - звезда.
вообще-то на ура могут работать и в полудуплексе на 100 мбит, более того - были и 100мбит хабы, с коллизиями, да... впрочем - это скорее имеет археологический интерес.
Поэтому предлагаю вообще забить на коллизии)) Достаточно простого ACK для гарантированной доставки пакетов.
проще уж как в эзернете - если не получен аск, засыпать на рандомное время и повторять отправку.
хотя мне больше идея TDMA сейчас нравится, пускай и по потреблению больше будет - зато универсальнее (можно что-то типа домофона даже прикручивать в ту же сеть). мастер шлет синхрофреймы с таймслотами для каждого девайса (если от девайса данных не требуется - таймслот нулевой длины), + специальный таймслот на регистрацию новых девайсов, в котором девайсы уже дружат друг с другом по принципу эзернета (рандомом задержка в пределах таймслота). слейв - просыпается и слушает что происходит, если его упомянули - все ок, не упомянули - на третий фрейм идентификации заявляет о себе. упомянули и потребовали отчитаться (с уникальным ид команды) - передает результат исполнения команды.
1 - мастер должен непрерывно передавать синхропакеты... тррррр)) 2 - слейвы должны постоянно просыпаться и слушать мастера... 3 - большая задержка передачи данных...
как ? передача звука через NRF ? Можно... Только звук займёт весь канал связи... Если без кодеков))
а кто сказал - без кодеков? тот же adpcm элементарно реализуется даже на раритетах типа 8051 и атмелов, про более свежие камни - молчу, те вполне и какой-нить GSM-FR пережуют...
2 - слейвы должны постоянно просыпаться и слушать мастера...
зачем - постоянно? раз в минуту например. когда данные с датчиков актуализируют. и даже мастер может командовать слейву, когда примерно ему просыпаться.
До самодельный кодеков я ещё не дошёл)) Передаю обычный PCM в RAW формате.
Не нравится мне когда мастер строчит пустые пакеты в эфир как из пулемёта))
Повторяю... всё зависит от трафика. Если будет видеокамера которая будет занимать весь канал связи то общая синхронизация нужна. Иначе слейвы не смогут связаться с мастером. А если трафик маленький (один пакет в минуты) то нафиг эта синхронизация вообще нужна))
У меня на первом месте задержки. Мне надо чтоб нажал на кнопочку - и тут же включилась лампочка. Задержка пару миллисекунд допустима. )) Или сработал датчик - мастер узнал об этом через пару миллисекунд. При таких условиях общая синхронизация только мешает.
До самодельный кодеков я ещё не дошёл)) Передаю обычный PCM в RAW формате.
дык есть готовые библиотеки. ну а ADPCM - он и на коленке пилится по спецификации, никаких высших материй там нет. 8051 хватает чтобы с I2C флэшки играть ADPCM на 16КГц что ли...
Если будет видеокамера которая будет занимать весь канал связи то общая синхронизация нужна. Иначе слейвы не смогут связаться с мастером. А если трафик маленький (один пакет в минуты) то нафиг эта синхронизация вообще нужна))
ну я пока что не вполне представляю что там будет жить. точно будет кучка датчиков (типа метеостанции, комнатных и не только комнатных термометров, датчика уровня воды в колодце и т.п.), скорее всего кнопка звонка, а вот что еще захочется потом - пока не знаю.
У меня на первом месте задержки. Мне надо чтоб нажал на кнопочку - и тут же включилась лампочка. Задержка пару миллисекунд допустима. )) Или сработал датчик - мастер узнал об этом через пару миллисекунд. При таких условиях общая синхронизация только мешает.
Надо чтоб слейвы инициировали соединение и передачу
вы даже не видите противоречия в том, что пишите: слейв потому и называется так, что сам ничего не может инициировать! в сети с топологией "мастер-слейв" слейвы - полностью пассивные узлы. то, о чем вы постоянно говорите, не является такой сетью по определению! не знаю, как оно правильно, но это одноранговая сеть, все узлы которой равноценны по возможностям начинать передачу.
_________________ если рассматривать человека снизу, покажется, что мозг у него глубоко в жопе при взгляде на многих сверху ничего не меняется...
Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 20
Вы не можете начинать темы Вы не можете отвечать на сообщения Вы не можете редактировать свои сообщения Вы не можете удалять свои сообщения Вы не можете добавлять вложения