borg

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.

You can either use the newest RED Brick image (1.13), it comes with the LCD128x64 Bindings or you can update them with the Brick Viewer.

There is nothing in the firmware that should stop it from reconnecting to a network for 3:45 hours. Does this happen in a regular interval? Like every XXX hours? Do you have any logs in your network infrastructure that show if the Extension tries to reconnect or just does nothing?

Did you use the correct UID?

Hard to say, this is definitely not a general problem. We have had WIFI Extensions running for many months without any connection drop. Do you have any more information about your setup? Are you using the WIFI Extension V1 or V2?

Die "_low_level"-Funktionen sind zur internen Nutzung in den Bindings. Du kannst die get_temperature_image-Funktion verwenden und das komplette Bild in einem Array bekommen.