borg

Wir haben aktuell keine offenen Probleme die wir reproduzieren können. Das letzte Problem was wir reproduzieren konnten war das USB/EMV Problem welches zu neustarts führen konnte. Das wurde in 2.4.6 gefixt, da hatten wir aber auch etwas an I2C geändert. Deswegen dachte ich du könntest einmal mit der älteren Version testen. Aber wenn du das Problem schon so lange hast kann es daran ja gar nicht liegen.

Kannst du mal einmal mit Master Brick Firmware Version 2.4.5 testen? http://download.tinkerforge.com/firmwares/bricks/master/ Das ist die letzte Version bei der wir die I2C-Kommunikation noch nicht auf DMA umgestellt haben (Temperature und Temperature IR Bricklet nutzen beide I2C).

Welche Firmware-Versionen haben die Bricks/Bricklets?

Ich befürchte das ist nicht möglich. Der Prozessor den wir verwenden läuft mit 32MHz, wir sprechen mit dem Lepton mit 8MHz. D.h wir haben 4 Prozessortakte pro Bit an Daten zur Verfügung. Damit müssen wir das Protokoll mit dem Lepton sprechen, die Daten Zwischenspeichern, API-Aufrufe abarbeiten, das Protokoll mit dem Brick sprechen und I2C mit dem Lepton zur Konfiguration, etc.

Bezüglich der CPU Last: Wir haben das gerade nochmal diskutiert und uns die Tests angeguckt die wir gemacht haben etc. Wir sehen da zwei Dinge: 1. Der RED Brick mit 1.10 Image nutzt jetzt den Linux CPU frequency scaling governor. D.h. per Default wird die Frequenz runtergetaktet und nur erhöht bei hoher Last. Dadurch zieht der RED Brick weniger Strom und bleibt kälter. Allerdings sieht die CPU Last dadurch höher aus (höhere Auslastung bei niedrigerer Frequenz). 2. Wir haben mit 1.10 auf den aktuellen neuesten Linux Mainline Kernel gewechselt. Für unsere Anwendungszwecke ist der SPI Treiber dort leider erheblich ineffizienter geworden. Das liegt soweit wir das verstehen hauptsächlich daran das die Treiber in der Zwischenzeit mehr auf Multiprozessor-Systeme ausgelegt sind, welches wir bei dem RED Brick leider nicht haben. Wir haben dort schon angesetzt und das für unseren Use Case verbessert. Hier sind die ganzen Änderungen die wir im Linux SPI Treiber gemacht haben: https://github.com/Tinkerforge/red-brick-linux/commit/2082ee9458d1bd553fb2c1b933162b3beabc8332 Nichtsdestotrotz, wenn wir das 1.9er Image mit dem 1.10er Image per Stress-Test vergleichen können wir sehen dass das 1.9er Image in der Tat immernoch performanter ist. Wir arbeiten aber noch daran, man kann mit bei sowas leider sehr viel Zeit versenken .

Welche Firmware Version hat das NFC/RFID Bricklet? In Version 2.0.1 gab es folgenden Fix:

Du solltest den brickd eigentlich nie neustarten müssen, da ist irgendetwas faul. Funktioniert es wenn du nur einen Master Brick verwendest (oder den anderen)? Funktioniert es ohne die Bricklets? Also die Frage ist: Was ist der kleinste Aufbau mit dem du das Problem noch erzeugen kannst?

Die Leiterplatten sind schon länger bestellt und sollten in den nächsten Tagen eintreffen. Die Bestückung startet entsprechend wahrscheinlich noch im Januar. Also Mitte/Ende Februar halte ich für realistisch. Dokumentation, Beispiele und Co für das neue Bricklet sind bereits so gut wie fertig, an der Stelle sollte es also keine Verzögerung geben.

Was für eine Funksteckdose verwendest du? Und über USB funktioniert es wirklich immer oder auch nur zeitweise?

Hab das gerade doch schon getestet . Ich habe hier jetzt einen Master Brick (FW 2.4.7) + Remote Switch Bricklet (FW 2.0.1) + Ethernet Extension mit PoE. Versorgt per USB-Netzteil, nicht über PoE. Ich kann sowohl über USB (localhost) als auch über Ethernet (IP von Ethernet Extension) mit dem Brick Viewer eine Steckdose vom Typ A schalten .

Muss ich morgen ausprobieren ob ich das reproduzieren kann. So richtig kann ich mir das gar nicht vorstellen, das Remote Switch Bricklet kann nicht zwischen Paketen die über USB kommen und welchen die über Ethernet kommen unterscheiden. Prinzipiell ist die Verbindung ja da so wie ich das verstehe, sonst würde das Bricklet im Brick Viewer ja gar nicht erst auftauchen.

Hast du in deinem Programm die IP von "localhost" auf die IP der Ethernet Extension geändert?

Klingt sinnvoll, schreibe ich mir auf die TODO-Liste . Komme ich aber erst frühestens nächste Woche zu.

Das wieder anstellen funktioniert bei mir auch. Je nachdem wo sich die Extension gerade befindet beim Verbindungsaufbau etc kann es allerdings ein wenig dauern bis die LED angeht.

Firmwares: DC Brick 2.3.6, IMU Brick 2.3.6, IMU 2.0 Brick 2.0.11, Master Brick 2.4.7, Servo Brick 2.3.6, Silent Stepper Brick 2.0.5, Stepper Brick 2.3.7 Fix für Nachrichtenduplizierungs-Bug Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Firmwares: DC Brick 2.3.6, IMU Brick 2.3.6, IMU 2.0 Brick 2.0.11, Master Brick 2.4.7, Servo Brick 2.3.6, Silent Stepper Brick 2.0.5, Stepper Brick 2.3.7 Fix message duplication bug Download: DC Brick, IMU Brick, IMU 2.0 Brick, Master Brick, Servo Brick, Silent Stepper Brick, Stepper Brick

