Здесь принимаются все самые невообразимые вопросы... Главное - не стесняйтесь. Поверьте, у нас поначалу вопросы были еще глупее :)
Ответить

Re: nrf24L01+

Чт янв 25, 2018 17:37:13

roman.com писал(а):Если верить даташиту: "В режиме ACK, количество повторных передач может достигать максимального числа, определенных в ARC. Если это произойдет, nRF24 установит флаг MAX_RT и вернется в режим ожидания-I."
Или по-простому... количество ACK у NRF24 ограничено - 15 попыток. Затем надо сбрасывать флаг... и запускать всё заново...

У меня в одном месте так и сделано. Циклим эти 15 попыток по времени вплоть до минуты. Если уж за минуту не передалось, то бросаем это дело, т.к. нужно будет передавать уже другой пакет.

В "прозрачном" режиме количество ACK не ограничено...))

В "прозрачном" режиме их вообще нет и если они нужны, то придется их изображать самостоятельно, реализуя некий доморощенный протокол. Зачем это может потребоваться, если все это уже есть в железе, непонятно.

Re: nrf24L01+

Чт янв 25, 2018 18:35:33

Mishany передавай не по байтно а пакетом и включи в пакет ID номер посылки(2 байта я думаю хватит), все посылки с одинаковым номером, считаются дублем и можно просто игнорировать :))

Re: nrf24L01+

Чт янв 25, 2018 19:37:58

a5021 писал(а):Зачем это может потребоваться, если все это уже есть в железе, непонятно.

Причины могут быть разные...

Во-первых ACK в nRF24 - это не гарантия что пакет дойдёт до адресата (МК - МК).

Во-вторых можно отключить ACK nRF24 для экономии трафика. Сделать например как протоколе TCP/IP.
Вместо ACK для каждого пакета, делаем например указатель подтверждения (до какой позиции МК получил поток).

http://we.easyelectronics.ru/electro-an ... lient.html

... другие причины.

Re: nrf24L01+

Чт янв 25, 2018 21:03:50

вот такая задача, постоянный поток данных в оба направления. использовал 2 пары NRF каждая NRFка работает в своем направлении PTX / RTX каждая NRFка на своем МК. Одно спасение, что прием, подтверждение, ответ как то должно быть организовано в программе ПК и ЧПУ. Я еще сначала мучился с 4-мя прошивками, потом все же сделал одну универсальную которая сама переходит в нужную конфигурацию по состоянию 2-х ножек МК.
СпойлерИзображение
Изображение

Если рассмотреть такое стечение обстоятельств:
PTX отправляет байт
PRX принял байт, отправил ACK, IRQ - Low и т.д....
PTX ACK не услышал, запускает повтор....
......
PRX принимает дубликат? или там как то все иначе произойдет?
Последний раз редактировалось Mishany Чт янв 25, 2018 21:29:28, всего редактировалось 1 раз.

Re: nrf24L01+

Чт янв 25, 2018 21:13:38

roman.com писал(а):Во-первых ACK в nRF24 - это не гарантия что пакет дойдёт до адресата (МК - МК).

В идеале нет(идеала и не существует) но в основном ACK для этого и нужен
roman.com писал(а):Во-вторых можно отключить ACK nRF24 для экономии трафика.
А зачем, вопрос не стоит в экономии трафика.
Любите Вы по второму разу изобретать колесо, всё уже было придумано до нас и реализовано в железе.

Re: nrf24L01+

Чт янв 25, 2018 21:35:29

кто в курсе, как работает команда:
REUSE_TX_PL (1110 0011) = 0
Used for a PTX device Reuse last transmitted payload. TX payload reuse is active until W_TX_PAYLOAD or FLUSH TX is executed.
TX payload reuse must not be activated or deactivated during package transmission.
?
если поднимает флаг MAX_RT, то передача не удалась и в W_TX_PAYLOAD остаются данные. которые можно как я понимаю выплюнуть в воздух без перенастройки с помощью этой команды?

Re: nrf24L01+

Чт янв 25, 2018 21:50:41

вот такая задача

Ну во первых стоит наверно промониторить каналы, если это не было сделано, во вторых при решении данной задачи я бы порекомендовал смотреть в сторону ESP8266, так как сам игрался с NRFками, было сделано программа на ПК шлёт через уарт(usb-uart) данные на контроллер, контроллер это обрабатывает шлёт через пару NRFок на другой контроллер, получается полный :facepalm:
В принципе работает, но сколько времени на это было убито :kill:
А потом начал понимать: а нафига всё это надо? :dont_know: если только ради эксперемента или эротики. С самого начала надо было взять ESP12 и прикрутить её к удалённому контроллеру, а данные сразу слать из программы по TCP через WI-FI точку доступа, причём это всё заботы винды о которых даже не стоит задумываться, в том числе и о качестве связи.

Re: nrf24L01+

Чт янв 25, 2018 21:52:33

