remotecontrol

Normalerweise nehme ich eh die USB2-Ports an dem Rechner (unter Windows 7 x64) und damit klappt alles problemlos. Einen USB3-Port habe ich mir aber an den Tisch "hochgelegt" und das ist ganz praktisch, nur funktiert der nicht unter Windows . Ist aber nicht schlimm, ich such' mal ob es dafür ein Treiberupdate gibt; wenn nicht dann eben nicht ...

Hallo zusammen, ich habe einen Rechner Dual-Boot Windows+Linux und USB3. Schließe ich einen Stack unter Linux am USB3 Port an, so wird der Stack erkannt und kann angesprochen werden, dasselbe unter Windows funktioniert allerdings nicht? Ist das ein spezifisches Problem des Windows-Treibers oder ist es eher Zufall, dass das unter Linux funktioniert. Die Bricks nutzen ja nur USB 1.1, sollte doch theoretisch auch an USB3 Port klappen - oder?

Hier gibt es eine Menge verschiedener Möglichkeiten ... Ich würde Jedes Brick/Bricklet softwareseitig an ein Objekt binden. Das Objekt wird über die Listener mit dem aktuellen Hardware-Zustand aktualisiert und kennt zu jeder Zeit den Zustand der Hardware. D.h. Statusabfragen von außen fragen dann nur diese Objekte ab und gehen nicht direkt auf die TF-API / Hardware. Wenn eine neue Position gesetzt werden soll, muss die Methode im Main-Thread den aktuellen Zustand der Objekte erstmal prüfen und testen, ob die neue Position gesetzt werden kann (oder schon erreicht oder Abstand innerhalb der minimalen Bewegung, ...) Nach Senden von Positionsänderungen über die an die Bricks gebundenen Objekte könnte die Methode einfach wait(timeout) nutzen. Die an die Hardware gebundenen Objekte müssen ein Synchronisations-Objekt des Main-Thread kennen und könnten bei jeder Positionsänderung per notify() den Main-Thread aufwecken. Die Methode im Main-Thread muss dann aber nach jedem Wake-Up kurz prüfen, ob die Position erreicht ist. In Summe sollte der wait() nie endlos warten für den Fall, dass aus irgendeinem Grunde die Position nicht erreicht wird. Alternativ könnten die Brick-Objekte den notify() auch nur dann auslösen, wenn die gewünschte Position erreicht ist. Dann muss der main-Thread nicht so oft prüfen, ob die Position korrekt erreicht ist. Letzteres geht einfach, indem die Positionsänderung aus dem Main auch über das eigene Brick-Objekt geht (welches dann intern erst die TF-API nutzt), damit weiss das Objekt ja, welche Ziel-Position erreicht werden soll und könnte den notify erst auslösen, wenn diese Zielposition erreicht ist (für jenen Teil der Steuerung, wo das Erreichen der Zielposition nicht direkt per TF-API-Callback mitgeteilt wird). Das mal als Versuch, einen möglichen Ansatz zu beschreiben.

Hallo StromFahnder77, der Post ist ja schon älter. Ich weiss gar nicht mehr welche Version der App Ihr im Einsatz habt. Der Stand auf der TF-Projektseite ist sicher ein Älterer .. Aber allein die Tatsache, dass die App auch mit anderer Kombination der Hardware nutzbar ist, ist interessant. Was bräuchtet Ihr denn noch an Anpassungen?

Ich habe noch Kabel "älterer" Bauart: nicht gedreht und nur mit Kabelbindern etwas zusammengehalten. Die sind sehr flexibel und ca. 20-25cm lang (kann gerade nicht nachsehen). Eins könnte ich abtreten - passt ja in einem Briefumschlag.

Ich verwende auch die TagWriter App und die erkennt bei mir die Message problemlos. Da muss noch ein anderes Problem vorliegen. Kann die App die unveränderten Tags auslesen? Da muss eine URL und eine Text-Message drauf sein.

