borg

Grob kannst du bei jedem Getter mit 2ms und bei jedem Setter mit 1ms Laufzeit rechnen. Du hast in deiner Schleife 4 getter und 8 Setter. Das entspricht also 16ms pro Schleifendurchgang, ich würde in dem Programm also in etwa mit einem Durchsatz von maximal 1000/16 = 62 Beschleunigungsdaten pro Sekunde rechnen. Ich würde versuchen das so umzustellen das du deine Aufzeichnung der Daten per Callback machst (z.B. für 500ms), diese speicherst und danach darstellst. Nach dem darstellen wieder die nächste Aufzeichnung starten etc.

Es gibt hier denke ich kein Hardwareseitiges Problem. Als ersten Schritt sollten wir erstmal in deinem Programm die vollen 1000Hz erreichen. Wenn du nur Master Brick + Accelerometer Bricklet anschließt und in deinem Programm einfach nur die Daten loggst (oder sogar nur zählst erstmal), dann solltest du auf jeden Fall auf 1000Hz kommen. Wenn das funktioniert müssen wir von da aus schauen wie wir den Rest der Hardware einbinden. Dabei ist wichtig: 1000 Nachrichten pro Sekunde sind die maximale Anzahl an Nachrichten die über einen USB-Anschluss laufen können bei uns im System. Wenn du z.B. einen Getter verwendest wird eine Anfrage zum Bricklet geschickt und eine Antwort wieder zurück. Das sind dann bereits zwei Nachrichten. D.h. Callbacks sind in deiner Anwendung definitiv notwendig (die erzeugen nur eine Nachricht, da es die Anfrage nicht gibt). Wenn du mehrere Bricklets verwendest teilen sich diese die Anzahl der Nachrichten. Wenn du also die 1000 Nachrichten/Sekunde von dem Accelerometer Bricklet benötigst, wirst du einen Stapel benötigen der nur aus Master + Accelerometer besteht und einen weiteren für die restlichen Module. Alternativ wenn die Aufzeichnung "schubweise" stattfinden soll kann man es auch so bauen das die anderen Bricklets nicht angesprochen werden während die Aufzeichnung läuft. Wie soll dein Aufbau später aussehen? Standalone irgendwo in einer kleinen Box oder ist er immer am PC angeschlossen?

Hattest du denn vor ein eigenes Programm zu schreiben oder nur den Logger zu nutzen? Mein Beispiel oben wäre ja bereits ein guter Einstieg. Es erhebt die Daten bereits mit den vollen 1000Hz, es fehlt nur das schreiben in eine Datei.

Die RS485 Extension ist zum verbinden von mehreren Stapeln, die benötigst du hier nicht. Du kannst deinen Stapel bauen aus (von unten nach oben): Step-Down Power Supply + Master Brick 2.1 + WIFI Extensin 2.0. Das Thermal Imaging Bricklet wird am Master Brick angeschlossen. Für die initiale Konfiguration des WLANs kannst du den Stapel per USB mit dem PC verbinden. Danach kannst du die Stromversorgung über die Step-Down Power Supply machen und über das WLAN auf den Stapel zugreifen. Der Master Brick bleibt dabei die ganze Zeit im Stapel.

Also prinzipiell schafft das Bricklet die vollen 1000 Nachrichten pro Sekunde, gerade mit folgendem Python-Skript getestet: #!/usr/bin/env python # -*- coding: utf-8 -*- import time HOST = "localhost" PORT = 4223 UID = "3cnLyG" # Change to the UID of your Accelerometer Bricklet from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_accelerometer import BrickletAccelerometer count = 0 def cb_acceleration(x, y, z): global count count += 1 if __name__ == "__main__": ipcon = IPConnection() a = BrickletAccelerometer(UID, ipcon) ipcon.connect(HOST, PORT) a.set_configuration(a.DATA_RATE_1600HZ, a.FULL_SCALE_8G, a.FILTER_BANDWIDTH_800HZ) a.register_callback(a.CALLBACK_ACCELERATION, cb_acceleration) a.set_acceleration_callback_period(1) while True: time.sleep(1) print('{0} messages per second'.format(count)) count = 0 raw_input("Press key to exit\n") # Use input() in Python 3 ipcon.disconnect() Ausgabe: Wenn ich das bei mir auf dem PC mit dem Logger im Brick Viewer versuche, kommt dieser mit dem Loggen nicht hinterher und die Daten fangen an sich aufzustauen. Vielleicht passiert das auch bei dir? Der Logger ist leider nicht wirklich darauf ausgelegt riesige Datenmengen zu loggen.

Die WIFI Extension 2.0 basiert auf einem komplett anderen WIFI-Modul, daher lassen sich die beiden kaum vergleichen. Da wir die V1 jetzt bereits seit über 2 Jahren ersetzt haben wollen wir dort eigentlich keine großen Software-Änderungen mehr vornehmen. Wir würden dir aber eine neue WIFI Extension 2.0 als Ersatz schicken, bitte bei info@tinkerforge.com melden diesbezüglich. Da kann ich mir nicht so recht vorstellen wie das zustande kommen kann, bitte wenn möglich einmal im Brick Viewer überprüfen ob es dort auch die Probleme mit der Temperatur gibt.