с вифи я еще не подружился(((

Re: nrf24L01+

Чт янв 25, 2018 22:05:37

alex_ писал(а):вопрос не стоит в экономии трафика

Зачастую стоит.
alex_ писал(а):Любите Вы по второму разу изобретать колесо

В этом всё дело, я не изобретаю колёс, а использую стандартные сетевые протоколы. Меня интересует только одно: дошёл мой пакет из пункта А в пункт Б или нет. Настроил две nrf24 в режим моста. Пакеты идут сквозняком, без задержек... nrf24 >> nrf24 >> nrf24 >> nrf24...
Передаю массивы данных. По статистике из ~10.000 пакетов 1 пакет потерялся... Не беда)) Отправил повторно 1 пакет из массива...

У Вас после каждого пакета (nrf24 >> пакет >> nrf24) оправляет ACK (nrf24 << ACK << nrf24) - это называется "непроизводительное занятие канала". У Вас точно какие то "колеса" ... ))

Какойто бесполезный разговор..))
Последний раз редактировалось roman.com Чт янв 25, 2018 22:32:05, всего редактировалось 1 раз.

Re: nrf24L01+

Чт янв 25, 2018 22:27:57

кое что нашел про REUSE_TX_PL
-если не хватает отведенных чипом 15-ти попыток передачи пакета, можно использовать команду REUSE_TX_PL и пытаться отсылать хоть до бесконечности. Суть в том, что в каждом пакете есть PID и приемник точно отличит повторный пакет среди потока. Может быть ситуация, что ACK не дошел до передатчика и тот отправил пакет снова, приемник поймет, что пакет повторный, и отправит ACK снова.
Не стоит мутить повторную отправку руками, через W_TX_PAYLOAD, это неверный путь, да и ненужный труд, все уже реализовано в железе.

источник

Re: nrf24L01+

Чт янв 25, 2018 23:46:50

можно отключить ACK nRF24 для экономии трафика

под "экономией траффика" подразумеваете передачу больших объемов данных? nrf-ки малость не для этого предназначены и, как следствие, приспособлены; скорее для случаев типа моего - перекидываться десятком-другим байт между точками. Вытягивать из них пропускную способность при наличии esp и разных синезубых чипов - имхо, троллейбус_из_буханки.jpg
Сделать например как протоколе TCP/IP

скорее как на канальном уровне wifi или bluetooth. Прям как в TCP, с установлением соединения и скользящим окном, будет довольно печально шевелиться. И да, еще мелкая придирка - только в TCP, IP никакого контроля передачи не предполагает.

Re: nrf24L01+

Пт янв 26, 2018 01:18:40

с вифи я еще не подружился(((

Полагаю стоит попробовать, и думаю что результат понравиться.
roman.com писал(а):вопрос не стоит в экономии трафика. Зачастую стоит.
Обычно под задачи выпирают железо а не железо разгоняют под задачи, я абсолютно согласен с arkhnchul хотите скорость используйте другой чип, это как хотите быстрее - вызывайте такси, автобус вас быстрее не повезёт.
roman.com писал(а):В этом всё дело, я не изобретаю колёс, а использую стандартные сетевые протоколы.
Может быть но, зачем NRF склонять к сетевому протоколу, это как ехать на санках по асфальту, хотя они лучше едут по снегу.

Re: nrf24L01+

Пт янв 26, 2018 14:24:28

зачем NRF склонять к сетевому протоколу

на прикладном уровне удобно, если устройств больше двух и их переменное количество :dont_know: только в случае nrf он идеологически скорее должен быть чем-то из разряда fieldbus-ов (modbus, devicenet, что-то свое наподобие), нежели жирным протоколом больших сетей.

Re: nrf24L01+

Пт янв 26, 2018 14:30:53

вопрос был про использование аппаратных функций модуля. Решил я уже задачу, все передается без ошибок, при потере связи за потерю пакетов отвечает только буфер в МК.
Всем спасибо.

NRF24L01 + PA + МШУ Беспроводной модуль без arduino?

Чт окт 04, 2018 22:34:02

Здравствуйте. Нашёл у китайцев вот такой передатчик, NRF24L01, однако в интернете в информации к нему везде пишут подключение к arduino, я так понимаю что arduino это просто микроконтроллер атмеловский, тоесть чтобы запустить этот передатчик нужна программа? Вопрос в следующем- мне нужно просто передать сигнал из точки А (контакт замкнулся) в точку Б (реле включилось), это возможно без микроконтроллера?


Сюда перенес.
aen

Re: NRF24L01, NRF24L01+

Пт окт 05, 2018 08:20:29

Без микроконтроллера проблематично. Процессу передачи данных по радио должна предшествовать запись этих данных в NRF24L01 через интерфейс SPI.

Re: NRF24L01 + PA + МШУ Беспроводной модуль без arduino?

Пт окт 05, 2018 22:38:03

Вопрос в следующем- мне нужно просто передать сигнал из точки А (контакт замкнулся) в точку Б (реле включилось), это возможно без микроконтроллера?

Нет.

Re: NRF24L01, NRF24L01+

Пт окт 05, 2018 23:41:05

a5021, типа проблематично, но возможно? это как?
без управляющего МК не возможно!

Re: NRF24L01, NRF24L01+

Сб окт 06, 2018 00:50:12

Да можно, если постараться. На тот же принтерный порт (LPT) повесить и битбэнгом SPI на нем изобразить. Будет работать, никуда не денется.

Re: NRF24L01, NRF24L01+

Сб окт 06, 2018 10:16:22

спасибо
вобщем то понятно, придётся МК городить, я так понимаю аттинка 13 не подайдёт? А что есть в природе попроще атмега 8? Нужно передавать всего одну команду.
Ответить