NRF24L01, NRF24L01+

[roman.com]

У меня в каждом из модулей GPS-Glonass модули стоят, которые дают эталонное время. Поэтому временные задержки на передачу каналов тут можно и не учитывать.

ну тогда воообще нет проблем)) берите любые модули.

как насчет однонаправленности связи?

какой однонаправленности? nrf24L01+ это трансиверы.

увы похоже не подойдут....

почему? зависит от дальности. Простые модули без усилителя работают максимум ~400 метров (при условии точной направленности).

без усилителя.jpg

(141.5 KiB) Скачиваний: 813

Модули с усилителем работают более 1000 метров. (без точной направленности).

с усилителем.jpg

(13.19 KiB) Скачиваний: 692

[arkhnchul]

хочу сочинить из nrf-ок сеть а-ля шина с мастером и кучей слейвов, конкретно - для подцепления разномастных датчиков по modbus-у. С самим модбасом более-менее разгребся, теперь рисую архитектуру беспроводной части.
В общих чертах:
не хочу сильно заморачиваться с самостоятельным контролем передачи на физическом уровне, и предполагаю использовать ShockBurst. Шести адресов на канал мало, плюс у каждого устройства будет еще и modbus-адрес. Тако же modbus ADU в общем случае не влезет в максимальные 32 байта payload-а, которые допускает ShockBurst, и его придется крошить. Пока вырисовывается такая схема передачи одного ADU:
-1) мастер PTX, слейвы PRX
0) мастер получает от клиента ADU по rs485
1) все слейвы слушают один и тот же RX_ADDR, на всех отключен Auto ACK.
2) мастер посылает в эфир пакет c payload-ом вида "modbus-адрес abc прими n байт ADU"
3) все слейвы получают пакет, проверяют адрес. Слейв с совпадающим адресом включает Auto ACK (или нет, если нужного адреса нет в сети вообще или он висит на проводе rs485).
4) мастер, не получив ACK, передает пакет еще раз. На этот раз получает его от слейва с совпадающим modbus-адресом (или нет, тогда через несколько повторов процедура заканчивается).
5) мастер передает покромсанный на куски ADU, слейвы его принимают и собирают.
6) мастер передает "тчк". Получает на него ACK, переключается в режим PRX со включеным Auto ACK.
7) слейвы анализируют ADU обычным для модбаса образом - т.е. все, кроме одного, его игнорируют ввиду несовпадения modbus-адресов.
8 ) нужный слейв крутит шестеренками, обрабатывает PDU, переключается в PTX.
9) от бывшего слейва к бывшему мастеру передается цепочка "прими n байт ADU" - покромсанный ADU ответа - "тчк".
10) мастер собирает ADU, снова переходит в PTX, слейв - так же обратно в PRX с выключенным auto ACK.
11) мастер отсылает клиенту ADU по rs485.

если нужно передать ADU с broadcast адресом в понимании модбаса, просто на мастере отключаем auto ACK и передаем все подряд, как-нибудь там примут (или нет). Такое поведение (отсутствие ответов на broadcast ADU и негарантированная их доставка) вполне соответствует спецификации.

есть какие-то фатальные недостатки в этой схеме, из-за которых она не будет работать?

[roman.com]

не хочу сильно заморачиваться с самостоятельным контролем передачи на физическом уровне, и предполагаю использовать ShockBurst.

Ну и зря)) ShockBurst (с Auto ACK) гарантирует доставку пакетов только между двумя nrf24L01+ <> nrf24L01+, но он не гарантирует доставку пакетов между двумя конечными устройствами: МК---nrf24L01+ <> nrf24L01+---МК.

1) все слейвы слушают один и тот же RX_ADDR, на всех отключен Auto ACK.

Не обязательно всем слейвам слушать один и тот же RX_ADDR. Мастер может обратится к любому слейву напрямую, по адресу радиомодуля nrf24L01+.

Слейв с совпадающим адресом включает Auto ACK (или нет, если нужного адреса нет в сети вообще или он висит на проводе rs485).

Если верить даташиту, то перед началом передачи пакетов, все радиомодули nrf24L01+ должны быть настроены в одинаковый режим:
-в режим с включенным ShockBurst (с Auto ACK)
-или в режим с выклюенным ShockBurst (с Auto ACK).
Радиомодуль не может "на ходу" включать/выключать режим ShockBurst (с Auto ACK). В этом случае мастер не получит ACK.
Да и нафиг он вообще нужен.. этот ShockBurst (с Auto ACK).. Лично я им вообще не пользуюсь, так не вижу в нем практической пользы.))

[arkhnchul]

roman.com писал(а):

Ну и зря))

леееень)

roman.com писал(а):

