RF24... radio.write() in einer Schleife?

  • Hallo,

    ich nutze folgenden Code in meinem Pi... die Funktion rf24_Send läuft sozusagen in einer Schleifen...
    ich empfange per TCP von Client ständig ein Array... und gebe diesen dann an diese Funktion.

    TCP ist denke ich mal nicht das Problem da er mir alles anzeigt was er empfängt...

    irgendwann bekomme ich dann diese Meldung. ich denke dass hat was mit dem Zeitabstand zu tun, zwischen 2 Sendevorgängen.

    "RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc."


    Das komische ist... auf der anderen Seite bekomme ich nach der Meldung alles weiter zugestellt.

    und die Meldung kommt dann ständig wieder, auch wenn der nichts mehr an RF zu schicken hat.


    ICH HOFFE IHR VERSTEHT MEIN PROBLEM HAHA:)

    Einmal editiert, zuletzt von mitch_m (23. Juni 2015 um 12:56)

    • Offizieller Beitrag

    Warum postet du nicht deinen ganzen code? Ich seh da keine While-Schleife. Wenn keiner antwortet liegt das meistens daran das der TE (also du) sich aus Helfersicht zu wenig Mühe gibt. Unvollständiger Code, was wurde versucht usw. du schreibst selbst

    Zitat

    ich denke dass hat was mit dem Zeitabstand zu tun, zwischen 2 Sendevorgängen.

    wie sind die Erfahrungen mit unterschiedlichen Zeitabständen und wie klein sind diese? (was uns wieder zum unvollständigen code zurückbringt)

    Der Unterschied zwischen Genie und Wahnsinn definiert sich im Erfolg.

    Einmal editiert, zuletzt von dbv (24. August 2015 um 18:58)

  • :) dann habt ihr hier etwas mehr....



    ich habe war bei rf24_Send die 100ms sleep eingebaut... aber ich merke (auch mit 1 sek.) dass der die sekunde garnciht wartet...

    kann es an dem Thread liegen? dass der den rf24_Send immer wieder neu aufruft?

  • Hi,
    Du rufst in einer Endlosschleife dauernd einen threadcreate() auf und wunderst Dich, dass der losläuft und der sleep nicht greift?
    Ich glaube, da solltest Du Dir mal ein paar Basics zum Thema pthreads in C aneignen.
    Andererseits frage ich mich, ob hier multithreading überhaupt nötig ist ...
    Das ganze Konstrukt wirkt auf mich jedenfalls weder besonders durchdacht noch robust. Allein diese TCP-Geschichte ... ist ja irre, was Du dem RPi da zumutest. Das geht komplett an dem vorbei, wie man eine Serverfunktionalität implementiert (schau vielleicht mal -> hier <- rein ... da ist u.a. auch ein TCP/IP Server und was mit einem nRF24L01 dabei).
    Aber heute ist es mir schon zu spät, das Gewirr auseinanderzufummeln ...

    Ich würde das mal von Grund auf neu schreiben ... und zwar mit pthreads und nicht mit dieser Krücke aus wiringPi ...

    cu,
    -ds-

  • okay danke... habe es mal ohne threading versucht... funktioniert viel besser... sogar perfekt...
    nur jetzt ist mir wieder eingefallen warum ich den thread überhaupt da eingebaut habe....
    wegen meiner rf24_receive() funktion... diese wird dann nämlich nicht mehr aufgerufen weil der auf ein tcp paket wartet

  • ich habe es mit

    Code
    struct timeval tv;
    
    
    tv.tv_sec       = 1;
    tv.tv_usec      = 0;
    setsockopt(listenfd,SOL_SOCKET,SO_RCVTIMEO,(struct timeval *)&tv,sizeof(struct timeval));

    versucht...

    aber das läuft auch irgendwie nicht:( er bleibt beim recv() hängen:(

  • habs hinbekommen:)

    mit

    Code
    save_fd = fcntl( listenfd, F_GETFL );
        save_fd |= O_NONBLOCK;
       fcntl( listenfd, F_SETFL, save_fd );

    das läuft nun soweit...

    ich schicke vom Smartphone über TCP ca. 10 Byte an meinen Server...

    dieser schickt es per RF24 weiter an meinen microcontroller....

    das funktioniert... aber.. ab und zu bekomme ich immernoch die Meldung
    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]"RF24 HARDWARE FAIL: Radio not responding, verify pin connections, wiring, etc."[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]das dauert dann ne sekunde und ich kann weiter machen....[/font]

    [font="Source Sans Pro, Tahoma, Helvetica Neue, Arial, sans-serif"]warum ist das so? ich habe schon verzögerungen von 100ms eingbaut... das kommt aber dennoch ab und zu[/font]

  • Kann ich so nicht sagen. Hatte ich noch nicht und ohne Code ist das nur Mutmaßung.
    Evtl. schaltest Du ListeningOn/Off in zu kurzen Zeitabständen oder hast in der Tat einen Wackler in Deinem Aufbau ...
    Möglicherweise schaltest Du auch das Listening ab, während der nRF24 gerade Daten empfängt bzw. empfangen will bzw. ein, während er noch sendet ...
    Da wirst Du etwas herumexperimentieren müssen, denke ich.

    cu,
    -ds-

  • so sieht meine Sendfunktion aus

    nach dem senden sprnigt der zurück ins receive()

    Code
    radio.startListening();
    //    printf("rec\n");
       while (radio.available()) {
           send_busy = 1;
           radio.read(got_RF24, 10);
           //usleep(200);
    ....
       }

    und dann wieder in meine TCP_schleife...

    über TCP bekommt der ab und zu dann diese 10 byte... das geht auch recht schnell... also man kann sagen das der ständig per TCP empfängt und das dann direkt an RF24 weitergibt...

  • Hm ... ist aus den Fragmenten jetzt auch schlecht rauszulesen, was das noch schief gehen könnte.
    Ich hab' in einem Source von mir das Handling des radio-Listening folgendermassen:

    Möglicherweise ist das die Ursache?
    Ich häng' Dir mal den kompletten Source an (Achtung: ist absolut wip!). Evtl. kannst Du ja da was rauslesen.
    Wichtig ist auch das Initialisieren mit retries usw. des Funkmoduls.

    cu,
    -ds-


  • du stops dein listening wärend des read?... wieso das?
    ...


    weil ich ja erst mal die Daten abholen will, die da sind. Evtl. muss ich ja eine Quittung zurückschicken. Erst wenn ein Datenpaket abgearbeitet ist, ist es an der Zeit weitere zu empfangen ;)
    Nur so kann ich sicherstellen, auch alle Pakete zu erwischen. Die FIFOs des Chips sind nicht unendlich ...

    cu,
    -ds-

  • Okay verstehe:).. Na bei mir ist da nicht das empfangen das Problem.. Ich empfange wenig.. Sende dafür in diesem Fall eine ziemliche masse..

    Wenn ich die retries auf (1,1) stelle.. Dann hab ich Keime Probleme mehr... Allerdings bekomme ich dan zu 80% ein fail. Beim write

Jetzt mitmachen!

Du hast noch kein Benutzerkonto auf unserer Seite? Registriere dich kostenlos und nimm an unserer Community teil!