fast rsponse time wireless network, выбор подходящей элементной базы Опции

[Electronics Engi...]

Нет, правильнее — это без "кажется". Можно на месте откалибровать под конкретные модули и ПО все задержки — даёте команду калибровки паре модулей, один начинает передавать сразу, второй выходит в эфир с задержкой, мастер фиксирует момент начала порчи данных, затем второй уходит из эфира, а мастер фиксирует момент возобновления приёма.

Действительно, только в реальных условиях можно определить минимально допустимые задержки.
На данной стадии разработки главное, чтобы это было реализуемо чисто теоретически, беря во
внимание основные временные параметры трансивера.
На практике нужно все равно будет оставлять небольшой временной резерв (5-10%).

Сейчас получается, что на одном канале можно опрашивать до 14 сенсоров, исходя из того, что
передается 3 байта адреса (минимально допустимо), 2 байта данных, 2 байта CRC.
По моим подсчетам получилось 73 бита. На скорости 2Mbps длительность пакета получается не более 40мкс.
Тут также бралось во внимание 2 задержки на переключение главного устройства с режима RX <-> TX (130мкс).

Если требуется большее количество датчиков, то, наверно, можно будет использовать несколько каналов
по 14 датчиков в каждом канале. Думаю, соседние каналы не будут влиять друг на друга.
Дальше информация с локальных главных контроллеров будет стекаться по проводам (например, используя USART
на скорости до 2Mbps ) в центральный контроллер (FPGA или ATXMEGA).

[_pv]

Сейчас получается, что на одном канале можно опрашивать до 14 сенсоров, исходя из того, что
передается 3 байта адреса (минимально допустимо), 2 байта данных, 2 байта CRC.
По моим подсчетам получилось 73 бита. На скорости 2Mbps длительность пакета получается не более 40мкс.
Тут также бралось во внимание 2 задержки на переключение главного устройства с режима RX <-> TX (130мкс).

crc можно сделать один байт (а то и вообще выкинуть, но лучше не надо), а из трех байтов адреса - два использовать под данные, если более 256 устройств не планируется. то есть поменять адрес и данные местами. раз под адрес всё равно минимум 3 байта выделено.
правда всё равно, хоть один байт в данных должен быть. но минимум всё таки 49 бит. в полтора раз меньше.

есть еще одна похабная идея:
как только датчики получили команду от мастера, часть из них переключается на другие частотные каналы и начинают сливать данные нескольким другим выделенным датчикам, когда придёт их время эти особые датчики передадут мастеру все собранные от соседей данные за раз, то есть адрес, crc и синхронизация будет передана только один раз а данные сразу от нескольких датчиков.
учитывая что полезных данных 16 бит, а неполезных - под 40бит, то должно заметно помочь.

[Electronics Engi...]

crc можно сделать один байт (а то и вообще выкинуть, но лучше не надо), а из трех байтов адреса - два использовать под данные, если более 256 устройств не планируется. то есть поменять адрес и данные местами. раз под адрес всё равно минимум 3 байта выделено.
правда всё равно, хоть один байт в данных должен быть. но минимум всё таки 49 бит. в полтора раз меньше.

есть еще одна похабная идея:
как только датчики получили команду от мастера, часть из них переключается на другие частотные каналы и начинают сливать данные нескольким другим выделенным датчикам, когда придёт их время эти особые датчики передадут мастеру все собранные от соседей данные за раз, то есть адрес, crc и синхронизация будет передана только один раз а данные сразу от нескольких датчиков.
учитывая что полезных данных 16 бит, а неполезных - под 40бит, то должно заметно помочь.

В моем случае одного байта для адреса достаточно. Было бы хорошо два оставшихся байта использовать для данных.
В детали данного трансивера (nRF24L01+) еще не вникал. Когда поверхностно просматривал его даташит,
у меня сложилось впечатление, что он адрес проверяет железно. И пакет принимается и записывается в FIFO, если совпал
адрес, т.е. все три байта. Может ошибаюсь.
Пока в детали вникать не стоит, т.к. реальная разработка может начаться только через пару месяцев.