ShockBurst (с Auto ACK) гарантирует доставку пакетов только между двумя nrf24L01+ <> nrf24L01+, но он не гарантирует доставку пакетов между двумя конечными устройствами: МК---nrf24L01+ <> nrf24L01+---МК.

вот этого не понял. Что случится с данными при передаче МК--nrf по SPI?

roman.com писал(а):

Мастер может обратится к любому слейву напрямую, по адресу радиомодуля nrf24L01+.

в рассматриваемом случае мастер не знает адресов радиомодулей, тем более их соответствия modbus адресам.

roman.com писал(а):

Радиомодуль не может "на ходу" включать/выключать режим ShockBurst (с Auto ACK).

я не нашел там прямого запрета на таковое действие. В крайнем случае, можно и переинициализировать модуль вообще с нуля, отключая питание, тайминги вроде как позволяют.

[roman.com]

Что случится с данными при передаче МК--nrf по SPI?

Всё что угодно..)) Перечислять можно долго.. начиная от плохого контакта и помех по шлейфу SPI... ))

я не нашел там прямого запрета на таковое действие. В крайнем случае, можно и переинициализировать модуль вообще с нуля, отключая питание, тайминги вроде как позволяют.

Вроде всё понятно...

1.jpg

(184.04 KiB) Скачиваний: 707

PRX получил пакет и атоматом отправил ACK. А если ShockBurst (с Auto ACK) отключить... то PRX атоматом ACK не отправит. Не пробовал)) Но помоему логика nrf24L01+ не позволит отправить "в ручную" ACK, после того как пакет уже принят и обработан.

2.jpg

(63.81 KiB) Скачиваний: 637

В крайнем случае, можно и переинициализировать модуль вообще с нуля, отключая питание, тайминги вроде как позволяют.

при отключении питания все регистры nrf24L01+ сбрасываются (переходим на заводские настройки) и вся информация теряется.

И вообще мне не нравится ShockBurst (с Auto ACK)... Отправлять по одному пакету и сидеть ждать ACK после каждого пакета...
В нормальных протоколах так не делают)) Например Modbus TCP - http://www.cta.ru/cms/f/435973.pdf

Протокол TCP. Управление потоком. - http://kunegin.com/ref1/net_prot/tcpprot.htm
Для ускорения и оптимизации процесса передачи больших объемов данных протокол TCP определяет метод управления потоком, называемый методом скользящего окна, который позволяет отправителю посылать очередной сегмент, не дожидаясь подтверждения о получении в пункте назначения предшествующего сегмента.

И т.д. и т.п.))

[arkhnchul]

roman.com писал(а):

Но помоему логика nrf24L01+ не позволит отправить "в ручную" ACK, после того как пакет уже принят и обработан.

не, идея не в том, чтобы отправить ACK руками, а в том, чтобы оно отправило его автоматом на второй (или третий-четвертый-пятый) переотправленный пакет, который пришлет PTX, не получив ACK на первый) судя по даташиту, на packet id, по которому оно определяет чего это за пакет, не должно влиять чтение содержимого из буфера.

roman.com писал(а):

В нормальных протоколах так не делают)) Например Modbus TCP

tcp в stm8s103 не влезет, хоть расшибись)

roman.com писал(а):

Для ускорения и оптимизации процесса передачи больших объемов данных

мне там дефолтных modbus-овских 19200 бит/с вполне достаточно

[roman.com]

отправило его автоматом на второй (или третий-четвертый-пятый) переотправленный пакет, который пришлет PTX, не получив ACK на первый)

ну можно и так. Тогда на первый отправленный пакет PTX не получит ACK. А начиная со второго и далее... получит ACK)).

на packet id, по которому оно определяет чего это за пакет, не должно влиять чтение содержимого из буфера.

Тогда наверное лучше чтобы первый пакет PTX отправил с установленным флагом NO_ACK в поле "PacketControl Field". В этом случае ни один из слейвов ACK не отправит.

из даташита: Функция выборочного автоматического подтверждения - флаг NO_ACK. Установка флага - пакет не должен быть автоматически подтвержден. На PTX вы можете установить флаг NO_ACK в поле управления пакетами "PacketControl Field" с помощью этой команды:W_TX_PAYLOAD_NOACK. Однако сначала функцию необходимо включить в регистре FEATURE, установив бит EN_DYN_ACK. Когда вы используете эту опцию, PTX переходит непосредственно в режим ожидания-I после передачи пакета.
PRX не передает пакет ACK при получении пакета.

