"Wi-Fi" на модулях NRF24L01

Собственно, от вайфая здесь только частота рабочая. Продолжая вялотекущие изыскания по удобному объединению датчиков и исполнительных устройств в пределах дома, после проводов добрался и до беспроводки.
Городить очередной адаптер для домашнего сервера не хотелось и возник вопрос — а может скрестить nrf24 и сеть проводную/беспроводную вполне стандартную? Т.е. ethernet.

Дальше был откопан тестовый полигон из PIC24FJ64GA002 + ENC28J60, взят TCP/IP стек от Lifelover, отдельное спасибо ему за труд.
С некоторыми модификациями и костылями прикручена эмуляция провода с использованием модулей nRF24L01.

Получена вот такая красота:
C:\WORK\STM32\ai_ethernet_nrf>ping 192.168.201.231

Обмен пакетами с 192.168.201.231 по с 32 байтами данных:
Ответ от 192.168.201.231: число байт=32 время=29мс TTL=64
Ответ от 192.168.201.231: число байт=32 время=13мс TTL=64
Ответ от 192.168.201.231: число байт=32 время=12мс TTL=64
Ответ от 192.168.201.231: число байт=32 время=12мс TTL=64

Статистика Ping для 192.168.201.231:
Пакетов: отправлено = 4, получено = 4, потеряно = 0
(0% потерь)
Приблизительное время приема-передачи в мс:
Минимальное = 12мсек, Максимальное = 29 мсек, Среднее = 16 мсек

Между проводом и беспроводным участком стоит шлюз, пакующий пакеты Ethernet в кусочки для nRF24L01 и в обратную сторону. Для проводного участка переход формально незаметен, беспроводной клиент тоже с точки зрения работы с сетью не знает, что он беспроводной (если сравнивать с тем же стеком, работающим через ECN28J60).

Клиенты собираются вообще с выбрасыванием куска, ответственного за работу с ENC28J60.
MAC адрес беру пятибайтовым, с прицелом на дальнейшую аппаратную фильтрацию пакетов самим радиомодулем, который имеет максимальный размер адреса как раз в 5 байт. Шестой определен, занулен.

Оптимизаций пока никаких нет, разве что шлюз жестко фильтрует широковещательные и прочие пакеты, которые адресом назначения никак не похоже на клиентские устройства, чтобы не засорять и так не резиновый эфир.
Никаких возможностей радиомодуля по фильтрации пакетов и повторной передаче при потерях тоже не задействовано, это все для версии 2.

Примеры из вышеупомянутого курса вполне работают через такой эрзац вайфай.

Ожидаемый вариант применений — датчики смогут сразу на сервер http запросами писать свое состояние, например.
Или управляться, соответственно, через web-интерфейс. Из очевидных на сейчас граблей — шифрования никакого еще нет, критичные вещи нельзя так открывать.

Сырой вариант кода в приложении. Проверялось на PIC24FJ64GA002, STM32VLDISCOVERY, собирается и для STM8S003(собственно, на них в основном и расчет для датчиков)

Дополнение
Схемы как таковой нет, это прототипная модель для изучения принципа. Для стенда на STM32 модуль nRF24L01 подключен к SPI1 контроллера (PA5, PA6, PA7). Для стенда на PIC24 — нрф висит на SPI2, ENC28J60 на SPI1. Ноги конкретные приводить вообще бессмысленно — у этого контроллера периферию можно назначить на любые удобные.
Рисунок ПП для PIC24 приложен(формат SL5.0).

На вопрос «зачем это нужно, tcp/ip в контроллерах и что с этим можно сделать» — есть ответы в курсе Lifelover, ссылку привел в заметке.

Лично для меня это развитие идей из проводной связи , поскольку провод все же не везде удобен, а поскольку в качестве основного ПО для управления используется Majordomo — посчитал вполне логичным опереться на стандартный tcp/ip, после некоторого времени, убитого на попытки изобрести свой велосипед. Конечная цель (в идеале) — распределенная сеть, где узлы смогут служить маршрутизаторами друг для друга (MESH сеть).

Фото в реальной жизни (вдруг кто не видел STM32VLDISCOVERY :) )

  • 0
  • 24 декабря 2013, 19:48
  • artko
  • 2
