remotecontrol

Hallo Nic, ich hab's gerade mal ausprobiert, weil ich auf den Disconnect nur "global" reagiere, d.h. nur den Callback, aber den Disconnect-Enumerate ignoriere. Im Disconnect Enumerate bekomme ich auch keinen Device-Typ (C + Java), sieht das z.B. so aus: Disconnect UID: 6wTCtc Enumeration Type: 2 Connected UID: Position: Hardware Version: 0.0.0 Firmware Version: 0.0.0 Device Identifier: 0 UID: cJW Enumeration Type: 2 Connected UID: Position: Hardware Version: 0.0.0 Firmware Version: 0.0.0 Device Identifier: 0 Den Typ brauche ich zu der Zeit aber auch nicht mehr, da ich mir die Informationen beim Connect merke und im Disconnect ja weiss, welche UIDs und Typen ich hatte. Oder meintest Du etwas anderes?

Den getIdentity brauchst Du eigentlich nicht. Es gibt einen Enumerate Callback in der IPConnection, mit dem Du alle angeschlossen Bricks und Bricklets aufgelistet bekommst. Darüber bekommst Du die UIDs und die Device Typen (Master, Servo, LCD, Temperatursensor etc.). Siehe auch http://www.tinkerforge.com/de/doc/Tutorials/Tutorial_Rugged/Tutorial.html#tutorial-rugged-approach

Den Stackemulator pflege ich noch von Zeit zu Zeit und nutze den nach wie vor für interne Tests, http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Stackemulator_(stubserver). Was noch fehlt ist eine Visualisierung des akt. Zustandes des Stacks (also z.B. wie ist der Inhalt des LCDs, oder die Stellung eines Servos) und aktive Bedienelemente wie ein Touch-Feld um gezielt Einfluss auf eine Anwendung nehmen zu können. Aktuell muss man dem Touch-Feld per Config vorgeben, zu welcher Zeit welcher Button "gedrückt" werden soll. Für eine meiner Anwenwendungen habe ich bzgl. der Bedienelemente einen Workaround: die Anwendung lässt sich per Hardware (Multitouch) oder per Android-App mit Buttons steuern. Das ist aber keine allgemeine Lösung für die Simulation der Hardware. Diese Anwendung kann ich damit aber komplett ohne reale Hardware testen.

