photron

Loetkolben, dass da auf dem Status Fenster als 0 ist wenn der Status "Associating" ist, ist normal und kein Zeichen für ein Problem. Deine WIFI Extension versucht sich mit dem eingestellten Access Point zu verbinden (Status Associating, grüne LED blinkt), schafft es aber nicht. Ich nehme mal an, andere Geräte können sich noch zum Access Point verbinden. Das Problem liegt also nicht auf der Access Point Seite? Es hat auch niemand etwas am Access Point verstellt? Hat der Access Point ein Log über WIFI Aktivität wo vielleicht was steht, dass er die WIFI Extension abgelehnt hat? Hast du mal versucht die WIFI Extension im Brick Viewer über den Configure Button oben rechts erneut auf WIFI zu konfigurieren (Factory Reset) und dann den Master Brick neu zustarten?

Stimmt, die Beispiel sind Function Files. Es funktioniert wenn ich unter der Function Definition die Funktion direkt aufrufe. Ich füge da gleich einen Hinweis in der Dokumentation für ein. Bezüglich Callbacks: Ich habe gerade nochmal das Humidity Callback Example getestet und das funktioniert. Wie sieht dein Callback Test aus?

Welches Kabel du verwenden solltest hängt von der Strecke zwischen den beiden RS485 Knoten ab. Für ein paar Meter tut es sicherlich jedes Kabel. Der Querschnitt ist nicht so bedeutend, da hier keine große Leistung übertragen wird. Für längere Strecken als ein paar Meter solltest du mindestens ein verdrilltes (twisted pair) Kabel verwenden. Telefonkabel ist häufig verdrillt, damit machst du sicherlich nichts falsch. Die nächste Stufe ist dann Ethernet-Kabel, das ist verdrillt und besser geschirmt. Da du in einem Telefon- und auch Ethernet-Kabel normalerweise mehrere verdrillte Paare hast solltest du für A und B ein Paar nehmen und GND über ein anderes Paar führen. Nachtrag: Ich habe der Dokumentation einen Empfehlung für Twisted Pair Kabel hinzugefügt.

Getter in den JavaScript Bindings sind async. Du musst getPort so aufrufen: // Get current value from port A as bitmask io.getPort('a', function (valueMask) { alert('Value Mask (Port A): ' + valueMask.toString(2)); }, function (error) { alert('Error: ' + error); } );

Das kommt wohl hin. In meiner 1-wöchigen Messreihe hatte ich am Mittag mit direkter Sonne um die 80000 - 90000 Lux.

Es gibt jetzt Plugin 2.0.2 für's Ambient Light Bricklet 2.0. Darin wird zwar nicht das aktuelle Problem dieses Threads gelöst, da es noch nicht ergründet wurde, aber es geht mehr oder weniger noch mal um das Problem, das ich schon in Version 2.0.1 angegangen habe (Sensor ist gesättigt) und um den Messbereich des Bricklets. Daher will ich das hier kurz erläutern. Wenn es viel heller als der eingestellt Messbereich ist oder die Integrationszeit zu hoch eingestellt ist für die aktuelle Helligkeit, dann kann der Sensor gesättigt sein. In diesem Fall hatte Plugin 2.0.0 versuch den Wert des gesättigten Sensors noch zu verwenden was zu falschen Ergebnissen führte. Das war das initiale Problem in diesem Thread. In Plugin 2.0.1 wurden dann im Fall eines gesättigten Sensors, dessen Messwerte ignoriert und der letzte noch gültige Werte wurde weiterhin vom Bricklet gemeldet. Das löste das Problem der falschen Werte, machte es dem Nutzer aber nicht einfach zu erkennen, dass der Sensor in Sättigung war und eigentlich die Konfiguration hätte geändert werden sollen. Stattdessen sah es so aus, als ob sich die Helligkeit nicht ändern würde. Zusätzlich war es schon seit Plugin 2.0.0 so, dass das Bricklet Werte außerhalb des eingestellten Bereichs zurückliefern konnte. Das ist bedingt dadurch, dass der Sensor ca. 150% über den eingestellten Bereich hinaus messen kann. Allerdings mit abnehmender Genauigkeit. Auch das hat hier im Thread Probleme gemacht. Wir haben uns darüber jetzt noch mal Gedanken gemacht. In Plugin 2.0.2 liefert das Bricklet jetzt 0,00 Lux zurück, wenn der Sensor in Sättigung ist. Wenn er nicht gesättigt ist, ist der minimale Wert jetzt 0,01 Lux. Dadurch kann der Nutzer jetzt direkt erkennen, ob der Sensor in Sättigung ist und entsprechend reagieren. Die Messwerte werden jetzt auf den eingestellten Messbereich +0,01 Lux beschränkt. Wenn der Messbereich also auf 0-8000 Lux eingestellt ist und das Bricklet 8000,01 Lux meldet, dann ist der wirkliche Messwert höher als 8000 Lux und der Messbereich sollte umgestellt werden. Da der 0-64000 Lux Bereich jetzt wirklich nur noch bis 64000 Lux ausgibt, gibt es einen zusätzlichen unbeschränkten (unlimited) Messbereich, der bis zum absoluten Maximum (ca. 100000 Lux) des Sensors messen kann, wobei in diesem Bereich über 64000 Lux allerdings die Genauigkeit abnimmt.

