remotecontrol

Hi Bottesford, you're right: to pass 4 bricklet-cables through a window is not that easy and you'll have a limited range. Currently all cables have a max. length of 2m (due to technical reasons). Using RS485 is a possibility, you can reach much longer distances and have less wires. A WIFI extension could be a possibility too, but that stack will have a higher power consumption (you probably already thought about this).

Hallo Batti, danke für die Antwort, auch wenn es schade ist, dass die Spannung nicht steuerbar ist. Ich vermute, dass ein Teil der Schwankung über den dauerhaften Strom kommt, bis sich die Umgebung mal "dran gewöhnt" hat. Ich tue mich recht schwer mit der Kalibrierung der Sensoren. Ich muss eigentlich den Grenzwert (wann gewässert werden soll) von Zeit zu Zeit wieder verschieben (aber im Großen und Ganzen funktioniert es). Einen schönen Abend noch

Outdoor Sensoren über das RemoteBricklet abfragen steht bei mir auf der Wunschliste (oder einfach mehr mit dem RemoteBricklet steuern können als nur Steckdosen, gehört auch zum Kabel-Thema). Richtung Stromversorgung wäre eine Art USV toll: z.B. gibt es für Odroid-Rechner eine zum aufstecken, das funktioniert auch gut. Wenn man einen SoC dauerhaft betreibt hat man recht schnell das Problem, dass der Strom übers Jahr öfter mal aussetzt und immer ist der Rechner abgestürzt. Das betrifft den RED später auch mal.

Hallo TF-Team, mir ist folgendes aufgefallen: wenn ich das Moisture-Bricklet in die Erde stecke und alle paar Minuten den Wert messe, dann steigt dieser erstmal eine ganze Weile leicht an, bis er sich einpendelt (alles ohne, dass gewässert würde). Z. B. ist der Wert kurz nach Einstecken 2680, 10 Min. später schon 2720 und weitere 10 Minuten später 2750. Könnt Ihr das erklären? Das Moisture Bricklet misst ja kontinuierlich und somit stehen die Elektroden auch dauerhaft unter Spannung. Könnte man das per API steuern: lässt die Hardware das Abschalten der Messspannung prinzipiell zu?

Hier steuere ich den Motor über einen Mini-Fahrtregler per Servobrick. Da ich eh schon Step-Down, Master-, ServoBrick und WLAN im Stack habe (aber nur 1-2 Moisture Bricklets und nur 1 Servo-Port benutzt) wollte ich nicht auch noch einen DC Brick verbauen. Wobei mich der Fahrtregler ganz schön gefuchst hat: nach einem Pumpvorgang muss ich die Pumpe kurz rückwärts laufen lassen, um den Schlauch zu leeren. Sonst kann es passieren, dass (wenn der Wasserstand im Behälter höher als "Pumpenniveau" ist) weiter Wasser aus dem Schlauch tröpfelt - angesaugt eben. Aber der Fahrtregler lässt eine Umkehr nicht direkt zu (entspricht Vollbremsung), sondern man braucht ein gewisses Timing nahe der 0-Position, um in den "Rückwärtsgang" zu kommen. Das minimale Timing muss man erstmal rausbekommen. Mit dem DC-Brick ist das etwas einfacher.

Hallo TF-Team, die MakerBeams sind eine tolle Ergänzung. Jetzt habe ich endlich eine solidere Konstruktion für meine "Pumpstation" (die meine Tomaten bewässert). Ist noch nicht ausgereift, aber schon funktionsfähig und war schneller aufgebaut als alles was ich vorher versucht hatte. Und ein 20cm Beam ist noch leicht genug, um es mit Schlauch einfach auf ein Servo zu schrauben. Damit ist dann auch die bewegliche Auslegervariante schnell gemacht, die mir einen Schwenk (z. B. zu einem anderen Kasten) ermöglicht Viele Grüße

das ist tatsächlich schon eingetreten: Beams fehlen in ausreichender Menge ...

Mit der aktuellen Firmware ergibt sich das identische Verhalten, d.h. mit dem "dachte ich zumindest" lag ich doch daneben. Die Ruckler sind wohl eher durch das WLAN bedingt (bei WLAN Rechner auf WLAN Stack). Ich habe mir noch ein Testprogramm geschrieben und damit getestet (LAN Rechner auf WLAN Stack) und das läuft recht flüssig, und mit beiden Firmware Versionen gleich. Mir ist nur eins aufgefallen (aber auch mit beiden FW Versionen gleich): ist der Stack gestartet und über Step-Down versorgt, eine Anwendung lief und ich stecke den Stack dann per USB an einen Rechner, so wird der Stack nicht erkannt. Er bootet auch nicht neu. Normalerweise bootet der Stack ja neu, wenn er per USB verbunden wird - oder? Ab und zu macht er das, ab und zu aber nicht. Aktuell könnte ich nicht sagen, unter welchen Bedingungen der Stack erkannt wird, wenn er nachträglich per USB an einen Rechner angeschlossen wird.