А начиная со второго пакета и далее... в PTX сбросим флаг NO_ACK в поле "PacketControl Field". В этом случае от всех слейвов, в которых включена функция ShockBurst (с Auto ACK) будет получен ACK. Значит, после получения первого пакета от мастер, на всех слейвах кроме одного одолжна быть отключена фенкция ShockBurst (с Auto ACK) ... надо уточнить, можно ли отключить Auto ACK в слейве с помощью регистра/флага.

Блин.. чтото слишком много телодвижений)) Включать отключать... устанавливать/сбрасывать флаги... Помоему проще вообще отключить режим ShockBurst (с Auto ACK) и отправлять ACK "в ручную". Т.е. доверить управление потоком stm8s103... Так будет быстрее и проще)) А главное надёжней)) Не нужно думать что делать в случае потери пакетов и т.д.

[arkhnchul]

roman.com писал(а):

В этом случае ни один из слейвов ACK не отправит. ...
... от всех слейвов, в которых включена функция ShockBurst (с Auto ACK) будет получен ACK...

по идее изначально auto_ack отключен на всех.

roman.com писал(а):

доверить управление потоком stm8s103... Так будет быстрее и проще))

ниахота разгребать контроль целостности, ACK-и и ретрансмит руками, когда это умеет чип.

roman.com писал(а):

Не нужно думать что делать в случае потери пакетов и т.д.

ну как не нужно? как раз рожать систему с квитанциями и переотправками)
вообще, в случае чего просто не сойдется контрольная сумма у самого modbus ADU, она там своя. Штатная ситуация по спецификации.

[roman.com]

arkhnchul писал(а):

раз рожать систему с квитанциями и переотправками)

Да что там рожать.. )) Куча слейвов... сидят ничего не делают)) А nrf24L01+ слушает эфир... nrf24L01+ принял пакет, сработал IRQ, читаем адрес (кому адресован пакет). Если нам, то закинули свой адрес в TX FIFO и нажали кнопочку "отправить" (CE 1). ACK улетел мастеру))
Всё. Сидим дальше ничего не делаем... )) По количеству операций, не больше чем со всякими переключениями... флагами... auto_ack... ShockBurst... и т.д.))

Хотя для низкой скорости передачи, modbus-овских 19200 бит/с, не вижу разницы как передавать, если использовать буферизацию))

А можно сделать сквозной канал, без гарантии доставки. modbus чувствителный к задержкам... Согласно спецификации у modbus сообщение начинает восприниматься как новое после паузы 14 бит.... Пакет максимум 255 байт. Тогда передаём все 255 байт подряд, с modbus CRC, без всяких ACK, без задержек ..))
Можно только в самом конце отправить ACK, типа весь пакет (255 байт) прошёл..

Вообще с modbus не работаю. Но лично мне нравятся универсальные схемы. А если я завтра захочу заменить радиомодуль на другой, без auto_ack, всё надо будет менять? ))

И вообще... мне не нравится протокол TCP. Лучше UDP. Контроль, доставка, разборка/сборка пакетов, порядок следования пакетов и т.д. всё на уровне приложения. Схема универсальная, не зависит от канала связи... от типа радиомодуля... и т.д. и т.п.))

[arkhnchul]

roman.com писал(а):

modbus чувствителный к задержкам... Согласно спецификации у modbus сообщение начинает восприниматься как новое после паузы 14 бит.

это в какой спеке? в modbus RTU - после 3.5 длительностей символа, т.е. 38.5 длительностей бита, или 1750мкс для бодрейтов больше 19200. В modbus ASCII требований нет, новое сообщение начинается с символа ":", заканчивается CR LF. Самому по себе модбасу вообще плевать на тайминги. Спецификация рекомендует иметь какой-нибудь таймаут, чтобы не ждать ответа от зависшей железки весь остаток вечности, и все на этом.

roman.com писал(а):

Лучше UDP. Контроль, доставка, разборка/сборка пакетов, порядок следования пакетов и т.д. всё на уровне приложения. Схема универсальная, не зависит от канала связи... от типа радиомодуля... и т.д. и т.п.))

с другой стороны - вот все это нужно велосипедить на уровне каждого приложения.

[Anton.M]

roman.com писал(а):

какой однонаправленности? nrf24L01+ это трансиверы.

Свалился в больницу, выпал совсем из диалога.
Имеется ввиду, работает как приемо-передатчик на одном канале (двусторонняя связь)? Или только один приемник, другой передатчик и никак по-другому?

[alex_]

Имеется ввиду, работает как приемо-передатчик на одном канале (двусторонняя связь)?

Это смотря как вы его настроите, он может работать как приёмопередатчик но только в полудуплексном режиме. Причём переключить его нужно будет контроллером сам он переключаться не умеет(за исключением ответа на принятый пакет).

[roman.com]

Имеется ввиду, работает как приемо-передатчик на одном канале (двусторонняя связь)?