Das VoltageCurrentBricklet hat +/- am Eingang und +/- am Ausgang (jeweils 2 Anschlüsse). Jetzt kann ja Strom vom Eingang zum Ausgang oder auch umgekehrt fließen (nativer Stromwert) aber +/- bleibt dabei unverändert. In der Doku ist ein gutes Beispiel: Laden und Entladen. Das ändert die Stromrichtung zwischen Eingang und Ausgang, aber nicht die Polarität.

Ich habe das so verstanden, das sich die Polarität nicht ändern darf, nur die Stromrichtung (so ist es bei mir auch im Einsatz). Bei der Bricklet-Doku steht auch +-20A, aber 'nur' 36V (ohne +-).

Prinzipiell müsstest Du mit dem DC Brick den Stromverbrauch regeln können. Ich weiss aber nicht, ob Deine Heizmatte dieses quasi schnelle ein/ausschalten verträgt. Schon mal darüber nachgedacht?

Prinzipiell gehen auch zwei WLAN-Sticks, die sollten dann die logischen Devices "WLAN0" und "WLAN1" bekommen. Auch wenn Du mal unterschiedliche WLAN Hardware mit demselben Rechner verbindest, kann es passieren, dass der 2. Stick WLAN1 hat, obwohl nur ein WLAN gerade angestöpselt ist. Je nach Distribution werden einmal verbundene Geräte anhand der MAC-Adresse wieder konfiguriert. Das sollte auch mit Debian gehen. Ich weiss aber nicht, was der Brick-Viewer intern macht.

Die Spannungsmessung der StepDown/Master ist sicher nicht so genau wie ein Multimeter (0,3V Toleranz sind da wohl "normal"). Hast Du so ein Segment-Display angeschlossen? Das könnte die Spannungsmessung zusätzlich beeinflussen. Für exakte Messung ist das VoltageCurrent Bricklet gedacht. Da habe ich <0,03V Abweichung zu meinem Multimeter.

Brickv nutzt doch auch die API, d.h. da dürftest Du keinen Unterschied haben? Welche API Funktion nutzt Du? Einen Unterschied dürfte es nur geben, wenn Du mit einem Multimeter misst: das ist sicher genauer. Da es auch noch Bauteilschwankungen geben kann würde ich mal den API Wert mit dem Wert eines Multimeters vergleichen. Bei einer meiner StepDowns bekomme ich über die API z.B. 11,15V das Multimeter sagt aber 11,34V.

Die 16V sind fix (ist ein Akku). Eine Step-Down habe ich noch im "Vorrat", dann werde ich das wohl mal testen ...

All bricks work if they are connected independently (not in a stack)? Which firmware versions have the bricks? WIFI is on top of the Master brick?

Hallo zusammen, hat jemand Erfahrungen mit der Step-Down gemacht, wenn diese dauerhaft mit 2,5A bei 5V (Eingang ca. 16V) belastet wird? Wird die ggf. sehr heiß (Belüftung ist im Stack ja schwierig)? Ich habe hier andere Step-Downs mit einem LM-XXX Chip, die bei 2A schon einen kleinen Kühlkörper brauchen, sonst erwärmen sich diese auf ca 70°. Viele Grüße

Ich bevorzuge sowas in der Art #include <chrono> #include <thread> std::this_thread::sleep_for(std::chrono::milliseconds(x)); Das sollte unter Windows und Linux gehen, wenn die Compiler nicht zu alt sind. Ansonsten gibt es unter Linux "sleep" (nur ganze Sekunden warten) und "usleep". Mit man 3 sleep bzw. man 3 usleep bekommst Du unter Linux die Hilfe zu der API (sofern im Image installiert).

