geen communicatie tussen twee arduino's nrf24l01

[nicoverduin Profiel PrivéberichtWebsite]

Volgens mij is het net als serial.available(). Dus als er niets is moet je niet gaan lezen of printen. Net als serial

[tim- Profiel Privébericht]

Volgens mij is het net als serial.available(). Dus als er niets is moet je niet gaan lezen of printen. Net als serial

ja klopt daar was ik ook al achter

Dit zorgt er wel voor dat de communicatie iets minder stabiel is als eerst... Ik "mis" nu af en toe een sensor. Heb nog steeds 2 temperatuur sensoren en zodra er 1 of 2 aanwezig zijn wil ik de waarde weergegeven hebben op het scherm en als ze niet aanwezig zijn (omdat ik nog wel eens de stekker er uit haal gewoon om te testen) moet het maar 1 temperatuur sensor weergeven en niet Temp buiten 0.00 en Temp binnen 22.00 ... nu heb ik regelmatig dat ik Temp buiten 25.80 heb en Temp binnen staat er niet bij.. terwijl beide sensoren aan staan.. en bij de volgende keer dat het scherm weer vernieuwd is staat het er wel bij.. dan kan het een paar keer goed gaan maar kan het ook zo zijn dat de sensore er de volgende keer niet meer bij staat. Ligt dit aan de "vertraging" tussen de nrf's of heeft dit te maken met de manier waarop ik controleer of de sensor aanwezig is of niet:

hier de code die ik gebruik om te zien of de sensoren aanwezig zijn of niet:

cpp code

if (radio.available(&pipeNum)) {
     if(pipeNum == 1){
     sensoren = Counter(sensoren);
      GetTemp();
    }}
   if (radio.available(&pipeNum)){  
    if (pipeNum == 2)
    {
      sensoren = Counter(sensoren);
      GetTemp2();
    }
  }

GetTemp() code (GetTemp2() is exact hetzelfde)
cpp code

void GetTemp() {
  // ------------------ temp sensor binnen -----------------------
  sensors.requestTemperatures();
  waardes[sensoren] = sensors.getTempCByIndex(0);
}

De sensoren zijn juist gedefinieerd en de waardes zijn ook juist en worden juist weergegeven.. alleen niet altijd beide terwijl dat wel moet
de counter met sensoren werkt wel en is volgens mij niet de reden dat er een vertraging in zit.

omdat de bovenstaande code heel raar is (en ik me daar van bewust ben) heb ik ook deze geprobeerd maar er zat geen verschil in..

cpp code

if (radio.available(&pipeNum)) {
     if(pipeNum == 1){
     sensoren = Counter(sensoren);
      GetTemp();
    }
    if(pipeNum == 2){
   sensoren = Counter(sensoren);
   GetTemp2();

[tim- Profiel Privébericht]

Ik ben nog eens verder gaan lezen.. en kwam er achter dat ik totaal in de verkeerde richting aan het zoeken was.. Ik heb wat tutorials op youtube bekeken en kwam er zo achter dat ik mijn lcd scherm niet op de juiste manier had gecodeerd en iedere keer het hele scherm opnieuw aan het vullen was

(vond het al raar dat het op die manier ging.. maar dat is nou eenmaal het nadeel van open source en het net beginnen met het programmeren van micro controllers) De rare vertragingen zijn in ieder geval voor nu weg.. nu even zien of ook de sensoren sneller herkend worden en weergegeven worden op de juiste manier.

mochten er nog aanvullende tips zijn die zijn natuurlijk altijd welkom!

[tim- Profiel Privébericht]

Dit was dus niet de reden waarom mijn sensoren "gemist" worden..

Heb bij beide tx codes een retry er op van 15,15:
cpp code

radio.setRetries(15, 15);

Verder kan ik me alleen bedenken om iets van een ping in de code te zetten.. dus eerste vragen of er iets gestuurd mag worden dan wachten op reactie en dan pas de data versturen.. Dit houd echter wel in dat het scherm ook tussendoor de hele tijd aangepast word. van 1 regel tekst weer naar 2 regels tekst omdat er dan altijd 1 pipe niet beschikbaar is. Ik wil / kan (voor verdere ideeën... als ik daar ooit aan toe kom) geen vaste waarde mee geven maar wil echt het aantal sensoren tellen. of weten dat ze aanwezig zijn. Denk ik hier in de goede richting of zit ik al weer helemaal de verkeerde kant op te denken??

en als het met ping kan moet ik dan die example sketch gaan bekijken om een idee te krijgen hoe ik dat het best kan gaan doen? of is dat puur kijken of er verbinding gemaakt kan worden en doet dat verder niks?

[nicoverduin Profiel PrivéberichtWebsite]

Tja
En dus gaat "Verduin weer zeiken...."
a) Op pagina 3 is al eens de tip gegeven door ondergetekende om de besturing in de master (of server of hoe je het wil noemen) te leggen. Die roept elke client aan voor de data En wacht op antwoord of een timeout
b) Wat ik al meerdere malen bij ander TS'ers (eigenlijk in de meeste gevallen een waste of time) heb aangegeven. Ga nu eerst je requirements (= gewoon specificaties) uitwerken op papier (inderdaad niet groen maar wel goed om je gedachten te ordenen). Papier is niet zo duur (2.75 bij de Action voor 500 vel zei Shooter paar jaar geleden) maar dwingt tot nadenken.
c) Als je een dialoog ga maken tussen de clients en de server werk deze eerst uit. Dus eerst nadenken.... en dan doen.... Trial & Error gaat je vanzelf opbreken

[tim- Profiel Privébericht]

Oke dan is het misschien toch wel beter om de optie van pagina 3 te proberen

Heb je misschien forums/ tutorials waar ik op kan kijken als ik ergens tegen aan loop? voor ik mijn vraag hier stel kan ik dat doorlezen kijken of dat evt mijn probleem al oplost.

[nicoverduin Profiel PrivéberichtWebsite]

Heel theoretisch (je moet dus in concepten gaan denken): UML en dan specifiek Sequence diagram. Overigens zijn dit niet van die ff doorlezen onderwerpen....