photron

Hast du denn das Bricklet neugeflashed?

@TF

 

Da wir nicht genau wissen woran es liegt, wuerde mich aber interessieren, ob in der Bricklet FW Informationen sind an welchem Ports die Bricklets arbeiten duerfen und an welchen nicht. Wie kamt ihr darauf diesen Rat zu geben?

Alle Bricklets funktionieren an allen Ports aller Bricks. Da gibt es keine Einschränkungen.

Da das Problem hier durch neu Flashen des IO-4 Bricklets gefixed wurde, würde ich vermuten, dass das im EEPROM des Bricklets gespeicherte Plugin eine Macke hatte. Das würde auch erklären, warum das Problem an 2 Master Bricks auftrat. Warum es dann nur am Master Brick und dann auch noch von Port und der Extension Konfiguration abhängt ist nicht klar.

Muss man damit rechnen, dass bei einer Erstinbetrebnahme einer Masterextension die FW (Bick oder Brickelt) nicht klarkommt??

 

Meine WLAN Extension habe ich seinerzeit erst erfolgreich zum laufen bekommen, als ich den Masterbrick neu geflasht habe. Das kann sicher Zufall gewesen sein.

WIFI braucht mindestens Master Firmware 1.3.0, das ist auch so dokumentiert (auch im Shop). Hattest du zu dem Zeitpunkt eine ältere Firmware verwendet?

Die Kalibrierung für den Sensor wird im EEPROM auf dem Bricklet gespeichert. Die kannst du mittels Brick Viewer ändern, siehe:

http://www.tinkerforge.com/doc/Hardware/Bricklets/Distance_IR.html#spannung-distanz-abbildung-speichern

Die MSDN Knowledge Base sagt, dass Windows 8 und Windows 7 (seit Mai 2012) automatisch den passenden Treiber installieren können, wenn ich das USB Gerät korrekt als WinUSB kompatible ausgibt. Wir verwenden WinUSB über libusb, daher sollte das gehen. Ich habe das testweise funktioniert und der Brick sollte sich jetzt als WinUSB kompatible ausgeben können. Leider funktioniert das noch nicht so richtig wie es soll.

Bis dahin kann ich dir den WinUSB Driver Installer Zadig von den libsub Entwicklern als Lösung anbieten. Dieser kann unter Windows 8 einen passenden und signierten Treiber installieren.

http://download.tinkerforge.com/_stuff/zadig_v2.0.1.159.exe

Wenn du das startest sollte das etwa so aussehen:

Wichtig ist dabei, dass das richtige Device ausgewählt ist (hier 'Master Brick') und WinUSB als Treiber. Dann 'Install Driver' klicken. Möglicherweise musst du dann noch einmal den Brick ab und wieder anstecken, damit er dann erkannt wird.

Ich kann das Problem hier reproduzieren. Eine Lösung ist in Arbeit.

