|
Сеть радиодатчиков, collision и SimpiciTI |
|
|
|
Nov 22 2015, 18:49
|
Местный
  
Группа: Свой
Сообщений: 340
Регистрация: 17-10-14
Пользователь №: 83 207

|
Нужно реализовать систему, которая будет собирать данные с датчиков температуры. Самая простая топология - звезда. Мастер - постоянно запитан. Слейвы (до 100 шт.) имеют батарейное питание и включаются на короткое время раз в 5-10 мин для передачи текущей температуры мастеру.
Собираюсь использовать CC1101 и протокол SimpliciTI, у него есть даже ретрансляторы, но они не нужны.
Но возникает одна проблема. Как избежать одновременной работы нескольких слейвов. Ведь при одновременной работе вместо пакета от одного слейва мастер получит кашу/мешанину и скорее всего не примет пакет вообще или отбросит его из-за несоответствия CRC.
И как я понял, в SimpliciTI эта проблема (коллизии) никак не решается.
Пока видится несколько вариантов решения, но ни один из них не вдохновляет.
1. В том же СС1101 есть технология под названием Clear Channel Assessment (CCA). Т.е. слейв перед отправкой может проверить, не занят ли канал другим слейвом. Но в этом случае при большом количестве слейвов некоторые могут очень долго ожидать свободного канала. К тому же во время ожидания будет использоваться батарейка. А слейв должен работать минимально возможное время, в отстальное время - сон.
2. Разделение по времени отправки пакета каждым слейвом. Непонятно как синхронизировать время. Даже если на каждом слейве есть RTC и время одинаковое, непонятно в какой момент слейв должен выполнять отправку.
Если у кого есть опыт реализации подобного, буду очень благодарен если поделитесь опытом/протоколом.
|
|
|
|
|
Nov 23 2015, 04:31
|
Гуру
     
Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713

|
Раз мастер имеет неограниченное питание, пусть управляет всем обменом - распределяет тайм-слоты в эфире. Выбираете некоторый период опроса, разбиваете его на тайм-слоты количеством равным максимальному кол-ву слэйвов. В начале каждого слота мастер пусть передаёт короткую посылку, содержащую номер слота и его длительность и общее кол-во слотов и после этого переходит на приём до конца слота. Каждый слэйв имеет свой уникальный номер. Когда у него есть данные на передачу, он слушает эфир, ловит ближайшую метку - начало слота, определяет по ней сколько осталось времени до слота с номером, равным его уникальному номеру и засыпает на время чуть меньшее, чтобы проснуться перед началом своего слота. Для такого алгоритма не нужен никакой беспроводной протокол, достаточно простого приёмо-передатчика типа nRF24L01.
|
|
|
|
|
Nov 23 2015, 07:37
|
Местный
  
Группа: Свой
Сообщений: 340
Регистрация: 17-10-14
Пользователь №: 83 207

|
Цитата(jcxz @ Nov 23 2015, 08:31)  Раз мастер имеет неограниченное питание, пусть управляет всем обменом - распределяет тайм-слоты в эфире. Выбираете некоторый период опроса, разбиваете его на тайм-слоты количеством равным максимальному кол-ву слэйвов. В начале каждого слота мастер пусть передаёт короткую посылку, содержащую номер слота и его длительность и общее кол-во слотов и после этого переходит на приём до конца слота. Каждый слэйв имеет свой уникальный номер. Когда у него есть данные на передачу, он слушает эфир, ловит ближайшую метку - начало слота, определяет по ней сколько осталось времени до слота с номером, равным его уникальному номеру и засыпает на время чуть меньшее, чтобы проснуться перед началом своего слота. Для такого алгоритма не нужен никакой беспроводной протокол, достаточно простого приёмо-передатчика типа nRF24L01. Похоже на рабочий сценарий. А по этому сценарию просыпаться слейву надо всегда два раза? Один раз для ловли метки, второй раз - для собственно передачи пакета во время своей метки?
|
|
|
|
|
Nov 24 2015, 11:22
|
Местный
  
Группа: Свой
Сообщений: 340
Регистрация: 17-10-14
Пользователь №: 83 207

|
Цитата(jcxz @ Nov 23 2015, 18:17)  Не обязательно. Так как после первой передачи слэйв уже знает размер слота и кол-во слотов, он может сразу рассчитать следующую точку просыпания. И, если у Вас в системе в процессе работы не меняются эти параметры, просыпаться будет уже только один раз на передачу. Ну или просыпаться через каждые N отправок для синхронизации меток (времени).
|
|
|
|
|
Jan 5 2016, 04:02
|
Участник