Ein paar mehr Erkenntnisse (alles noch mit der neuen Firmware) die Servos laufen relativ flüssig, wenn ich nur 1-2 Servos ansteuere (ganz selten Ruckler) schalte ich aber die 8 Quad-Relays-Kanäle im Sekundentakt als Monoflop hinzu, dann häufen sich die Ruckler merklich (jeder Kanal wird dabei einzeln geschaltet). Ein "Ruckler" ist bei mir ein Zucken, wo sich das Servo für eine Weile nicht bewegt und dann in die Zielposition springt, obwohl es sich gleichmäßig bewegen sollte. Ich habe sporadische Ruckler bis zu 0,5 Sekunden (gefühlt). zwischenzeitlich habe ich es 1x gesachafft, den Stack zum "Absturz" zu bekommen: hängt komplett, nur noch Reboot half. Wobei Ihr das ignorieren könnt: vermutlich kam das durch Störungen von einem Motor, der in der Nähe des Stacks läuft (habe jetzt mal die Betriebsspannung reduziert, damit der keine Bürstenfunken mehr erzeugt). Aber ich muss das auf jeden Fall mit der alten Firmware vergleichen. Ich kann aktuell nicht mehr sagen, ob sich das nicht ähnlich verhalten hat.

Hallo TF-Team, warum ist der Winkelbereich im Brickv für Servo-Bricks eigentlich von -90..90° voreingestellt? Die meisten Servos unterstützen nur -45..45, einige -60..60 bzw. -90..90. Ich finde einen Default von -45..45 passender. Oder: einen zusätzlichen Radiobutton über den man die beiden Felder für Winkelvorgaben schneller vorgeben kann: * manuell (Eingabefelder offen - wie aktuell) * +- 45° (-4500 .. 4500 wird in die Eingabefelder gesetzt) * +- 60° * +- 90° Viele Grüße

Ich habe mal meinen "üblichen" Teststack aus * Step-Down, Stromversorgung 3-Zellen LiPo Akku * Master 2.0 mit Rotary Poti * WLAN-Extension (nicht als AP) * Servo-Brick (oben) mit 2x Ind.Quad-Relay, 2 Servos und 1 Fahrtregler wieder in Betrieb genommen... Läuft soweit problemlos , keine Aussetzer oder Hänger. Das Einzige, was mir aufgefallen ist: gefühlt habe ich wieder mehr Ruckler in der WLAN Kommunikation. D. h. ab und zu machen die Servos wieder (große) Sprünge. Das Ruckeln war "damals" komplett weg: http://www.tinkerunity.org/forum/index.php/topic,1339.30.html. Sprünge dieser Art hatte ich eigentlich nicht mehr (dachte ich zumindest ). Ich habe auch mal ServoBrick und WLAN-Ext getauscht, d. h. WLAN ganz oben: kein merklicher Unterschied. Zum Vergleich muss ich wohl die alte/aktuelle Firmware nochmal einspielen und damit nochmal testen .. demnächst ..

Verstehe ich das richtig: für den Test der Beta-Firmware sind nur die Bricks zu aktualisieren und zwar alle im zu testenden Stack. Bricklets müssen nicht aktualisiert werden.

Ich hab mir gerade mal einen Schwung davon bestellt, aber vermutlich fällt einem beim Probieren erst auf, was man hätte besser bestellen sollen oder was fehlt Was mir schon aufgefallen ist: - es gibt eine Servohalterung , ggf. könntet Ihr noch eine für Mini-Servos herstellen oder gleich für 2 auf einer Platte. - Kunststoffplatten in verschiedenen Größen (aus denen auch Eure Gehäuse sind) passend zu ausgewählten Grundlängen (z.B. 10x10), damit man Konstruktionen an den Seiten schließen kann.

Das Digital-In braucht keinen Vorwiderstand, der ist schon im Bricklet enthalten. Das IO-4 sollte eigentlich auch keinen benötigen, solange die Eingangsspannung nicht zu groß wird (also auf jeden Fall erstmal messen).

Die Status LEDs werden wohl mit 3,3V versorgt (ohne Gewähr, solltest Du nachmessen), d. h. es sollte mit beiden Bricklets funktionieren. Das Digital-IN erkennt HIGH ab 3V (=> sollte reichen). Das IO-4 ist auf 3,3V ausgelegt, damit sollte es auch gehen.