Имеется ввиду nrf24L01+ работают как обычная рация: приём/передача.

-Переключили nrf24L01+ в режим приёмника и нажали кнопочку "вкл. приёмник" - сидим слушаем в режиме приёма.

-Переключили nrf24L01+ в режим передатчика и нажали кнопочку "вкл. передатчик" - сидим передаём в режиме передатчика.

Принимать и передавать можно на разных частотах (от 2.400GHz до 2.525GHz). Очень удобно, в режиме ретранслятора например...

Кстати... некоторые на nrf24L01+ делают рации)) https://www.youtube.com/watch?v=bgpNbGDZrEg

А по поводу надёжности nrf24L01+... спросите у sashamelja... например вот тут: viewtopic.php?f=28&t=148087&p=3276009#p3276009

sashamelja каждый раз когда слышит слово nrf24L01+... начинает материться))

[a5021]

alex_ писал(а):

Это смотря как вы его настроите, он может работать как приёмопередатчик но только в полудуплексном режиме. Причём переключить его нужно будет контроллером сам он переключаться не умеет(за исключением ответа на принятый пакет).

Вот этот "ответ" сам по себе интересный для полудуплекса подрежим. Фактически, приняв пакет, приемная сторона может тут же передать свой пакет произвольного (в рамках ограничений ntf24) объема в ответ, не разрывая связи. Эту фишку удобно использовать на неких автономных устройствах, которые никогда не находятся в режиме приема, а только шлют данные. Например, забрасывать данные точного времени для "подводки" часиков на удаленном девайсе.

[roman.com]

Вот этот "ответ" сам по себе интересный

этот "ответ" сам по себе ничем не интересен, ктоме как передавать ACK (подтверждение и приёме) это "ответ" ничем не интересен.))

Фактически, приняв пакет, приемная сторона может тут же передать свой пакет произвольного (в рамках ограничений ntf24) объема в ответ, не разрывая связи.

Что значит не разрывая связи? )) А если ntf24 работает под управлением МК... связь разывается? ))

забрасывать данные точного времени

в автоматическом "ответе" не может быть данных точного времени..)) потому, что.. что бы забросит данные точного времени... например на удалённое устройство... запрашиваемый сначала должен записать данные точного времени в ntf24 и только потом отправить на удалённое устройство. )) этот "ответ" абсолютно бесполезен))

[jcxz]

roman.com писал(а):

запрашиваемый сначала должен записать данные точного времени в ntf24 и только потом отправить на удалённое устройство. )) этот "ответ" абсолютно бесполезен))

А в чём проблема заблаговременно "записать данные точного времени в ntf24"?

[jcxz]

Очевидно как - просто писать туда каждые 1мсек.

[Mishany]

Кто подскажет как наиболее правильно организовать связь с нулевой потерей данных. Потеря байтов не допустима, как организовать передачу байта в один конец до тех пор пока он не передастся?
У меня при плохой связи теряются байты, а потом некоторые уже всплывают из буфера(не могу понять пока из какого)
примерно так:
1234567890
........
где то потерялось пару байт
........
8901234567

[roman.com]

Один из вариантов: Отключить все заводские настройки (всякие автоматические АСК) и передать всё управление МК.
МК точно знает: сколько пакетов отправлено, сколько получено, сколько (и какие именно) пакеты требуют повторой передачи...
В этом режиме nrf24L01+ работает "прозрачно".

[Mishany]

если все отключить, то тогда не узнать передался байт или нет.
после каждой отправки байта проверять TX_DS и MAX_RT в статусе, если TX_DS=1 то байт улетел, если MAX_RT=1 то повторить передачу.
IRQ при любом исходе же сработает?

Код:

//отправка байта по воздуху
void send_byte(uint8_t data)//отправка байта.
{
   w_register(W_TX_PAYLOAD,data);//запись байта в буфер TX для отправки
   ptx();//передача байта
   while (BitIsSet(PIND,IRQ));//Ждем пока байт не передан
   uint8_t temp_status = r_register(STATUS);//прочитали статус регистр
   if (BitIsSet(temp_status,TX_DS)&&BitIsClear(temp_status,MAX_RT))
   {
      w_register(STATUS, temp_status);//сброс флагов прерываний
   }
   else
   {
      if (BitIsSet(temp_status,MAX_RT)&&BitIsClear(temp_status,TX_DS))
      {
         w_register(STATUS, temp_status);//сброс флагов прерываний
         Erase_TX();
         Out_TX_return();//выбор предыдущего OUT_TX--; байта из буфера send_byte(buff_TX[OUT_TX++]);
      }
   }
}

теперь при плохой связи появляются лишние байты на 2000 переданных байта от 3 до 20 байт лишние(((