Группа: Участник
Сообщений: 22
Регистрация: 16-11-09
Из: Омск
Пользователь №: 53 657

|
Цитата(jcxz @ Nov 23 2015, 07:31)  Раз мастер имеет неограниченное питание, пусть управляет всем обменом - распределяет тайм-слоты в эфире. Выбираете некоторый период опроса, разбиваете его на тайм-слоты количеством равным максимальному кол-ву слэйвов. В начале каждого слота мастер пусть передаёт короткую посылку, содержащую номер слота и его длительность и общее кол-во слотов и после этого переходит на приём до конца слота. Каждый слэйв имеет свой уникальный номер. Когда у него есть данные на передачу, он слушает эфир, ловит ближайшую метку - начало слота, определяет по ней сколько осталось времени до слота с номером, равным его уникальному номеру и засыпает на время чуть меньшее, чтобы проснуться перед началом своего слота. Для такого алгоритма не нужен никакой беспроводной протокол, достаточно простого приёмо-передатчика типа nRF24L01. Здравствуйте. Аналогичная задача – мастер с неограниченным питанием и слэйвы на аккумуляторах, всё на CC1101. Интуитивно пришёл к такому же алгоритму, какой предложили вы. Но в чём необходимость обмена по тайм-слотам? Возможен ли такой вариант (какие подводные камни): 1 Все слэйвы спят. 2 Включается мастер и рассылает широковещательный запрос. 3. Все слэйвы просыпаются по радио-запросу. Насколько я понял из доков на СС1101, у него есть соответствующий режим WOR (Wake-On-Radio). 4. Мастер по очереди оправляет пакеты по всем возможным радио-адресам, либо по тем которые у него есть в базе слэйвов, после каждого пакета ожидая ответа с данными. 5. Ну и на этом как бы всё, все спят дальше. P.S. Может кто в курсе, при приёме пакета на CC1101, я получаю адрес того кто его отправил (на уровне драйвера)? В исходниках не нахожу соответствующего регистра.
|
|
|
|
|
Jan 5 2016, 08:41
|
Участник

Группа: Участник
Сообщений: 22
Регистрация: 16-11-09
Из: Омск
Пользователь №: 53 657

|
Цитата(jcxz @ Jan 5 2016, 12:12)  1. Не знаю как там сделано в конкретном чипе, но чтобы он что-то принял, у него должен быть включен приёмник, а приёмник кушает много (имхо - на порядки больше просто спящего МК с выкл. радио-частью) и если передача из центра может произойти в любой момент, то значит приёмник должен быть включен всегда. И никакого малого потребления в этом случае не получите. 2. Если у Вас по каждому кадру от центра будут просыпаться все слэйвы, опять крайне не эффективно - захотел центр пообщаться плотно с одним узлом (какой-нить большой журнал считать с него) - и в результате в течение всего обмена все слэйвы в сети спать не будут. 1. Думаю так и есть. Но именно чтобы "что-то принял", а чтобы просто проснулся похоже достаточно запроса из эфира. А принять можно и при следующем запросе, через интервал, необходимый для полного пробуждения. Вот дока от TI по этой фитче CC1101 http://www.ti.com/lit/an/swra126b/swra126b.pdf. Планирую так будить RF, а он уже через GPIO Разбудит МК. 2. В моём случае не критично, т.к. к этим слэйвам мастер будет приезжать очень редко, раз в неск. недель. Фактически это летаргический сон.
Сообщение отредактировал Yogen - Jan 5 2016, 08:43
|
|
|
|
|
Jan 5 2016, 09:00
|
Участник

Группа: Участник
Сообщений: 22
Регистрация: 16-11-09
Из: Омск
Пользователь №: 53 657

|
Цитата(jcxz @ Jan 5 2016, 11:50)  Как определить "запрос" это или просто помеха прилетела из эфира? Без включённого приёмника, имхо - никак. А если рядом у Вас что-то работает в том-же диапазоне? Вафля например. Всё время просыпаться от неё будете.
Надеюсь, просыпается по осмысленным сигналам в эфире, например по преамбуле пакета, нужно вчитаться в доку. Но предложенный вами вариант с тайм-слотами , если я правильно понял вообще, подразумевает постоянную прослушку эфира или периодическое пробуждение по таймеру на МК?! Лучше уж случайно/иногда от помехи, чем постоянно или периодически.
|
|
|
|
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0
|
|
|