Auf der anderen Seite (und hier spreche ich von einer zusätzlichen Maßnahme, könnten die Bindings ja durchaus für alle Methoden eine minimumRequiredFirmwareVersion kennen. Da die Bindings wissen welche Firmware auf dem Brick läuft, könnten sie dann eine hilfreiche Exception werfen bevor sie die Hardware mit Unsinn bombardieren.

Das ist eine sinnvolle Idee. Ich habe dazu gerade den ersten Schritt getan und alle Funktionen in den Configs mit ihrer "minimumRequiredFirmwareVersion" versehen. Als nächsten kommen, dann Checks dafür in den Bindings.

Sollte jetzt funktionieren.

Der Zeichensatz des LCDs ist fest und damit auch die Ausrichtung der Zeichen. Es ist daher rein technisch nicht möglich die Zeichen auf den Kopf zu drehen.

1. Nein, das geht nicht.

2. Ich nehme mal an du machst das im Moment so oder so ähnlich:

lcd.WriteLine(0, 0, "Joystick: " + x + ", " + y);

Da die Darstellung von x maximal 4 Zeichen (-100) bis 1 Zeichen (0) lang sein kann, musst du nur 3 extra Leerzeichen anhängen um bei x = 0 die restlichen 3 Zeichen zu "löschen". Da ich hier x und y in einer Zeile habe macht das 6 Leerzeichen, also:

lcd.WriteLine(0, 0, "Joystick: " + x + ", " + y + "      ");

3. Du musst einfach durch 10.0 (float) statt durch 10 (int) teilen:

lcd.WriteLine(0, 0, "Temperature: " + t / 10.0);

Brick Daemon 1.0.10

• Enable non-root usage on Linux
  
• Avoid potential data corruption in python-libusb1
  

Downloads: Windows, Linux, Mac OS X

Brick Daemon 1.0.10

• Kann jetzt als nicht-root User unter Linux gestartet werden
  
• Mögliche Datenkorruption in python-libusb1 vermieden
  

Downloads: Windows, Linux, Mac OS X

Brick Viewer 1.1.13

• Switch from green to dark green in graphs for better contrast on gray
  
• Show Barometer Bricklet altitude also in feet
  
• Fix progress dialog for Bricklet flashing
  
• Handle old names for Temperature IR and Distance IR Bricklets in Check-for-Updates dialog
  
• Automatically restore IMU factory calibration after flashing
  
• Improve flashing verification speed by reading whole flash pages
  
• Improve progress dialog for firmware and plugin discovery in flashing window
  
• Add basic FreeBSD support
  
• Add button to restore factory calibration to IMU calibration window
  
• Add missing image for Dual Replay Bricklet plugin
  

Downloads: Windows, Linux, Max OS X

Brick Viewer 1.1.13

• Grün durch Dunkelgrün in Graphen ersetzt
  
• Barometer Bricklet Höhe wird nun auch in Fuß angezeigt
  
• Fortschrittsanzeige beim Flashen von Bricklets verbessert
  
• Alte Namesversionen des Temperature IR und Distance IR Bricklets beim Check-for-Updates werden richtig behandelt
  
• IMU Werkskalibrierung kann nach dem Flashen automatisch wiederhergestellt werden
  
• Geschwindigkeit des Verifikationsschritts beim Flashen beschleunigt
  
• Fortschrittsanzeige bei der Abfrage der verfügbaren Firmware und Plugin Versionen verbessert
  
• Grundlegende FreeBSD Unterstützung
  
• Knopf zum automatischen Wiederherstellen der Werkskalibrierung zum IMU Kalibrierungsfenster hinzugefügt
  
• Fehlendes Bild zum Dual Replay Bricklet Plugin hinzugefügt
  

Downloads: Windows, Linux, Max OS X

Bindings: C/C++ 1.0.23, C# 1.1.15, Delphi 1.0.7, Java 1.0.21, PHP 1.0.16, Python 1.0.24, Ruby 1.0.13

• Add get_usb_voltage function to Master Brick API [All]
  
• Add Barometer Bricklet examples [All]
  
• Handle difference between currentThread and current_thread to support Python 2.5 [Python]
  
• Changed callback_queue from class variable to instance variable [Python]
  

Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Bindings: C/C++ 1.0.23, C# 1.1.15, Delphi 1.0.7, Java 1.0.21, PHP 1.0.16, Python 1.0.24, Ruby 1.0.13

• get_usb_voltage Funktion zur Master Brick API hinzugefügt [Alle]
  
• Barometer Bricklet Beispiele hinzugefügt [Alle]
  
• Unterschied zwischen currentThread and current_thread wird richtig behandelt um Python 2.5 zu unterstützen [Python]
  
• callback_queue der IPConnection von Klassenvariable zu Instanzvariable geändert [Python]
  

Download: C/C++, C#, Delphi, Java, PHP, Python, Ruby

Was ich stattdessen mal getestet habe ist nur das Barometer und das Temperature IR Bricklet anzuschließen. Diese Kombination habe ich mittlerweile trotz rund ein Dutzend Versuche nicht zu dem fehlerhaften Verhalten bringen können 

Das ist komisch. Genau da hätte ich jetzt auch Probleme erwartet.

Andere Frage: Wie lang sind die Bricklet Kabel die du da verwendest? Falls dem noch nicht so ist, kannst du dann mal den originalen Aufbau mit 15cm Kabel testen, oder dem kürzesten was du zur Hand hast?

Jetzt wo du's sagst kann ich das bestätigen. Bie mir sind es etwa 0,3°C weniger. Ich hatte vor Version 1.1.2 noch eine Abweichung in der implementierten Berechnung im Vergleich zu der im Datenblatt beschriebenen. Diese habe ich in Version 1.1.2 korrigiert.

Also die Vermutung ist, dass es ein Problem mit der I2C Kommunikation ist und sich das Temperatur IR und das Barometer da in die Quere kommen. Möglich wäre dass dein Temperatur IR Bricklet ein Problem hat und dem Barometer Bricklet reinredet.

Hast du noch andere I2C Bricklets zur Hand? Z.B. ein Temperatur Bricklet, ein LCD Bricklet oder ein IO-16 Bricklet?

Interessant sind jetzt ob bei folgenden Kombinationen jeweils alle Bricklets richtig funktionieren:

• Barometer Bricklet mit einem der anderen I2C Bricklets
  
• Temperatur IR Bricklet mit einem der anderen I2C Bricklets
  

Wie da konstant 20°C bei raus kommen können ist mir nicht klar.

Ich habe jetzt erstmal Version 1.1.2 released, die arminiusdcs Sprungproblem im Zusammenhang mit dem LCD behebt.

Du scheinst da noch ein anderes Problem zu haben. Ich experimentiere gerade noch mit ein paar Dingen in diese Richtung.

Barometer Bricklet Plugin 1.1.2

• Fix sensor readout timings, avoids reading wrong sensor values
  

Download: Plugin

Barometer Bricklet Plugin 1.1.2

• Timing für das Auslesen des Sensors korrigiert, vermeidet das Lesen falscher Sensorwerte
  

Download: Plugin

Also, der Sensorchip auf dem Barometer hat eine Werkskalibrierung die aus 6 Werten besteht. Diese 6 Werte sind mit einer CRC4 Checksumme gesichert. Das Bricklet Plugin liest diese 6 Werte aus und kontrolliert die Checksumme. Falls diese nicht passt ist irgendwas sehr im Argen. Dann werden konstant die Minimalwerte für Luftdruck und Temperatur ausgegeben: 10mbar und -40°C. Es findet keine Höhenberechnung statt und die Höhe wird als 0m ausgegeben. Und Änderungen am Referenzluftdruck sind nicht möglich. Dein Bild "4 Bricklet Setup.png" zeigt exakt diesen Fall.

Es sieht so aus als könntest du diesen Fall hier willentlich herbeiführen, indem du etwas anderes zusätzlich zum Barometer an den Brick hängst. Da ist mir gerade nicht klar wie das sein kann.

Nachtrag: Kannst du eingrenzen was du zusätzlich anstecken musst damit Probleme auftreten? Ich würde aufs Temperature IR tippen. Humidity und Ambient Light sollten keine Probleme machen.

Du kannst versuchen den DC Brick neu zu flashen. Hört sich an als wäre er im Bootloader.

http://www.tinkerforge.com/doc/Software/Brickv.html#brick-firmware-flashing

Ich habe gerade die Downloadseite mit Versionsnummern und Links zu den Changelogs versehen. Darüber hinaus kann Brick Viewer seit Version 1.1.12 auf Knopfdurck nach neuen Firmwareversionen gucken.

Hm, dass ist komisch. Klingt vielleicht blöd, aber bist du sicher Version 1.1.2 RC1 geflashed zu haben und den Master danach neugestartet zu haben, damit er auch das neue Plugin läd?

Denn ich kann das Problem hier mit deinem Aufbau weder mit Barometer Plugin Version 1.1.1 noch 1.1.2 RC1 reproduzieren. Mein Aufbau

• Master Brick (1.4.1)
  
• Temperature-IR Bricklet (1.1.1) an Port A
  
• Humidity Bricklet (1.1.0) an Port B
  
• Barometer Bricklet (1.1.1) an Port C
  
• Ambient Light Bricklet (1.1.0) an Port D
  

der liegt da einfach und ich schau mir mit dem Brick Viewer das Barometer an. Ansonsten greife ich nicht auf die Bricklets zu. Tust du vielleicht noch etwas zusätzliches, dass das Problem erzeugt? Oder hast du die Bricklets an anderen Ports? Wobei das eigentlich keinen Unterschied machen sollte.

Ich konnte das Problem mit Barometer Plugin Version 1.1.1 erzeugen, wenn ich gleichzeitig durchgehend auf ein LCD Bricklet am gleichen Master geschrieben habe. Das war arminiusdcs Aufbau aus dem anderen Thread. Und mit Version 1.1.2 RC1 ist zumindest das Sprungproblem in diesem Aufbau behoben.