Harry Fast Geschrieben March 12, 2019 at 08:44 Geschrieben March 12, 2019 at 08:44 Hallo, ich bin gerade dabei das Accelerometer 2.0 in Betrieb zu nehmen. Dabei habe ich festgestellt, dass nach Anpassung der Auflösung (16 Bit) und der Skalierung (z.B. 8g) die Berechnung des g-Wertes (1/10000 aus der Beschreibung) nicht mehr gilt. Ich habe eine Ahnung woran es liegen könnte würde mich aber über einen Hinweis zur richtigen Berechnung freuen. Eine entsprechende Ergänzung in der Beschreibung zum Bricklet halte ich ebenfalls für sinnvoll. Zitieren
borg Geschrieben March 12, 2019 at 09:01 Geschrieben March 12, 2019 at 09:01 Wenn du die Auflösung von 16bit auf 8bit umstellst, bekommst du in der tat die Einheit 256/10000g anstatt 1/10000g zurück (die 8 niedrigsten Bits werden einfach abgeschnitten). Das ist nicht hinreichend gut dokumentiert, kümmere ich mich drum! Die Skalierung und Datenrate solltest du allerdings ändern können ohne das sich die Einheit ändert. Edit: Hier sind die Änderungen die ich an der Doku vorgenommen hab um das klarer zu machen: https://github.com/Tinkerforge/generators/commit/fcd32651d873a40a16322866ef3515a45415f7ab Zitieren
Harry Fast Geschrieben June 12, 2019 at 07:35 Autor Geschrieben June 12, 2019 at 07:35 Hallo, Leider muss ich die Fragestellung nochmal aufgreifen. Wenn ich die Sensordaten via Python API auslese bekomme ich Werte welche (mit der beschriebenen Einheit) nicht der Erwartungshaltung entsprechen. Wenn ich z.B. nur die Erdbeschleunigung Messe bekomme ich einen Wert von ca. 17000 (Konfiguration: 16 Bit-Auflösung und 2g Messbereich) das wäre dann nach der angegebenen Berechnung 1,7g. Zu erwarten ist aber 1g. Wenn ich den Sensor via BrickViewer betreibe wird der Wert um 1,03g angezeigt. Die Berechnung geht also nicht auf. Zitieren
borg Geschrieben June 12, 2019 at 08:18 Geschrieben June 12, 2019 at 08:18 Den Brick Viewer Code kannst du dir hier ansehen: https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/accelerometer_v2/accelerometer_v2.py#L134 Wir teilen dort auch nur durch 10000. Zitieren
Harry Fast Geschrieben June 12, 2019 at 11:37 Autor Geschrieben June 12, 2019 at 11:37 Wenn ich folgenden Code verwende: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "HBp" # Change XYZ to the UID of your Accelerometer Bricklet 2.0 data_rate = 13 full_scale = 0 enable_x = True enable_y = True enable_z = True resolution = 1 from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_accelerometer_v2 import BrickletAccelerometerV2 # Callback function for acceleration callback def cb_acceleration(RawSensorData): print(RawSensorData) #print("Acceleration [X]: " + str(x/10000.0) + " g") #print("Acceleration [Y]: " + str(y/10000.0) + " g") #print("Acceleration [Z]: " + str(z/10000.0) + " g") #print("") if __name__ == "__main__": ipcon = IPConnection() # Create IP connection a = BrickletAccelerometerV2(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected a.set_configuration(data_rate, full_scale) a.set_continuous_acceleration_configuration(enable_x, enable_y, enable_z, resolution) # Register acceleration callback to function cb_acceleration a.register_callback(a.CALLBACK_CONTINUOUS_ACCELERATION_16_BIT, cb_acceleration) input("Press key to exit\n") # Use input() in Python 3 ipcon.disconnect() ---------------------------------------------------------------------------- Werden folgende Messwerte ausgegeben: (-48, 764, 17064, 24, 698, 17034, 211, 718, 17071, 265, 761, 17123, 256, 833, 17078, 252, 832, 17041, 79, 798, 17006, 15, 782, 16870, 88, 791, 16841, 139, 864, 16964) (78, 795, 17021, 15, 781, 16963, 70, 842, 16952, 63, 871, 16965, -43, 884, 17022, 44, 805, 17048, 203, 751, 17078, 108, 743, 17177, 12, 671, 17121, 86, 688, 17061) Muss ich bei den Einstellungen noch etwas spezielles beachten? Zitieren
borg Geschrieben June 12, 2019 at 12:28 Geschrieben June 12, 2019 at 12:28 Oh, ich hab mir gerade den Code angeschaut und du hast absolut recht. Die Continuous Callbacks geben den rohen ADC-Wert zurück der Abhängig von anderen Einstellungen ist, während der Getter (den der Brick Viewer nutzt) g/10000 zurück gibt. Unsere Dokumentation ist an der Stelle fehlerhaft. Ich fixe das in der Doku und melde mich dann nochmal wenn ich es fertig hab. Zitieren
borg Geschrieben June 12, 2019 at 15:34 Geschrieben June 12, 2019 at 15:34 Du kannst in deinem Fall die Werte mit der Folgenden Formel umrechnen:Beschleunigung = Rohwert*625/1024 Damit kommst du dann wieder auf die g/10000 Einheit die auch von get_acceleration() zurückgegeben wird. Das ist jetzt in der API Doku auch entsprechend erklärt und dokumentiert: https://www.tinkerforge.com/de/doc/Software/Bricklets/AccelerometerV2_Bricklet_Python.html#BrickletAccelerometerV2.set_continuous_acceleration_configuration Vielen Dank für den Hinweis, da hat jemand zwischen Programmierung und Dokumentation die Hälfte vergessen und dadurch nicht richtig dokumentiert. Zitieren
Harry Fast Geschrieben June 27, 2019 at 08:19 Autor Geschrieben June 27, 2019 at 08:19 Vielen dank für die schnelle Rückmeldung. Eine weitere Frage habe ich noch. In der Dokumentation wurde noch ein Text hinzugefügt. Da wird empfohlen, dass man für eine FFT die AD-Wandler-Werte nehmen sollte. Leider habe ich noch nicht ganz verstanden warum das empfohlen wird. Könnten sie mir dazu vielleicht eine kurze Rückmeldung geben? Vielen Dank. Zitieren
borg Geschrieben June 27, 2019 at 08:54 Geschrieben June 27, 2019 at 08:54 Wenn ich folgende Formel verwende: Beschleunigung = Rohwert*625/1024 und die Beschleunigung als Integer betrachte werfe ich ~1 Bit an Auflösung weg. Dies ist egal wenn ich die Beschleunigung selbst betrachte, da bei den hohen Frequenzen sowieso sehr viel Rauschen auf den Daten ist mit denen ich nichts anfangen kann wenn ich als Mensch die Daten betrachte. Wenn ich einen FFT auf den Daten anwende, können sich im "Rauschen" aber auf einmal doch noch Informationen zu irgendwelchen Frequenzen verstecken die eventuell interessant sind. Zitieren
Harry Fast Geschrieben June 27, 2019 at 11:12 Autor Geschrieben June 27, 2019 at 11:12 Okay das leuchtet ein. Da ich die Daten aber als Gleitkommazahl ablege sollte das dann keinen Unterschied machen. Danke für die Rückmeldung! Zitieren
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.