MiklPolikov 0 27 августа, 2011 Опубликовано 27 августа, 2011 · Жалоба Нужно сделать систему из 20 передатчиков и 1 приёмника. Расстояние передачи 10м Передатчики должны передавать 2 байта раз в секунду. Остальное время молчать- потребление очень критично. Есть ли какие-то готовые решения ? Помимо Bluetooth ? Если бы был 1 передатчик использовал бы в нём rfPIC. В приёмнике бы включал RF-тракт только в моменты передачи, определял бы их таймером. А когда передатчиков много, надо как-то разрешать коллизии... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 27 августа, 2011 Опубликовано 27 августа, 2011 (изменено) · Жалоба Нужно сделать систему из 20 передатчиков и 1 приёмника. .... А когда передатчиков много, надо как-то разрешать коллизии... Я решал это опросом и рандомизацией ответа. Раз в секунду абонент включает приемник, увидев фрагмент опроса (опрос - непрерывный поток коротких пакетов, с указанием, сколько времени осталось до начала окна приема), вычисляет момент начала своего ответа (начало окна ответа плюс задержка до нужного тайм-слота) с помощью генератора случайных чисел и отправляет ответ. При 256 тайм-слотах неплохо разруливаются полтысячи абонентов (результат моделирования, столько живьем у меня нет), до двух тысяч - более-менее приемлемо (в реальных условиях, вероятно, еще лучше). Соответственно, для 20 абонентов 16 тайм-слотов хватит. Ну, соответственно, за один опрос кто-то не попадет, исключаем ответивших, и повторяем. Увеличивая число тайм-слотов, уменьшаем количество коллизий. Изменено 27 августа, 2011 пользователем rx3apf Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
alex_zhuravlyov 1 27 августа, 2011 Опубликовано 27 августа, 2011 · Жалоба возможно стоит посмотреть в сторону zigbee, например на модули от DIGI http://www.digi.com/technology/rf-articles/wireless-zigbee или от украинских разработчиков http://www.embee.ua/ Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 4 28 августа, 2011 Опубликовано 28 августа, 2011 · Жалоба zigbee и прочие методы синхронизации это, конечно, здорово, но с ними есть одна проблема - к 20 передатчикам потребуется ещё и 20 приёмников чтобы слушать эфир. А без них передатчики никакой информации не имеют и планировать моменты своей передачи никак не могут. Остаётся только делать передачу покороче да передавать почаще, но без фанатизма. Надежда только на статистику. Пока суммарный трафик не превышает 5-10% от пропускной способности канала коллизии случаются редко. Можете поискать информацию о системе ALOHA, и расчет пропускной способности для неё. Если не ошибаюсь, предел там порядка 1/2e, то есть около 18%. Для исключения случаев когда моменты передачи у двух устройств почти совпадают и это продолжается на протяжении нескольких периодов, пока из-за разности частот не набежит достаточное рассогласование, полезно период передачи делать не точно постоянным, а немного варьировать псевдослучайным образом. Количество коллизий в среднем не изменится, но они не будут группироваться, а будут более-менее равномерно раскиданы по времени. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
MiklPolikov 0 28 августа, 2011 Опубликовано 28 августа, 2011 · Жалоба zigbee и прочие методы синхронизации это, конечно, здорово, но с ними есть одна проблема - к 20 передатчикам потребуется ещё и 20 приёмников чтобы слушать эфир. А без них передатчики никакой информации не имеют и планировать моменты своей передачи никак не могут. Остаётся только делать передачу покороче да передавать почаще, но без фанатизма. Надежда только на статистику. Пока суммарный трафик не превышает 5-10% от пропускной способности канала коллизии случаются редко. Можете поискать информацию о системе ALOHA, и расчет пропускной способности для неё. Если не ошибаюсь, предел там порядка 1/2e, то есть около 18%. Для исключения случаев когда моменты передачи у двух устройств почти совпадают и это продолжается на протяжении нескольких периодов, пока из-за разности частот не набежит достаточное рассогласование, полезно период передачи делать не точно постоянным, а немного варьировать псевдослучайным образом. Количество коллизий в среднем не изменится, но они не будут группироваться, а будут более-менее равномерно раскиданы по времени. В эту строну и думаю. Если передатчиков 20, а окно передачи разбито на 1000 ячеек, то конкретный передатчик будет перекрыт любым другим с вероятностью 19/1000 = 0.019 . Перекрывание одного и того же передатчика в трёх окнах подряд - уже 0.019 х 0.019 х 0.019 = 0.0000068 То есть, 1 раз на 1/0.0000068 = 150000 окон передачи Ячейку передачи лучше выбирать не квазислучайно, а совсем случайно. Читая шум с ножки АЦП . А то , если во всех передатчиках алгоритм расчёта квазислучайного числа один и тот же, то какой вообще в нём смысл ? Будут точно так же появляться пары почти совпадающих передатчиков, "прыгающих" по ячейкам друг за другом. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
rx3apf 0 30 августа, 2011 Опубликовано 30 августа, 2011 · Жалоба Ячейку передачи лучше выбирать не квазислучайно, а совсем случайно. Читая шум с ножки АЦП . А то , если во всех передатчиках алгоритм расчёта квазислучайного числа один и тот же, то какой вообще в нём смысл ? Будут точно так же появляться пары почти совпадающих передатчиков, "прыгающих" по ячейкам друг за другом. Зависит от реализации ГСЧ и "затравки". Устройства разные, вероятно, есть серийник. Вот от него и плясать. А вот будет ли сигнал с АЦП истинно случайным - это еще вопрос... Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
Sirko 0 31 августа, 2011 Опубликовано 31 августа, 2011 · Жалоба Расстояние передачи 10м... ...потребление очень критично Складывается впечатление, что это своего рода небольшие маячки, которые включают для сбора данных какого-то события в течении определенного промежутка времени. Отсюда возникает мысль, что можно изначально предусмотреть некий вход для синхронизации при включении передатчика. Либо это будет просто "сброс", подаваемый на все устройства одновременно, либо каждый передатчик при включении подсоединить к приемнику-конфигуратору. Одним словом, если передатчики работают не слишком долго, то возможно получится выделить конкретному передатчику конкретный квант времени при включении. Стабильность более-менее нормального кварца позволит несколько дней поработать при таком количестве байт в секунду. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
SSerge 4 1 сентября, 2011 Опубликовано 1 сентября, 2011 · Жалоба А то , если во всех передатчиках алгоритм расчёта квазислучайного числа один и тот же, то какой вообще в нём смысл ? Будут точно так же появляться пары почти совпадающих передатчиков, "прыгающих" по ячейкам друг за другом. Мне представляется что это не проблема. Строго одновременное включение даже пары устройств маловероятно, но и в этом случае их времена достаточно быстро разойдутся за счёт несинхронности их генераторов. Впрочем, инициализировать ГСЧ каким-нибудь уникальным номером (если он есть) или случайным числом с того-же АЦП лишним не будет. Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
mempfis_ 0 1 сентября, 2011 Опубликовано 1 сентября, 2011 · Жалоба Нужно сделать систему из 20 передатчиков и 1 приёмника. Расстояние передачи 10м Передатчики должны передавать 2 байта раз в секунду. Остальное время молчать- потребление очень критично. Передатчики не могут работать на разных частотах? Может быть самое простое было-бы настроить передатчики на 20 частот а приёмник перестраивать и слушать эфир по 2 секунды (чтобы гарантировано засечь ответ)? Цитата Поделиться сообщением Ссылка на сообщение Поделиться на другие сайты Поделиться