Die API funktioniert bei mir, getestet mit import com.tinkerforge.IPConnection; import com.tinkerforge.BrickMaster; public class ExampleStackStatus { private static final String HOST = "localhost"; private static final int PORT = 4223; private static final String UID = "68z3jd"; // <------ CHANGE TO YOUR UID public static void main(String args[]) throws Exception { IPConnection ipcon = new IPConnection(); BrickMaster master = new BrickMaster(UID, ipcon); ipcon.connect(HOST, PORT); master.disableWifi2StatusLED(); ipcon.disconnect(); } }

Die API sollte natürlich funktionieren, muss ich gleich ausprobieren. Bei der letzten Bestückung ist die LED in der Tat sehr hell ausgefallen, obwohl wir soweit ich das verstehe weder LED noch Vorwiderstand gewechselt haben und wir betreiben die LEDs bereit unterhalb des spezifizierten Stroms damit sie nicht so hell ist .

Ich meinte die "set_sensor_fusion_mode" Funktion. Damit kann man einen Fusion-Modus ohne Magnetometer auswählen, dann kann es nicht mehr zu Drift auf Grund von Magnetfeldern kommen. Allerdings kann die IMU dann keine absoluten Werte mehr zurück geben sondern nur noch Veränderungen (ob das für eure Anwendung OK ist weiß ich nicht). Dass das drei Vergleichswerte sind hab ich mir schon gedacht. Bei ~1200 Sekunden sieht es so aus als würden die IMU Brick Daten zurückspringen auf die anderen Daten. Die Frage ist warum das passiert dort?

Ein Drift kommt oft Zustande wenn sich Magnetfelder in der Umgebung ändern. Welchen "Sensor Fusion Mode" verwendet ihr? Gibt es irgendein spezielles Event bei ~1200 Sekunden welches dazu geführt hat das der Wert zurückspringt?

Um per UART zu flashen ist das nicht passend angeschlossen. Macht auch keinen Sinn, dann könnte man per WIFI flashen, aber nicht per Ethernet. Das versteht dann am ende des Tages niemand mehr was da funktioniert und was nicht . Die Vorgehensweise wäre denke ich in der Tat "einfach" über unser normales Protokoll zu flashen, wie wir es auch bei den neuen Bricklets machen. Die einfachste Möglichkeit das zu implementieren ist sicherlich 50% des Flashes nur zum flashen zu nutzen (um dort Zwischenspeichern zu können). Ein unveränderlicher Bootloader der aber trotzdem Ethernet/WIFI/RS485 sprechen kann (damit auch auch darüber flashen kann) ist leider sehr viel Aufwand. 50% flash haben wir leider nicht frei bei allen Bricks. Blöd ist es auch wenn man dann doch einmal etwas am Ethernet/WIFI/USB Code ändern muss. Dann muss man auf einmal doch wieder über den Atmel-Bootloader flashen. Das macht es dann natürlich komplizierter .

Konnte das gerade doch kurz testen und bei mir funktioniert alles so wie es soll. Habe den Brick Viewer gestartet und dann folgendes ausgeführt: #!/usr/bin/env python # -*- coding: utf-8 -*- HOST = "localhost" PORT = 4223 UID = "D1H" # Change XYZ to the UID of your Thermal Imaging Bricklet from tinkerforge.ip_connection import IPConnection from tinkerforge.bricklet_thermal_imaging import BrickletThermalImaging # Callback function for high contrast image callback def cb_high_contrast_image(image): print("cb") if __name__ == "__main__": ipcon = IPConnection() # Create IP connection ti = BrickletThermalImaging(UID, ipcon) # Create device object ipcon.connect(HOST, PORT) # Connect to brickd # Don't use device before ipcon is connected # Register high contrast image callback to function cb_high_contrast_image ti.register_callback(ti.CALLBACK_HIGH_CONTRAST_IMAGE, cb_high_contrast_image) # Enable high contrast image transfer for callback ti.set_image_transfer_config(ti.IMAGE_TRANSFER_MANUAL_HIGH_CONTRAST_IMAGE) raw_input("Press key to exit\n") # Use input() in Python 3 ipcon.disconnect() Der Brick Viewer nutzt das High Contrast Image im Callback-Modus. Wenn ich die "set_image_transfer_config"-Funktion auskomentiere und das Skript ausführe läuft im Brick Viewer alles weiter und ich bekomme "cb" Prints über den Callback (welcher vom Brick Viewer gestartet wurde). Wenn ich die Funktion drin lasse und dadurch die Config auf "manual" umstelle bleibt das Bild im Brick Viewer stehen und ich bekomme auch keine Prints. Die LED hört auch auf zu blinken.

Ja gehört es. Du verwendest auch RS485? Dann ist das Update wahrscheinlich wirklich der Grund für die Verbesserung .

Das Flashen der Bricks läuft über den internen USB Bootloader (der ist in Hardware) der SAM3S/SAM4S Prozessoren. Das hat den großen Vorteil das man Bricks nicht komplett "bricken" kann, da man über den Erase-Knopf immer in den USB-Bootloader kommt. Das funktioniert auch noch wenn ich ausversehen eine mp3-Datei anstatt einer Firmware flashe . Hat aber den Nachteil das wir da nichts dran ändern können. D.h. das Flashen geht nur über USB wenn der Brick im Bootloader-Modus ist.

Huch? Das muss ich testen, du solltest keine Callbacks mehr bekommen wenn du auf "manual" umstellst. Komme ich aber frühestens Montag zu.