Hallo TF-Team, ich habe meinen Aufbau (der jetzt 8 Monte fulltime stabil lief) nochmal mit einem neuen Gehäuse versehen (mit Makerbeams) und dabei die Firmware aller Master auf 2.3.0 aktualisiert, d.h. auch den Stack komplett zerlegt und wieder zusammen gesetzt. Seit diesem Update habe ich den Effekt, dass sich das LCD sporadisch komisch verhält: teilweise wird die letzte Zeile nicht aktualisiert, teilweise ist der Cursor noch sichtbar, obwohl der Befehl gekommen ist, diesen abzuschalten. Stackaufbau (3 Master mit 10 Bricklets), ganz unten Step-Down: Device: uid=62DrY6, type= MASTER, fw=2.3.0 at port '0' of 0 (main master) Device: uid= avN, type= LIGHT, fw=2.0.3 at port 'a' of 62DrY6 Device: uid= iSG, type= MOTION, fw=2.0.0 at port 'b' of 62DrY6 Device: uid= iEQ, type= SOUND, fw=2.0.2 at port 'c' of 62DrY6 Device: uid= iUj, type=REMOTE_RELAY, fw=2.0.1 at port 'd' of 62DrY6 Device: uid=6Ct7da, type= MASTER, fw=2.3.0 at port '1' of 62DrY6 Device: uid=6Kuxh6, type= MASTER, fw=2.3.0 at port '2' of 62DrY6 Device: uid= dFs, type= TEMPERATURE, fw=2.0.2 at port 'a' of 6Ct7da Device: uid= deY, type= HUMIDITY, fw=2.0.2 at port 'a' of 6Kuxh6 Device: uid= moe, type= SOUND_INPUT, fw=2.0.1 at port 'b' of 6Ct7da Device: uid= d7C, type= BAROMETER, fw=2.0.2 at port 'b' of 6Kuxh6 Device: uid= iJF, type= TOUCHPAD, fw=2.0.0 at port 'c' of 6Ct7da Device: uid= cCm, type= DISPLAY, fw=2.0.6 at port 'd' of 6Ct7da Ich schneide inzwischen den IP-Traffic zwischen IPConnection und brickd mit. Hier ein Beispiel: # Time length UID fun sq - data 1419872659.490810 1E 000098C8 01 90 - 00 00 20 20 53 74 61 72 74 20 4F 53 2D 43 6F 6D 6D 61 6E 64 20 20 1419872659.490845 1E 000098C8 01 A0 - 01 00 20 57 4C 41 4E 20 6F 66 66 20 20 20 20 20 20 20 20 20 20 20 1419872659.490882 1E 000098C8 01 B0 - 02 00 20 57 4C 41 4E 20 6F 6E 20 20 20 20 20 20 20 20 20 20 20 20 1419872659.490914 1E 000098C8 01 C0 - 03 00 20 53 48 55 54 44 4F 57 4E 20 20 20 20 20 20 20 20 20 20 20 1419872659.490950 1E 000098C8 01 D0 - 02 13 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1419872659.490980 0A 000098C8 06 E0 - 01 01 1419872659.491003 1E 000098C8 01 F0 - 02 13 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1419872659.491036 0A 000098C8 06 10 - 01 01 1419872659.491061 0E 0000E830 01 20 - 1E 00 00 00 E8 03 1419872661.078934 1E 000098C8 01 30 - 00 13 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1419872661.078984 0E 0000E830 01 40 - 1E 00 00 00 E8 03 1419872661.323173 1E 000098C8 01 50 - 01 13 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1419872661.323208 0E 0000E830 01 60 - 1E 00 00 00 E8 03 1419872661.567169 1E 000098C8 01 70 - 02 13 20 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1419872661.567229 0E 0000E830 01 80 - 1E 00 00 00 E8 03 1419872662.850181 1E 000098C8 01 90 - 00 00 32 39 2E 44 65 7A 20 31 38 3A 30 34 20 20 7C 0C 0B 0C 0C 7C 1419872662.850218 1E 000098C8 01 A0 - 01 00 20 20 32 31 2E 39 20 DF 43 20 20 20 20 20 33 38 33 20 32 78 1419872662.850254 1E 000098C8 01 B0 - 02 00 20 20 34 36 2E 37 20 25 72 48 20 20 20 20 20 20 20 20 20 20 1419872662.850286 1E 000098C8 01 C0 - 03 00 20 39 36 38 2E 34 20 6D 62 61 72 20 09 20 20 31 30 20 4C 78 1419872662.850321 0A 000098C8 06 D0 - 00 00 1419872662.850342 0E 0000E830 01 E0 - 1E 00 00 00 E8 03 1419872663.257915 1E 000098C8 01 F0 - 00 00 32 39 2E 44 65 7A 20 31 38 20 30 34 20 20 7C 0C 0B 0C 0C 7C 1419872663.448983 1E 000098C8 01 10 - 03 00 20 39 36 38 2E 34 20 6D 62 61 72 20 09 20 20 31 30 20 4C 78 000098C8 ist das LCD. Ich habe "virtuelle" Displays in der Anwendung (nur interner Puffer mit 4*20 Zeichen) und per Touch kann ich die Art der Anzeige ändern. Eine Anzeige nutzt den Cursor, die meisten anderen nicht. Im obigen Beispiel werden alle 4 Zeilen des LCD mit Text gefüllt, dann der Cursor aktiviert, ein wenig verschoben und etwas "gepiept" (ein Piep je Touch). Mit dem Timestamp "1419872662.850181" wird auf den Hauptscreen gewechselt und danach kommt ein lcd_20x4_set_config(false,false), Timestamp 1419872662.850321 - aber der Cursor blieb sichtbar! Ich habe teilweise auch den Effekt, dass beim Screen-Wechsel, wo ich definitiv immer alle 4 Zeilen neu sende, die 4. Zeile nicht aktualisiert wird. Dumm an der Sache: das passiert leider sporadisch, nicht immer gleich, aber erst seit Firmware 2.3.0 und es ist entweder Zeile 4, die den alten Inhalt behält, obwohl ich alle Zeilen neu sende oder der Cursor-Status wird nicht aktualisiert. Ich habe jetzt schon Stunden verbracht, mit dem Versuch das weiter einzugrenzen, aber die Commands werden korrekt zum LCD gesendet, Stecker sind auch alle fest. Ich habe keine andere Idee mehr, als dass hier Commands verloren gehen ? Vielleicht fällt Euch noch was ein? Brickd ist 2.2.0 und der meldet keine Fehler im Protokoll. Der Stack hängt per USB an einem ARM Board.

Es gab mal einen ähnlichen Thread zum QuadRelais: http://www.tinkerunity.org/forum/index.php/topic,2133.15.html Das Problem war damals wohl, dass der Einschaltstrom höher ist als der kurz drauf anliegende Dauerstrom, das führte zum Spannungseinbruch. Versucht mal, mehrere Ports parallel zu schalten.