Plugin: Ambient Light Bricklet 2.0 2.0.2 Invalid values due to sensor saturation are reported as 0lux Clamp measured values to the configured illuminance range Add new unlimited illuminance range for unclamped measurements Download: Ambient Light Bricklet 2.0

Plugin: Ambient Light Bricklet 2.0 2.0.2 Ungültige Sensorwerte bedingt durch einen gesättigten Sensor werden als 0Lux gemeldet Sensorwerte werden auf den eingestellten Messbereich beschränkt Neuen unbeschränkten (unlimited) Messbereich hinzugefügt Download: Ambient Light Bricklet 2.0

Das rot-schwarze Kabel ist für die Stromversorgung des Schrittmotors. Es ist am schwarzen Anschluss des Stepper Bricks angeschlossen. Der Schrittmotor wird nicht über USB versorgt. Ups, das haben wir wohl im Blogpost unterschlagen. Parmaster, du meinst das schwarze Kabel mehr links im Bild, dass geht zur Kamera.

Die einfachste Erklärung ist, dass dennoch die UID nicht passt. Du hast aber auch die UID des Bricklets angeben? Die ist normalerweise 3 stellig. Du kannst testweise mal folgende Zeile nach der "$sd4x7 = new BrickletSegmentDisplay4x7(UID, $ipcon);" Zeile im Beispiel einfügen: $sd4x7->setResponseExpectedAll(true); Wenn dann ein Fehler auftritt hast du die falsche UID angegeben, denn dann hat niemand auf den setSegments() Aufruf geantwortet. Wenn kein Fehler auftritt, aber immer noch nichts angezeigt wird, dann hast du die UID des falschen Bricks oder Bricklets angegeben.

Die RED Brick API hat keine direkte Funktion dafür. Die API bietet grundlegende Funktionen wie Dateien auf dem RED Brick lesen/schreiben und Programme auszuführen. Darüber erledigt der Brick Viewer dann z.B. auch die Access Point Konfiguration. Das ist allerdings halbwegs kompliziert. Du kannst die den Code dafür im Brick Viewer u.a. hier ansehen: https://github.com/Tinkerforge/brickv/tree/master/src/brickv/plugin_system/plugins/red https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/red_tab_settings_ap.py https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/scripts/settings_ap_apply.py https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/scripts/settings_ap_get_interfaces.py https://github.com/Tinkerforge/brickv/blob/master/src/brickv/plugin_system/plugins/red/scripts/settings_ap_status.py

Signal 9 ist das Unix Signal SIGKILL. Wenn du im Brick Viewer den Kill Knopf für das Programm klickst, dann wird es mit SIGKILL umgebracht. Das wichtige an SIGKILL ist, dass sich das Programm nicht dagegen wehren kann. Wenn du den den Exit Knopf klickst wird das Programm mit SIGTERM (Signal 15) gebeten sich zu beenden. Wenn das Programm aber nicht will, kann es SIGTERM ignorieren. Sprich SIGKILL kann auftreten, wenn du den Kill Knopf klickst, was du wahrscheinlich nicht getan hast. Ansonsten kann SIGKILL auftreten, wenn du das Programm löscht während es noch läuft, oder der RED Brick API Daemon sich beendet wenn es noch läuft. Das wird aber alles hier nicht der Fall sein. Wie viel RAM braucht dein Programm? Es kann sein, dass dein Programm allen RAM des RED Bricks belegt. In dem Fall kommt der Linux OOM (Out-of-Memory) Killer ins Spiel, der so lange Programm (mit SIGKILL) umbringt bis wieder ausreichend RAM frei ist damit das System weiterlaufen kann.

Ich denke dein Problem ist, das du zwar den Mode umstellen kannst und der Monitor auch folgt, aber X nicht. Ich habe hier gerade etwas damit herumgetestet bekomme aber X nicht dazu nach einer Mode-Änderung seine Auflösung mit zu ändern. Die Fallback-Auflösung ist in der Kernel Kommandozeile definiert. Die ist beim RED Brick mit in den Kernel reinkompiliert und daher extern nachher nicht mehr änderbar. Um diese zu ändern müsstest du also den Kernel seblst neu kompilieren: https://github.com/Tinkerforge/red-brick/blob/master/image/README.rst

In which file format did you store the data? Here's a LabVIEW example for reading CSV files: https://decibel.ni.com/content/docs/DOC-12287

LPD, ich nehme mal an dein Skript würde nicht 0 ins RRD eintragen, wenn der Sensor nicht wirklich 0 geliefert hat. Ich hatte hier einen einwöchigen Test mit 3 Bricklets laufen, keine Probleme. Ich hatte sie allerdings nicht in einem geschlossenen Gehäuse wie du. Es besteht also die Chance, dass es dem Bricklet in deinem Gehäuse zu warm wird. Die Möglichkeit kann ich nicht ausschließen. Abgesehen davon gehen mir die Ideen aus. Was ich dir anbieten kann, ist dir ein neues Ambient Light Bricklet 2.0 zu zuschicken, um zu sehen ob das einen Unterschied macht. Melde dich dafür mit deiner Bestellnummer bei info@tinkerforge.com und verweise auf den Thread hier.