Vielleicht kurz zu dem hier: Deine Annahme ist schon korrekt: nach dem Compile-Vorgang liegt ARM-Code vor. Aber um erfolgreich zu compilieren, muss das Projekt die Besonderheiten der (ggf. verschiedenen) Zielumgebungen beachten. Die TF-API ist erstmal frei von Windows- / Linux-Spezifika; intern sind zwar Unterschiede, die API ist aber frei davon. Wenn Du nun ein Programm in C++ schreibst, musst Du einfach aufpassen, welche sonstigen API's Du verwendest, die nicht Standard C++ sind. Alles was Windows spezifisch ist, wird auf dem RED nicht funktionieren (auch auf MAC auch nicht ..).

Hallo Borg, an der Stelle ein großes "Danke" an Euch: mit der Reduzierung der Abhängigkeiten im Brickv 2.2.2 kann ich nun auch unter OpenSuse endlich den Brickv recht einfach zum Laufen bekommen. Davor bin ich an den Libs gescheitert, die so nicht verfügbar waren. Viele Grüße

Hast Du bei der Fritzbox eine Option zur Reduzierung der WLAN-Stärke bei Nichtnutzung aktiv? Dann wäre es denkbar, dass z.B. ein Smartphone daheim das WLAN aktiv hält. Wenn Du aber gehst (und der Stack ja aktiv keine Pakete sendet), dann könnte die FritBox evtl. die WLAN-Leistung reduzieren und dann bricht die Verbindung ab.

Es gibt auch einen Switching-Done Callback. Damit wirst Du benachrichtigt, wenn der Schalt- / Sendevorgang beendet ist. D.h. Du musst das eigentlich nicht in einer Schleife abfragen. Meine Beobachtung ist, dass es bei Repeat-Count 5 ca. 500ms dauert, bis der Sendevorgang beendet ist, also 100ms pro Repeat.

Guter Tipp, danke! Sowas in der Art suche ich und die haben auch Acrylglas im Zuschnitt. Den TF-Kunststoff würde ich auch nicht schneiden wollen, sondern eher Standardplatten verwenden. Ich hab mal ein paar 3mm Löcher gebohrt, das ging immerhin recht gut.

Hallo TF-Team, habt Ihr schon mal drüber nachgedacht, von den Kunststoffplatten aus denen Ihr die Gehäuse herstellt, vordefinierte Größen im Shop anzubieten? Z. B. 10x10, 10x20, 10x30, 5x10, 5x20 ... ? In Kombination mit Makerbeams kann man daraus recht gut Abdeckungen/Gehäuse machen. Ich habe in der Not mal zwei Wetterstation-Gehäuse hergenommen und die Teile auf Makerbeams befestigt. Rückwand schwarz, Front klar: schaut mit dem schwarzen Alurahmen richtig gut aus . Und Euer Kunststoff lässt sich auch gut verarbeiten: beim Bohren splittert der nicht auf - von dem Material hätte ich gerne mehr ... Zum Basteln braucht man immer einen gewissen Vorrat an Material, nur bei den Gehäusen ist das bisher schwierig. Viele Grüße

Prinzipiell geht das mit Dioden oder Gleichrichtern, wobei ich Deine Schaltung noch nicht so recht verstanden habe. Das Datenblatt der LS 1020 spricht von Versorgungsspannung 12-24V und hat ein Alarm-Relais. Mit welcher Spannung versorgst Du denn die Lichtschranke (hast Du schon eine)? Evtl. brauchst Du das alles gar nicht und kannst direkt 12V über das Alarmrelais schalten und die 12V musst Du eh über ein Netzteil bereitstellen, weil die LS damit versorgt werden muss.

Wie hast Du Dich am RED angemeldet bzw. worüber das Programm gestartet? Es sieht so aus, als sei in Deiner Console die DISPLAY-Variable nicht gesetzt.

Jetzt bin ich etwas sprachlos. Ich habe zwar gehofft, dass mir kein Fehler unterlaufen ist, aber das das Problem irgendwann per Firmware-Update gelöst werden kann. Sieht ja eher nicht so aus . Dennoch danke für die Mühe. Zumindest lässt das Freiraum für eine Hardwareversion 2 in ferner Zukunft .