Du hast die Extension auf den Master-Brick gesteckt (nicht drunter) - oder? Die weißen Kontaktleiten am Rand mit denen die WIFI-Extension auf dem Master sitzt liegen sauber aufeinander? Wenn die Befestigungen zu stark angezogen werden, kann sich der Aufbau evtl. leicht verbiegen und ggfs. Kontakt fehlen. Für einen Test muss es reichen, die WIFI Extension auf den Master zu stecken (Kontaktleisten rasten ein). Die blaue LED an der WIFI Extension zeigt an, dass diese zumindest mit Strom versorgt wird.

Hmm, ganz ohne Netzwerk wird es schwer. Theoretisch könnte man alle Pakete auf einen PC laden (das ist wegen der Abhängigkeiten manuell schon nicht ganz einfach) und dann auf den RED 'kopieren'. Und da würde ich scp nehmen, aber das braucht mindestens lokales Netzwerk. Kann man über brickv Dateien direkt kopieren? (Habe noch keinen, darum die Frage).

Versuch in der Console mal einen apt-cache search gphoto2 Das listet alle in Repositories verfügbaren Packages auf, die das Stichwort "gphoto2" beinhalten. Wenn gphoto2 gefunden wird (und es auch so heisst), dann kannst Du es mit apt-get install gphoto2 nachinstallieren (wenn ich mich nicht irre ).

Noch habe ich keinen RED, daher Frage dazu: Wie ist denn das root-Dateisystem in der fstab eingestellt? Sind dort "noatime,nodiratime" aufgeführt? Wenn nicht, führen auch Leseoperationen zur Aktualisierung des Dateistempels und damit zum Schreiben aufs Dateisystem.

Wie wär's damit: da komme ich mit 4 Dual-Relais aus (=> 1 Master). Schaltplan.pdf

5A bei 12V sollten beim Dual-Relais schon gehen, aber das sind dann schon größere induktive Lasten. Da sollten die Motoren auf jeden Fall entstört sein und möglichst weit weg vom Stack. Und: ich würde auf keinen Fall eine volle Schubumkehr machen. Also immer erst: Motor aus, Richtung umschalten, Motor ein; wieder Motor aus, Richtung umschalten, Motor ein. Bei 6 Motoren würde ich 6 separate 2-Pol-Wechsel-Relais nehmen, die ich per Quad-Relais schalte (also 2x Quad Relais) und dann 3 Dual-Relais, wobei Du mit jedem Dual-Relais 2 Motoren ein/aus schalten kannst (Du brauchst dann 5 Bricklets und 2 Master) Wenn Du ohne separate Relais arbeiten willst (alles mit Dual-Relais) braucht Du je ein Dual-Relais pro Motor für die Richtung plus 3 weitere für ein/aus, also 9 Relais + 3 Master. Nachtrag: wenn Du sicher immer nur 1 Relais an haben willst bzw. wenn mehr als 1 an ist alle in die gleiche Richtung laufen, ginge das auch mit weniger Relais: nur 1 Wechsler und 6x ein/aus Ich kann mal versuchen, Variante 1 von Hand aufzuzeichen.

Meist Du sowas (aus Bereich Fotografie): http://www.brenner-foto.de/default.asp?UIDASP=2014122308110060410718819210547&ARTNR=486010&UG=680&Anzahl=16&Anf=1&Ende=10&SON=5&UE=14,56,680&MENPRO=3&ES= Sowas gibt's von diversen Herstellern mit mehr oder weniger Farben.

Wie viele Motoren willst Du denn ansteuern? Wie viel Strom verbrauchen die unter Last? Und die müssen vermutlich alle einzeln ein/aus geschaltet werden - oder? Wenn viel zu schalten ist, kann ein Ind.Quad-Relais hilfreich sein und über das Quad-Relais dann normale Wechsel-Relais schalten, die jeweils 2-Wechsler besitzen. Das macht die Spannungsumkehr einfacher, aber Du musst separate Verkabelung machen (ggf. löten). Und über das TF Dual-Relais könnte dann der Ein/Aus geschaltet werden. Aber alles etwas abhängig von der Anzahl Motoren, die Du schalten willst.

Prinzipiell kannst Du auch mit dem DC-Brick direkt oder mit dem Servo-Brick plus separate Fahrtregler Motoren steuern. Allerdings wird das teurer als mit Relais, dafür kannst Du die Geschwindigkeit der Motoren gezielt steuern. Wenn Du eh nur "Motor vor/zurück" erreichen willst, ist ein Relais eigentlich schon richtig ... Zu beachten ist noch, dass Du mit dem Dual-Relais zwar vor/zurück steuern könntest, aber dann ein 2. Relais brauchst, um den Motor auch ein/aus schalten zu können (es sein denn, er darf immer laufen).