Loetkolben: Der Sensor verwendet einen 16 Bit 2-Kanal ADC. Dies beiden 16 Bit Werte sind aber nicht in Lux, sondern müssen noch nach einer bestimmten Formel mit einander verrechnet werden um den endgültigen Messwert in Lux/100 zu erhalten. Daher mach es keinen Sinn die 16 Bit Rohdaten des Sensors durchzureichen. Lux/100 sind schon richtig. Das Bricklet gibt den Wert in hundertstel Lux an (Lux/100). Du musst ihn als durch 100 Teilen um einen Wert in Lux zu bekommen. Bezüglich der 64k Lux Grenze: Die ist nicht hart. Der Sensor kann bis zu 150% darüber messen, sprich bis zu ca. 100k Lux. Allerdings nimmt ab 64k Lux die Genauigkeit ab. Da ist kein Fehler diesbezüglich in der Firmware des Bricklets. Allerdings ist die Dokumentation nicht ganz vollständig an der Stelle. Ich habe das nun korrigiert.

Ich nehme an du hast den Monitor angeschlossen und dann erst den RED Brick angeschlossen? Falls nicht, teste das bitte mal in der Reihenfolge. Wenn du nicht Mode 26 setzt, dann skaliert der Monitor das 800x480 Bild auf 1360x768 hoch? Wenn du Mode 26 setzt, dann skaliert der Monitor nicht mehr, sondern zeigt das 800x480 Bild mit schwarzen Balken rundherum auf 1360x768 aufgefüllt an? Das 800x480 Bild ist aber immer vollständig und nichts ist abgeschnitten?

Wenn du einfach das PHP Beispiel hier unverändert (abgesehen von der UID des Brickelts) testet, funktioniert das? http://www.tinkerforge.com/de/doc/Software/Bricklets/NFCRFID_Bricklet_PHP.html#write-read-type-2 Hast du mal Daten lesen/schreiben mit Brick Viewer getestet?

Ich nehme an, dass du das "Write Read Type 2" Beispiel angewandelt hast? Ich habe deine Änderungen getestet und es funktioniert. Wie testet du denn ob es funktioniert hat, bzw. wie stellst du fest, dass es nicht funktioniert hat?

Jedes deiner 4 Linear Poti Bricklets sendet seinen Callbacks für sich selbst, da wird nichts zusammengefasst oder so. Wenn du 4 Bricklets hast kannst du auch 4 verschiedene Callbacks erhalten.

Nein, nicht jedes Device hat einen Callback Thread, sondern jede IP Connection. Wenn du deine 4 Linear Potis über die gleich IP Connection ansprichst, dann werden deren Callbacks über den einen Callback Thread der einen IP Connection ausgeliefert.

Das Datenblatt des Sensors schweigt sich über UV aus. Das erste Bild ist von einem der zwei Ambient Light 2.0 Bricklets, die hier schon seit Montag messen. Heute morgen habe ich sie nach draußen gestellt und zu Mittag waren sie direkt in der prallen Sonne. Keine Probleme. Das zweite Bild ist von einem weiteren Ambient Light 2.0 Bricklet, dass ich zur Westseite hinter ein Fenster gestellt habe. Die ersten beiden stehen an der Ostseite und sind jetzt mehr im Schatten. Dieses steht aber gerade in der vollen Sonne, allerdings hinter einer Fensterscheibe. Auch hier bisher keine Probleme. Ich glaube mein RRD ist etwas unglücklich eingestellt, was zu diesen etwas "eckigen" Graphen führt.

Plugin: Analog In Bricklet 2.0.5, Analog In Bricklet 2.0 2.0.1, Voltage Bricklet 2.0.2 Fix value range and comparison for threshold callback Download: Analog In Bricklet, Analog In Bricklet 2.0, Voltage Bricklet

Plugin: Analog In Bricklet 2.0.5, Analog In Bricklet 2.0 2.0.1, Voltage Bricklet 2.0.2 Wertebereich und Vergleichslogik für Threshold-Callback korrigiert Download: Analog In Bricklet, Analog In Bricklet 2.0, Voltage Bricklet

Das ist ein Copy-Paste Fehler. Der betrifft mehrere Bricklets. Aber der gültige Werte Bereich für min/max ist bei allen nicht beeinträchtigt. So dass wir die Stabilität der API höher gewertet haben als die Korrektheit der Typen. Als ich das noch mal durchgegangen bin ist mir allerdings aufgefallen, dass das für das Analog In Bricklet (2.0) nicht stimmt und nicht der vollständige Messbereich als min/max angegeben werden kann. Daher haben wir uns jetzt entschieden alle betroffenen Bricklets zu korrigieren.