nRF24L01+ : побеждаем модуль.

Ответ всегда надо ждать, и давать после него команду на запуск. 15 миллисекунд думаю мало. Сегодня две платы расположили рядом и заметили, что идет наводка. Приемник получал инфу около секунды и вообще тупил. Сделали расстояние 30 см. Все как часики заработало.

Завтра перепишу вашу функцию под себя и чую, что будут пылиться наши xbeeшечки

А delay нужен только если устройства постепенно опрашиваются, чтобы координатор не выполнял запросы от других устройств в этот момент. Спит после работы... Отстаньте от него


Да кстати забыл спросить про кондеи !!!!



Вчера купили два датчика, включили и начали тестить GetStarted скетчом. Смотрим начала вылезать какая-хрень. Припаяли 2.2 МКФ к GND и VCC, отпаяли от блока питания умершего. Датчики не захотели работать. Тест выдает табличку. Сканер работает. А вот прием и передача нет. Мучались долго. С утра купили новые датчики и запитали проводочками МАМА-ПАПА к ардуине. Сразу появился и прием и передача.

Вопрос, могут ли в Россию поставлять бракованные датчики или на таможне их специально выводить из строя???? У меня есть подозрение, потому как при покупке Xbee партией 8 штук из них удалось прошить оригинальной платой только две штуки и пришлось мутить на NRF из-за этого.

 

У меня когда барахлило(модули с антенной ставил), я пробовал и больше выставлять, толку нет... если отвечает, то отвечает и за 15мс, а если нет.... то и нет... я думаю лучше реализовать повторы.... и проверки... по типу как функция SetRetries.... Чтобы пробовала отсылать ответ несколько раз, ну по крайней мере себе хочу так реализовать... Игорь К кстати тоже об этом и говорил по выше в этой теме.

По конденсаторам сказать нечего)
Есть только вопрос: Какую ёмкость можно применить? Если я поставлю по 100мкф не погорят модули?

По датчикам: Заказывал 6 обычных, 2 с антеннами все рабочие.
Все были запаяны в антистик пакеты, может статическое электричество?

 

Возможно и статика, сейчас уже поняли, что в итоге брать нужно 1 $ за NRF вчера нашли в cети.

Про кондеи. Я в электрике вообще ноль+ может вот эта ссылка подскажет http://www.electrosad.ru/Electronics/SFRadiohob/SFRadiohob2.htm.

 

От 100 мкф модули не погорят, а вот то что их питает может посчитать ситуацию коротким замыканием. Импортные товарищи говорят о максимум 10 мкф, но больше 2,2 ставить нет смысла ИМХО,
Еще на счет левых модулей. Похоже они действительно существуют. Возьмите лупу и посмлтрите что написано на чипе. Возможны забавные открытия.

 

magic21, Вы там в коде, полагаю, лишних движений наделали.
Функции radio.openReadingPipe и radio.openWritingPipe не открывают никаких труб, а не более чем пишут информацию в регистры модуля. Поэтому для манипуляций с приемом и передачей вполне достаточно функций radio.stopListening и radio.startListening.
radio.openReadingPipe и radio.openWritingPipe эффективнее выносить в сетап.
Когда действительно необходимо их трогать, так это в случае передачи информации на приемники с разными трубами.

 

Игорь мы пробовали без этих функций - НЕ РАБОТАЕТ. Как написали на открытие и закрытие стало отсылать, хотя есть и вероятнось, что манипулируя с кодом и работает без них. Сегодня проверю и отпишусь.

На всех модулях написано одно и тоже. Первой строчкой NRF

 

Библиотека то у Вас какая? Форк или новая, на которую указывал magic21 в посте номер 88? В старой библиотеке видимо существует проблема очистки буфера при передаче пакетов, а в форке это решено.
Вы пробовали эту новую библиотеку?

В старой библиотеке проблема с буфером решалась путем перевода в public функций flush_tx() и flush_rx() и вызова их перед отправкой сообщения и иногда после приема.
(Причем в некоторых случаях на одном и том же коде но на разных модулях это не требовалось!!! )
Повторять постоянно radio.openReadingPipe и radio.openWritingPipe не рационально.

А что касается модулей, то мне встречались микросхемы без опознавательных знаков.

 