Hallo foley, ich habe ja keinen Python Mustercode, darum ein Versuch mit einer Art Pseudocode. Variante 1: Display ist an, wenn das Licht entsprechend hell ist (Ambilight-Sensor ist angeschlossen). D.h. tagsüber ist es eigentlich an und abends, wenn eine Zimmerlampe an ist. Das ist aber nicht bewegungsabhängig: int lightOffTimer = 0; bool lightOn = false; bool beenden = false; // kann z.B. per Signal-handler gesetzt werden / Ctrl-C // Hauptverarbeitung lcd_20x4_backlight_off(); while (!beenden) { int lux = ambient_light_get_illuminance() / 10; if (lux >= 2) { // Licht ein ab 2 Lux, wenn's noch nicht ein ist if (!lightOn) { lightOn = true; lightOffTimer = 10; // mindestens 10 Sekunden lang ein lcd_20x4_backlight_on(); } } else if (lightOffTimer > 0) { --lightOffTimer; if (lightOffTimer == 0) { lightOn = false; lcd_20x4_backlight_off(); } } sleep(1); // 1 Sekunde warten } Die Helligkeit könnte man auch noch per Callback aktualisieren lassen. Das ist aber eher eine Optimierung. Variante 2: Display ist an, wenn ein TF MotionDetector-Bricklet eine Bewegung meldet und danach für ca. 20 Sekunden. Wenn sich die Person in den 20 Sekunden erneut bewegt sollte das Licht nicht ausgehen. Das hängt etwas von der Callback-Dauer des Motion-Detectors ab (da gibt es ein Potentiometer ... siehe Doku). int lightOffTimer = 0; bool lightOn = false; bool beenden = false; // kann z.B. per Signal-handler gesetzt werden / Ctrl-C function motionDetected() { lightOffTimer = 20; if (!lightOn) { lightOn = true; lcd_20x4_backlight_on(); } } // Hauptverarbeitung lcd_20x4_backlight_off(); motion_detector_register_callback(MOTION_DETECTOR_CALLBACK_MOTION_DETECTED, motionDetected); while (!beenden) { if (lightOffTimer > 0) { --lightOffTimer; if (lightOffTimer == 0) { lightOn = false; lcd_20x4_backlight_off(); } } sleep(1); // 1 Sekunde warten } Im 2. Beispiel müsste man den Callback noch thread-safe machen, aber das ist zu Beginn erstmal nicht so wichtig. Viel Spaß beim Experimentieren.