Seltsam. Du schreibst in dem anderen Thread das du dort eine Ethernet Extension hast die durchgängig läuft, was ist wenn du die beiden Ethernet Extensions austauschst? Verschiebt sich das Problem dann zum anderen Projekt oder bleibt es beim gleichen?

Die hohen Sprünge im 2 Sekunden-Takt liegen am verwendeten RED Brick Image. Dort gab es einen Kernel-Prozess der alle 2 Sekunden viel CPU-Zeit geklaut hat. Im neuesten Image (1.13) ist das gefixt. Könntest du zum testen einfach einmal den Master Brick direkt per USB am PC anschließen? Wie verhält es sich dann mit dem delta-t?

Unfortunately the blue LED of the WIFI Extension 2.0 is directly connected to the 3.3V rail and can not be controlled through software.

Das ist sehr seltsam. Hab gerade in den Source Code geschaut, die Temperatur wird immer gleichzeitig mit dem Luftdruck mit einem I2C-Read aktualisiert. Wenn die Temperatur einfriert, hast du bereits versucht dich in diesem Zustand mit dem Brick Viewer auf dem Stapel zu verbinden? Wird dort die Temperatur noch korrekt angezeigt?

Sind die Firmwares alle aktuell?

Ist die Master Brick Firmware bei dem zweiten Stapel aktuell? Wir hatten vor nicht allzu langer Zeit noch Bugfixes für die Ethernet Extension in der Master Brick Firmware.

Hab gerade bereits eine Antwort bekommen, ich zitiere die hier einfach mal: Wenn ich das richtig verstehe lässt also die Leuchtkraft der Pixel über Zeit nach wenn sie verwendet werden. OLED_Lifetime.pdf

Das war mir um ehrlich zu sein nicht bewusst, dass sich unser OLED so einbrennen kann . Ich frag mal beim Hersteller nach was die dazu sagen. Interessant wäre auch noch ob es wirklich eingebrannt ist oder eine Art Memory-Effekt. Bei zweiterem sollte es helfen das OLED einfach für ein paar Stunden aus zu schalten.

Das muss ich mir anschauen, ich vermute das die Begrenzung einfach ausversehen per Copy+Paste aus dem LED Strip V1 mit übernommen wurde.

Sind die Firmwares und das RED Brick Image etc alle auf dem aktuellen Stand?

Wir haben bereits ein paar Bugs gefunden in der neuen LCD API und gefixt: Firmware: LCD 128x64 Bricklet 2.0.3 + 2.0.4 + 2.0.5 Fix off-by-one in GUI graph height calcultion Fix bug in GUI remove functions Fix wrong initialization of touch LED Make sure display is updated on GUI remove-event Download: LCD 128x64 Bricklet 2.0.5

Some bugs were already found and fixed in the new LCD API: Firmware: LCD 128x64 Bricklet 2.0.3 + 2.0.4 + 2.0.5 Fix off-by-one in GUI graph height calcultion Fix bug in GUI remove functions Fix wrong initialization of touch LED Make sure display is updated on GUI remove-event Download: LCD 128x64 Bricklet 2.0.5

Mhhh, vielleicht ein Problem mit der USB-Hotplug-Erkennung? Taucht etwas auf wenn du zuerst den Brick per USB ansteckst und dann den Brick Daemon startest?

Grafische Benutzeroberfläche für LCD 128x64 Bricklet Blogeintrag

Graphical User Interface for LCD 128x64 Blog entry

Firmware: LCD 128x64 Bricklet 2.0.2 Fix backlight PWM (value of zero is now completely off) Use CIE 1931 lookup-table for backlight intensity correction Fix Status/Touch LED mixup Add Set/GetTouchLEDConfig API Add API for simple GUI elements with touch support Download: LCD 128x64 Bricklet 2.0.2

Firmware: LCD 128x64 Bricklet 2.0.2 Fix backlight PWM (value of zero is now completely off) Use CIE 1931 lookup-table for backlight intensity correction Fix Status/Touch LED mixup Add Set/GetTouchLEDConfig API Add API for simple GUI elements with touch support Download: LCD 128x64 Bricklet 2.0.2

Der Callback wird in der Periode ausgelöst weil sich innerhalb der Periode etwas am Wert ändert (die Position verschiebt sich leicht oder der Druck ist ein wenig anders, etc). Der Parameter ist mehr oder weniger da weil wir ihn bei jedem Callback haben. Ähnlich ist das z.B. beim Accelerometer Bricklet: Auf den Beschleunigungsdaten ist fast immer ein wenig rauschen, also wirst du auch fast immer den Callback mit der angegebenen Periode bekommen.

Did you check the UID? Maybe you are using the UID of a wrong Bricklet, that could explain the exception here.