Hallo Zusammen,

kann jemand sagen warum folgender Code kein Temperaturwert für die Kerntemperatur des IMU 2.0 Bricks zurück gibt?

#!/usr/bin/env python
# -*- coding: utf-8 -*-

HOST = "localhost"
PORT = 4223

UID = "6rGa5o"

import time

from tinkerforge.ip_connection import IPConnection
from tinkerforge.brick_imu_v2 import BrickIMUV2

Liste = ["X","X","X","X","X","X"]

def cb_quaternion(w, x, y, z):
    Liste[1] = (w/16383.0)
    Liste[2] = (x/16383.0)
    Liste[3] = (y/16383.0)
    Liste[4] = (z/16383.0)

def cb_temperature(temperature):
    Liste[5] = temperature

def main():
    ipcon = IPConnection()
    imu = BrickIMUV2(UID, ipcon)
    
    ipcon.connect(HOST, PORT)
    
    imu.register_callback(imu.CALLBACK_QUATERNION, cb_quaternion)
    imu.register_callback(imu.CALLBACK_TEMPERATURE, cb_temperature)
    
    imu.set_quaternion_period(100)
    imu.set_temperature_period(100)
    
    time.sleep(1)
    
    i = 0
    while i < 20:
        
        Liste[0] = i
        
        print("Übersicht Werte in Liste:")
        print("Wert 1:" + str(Liste[0]))
        print("Wert 2:" + str(Liste[1]))
        print("Wert 3:" + str(Liste[2]))
        print("Wert 4:" + str(Liste[3]))
        print("Wert 5:" + str(Liste[4]))
        print("Wert 6:" + str(Liste[5]))
        print("")
        i = i+1
        time.sleep(0.5)
        
    ipcon.disconnect()
    
if __name__ == "__main__":
    main()

Benutze ich cb_all_data wie in den Beispielen gezeigt, kommt der Temperaturwert mit. Möchte ich ihn einzeln haben, so wie hier in meinem Beispiel, bekomme ich ihn nicht aufgerufen.

Vielleicht hat jemand ne Idee, woran das liegen könnte?!

 

Hintergrund ist, das mein IMU regelmäßig aussteigt, und ich die Vermutung habe, dass ihm ein bisschen zu warm ums Herz ist 😉

 

Das führt mich zu einer weiteren Frage:

Gefühlt gibt es ein Performance-Unterschied zwischen:

• Alle Werte per Callback erheben, diejenigen die ich benötige loggen

zu:

• Nur diejenigen per Callback erheben und loggen, die ich benötige

 

liege ich da richtig? Und wenn ja, was sind so die gängigen Tricks und Kniffe, um ein möglichst hochfrequentes Loggen von spezifischen Werten zu realisieren ?

 

Vielen Dank an alle Tinkerforger da draussen :)

Grüße Tipsy

bearbeitet March 22, 2021 at 16:0222. Mär 2021 von Tipsy Tinker
typo

16 hours ago, Tipsy Tinker said:

Benutze ich cb_all_data wie in den Beispielen gezeigt, kommt der Temperaturwert mit. Möchte ich ihn einzeln haben, so wie hier in meinem Beispiel, bekomme ich ihn nicht aufgerufen.

Vielleicht hat jemand ne Idee, woran das liegen könnte?!

Das war ein Firmware-Bug, mit der frisch veröffentlichten 2.0.15 geht es bei mir. Hintergrund war, dass die Größe des Antwortpakets zu groß war (copy-paste-Fehler, es hat die Größe des AngularVelocityCallbacks benutzt). Die Bindings prüfen die Länge von Callback-Paketen und ignorieren zu kurze und zu lange Pakete, deshalb kam bei dir nichts an.

16 hours ago, Tipsy Tinker said:

Gefühlt gibt es ein Performance-Unterschied zwischen:

• Alle Werte per Callback erheben, diejenigen die ich benötige loggen

zu:

• Nur diejenigen per Callback erheben und loggen, die ich benötige

 

liege ich da richtig? Und wenn ja, was sind so die gängigen Tricks und Kniffe, um ein möglichst hochfrequentes Loggen von spezifischen Werten zu realisieren ?

Da gibt es tatsächlich Unterschiede: Die Bricks und Bricklets laufen mit einer Tickrate von 1 kHz. Pro Tick kann nur ein Paket erzeugt werden. Wenn du also Werte aus zwei Callbacks brauchst, kannst du jeden Wert nur noch mit 500 Hz auslesen. Aus Brick-Kommunikationssicht ist es also tatsächlich sinnvoller, das AllData-Callback zu benutzen und die Werte wegzuwerfen, die du nicht brauchst. Wenn du über ein Netzwerk gehst kann das natürlich anders aussehen, aber wir reden hier immer noch von sehr kleinen Datenmengen (z.b. beim AllData-Callback 54 kB/s).

Ok, scheint soweit geklappt zu haben 🙂

Selten lagen Verwunderung und Firmware-Update so nah beieinander *gg*

 

Vielen Dank auch für Deine Ausführungen zu den Ticks.

 

Gruß Tipsy