Ich prüfe einfach alle paar Sekunden, ob ich noch Spannung/Strom der Step-Down auslesen kann (über einen Master). Eine Alternative ist auch reagieren auf ausbleibende Callbacks, die regelmäßig kommen sollten (alles abhängig vom Aufbau!). Damit kann ich bei mir recht einfach prüfen, ob sich der Stack "aufgehängt" hat oder z. B. die Netzwerkverbindung (bei WLAN) unterbrochen ist. Beim Abziehen der USB-Verbindung müsstest Du DISCONNECTED Events bekommen (http://www.tinkerforge.com/de/doc/Software/IPConnection_VBNET.html#IPConnection.EnumerateCallback), das kannst Du eh auf direktem Wege per API mitbekommen.

Je nach Aufbau kann es noch eine Alternative sein, den Stack aufzuteilen und einfach zwei kleine Stacks über zwei USB-Anschlüsse zu betreiben. Die Anwendung muss auch dafür nicht geändert werden; sieht für die Anwendung aus wie ein Stack. Das hat mein Platzproblem recht einfach gelöst. Und das hat auch in der Art geklappt, dass der eine Stack mit Step-Down den Stack und den SoC mit Strom versorgt und der zweite Stack den Strom vom SoC über USB bekommt. In Summe habe nur ein USB-Kabel mehr.

No, as raphael_vogel already mentioned, you can't use the step-down for 5V input (green jack). This would also be a quite expensive solution: why buy a step-down and supply this with 5V if you can do the same without step-down? You can supply one brick with 5V via USB connector (see remark from raphael_vogel) which powers the whole stack then, not just that one brick.

Hallo zusammen, ich bin heute auf einen Effekt gestossen, den ich für einen Firmware-Bug halte - mindestens für einen unschönen Effekt: Stack mit Step-Down, Master (FW 2.3.0), WIFI Ext., LED-Strip-Bricklet und 50 LED-Pixel WS2801, Framerate 60ms (~15 Hz), C++ Anwendung läuft auf PC. Da das WIFI leichten Schankungen unterliegt kann es passieren, dass auch mal 400ms keine Daten übertragen werden. Wenn das aber passiert, dann stauen sich die Callbacks auf. Als Folge kommen danach in 1ms z.B. 7 Callbacks in der Anwendung an, was in meiner ersten Implementierung dann direkt 7x die kompletten Framedaten gesendet hat (eben 1x pro Callback). Als Folge hat sich der Stack vereinzelt verabschiedet - nur Reset hat geholfen. Dann habe ich das umgestellt auf Semaphores und der Callback sollte nur dann das Senden über einen 2. Thread triggern, wenn nicht eh noch ein Sendevorgang aktiv war. Beim Umsetzen hatte ich kurzzeitig einen Bug im Code und habe quasi dauerhaft Daten gesendet, als Folge hat sich der Stack wieder verabschiedet - nur Reset half. Jetzt ist das bereinigt und ich lege nach dem Senden noch eine zusätzliche Pause von 4ms ein, d.h. auch wenn in 1ms 7 Callbacks kommen, wir nur ein Frame übertragen - dann läuft alles stabil. Es scheint, als würde sich der Stack aufhängen, wenn zu schnell Daten per WIFI gesendet werden. Das ist unschön. Gerade der in der Doku beschriebene Ansatz funktioniert mit WIFI nämlich nicht mehr stabil, da es zu einer konzentierten Anzahl Callbacks kommen kann und eine zu hohe Datenrate den Stack zum Aufhängen bringt - so meine Beobachtung. Viele Grüße

Der Preis des RED liegt unter meinen Erwartungen. Finde ich super, dass Ihr das dafür hinbekommen habt . Das macht den RED sicher noch interessanter für potentielle Käufer, neben der Tatsache, dass der RED einfach super ins System passt und damit extrem klein ist und keine Kabel mehr und und und. Kleine Anmerkung zu dem Touchscreen von Pollin: den hatte ich mir mal für meinen U3 bestellt - und hab ihn prompt wieder zurück gesendet, da die Auflösung nicht zur Auflösung des U3 passt. Teile der Console konnte man nicht sehen und auch im Grafikmodus fehlte immer etwas. Das brachte mir die Erfahrung, dass die Grafik-Chips in SoCs nicht so flexibel sind wie Grafikkarten im PC und das Display schon dazu passen muss. Und das mit der separaten Platine den Kabeln hätte bei mir auch dazu geführt, dass ich es nicht mehr verbaut bekomme - alles andere als kompakt.

Hilft wirklich nur "Strom weg" oder geht auch ein Hardware-Reset am Brick? Ich hatte zu Beginn einige Probleme mit statischer Aufladung "des Bedieners". Ab und zu ist es direkt beim Berühren der Tasten oder des Gehäuses zu einem Reset oder Hänger gekommen, ein Hardware-Reset war dann notwendig. Nachdem der Kunststoff nun etwas älter ist, ist das weg. Ich die Tasten zwischenzeitlich auch noch durch ein Touch-Feld ersetzt.

Das NFC Bricklet hängt in der Luft. Das Kabel hat aber eine Zugentlastung oder? Wenn der Stecker nicht 100%-ig drauf sitzt kann das auch zu Hängern führen.

Bei meinem Bricklet passiert das auch vereinzelt (ca. alle 1-2 Monate 1x). Ich frage die Werte aber nicht aktiv ab, sondern nutze nur den Callback. Das mir bewegen sich die Sprünge in diesem Rahmen (old -> new): 2014-09-03 06:45:16.835961 Found a large pressure delta: old = 961100, new = 895300 ==> ignore this 2014-10-22 23:50:03.564597 Found a large pressure delta: old = 955100, new = 948600 ==> ignore this (meine Werte sind auf über 500m Höhe gemessen ...)

Hallo zusammen, im Shop gibt es einen "U.FL zu SMA Adapter" für das GPS Bricklet. Kann ich da eine beliebige Antenne aus dem Shop verwenden, da GPS-Empfang frequenzunabgängig ist? Viele Grüße

Hallo Batti, nach der ersten Inbetriebnahme habe ich gut 3 Wochen mit den Mittelwerten experimentiert und in den 2 Monaten danach ist mir das aufgefallen. Merken müsste man es eigentlich nach 4-6 Wochen (wenn das bei mir nicht noch ein anderer Effekt ist). In Summe läuft das System bei mir jetzt 5 Monate ununterbrochen. In den letzten 6 Wochen hat sich nicht mehr so viel verändert. Als würde sich das zu Beginn noch relativ "schnell" ändern und dann immer weniger. Viele Grüße