Файлы в топике: nrf24chan.zip, ETH.lay.zip

Комментарии (28)

RSS свернуть / развернуть
Я, конечно, понимаю, что «в коде всё есть»… Но, может быть, всё же стоит добавить схемку? Фотку? Чуть более развёрнутое описание? :)
0
+1
0
схема — любимый ваш МК, к выходам аппаратного SPI модуля подключаем радиоблок. Здесь есть разве что рисовать.
Описание — согласен, немного больше указал.
0
Нифига не понял про модули — вайфай, да не вайфай?

Для меня вайфай модули — это что-то типа XBee XB2B-WFST-001 с честным клиентским wi-fi (WEP/WPA/WPA2), адхоцем, даже wi-fi direct (это такая точка доступа для одного устройства типа телефона), с поддержкой TCP и UDP, как сервер и как клиент.
0
Да вроде ясно — беспроводные устройства работают по TCP/IP, но канальный уровеь(или физический? не помню уже) — это радиоканал на nrf.
И есть мост Ethernet<->radio.
0
Я догадывался, но вот прямо это не было сказано =)

Благо, TCP/IP пофиг над чем работать…
0
Не зря в названии wi-fi взят в кавычках :) Речь о реализации tcp/ip поверх в общем-то не рассчитанных на это радиомодулей.
0
>> шифрования никакого еще нет
Да и ладно, в Ethernet его тоже нет. В TCP даже CRC данных не считается и ничего(или считается всё-таки? опять забыл).
0
 В TCP даже CRC данных не считается и ничего(или считается всё-таки? опять забыл).

Забыли :), CRC считается.

Касательно топика — тяжело понять суть, без описания системы.

Есть в вопросы к автору поста.

О каких датчиках идет речь? Просто, если мы говорим, например, о метеостанции и банальном датчике влажности/температуры/… и т д., то использование HTTP для связи с датчиком — это, ИМХО, перебор. И шифровать такой канал связи — тоже перебор.

Хотя безусловно, наверное есть варианты, когда применение HTTP и шифрования будет оправданным. Вы бы немного описали систему, которую Вы разрабатываете.
+1
>>Забыли :), CRC считается.
Мой склероз мне не изменил...:)
Но там не CRC, а просто сумма или нет?
использование HTTP для связи с датчиком — это, ИМХО, перебор.
Ну, если есть возможности и усилий немно надо, то почему бы и нет?
И шифровать такой канал связи — тоже перебор.
Согласен: ну кому нужны эти данные кроме автора? Хотя тоже можно…
0
Но там не CRC, а просто сумма или нет?

Вы правы, я решил, что Вы говорите, что в TCP вообще нет проверки целостности пакета.
Если говорить четкими терминами, то там именно контрольная сумма а не CRC.
0
Ну на канальном уровне эзернета фреймы всё же подписываются с помощью CRC32 (поле FCS), хотя это и ниже тцп
0
Сейчас в планах — датчики движения, управление освещением светодиодным, датчики температуры, датчики наполнения емкости резерва воды в автономной системе, выключатели, датчик потребления энергии и т.п.
Да хотя бы панель показа времени — можно заставить самостоятельно синхронизировать время по NTP.

При реализации обычного tcp/ip если вдруг что-то из беспроводных устройств захочет странного — не потребуется переделывать программу шлюзования, как в текущем работающем варианте на проводах.

Для термодатчика http слишком — почему? У меня как платформа автоматизации используется majordomo. Показания датчиков и управление скриптами очень удобно выполнять http запросами.
(Понятное дело, веб-интерфейс у термодатчика совершеннно излишняя штука. А вот передача показаний периодическим UDP пакетом, например — вполне удобно мне кажется. Правда, в этом случае все равно потребуется какая-то программная дополнительная прослойка для ловли UDP)
Конечно, можно сделать шлюз, который короткие посылки от датчиков будет транслировать уже в запросы к БД, но было интересно — что выйдет из прямого доступа.
И насчет ненужности шифрования показаний температуры — не согласен. Предположим, что управление котлом зависит от показаний температуры снаружи дома и внутри. Если «подделать» показания этих датчиков, система управления, например или начнет греть дом, или наоборот — выключит отопление.
0
Для термодатчика http слишком — почему?

