Habt ihr eigentlich die Möglichkeit, die Signalempfangsstärke am Chibi irgendwie auszulesen?

Ich kämpfe hier mit Chibis in Verbindung mit Humidity Bricklets. Alle andere Bricklets sind weniger

anfällig, aber die Humidities hängen sich ganz häufig an den Chibis auf. Enumerate findet das Bricklet noch und ein get_version geht dann auch immer noch, aber ein get_humidity liefert ein Timeout bis der Stack resetet wird. Andere Bricklets (z.B. Joystick) an dem Slave-Chibi laufen weiterhin. Habe schon alles mögliche ausgetauscht (Humidity Bricklet, Master Brick, Chibi, etc.).

Und das Slave Chibi steht nur im Nachbarzimmer, sollte doch trotz kleiner Antenne eigentlich kein Problem sein, oder? Hier würde es zumindest mal helfen, wenn ich wüsste, wie die Empfangsstärke ist.

Der Master Brick hat eine get_chibi_signal_strength() Funktion.

Hatte ich übersehen, aber wird ja auch im Brickv angezeigt. Gibt es Erfahrungswerte bei welcher Stärke es grenzwertig wird?

Hilfreich wäre ein Callback in den Bindings, der darüber informiert das die Signalstärke unterschritten wird. Ähnlich zum CallbackUnderVoltage im Stepper-Brick.

Ja, das wäre gut.

 

Es zählen bei mir die No_ACK counter auf der Master-Chibi-Seite hoch, selten Overflows. Die Slave-Seite ist sauberer, deutlich weniger No_ACK.

Master (5 Sekunden Abstand, ein Wert abgefragt):

Chibi: Sig  12 dbm Freq 0 Underrun    0 CRC_error    0 No_ACK 5264 Overflow  122

Chibi: Sig  12 dbm Freq 0 Underrun    0 CRC_error    0 No_ACK 5266 Overflow  122

 

Slave:

Chibi: Sig  11 dbm Freq 0 Underrun    0 CRC_error    0 No_ACK 1770 Overflow    0

 

Bei reinen Problemen mit der Luftschnittstelle würde ich eher auch mal CRC Fehler erwarten. Was

kann das sein?

Ich gehe mal davon aus, daß beim Slave eine Power-Supply im Stack ist und der Master via USB versorgt wird. Vielleicht geht Deinem Master ab und zu des Saft aus.

Ich bin da jetzt auch nicht der Techniker, aber wenn Du noch ne Power-Supply hast, dann häng die mal in den Master-Stack und schau, ob es besser wird.

Danke für den Tipp! Hat leider nichts gebracht.

 

Konnte gerade empirisch feststellen, dass die Anzahl der NO_ACKs drastisch von

der Anzahl der sich im Stack befindlichen Elemente abhängt. 8 Elemente

(2x Master+Chibi, 4 Master/2 Slave Bricklets) verglichen mit (1xMaster+Chibi mit 4 Bricklets und

Slave 2xMaster+Chibi mit 6 Bricklets, macht 5 Elemente mehr im zweiten Aufbau. Dieses führt bei

ansonsten gleichen Bedingungen zu 4,5 mal mehr NO_ACKs auf der Master-Seite.

Ich verzweifle langsam. Kann das auch programmiertechnische Ursachen haben? Z.B. ipcon_destroy() zu früh aufgerufen?

Sobald ich ein enumerate aufrufe, auch wenn die Callback-Funktion nichts tut, treten die Chibi

NO_ACKs auf... Was kann man tun? (C-Bindings)

Wieso rufst du denn ipcon.Destroy() auf?

Kannst ja mal versuchen das weg zu lassen und zu gucken, ob es dann geht.

(sorry hab keine Chibi deswegen nur eine Vermutung)

Ich benutze es um sauber das Programm zu beenden. Weglassen hat leider nichts gebracht.

Aber Danke für den Tipp!

Jetzt schließe ich das hier erstmal ab. Vermutlich ist es ein Softwareproblem.

So, jetzt habe ich meinen Code soweit runtergestrippt, dass er immer noch die NO_ACK Fehler hochzählt:

 

#include <stdio.h>
#include "ip_connection.h"
#include "brick_master.h"

#define HOST "localhost"
#define PORT 4223

void cb_enumerate(char *uid, char *name, uint8_t stack_id, bool is_new) {
}

int main(int argc, char **argv) {
        char *uid = argv[1];

        IPConnection ipcon;
        if(ipcon_create(&ipcon, HOST, PORT) < 0) {
                fprintf(stderr, "Could not create connection\n");
                exit(1);
        }

        usleep(50000);
        ipcon_enumerate(&ipcon, cb_enumerate);
        usleep(75000);

        Master m; 
        master_create(&m, uid); 
        if(ipcon_add_device(&ipcon, &m) < 0) {
                    fprintf(stderr, "Could not connect to Brick\n");
                    exit(1);
        }

        uint16_t ret_underrun, ret_crc_error, ret_no_ack, ret_overflow;
        master_get_chibi_error_log(&m, &ret_underrun, &ret_crc_error, &ret_no_ack, &ret_overflow);
        printf("Chibi: Underrun %4d CRC_error %4d No_ACK %4d Overflow %4d\n", ret_underrun, ret_crc_error, ret_no_ack, ret_overflow);
}

 

Kommentiert man das enumerate aus, dann gibt es keine Fehler mehr. Der Aufruf erfolgt unter Linux

aus zwei Terminal jeweils für den Slave und eins für den Master über die Schleife

while(true); do ./tinker <Master|Slave-UID> ; sleep 5 ; done

Auf dem Master zählen die NO_ACKs hoch. Hat jemand eine Idee?

Nur so ein Gedanke warum steht vor und nach dem enumerate ein usleep ?

Du schreibst der Slave steht im Nachbarzimmer... also ich hatte Empfangsprobleme wenn ne dicke Betonwand und der Durchgang nur im die Ecke war, obwohl Luftline höchstens 2m.