Які ідеальні затримки між командами для RF24 lib

Я працюю на базі зрошувальної системи Wi-Fi, яка використовує RF24 для мобільних пристроїв. Отримано прототип датчика дистанційного керування, який працює в режимі очікування 0,036 мА, і передає дані щогодини навколо максимуму 12 мА. Під час запуску прототипу я бачу різні спроби повторення, які, здається, різняться з кожною передачею - не дивлячись на те, що весь час встановлюється в однакових умовах. Я закодовав цикл повторення, щоб обмежити це, щоб 10 спроб підключення до майстра - не хочу, щоб датчик постійно відправлявся без отримання підтвердження від майстра

Те, що я намагаюся знайти, - це ідеальна затримка, необхідна між різними командами RF24, щоб максимально скоротити час передачі для економії використання енергії. Будь-які ідеї ?? (фрагменти коду додаються)

   pinMode(mostureSensorVCC, OUTPUT);
   digitalWrite (mostureSensorVCC, HIGH); //VCC to sensor   
   pinMode(mostureSensor1, INPUT);      //moisture sensor on
   delay(10); 
   int sensorValue1 = analogRead(mostureSensor1);//read the input on analog pin 
   Serial.print("Current Value Sensor 1 is : ");//debugging
   Serial.println(sensorValue1);//print out the value you read:  
   msg[0] = sensorValue1;
    digitalWrite(mostureSensor1, LOW);
    digitalWrite(mostureSensorVCC, LOW);    
      while (message != sensorValue1)
        { 

          Serial.print("sensorValue in while loop is ");//debugging
          Serial.println(sensorValue1);                  //debugging
          Serial.print("Message One is ");               //debugging
          Serial.println(message);                       //debugging  
          radio.powerUp();
          delay(70);

          radio.stopListening();
          delay(50);
          radio.write(msg, 2);
          delay(40);
          radio.startListening();
          delay(50);

         Serial.println(d);              //debugging


          if (radio.available())
            {   
             Serial.println("Radio available");    //debugging
              radio.read(msg, sizeof(msg));
              message = msg[0];
              Serial.print("Check Message received from master ");// debugging
              Serial.println(message);

            }
            if(d>=10)
            {
              Serial.println("Unable to send to master");
              break;
            }
       d++;   
  }

delay(1000);       
radio.powerDown();
message = 0; 
msg[0] = 0;
1
1. Не використовуйте затримки, абсолютно непотрібні 2. Подивіться на приклади, PingPair і т. Д.
додано Автор user67244, джерело
Чи в кінцевому підсумку ви отримаєте підтвердження після кількох спроб? Який стан (енергозбереження та все) є основоположником, коли вузол починає передавати? І що змушує вас думати, що затримка (чи відсутність її) є причиною? Ви намагалися скоректувати потужність передачі та швидкість передачі даних?
додано Автор passing through, джерело
Привіт, Дякуємо за чудові відповіді Отримати підтвердження після різних номерів відповідей - варіює від 2 до 8 або 9 спроб майстра. Бачили на майстер, що він іноді отримує до 3 повідомлень, на які, здається, це відповідає. Включати відповідний код кліпу з майстра нижче
додано Автор Erf, джерело
Я налаштував певний канал за межами більшості використовуваних у моєму районі і використовував рекомендовані параметри для віддаленого датчика передає //.....start радіо і труби ..... Serial.println ("Start radio ..." );//налагодження radio.begin (); затримка (30); radio.setPALevel (RF24_PA_MAX); radio.setDataRate (RF24_250KBPS);//досить швидко ... краще діапазон radio.setChannel (108); //2.508 Ghz Над більшістю каналів Wifi radio.openWritingPipe (труби [0]); radio.openReadingPipe (1, труби [1]);
додано Автор Erf, джерело

1 Відповіді

Вилучіть всі затримки, крім одного після startListening.

Ви можете замінити його на "чекати радіо". Доступно, щоб бути справжнім, або 50 мс пройшов "шматок коду". Немає необхідності чекати 50 мс, якщо повідомлення вже було отримано після, наприклад, 10 мс.

Навіть краще було б використовувати функцію ACK-пакету NRF. За допомогою цієї функції майстер вже готує пакет для раба. Тоді, коли підлеглий надсилає це повідомлення (кожну годину), підготовлений пакет входить до пакету ACK (підтвердження).

Що стосується оптимізації його ще більше. Було б краще оптимізувати код сну, потім код відправлення. Частина сну все ще буде використовувати більше енергії за годину, ніж код відправлення, навіть якщо це займе 10 секунд.

Що стосується втрачених пакетів. Спробуйте використати інший канал. Ви також можете отримати модуль NRF з справжньою антеною, а може навіть і підсилювачем, для майстра.

PS Ви можете видалити serial.print у розгорнутій версії.

1
додано
Також перегляньте цей калькулятор акумулятора , щоб дізнатися, скільки часу роботи ви отримуєте.
додано Автор Al., джерело
Привіт, Дякую за відповідь. Не впевнений, як налаштувати функцію пакету ACK - це чудово інше для цього радіо. Я (я відчуваю) отримав код сну досить добре налаштовується - малюючи навколо 0.035mA під час сну, що працює для мене. Всі заяви Serial.Print просто для налагодження, і я видаляю їх з розгорнутого коду.
додано Автор Erf, джерело