Wat zijn ideale vertragingstijden tussen opdrachten voor RF24-lib

Werk aan een WiFi-gebaseerd irrigatiesysteem dat gebruik maakt van de RF24 lib voor communicatie. Er is een prototype van een externe sensor in gebruik genomen met een standby-stroom van 0.036 mA en verzendt elk uur gegevens met een piek van 12 mA. Tijdens het uitvoeren van het prototype zie ik verschillende pogingen om opnieuw te proberen die bij elke verzending lijken te variëren - ondanks dat de installatie altijd onder dezelfde omstandigheden plaatsvindt. Ik heb een nieuwe lus gecodeerd om dit te beperken tot 10 pogingen om verbinding te maken met de master - ik wil niet dat de sensor voortdurend verzendt zonder een bevestiging van de master te krijgen

Wat ik probeer te vinden, is de ideale vertraging die vereist is tussen verschillende RF24-opdrachten om de overdrachtstijden zoveel mogelijk te beperken om stroomverbruik te besparen. Om het even welke ideeën ?? (codefragmenten bijgevoegd)

   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. Gebruik geen vertragingen, totaal onnodig 2. Kijk naar de voorbeelden, PingPair etc.
toegevoegd de auteur user67244, de bron
Krijg je na een aantal pogingen uiteindelijk bevestiging? Welke status (energiebesparing en alles) is de master wanneer het knooppunt begint te verzenden? En waarom denk je dat vertraging (of gebrek daaraan) de oorzaak is? Heb je in plaats daarvan geprobeerd het zendvermogen en de gegevenssnelheid aan te passen?
toegevoegd de auteur passing through, de bron
Hallo, bedankt voor de geweldige reacties Krijg bevestiging na verschillende aantallen antwoorden - varieert van 2 tot 8 of 9 pogingen naar de master. Heb aan de meester gezien dat het af en toe 3 berichten ontvangt waarop het lijkt te reageren. Onderstaande codeclip van de onderstaande master zal worden opgenomen
toegevoegd de auteur Erf, de bron
Ik heb een specifiek kanaal geconfigureerd buiten de meest gebruikte in mijn regio, en heb aanbevolen instellingen voor afstandsbedieningssensoren gebruikt //..... start radio en leidingen ..... Serial.println ("Start radio ..." );//debugging radio.begin (); vertraging (30); radio.setPALevel (RF24_PA_MAX); radio.setDataRate (RF24_250KBPS);//Snel genoeg ... Betere afstand radio.setChannel (108); //2.508 Ghz Boven de meeste wifi-kanalen radio.openWritingPipe (pipes [0]); radio.openReadingPipe (1, pijpen [1]);
toegevoegd de auteur Erf, de bron

1 antwoord

Verwijder alle vertragingen behalve die na StartLijst worden.

Je zou het kunnen vervangen door een "wachten op radio.beschikbaar om waar te zijn OF 50ms om een ​​stuk code te hebben gepasseerd. Het is niet nodig om 50ms te wachten als het bericht al is ontvangen na b.v. 10ms.

Nog beter zou het zijn om de ACK-pakketfunctie van de NRF te gebruiken. Met deze functie bereidt de master al een pakket voor op de slaaf. Wanneer de slaaf vervolgens zijn bericht verzendt (elk uur), wordt het voorbereide pakket opgenomen in het ACK (bevestiging) -pakket.

Om het nog verder te optimaliseren. Het is beter om de slaapcode te optimaliseren en vervolgens de verzendcode. Het slaapgedeelte gebruikt binnen een uur nog steeds meer vermogen dan de verzendcode, zelfs als het 10 seconden duurt om dit te doen.

Wat betreft de verloren pakketten. Probeer een ander kanaal te gebruiken. Misschien wil je ook een NRF-module met een echte antenne en misschien zelfs een versterker voor de master.

PS Je kunt de serial.print verwijderen in de geïmplementeerde versie.

1
toegevoegd
Bekijk ook deze batterijcalculator om te zien hoeveel runtime u krijgt.
toegevoegd de auteur Al., de bron
Hallo, bedankt voor het antwoord. Weet niet zeker hoe de ACK-pakketfunctie moet worden geconfigureerd - vrij nieuw voor deze radiomateriaal. Ik ben van mening dat de slaapcode behoorlijk goed is geconfigureerd - ongeveer 0,035mA tekenen tijdens het slapen, wat voor mij werkt Alle verklaringen van Serial.Print zijn alleen bedoeld voor foutopsporing en ik verwijder ze uit de ingezette code.
toegevoegd de auteur Erf, de bron