Слишком тяжеловесный протокол. Ели бы у Вас был чесный WiFi – возможно это бы имело смысл. А так – все рано нужен «центральный контроллер», который будет опрашивать датчики. Я бы между «центральным контроллером» и датчиками использовал бы более легковесный протокол (типа MODBUS). А вот доступ к центральному контроллеру сделал бы по TCP (можно и WEB морду прикрутить).

Это все сугубо ИМХО, как известно, на вкус и цвет фломастеры разные.

И насчет ненужности шифрования показаний температуры — не согласен. Предположим, что управление котлом зависит от показаний температуры снаружи дома и внутри. Если «подделать» показания этих датчиков, система управления, например или начнет греть дом, или наоборот — выключит отопление.

Тогда правильнее говорить не о шифровании а о аутнефикации и целостности. В чистом виде шифрование не решает этих проблем, но на основании симметричного шифрования действительно можно реализовать аутентификацию и контроль целостности. А если просто зашифровать только значение температуры – то это ничего не даст.
0
Если возможностей ультрадешевого STM8S003 хватает для его реализации — почему нет? (касательно тяжеловесности), особенно если в конкретном частном моем случае это может дать некоторую плюшку в виде прямой записи в БД, например.
Насчет шифрования только значения — понятное дело, надо все стадии проверять. Само значение абсолютно бессмысленно шифровать, согласен.
0
А так – все рано нужен «центральный контроллер», который будет опрашивать датчики.
Ну как я понимаю, здесь девайс на PIC24 — не контроллер, а просто точка доступа. А контроллер — ПК.
0
да, PIC24 (или любой другой с радио и проводным интерфейсом одновременно) просто транслятор. Кидает пакеты в разные стороны, сам ничего не делает.
0
Ну так Ethernet проводной, его не может просто так перехватить левый хрен с улицы и запнуть левый пакет. Все беспроводные коммуникации шифруются. Эту без шифрования может спасти разве что то, что это редкий зверь, которого никто не знает.
+1
которого никто не знает.
Или «Неуловимый Джо», которого поймать-то можно, но кому он нужен…
+1
Ну, сосед вполне может быть и заинтересован. Или вор. С старыми радиотелефонами, которые были почти без защиты, народ, бывало, попадал.
Если сеть управляет умным домом — мона не так уж слабо с ее помощью навредить. Так что криптография нужна, и криптография хорошая. Не RSA32. Если там только термометр (и он не используется для управления обогревом) тогда да, можно оставить без защиты.
0
RSA32
RSA как мн кажется далеко от МК… Или не так всё сложно
И ресурсоёмко?
AES/DES/TEA — гораздо лучше, имхо.
0
RSA несложно, но очень ресурсоемко. Тут есть статья про RSA на МК. С ключом 32 бита. Это при том, что сегодня для RSA 1024 бита считается не слишком надежно.
DES не особо стойкий, а производительностью не блещет. Вроде есть и более подходящие для МК алгоритмы.
Но сравнивать RSA и AES/DES/TES некорректно, RSA — асимметричное шифрование, и симметричные алгоритмы ему не замена.
0
RSA несложно, но очень ресурсоемко.
Намного больше AES/DES?
DES не особо стойкий,
Кто же его ломать будет? Зато AES/DES может быть реализован в МК аппаратно.
0
Намного. Немножко поискал по этой тематике — сложность (в плане количества расчетов) той же RSA32 на порядки превосходит AES128 например.
0
Спасибо, понятно.
0
а самопальный мост на нордике не редкий зверь?)
0
просто сами нордики нередкие звери, а пакеты сейчас просто бьются на части и отсылаются. Собрать из них подряд блок и увидеть там ethernet фрейм очень несложно. Как и закинуть свой в обратную сторону.
0
Даже этого редкого зверя без шифрования не планируется использовать. Пока, скорее всего, попробую ограничиться сравнительно «легким» AES128 с добавлением мусора в пакеты, чтобы разные были и контролем после расшифровки.
0
Только зарегистрированные и авторизованные пользователи могут оставлять комментарии.