photron

Brick Daemon 2.2.2 RED Brick Kernel Release wird per uname ermittelt um den Ethernet Extension Kernel Treiber richtig zu laden (Hotfix-1: Bereits als Teil des RED Brick Image 1.6 veröffentlicht) RED Brick SPI Stack Protokoll Fehlerbehandlung verbessert (Hotfix-2: Bereits als Teil des RED Brick Image 1.7 veröffentlicht) Startmenü Verknüpfung zur logviewer.exe auf Windows hinzugefügt Installer an Änderungen des Dateisystem-Schutzes in Mac OS X 10.11 angepasst libusb WDF Co-Installer für Windows Vista und 7 aktualisiert Downloads: Windows, Linux (amd64, i386, armhf), Mac OS X

Dieses neue Produkt ist eine Zusammenfassung mehrerer bestehender Produkte zu einem. Eine WIFI Bridge/Nugget ist eine Zusammenfassung von: - Master Brick - WIFI Extension in einer Platine, wobei der Master Brick Teil keine Stack-Funktion hat und nur einen Bricklet Port. Das Ziel des Ganzen ist es ein Bricklet möglichst einfach über WIFI erreichbar zu machen. Es gibt keinen funktionalen Unterschied zwischen WIFI Bridge und WIFI Nugget, dass sind nur zwei verschiedene mögliche Namen für das gleiche Ding.

Sagt die Meldung einfach nur, dass ein Fehler aufgetreten ist? Oder stehen da noch Details zum Fehler?

Die dynamische Lösung ist über den Enumerate Callback, so wie du sie da hast. Der Enumerate Callback gibt dir alle Informationen und erlaubt dir alle Bricks und Bricklets zu finden ohne vorher wissen zu müssen welche vorhanden sind und welche UIDs sie haben. Im Enumerate Callback findet GetIdentity keine Anwendung, da dir Enumerate schon alle Information gibt, die dir GetIdentity geben kann. GetIdentity ist für den Fall nützlich, dass du mit einem bestimmten Brick(let) arbeiten willst und dessen UID und Typ schon kennst. Dann kannst du ein entsprechendes Brick(let) Objekt erstellen, anhand der UID, und mit GetIdentity weitere Informationen über das Brick(let) erhalten. Zum Beispiel, seine Firmware Version oder die Position im Stack.

"MAC Address" auf dem Statusfenster ist die des Moduls. "BSSID" ist die MAC Adresse des verbundenen Access Points. Hast du dir mal den U.FL Stecker des Moduls angesehen? Steckst das Kabel da richtig drauf? Was du auch noch testen kannst ist die Extension als Access Point mit Static IP zu konfigurieren. Da sollte das Statusfenster dann nciht alles 0 sein und du kannst testen ob du dich damit vom Notebook aus damit verbinden kannst. Wenn das geht, dann funktioniert die Kommunikation zwischen Master Brick und WIFI Modul auf der Extension.

Siehe hier: http://www.tinkerforge.com/de/doc/Software/API_Bindings_MATLAB.html#function-vs-script-dateien Hier das Humidity Bricklet Callback Beispiel. Ich habe nur die letzte Zeile hinzugefügt und jetzt kann ich es per "octave octave_example_callback.m" von der Kommandozeile aus aufrufen und es funktioniert auch so auf dem RED Brick. function octave_example_callback() more off; HOST = "localhost"; PORT = 4223; UID = "qRH"; % Change to your UID ipcon = java_new("com.tinkerforge.IPConnection"); % Create IP connection h = java_new("com.tinkerforge.BrickletHumidity", UID, ipcon); % Create device object ipcon.connect(HOST, PORT); % Connect to brickd % Don't use device before ipcon is connected % Set Period for rh callback to 1s (1000ms) % Note: The callback is only called every second if the % humidity has changed since the last call! h.setHumidityCallbackPeriod(1000); % Register humidity callback to function cb_humidity h.addHumidityCallback(@cb_humidity); input("Press any key to exit...\n", "s"); ipcon.disconnect(); end % Callback function for humidity callback (parameter has unit %RH/10) function cb_humidity(e) fprintf("Relative Humidity: %g %%RH\n", e.humidity/10.0); end octave_example_callback(); % Diese Zeile ist neu

Wenn du die Extension erneut auf WIFI konfigurierst wird der Inhalt des EEPROMs auf Extension auf Default zurückgesetzt. Das hat nichts mit dem WIFI Modul auf der Extension an sich zu tun. Die Änderungen dadurch siehst du erst nach einem Reset des Master Bricks. Wenn nach einem Reset des Master Bricks deinen statischen IP Einstellungen immer noch da sind, dann hat das Neukonfigurieren nicht geklappt. Die MAC Adresse steht auf dem Statusfenster, wenn die Verbindung besteht. Warum Signalstärke und MAC Adresse beim Associating Zustand nicht angezeigt werden musst du borg fragen, das hat sicherlich interne Gründe. Du hast nicht zufälligerweise noch einen anderen Access Point zur Hand, zum testen? Oder kannst dein Smartphone oder Notebook testweise als Access Point konfigurieren?

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?