Are you sure that your application doesn't deadlock? If you receive data from three bricks via callbacks you must properly synchronize your application threads. It might be that in case of an application deadlock the stack cannot send data any more and then has an internal overflow (just a guess). How many callbacks do you typically get per second?

You have one C# application which connects to three bricks simultaneously or do you disconnect the others before you connect to one brick (only one is connected at a time)? Can you still "ping" the bricks if they are unreachable via API? Are the bricks located nearby other electric devices? Can you see anything specific in the access point's log? Do you have the possibility to connect a brick to USB if the brick does not respond to wifi and check if brickv finds the usb connected device?

Hallo Unexpected, ich habe eine "Dreickeckbeschaltung" gemacht: je ein Kondensator zwischen + und Gehäuse, - und Gehäuse und zwischen + und -. Ich kann's leider nicht mehr ablesen, aber ich glaub es sind je 100nF. Ich bin mir nicht sicher, ob diese Entstörung immer notwendig ist. Probleme gibt es auf jeden Fall, wenn der Motor sehr dicht am Stack oder Bricklet ist und zudem noch Bürstenfunken oder Schaltfunken im Relais entstehen, die sich auf die Stromversorgung übertragen. Bei halber Betriebsspannung sollten schon mal weniger Störungen entstehen, auszuschließen ist das aber nicht. Das neue Dual-Relais hat wohl noch Kondensatoren am Relais zur Entstörung.

Ich habe sowas ähnliches schonmal mit dem Dual-Relay Version 1.0 geschaltet: eine kleine Wasserpumpe mit 12V (1,5-2 A bei 12V). Die Betriebsspannung ging an eine Step-Down und den Eingang des Dual-Relais, hat letztendlich also den Stack + Motor betrieben. An den Motor habe ich kleine Entstörkondensatoren angelötet und die Pumpe war im Betrieb ca. 3m vom Stack entfernt. Mit dem Aufbau hatte ich keine Probleme.

Der Stack-Emulator kann inzwischen ca. 20 Devices (http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Stackemulator_%28stubserver%29#Features) und hat mir doch schon einiges an Probieren mit realer Hardware erspart ... Die Callback-Loop habe ich auch noch etwas optimiert und dadurch erreiche ich nun eine Genauigkeit von "exakt" 1ms als minimale Auflösung. Aus meiner "produktiven" Umgebung kann ich Sensorwerte aufzeichnen und als Input für den Stubserver nutzen.

Der agt-get installiert nur jene Packages, die der brickv benötigt. Die Phython Bindings müssen separat runtergeladen und in das Verzeichnis entpackt werden, wo Deine Anwendung liegt. Siehe auch http://www.tinkerforge.com/de/doc/Software/API_Bindings_Python.html#api-bindings-python

Hast Du die Phython TF-Bindings neu installiert? Die Meldung sieht danach aus, als würden die Bindings nicht gefunden.

Hallo TF-Team, ich habe gerade ein SoundIntensity Bricklet bekommen und musste feststellen, dass die Werte der Hüllkurve doch sehr starke Sprünge machen, auch wenn sich das gemessene Gräusch recht gleichmäßig anhört. Wenn ich z.B. den Ton meiner Kaffeemühle aufzeichne bekomme ich während eine Mahlvorganges Werte zwischen 1050 und 2100. Hier mal ein Auszug der Werte. Die 1. Zahl ist die relative Zeit in mSek - hier also 0,7 Sekunden Delta zwischen Zeile 1 und 8; 2. Zahl ist der Wert des SoundIntensity Bricklets: Könnte man die Berechnung der Hüllkurve (oder Wert-Durchschnittsbildung) theoretisch per Firmware anpassen oder ist das komplett durch die Hardware bestimmt?

Ein über init-Skript ausgeführtes Programm hat kein stdin und kein stdout (bzw. diese sind "geschlossen"). Das passt auch zur Fehlermeldung: EOF when reading a line. Du musst den "raw_input" ausbauen und durch einen anderen Warte-Mechanismus ersetzen.

Das AnalogOut Bricklet kann ja die Ausgangsspannung variieren. Bei konstantem Wiederstand und geänderter Spannung ändert sich die Stromstärke, das ist es doch, was Du willst. Nach R=U/I brauchst Du 25Ohm, damit bei 5v 0,02A fliessen. 250 Ohm ist der Wiederstand, damit der max. Strom bei 5V fließt und eben nicht zu viel. Regelst Du das AnalogOut per Programm dann auf 0V runter, fließt kein Strom mehr.