Я код писал чисто интуитивно, т.к. знания английского языка, языка си и микроконтроллеров у меня плохие.
Так как мой тестовый стенд собран и ждёт моих дальнейших потуг=)))
Я сейчас попробовал закомментировать строки в приёмнике (на передатчике оставил как есть):

Код (Text):

radio.stopListening();  //Перестаем слушать
//radio.openWritingPipe(pipe); //Открывем трубу для отправки
radio.write( &nodeRes, sizeof(nodeRes) ); // Отправляем ответ
//radio.openReadingPipe(1,pipe); //Открываем трубу для приёма
radio.startListening();//Слушаем

Всё работает!
Библиотека конечно, та про которую я писал.

Спасибо Игорь за то, что разжевали!

 

Библиотеку скачивали отсюда https://github.com/maniacbug/RF24/

 

Замените на эту: https://github.com/tmrh20/RF24
Я уже писал про неё.

 

Если не трудно, и вы продвинулись в работе с новыми функциями и нашли какие то интересные приёмы, делитесь=)

 

Ну я же не просто так исследованиями библиотек занимаюсь . Дойдут руки до проекта - разберусь.
Сейчас на Ардуино Yun делаю удаленный контроль температуры на улице, в доме и в системе отопления. Там следующим этапом может и будет что-то на этом модуле.
Вот посмотрите сами сколько там интересных функций автор нагородил.
Кстати, в этой библиотеке функция flush_tx сделана публичной, хотя и вспомогательной. Видимо я на уровне чувств пошел по верному пути.

Обратите внимание и на такое новшество в этой библиотеке: упрощено "определение труб". Теперь они могут задаваться массивами char из пяти байтов.

 

Вот, что значит написано по русски=))))
Я видел, только думал откуда они берут эти 1Node, 2Node...))) Сказывается конечно моё незнание си.

Эта фраза ставит мозг на место)

 

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

 

Благодаря мучениям и бессонным ночам. Мы все поняли как работает модуль. Скорость довольно шустра и нет зависонов...

------------------------------------------------------------------------------------------------
Внимание: вопрос знатокам!!!
------------------------------------------------------------------------------------------------

Я отправляю сообщение роутеру на задание от координатора. Роутер, если видит сообщение, то должен начать выполнять задание. Если задание началось выполняться, то координатору отослать ОК, что выполняется задание. В противном случае, координатор должен долбить роутера, пока тот не ответит ок и не запустит задание.

Как узнать запустилось ли задание ???????

Тестируя прием-передачу, столкнулся, что не всегда роутер получает команду, не всегда координатор получает ответ от роутера. Как с этим бороться, алгоритм пока не приходит в голову. Вот например у меня включается реле по команде 21 от координатора. Реле включается и с этим проблем нету

Код (Text):

//---------------------------------------------------------------------------------------------
            //Движение по часовой стрелке до первого счетчика
            //---------------------------------------------------------------------------------------------
            if (CommandValue1=="21")
              {
               
                  //Выключаем реле
                  digitalWrite(RelayPin1,HIGH);
                  digitalWrite(RelayPin2,HIGH);
                 
                  //Включаем реле
                  digitalWrite(RelayPin1,LOW);
                 
                  send_answer(MessageNRF,NRF);
                 
                  CommandWork=true;
              }

После включения реле, отсылаю команду координатору send_answer(MessageNRF,NRF);

MessageNRF - цифровой код 21
NRF - труба

Координатор не всегда получает сообщение, бывают сбои !!!. Но работает довольно стабильно.

Допустим координатор, не получил сообщение, реле сработало. Мотор-CW начал вращаться. А координатор не знает этого. И пишет 'Нет ответа. Бен это Данила, ай нид хелп'. и начинает долбить роутер, посылая команду "Включи мотор". А мотор все продолжает крутить и крутить....


Что скажете ? Какие есть идеи? Может 2 раза кидать команду (TEST,GO) или как нибудь по другому.

 

Подтверждать прием команды до начала ее выполнения.

 

Отослал я команду подтверждения, координатор отсылает команду на запуск . И тут кто-то нажал глушилку и роуте не получил команду... И все заново... Я думаю этого никак не избежать....

 

2. Пропускать мимо ушей повторную команду, которая сейчас исполняется, одновременно отправляя подтверждение об исполнении.

 

Да такой, алгоритм приведет к более стабильной работе. Посмотрим на его действие. Отпишусь

 

Ребят, не забивайте тему, а? Это же другой раздел!