remotecontrol

Sieht sehr gut aus, so flüssig wie noch nie ... Es läuft auch merklich flüssiger als mit der Alternative über setResponseExpected(BrickServo.FUNCTION_SET_POSITION, true). Ich hatte bei der Verwendung der Java-Bindings 2.0.5 nach einer Weile 1x komische "Verwirrungen" in der Kommunikation mit Timeouts. Nach Update dieser auf 2.0.6 läuft bis jetzt alles stabil!

Die Bricks sind mit den mitgelieferten Befestigungen gestapelt, das LCD auch. Die Bricklets hängen an 15 cm Kabel. An die Lcd-Lötpunkte sind Kabel angelötet, die auf einen mehrpoligen Stecker gehen. An diesen Stecker sind die 4 Taster angeschlossen mit ca 20cm langen Kabeln. Die Taster sind im Kunststoffgehäuse eingeschraubt. Wenn die Tasten gedrückt werden bewegt sich nichts in die Nähe der Bricks, hat auch alles viel Abstand und gibt nicht nach. Ich werde einen Taster mal gegen einen anderen austauschen, der einen anderen Anschlag hat.

Tja, passiert mit Firmware 2.0.1 auch :'(. (Temp-Firmware ist noch die neue). Aber was kann dazu führen, dass sich der Stack sporadisch aufhängt oder neu bootet wenn ein Taster gedrückt? Statische Aufladung? Oder ggf. doch extremes Tastenprellen, was zu sehr kurzen Interrupts führen könnte?

Irgendwie schaff ich's immer ... Neben meiner Fernsteuerung hab ich gerade noch ein anderes Projekt und da habe ich gerade die LCD + Temp-Sensor-Firmware aktualisiert. Jetzt habe ich folgenden Effekt, den ich vorher nicht hatte: Wenn ich die Taste 3 (von 0..3) drücke passiert es ab und zu, dass der ganze Stack neu bootet! Die Taste hat definitiv ein leichtes Tastenprellen. Vor dem Update hatte ich eher das Problem, dass mein Cursor dann schneller hüpft als erwartet, das fange ich inzwischen softwareseitig ab. Aber den Neustart-Effekt hatte ich noch nie. Mein Aufbau: - Ras-PI mit C++ Bindings - Brickd 2.0.3, Stack über USB - Step-Down-Power-Supply im Test mit (ca.) 12 V LiPo Akku mit ausreichend Kapa - Ras-PI hängt an der Step-Down mit dran - 1x Master Brick mit Temperatur, Barometer und Feuchtigkeit + LCD ist auch der Hauptmaster, an dem USB dran hängt - 1x Master an dem ein Dual-Relay hängt (wird nicht geschaltet bis zum Reboot) - Master mit Firmware 2.0.5 - LCD und Temp-Sensor frisch aktualisiert - 4 Tasten an den Lötpunkten des LCD - das ganze ist in einem Kunstoffgehäuse Wie erwähnt: vor dem Update der Bricklet-Firmware hatte ich keinerlei Probleme. Jetzt kann ich sporadisch den Stack zum Absturz bringen, wenn ich extern angeschlossene Taster bediene. Leider wieder nur sporadisch aber ist mir binnen 15 Minuten gleich 4x passiert und am Wochenende hatte ich schon gut 1h mit den Tasten gespielt - alles stabil. Edit: Ich schaff' es auch über brickv den Stack zum Hängen zu bringen! Stack dann per USB an Windows-PC, die LCD Seite öffnen, Tasten drücken, dann mal zu anderen Sensoren wechseln, wieder zur LCD Seite und irgendwann ist Ende - keine Werte mehr, keine Reaktion mehr, reconnect geht nicht. Vielleicht versuche ich morgen mal ein Downgrade der LCD Firmware.

Ich teste das mal an wie sich das bei der WIFI Extension als AP verhält. Ein "100Hz Ruckeln" ist ja schon kein merkliches Ruckeln mehr und für mich völlig ausreichend, mehr als erwartet.

Kleine Anmerkung zu dem hier: Genau das mache ich aktuell Client-seitig: ich nutze das LCD mehrfach als "virtuelles" Display und halte daher eh immer den ganzen Inhalt aller Anzeigen im Client. Nur so konnte ich überhaupt den Cursor in Spalte 0 bekommen: das letzte Zeichen einer Zeile aus meinem Client-Puffer nochmal ausgeben. Ich würde nicht zu viel Aufwand in der Firmware betreiben, nur um den Cursor-Sonderfall zu lösen. Eine Funktion in der LCD-API, die einem die "Quellzeile" liefert, wenn der Cursor in Spalte 0 der "Zielzeile" stehen soll wäre aus meiner Sicht ausreichend. Damit ist dann auch das Thema Doku erschlagen.

Der Cursor soll laut Doku hinter dem zuletzt mit writeline ausgegebenen Zeichen stehen. Wenn ich nun an der letzten Spalte des LCD ein Zeichen ausgebe landet der Cursor weder am Anfang der Folgezeile noch am Anfang der aktuellen Zeile (was beides sinnvolles Verhalten wäre), sondern springt in eine ganz andere Zeile, abhängig von der aktuellen Zeile. Für eine gezielte Positionierung auf Spalte 0 muss man daher genau wissen, welche Quellzeile zu einem Sprung in die gewünschte Zielzeile führt.

Hallo zusammen, mit ist aufgefallen, dass die Positionierung des LCD Cursors am Zeilenanfang etwas trial&error erfordert. Um den Cursor am Anfang der Zeile zu positionieren muss man aktuell nicht in der Zeile davor etwas ausgeben, sondern am Ende einer ganze anderen Zeile, in etwa so: if (dest == 2) line = 0; else if (dest == 3) line = 1; else if (dest == 1) line = 2; else if (dest == 0) line = 3; Ist das gewollt / bekannt?

Noch eine Frage: kann ich dem Kommentar jetzt entnehmen, dass die Anfrage beim Hersteller ergeben hat, dass sich der delayed ACK nicht abstellen lässt? Dann muss ich mir nämlich noch was überlegen, um den Durchsatz noch etwas zu erhöhen/optimieren. Aktuell liege ich bei ca. 80 Requests Sekunde (eben mit Response). Was nicht mehr viel ist, verglichen mit 1ms über USB. ... und eine Anregung: wäre ein "ErrorCallback" oder Ähnliches in der API für Euch nicht hilfreich? Ich habe im WLAN Code so ein paar TODO gesehen für Fehlerbehandlung, wo sich auch die Frage stellt: was ist überhaupt eine sinnvolle Fehlerbehandlung. Wenn der Client wenigstens einen Callback mit einem Fehlercode bekäme, würde das oft helfen, Probleme zu analysieren. Bei der LAN Extension ist der Durchsatz potentiel viel höher. Da könnten Puffer noch schneller voll sein.

Für ein anderes TF-Projekt habe ich mir vor wenigen Tagen auch einen zugelegt: der hat bei Amazon nur 40 EUR gekostet.

Das erklärt auch, warum es Ruckler in Kombination mit dem Quad-Relais gibt: wenn die Servo-Response aktiv ist, aber beim Relais nicht, führt der Monoflop-Impuls ohne Response zu einem 200ms Delay in der Netzwerkkommunikation. Wenn ich für alle Befehle eine Response aktiviere, läuft es relativ flüssig . Falls sich am Netzwerkverhalten nichts mehr ändern lässt, wäre ein 3. Zustand beim Handling von 'responseExpected' denkbar (eher kleine Optimierung): Nicht nur responseExpected true/false, sondern auch eine Art 'emptyResponse' Bei 'emptyResponse' kehrt Device.sendRequest zurück, ohne auf die Response zu warten. Der ReceiveThread wirft Responses dieser Art direkt weg

Der tcpdump der ersten Packages beim Aufbau des Sockets Tablet -> PC (ohne Ruckler) sieht so aus 21:23:08.345168 IP Nexus.47643 > mypc.4223: Flags [s], seq 4037415093, win 14600, options [mss 1460,sackOK,TS val 11923547 ecr 0,nop,wscale 6], length 0 21:23:08.345249 IP mypc.4223 > Nexus.47643: Flags [s.], seq 3885023147, ack 4037415094, win 14480, options [mss 1460,sackOK,TS val 54800367 ecr 11923547,nop,wscale 7], length 0 21:23:08.347537 IP Nexus.47643 > mypc.4223: Flags [.], ack 1, win 229, options [nop,nop,TS val 11923548 ecr 54800367], length 0 21:23:08.349080 IP Nexus.47643 > mypc.4223: Flags [P.], seq 1:9, ack 1, win 229, options [nop,nop,TS val 11923548 ecr 54800367], length 8 Und beim Aufbau des WLAN 21:03:55.527714 IP mypc.51853 > tinkertest.4223: Flags [s], seq 1809126939, win 14600, options [mss 1460,sackOK,TS val 53647549 ecr 0,nop,wscale 7], length 0 21:03:55.532842 IP tinkertest.4223 > mypc.51853: Flags [s.], seq 1301543003, ack 1809126940, win 2896, options [mss 1460,nop,wscale 0,nop,nop,TS val 676614046 ecr 53647549], length 0 21:03:55.532956 IP mypc.51853 > tinkertest.4223: Flags [.], ack 1, win 115, options [nop,nop,TS val 53647555 ecr 676614046], length 0 21:03:55.537074 IP mypc.51853 > tinkertest.4223: Flags [P.], seq 1:9, ack 1, win 115, options [nop,nop,TS val 53647559 ecr 676614046], length 8 Was auffällt ist, dass "SackOK" fehlt. SackOK gehört bei dieser Art Verbindung eigentlich mit zum Handshake - oder?

Bei mir redet der PC ja nichtmal direkt mit dem Stack, sondern per GBit Netzkabel mit der FritBox und die sendet die Pakete weg. Nur das Tablet kann direkt mit dem Stack kommunizieren. Umso komischer ist es, wenn das Betriebssystem hier was sammelt. Ich werde mal einen tcpdump versuchen, den Stack auch als AP einrichten und damit testen, ob das einen Unterschied macht.

Hab' nochmal was ausprobiert: Stack per USB+brickd am PC-1. Von anderem PC/Tablet per WLAN auf PC-1 verbunden: läuft relativ flüssig. Direkt per WLAN gegen den Stack ruckt stark (jeweils ohne setResponseExpected). Also kann es eigentlich nicht am Betriebssystem liegen, das dort Pakete gebündelt werden. Völlig überlastet kann der Stack auch nicht sein, sonst würde es bei Anschluß über USB nicht so sauber laufen.

Man merkt den Effekt schon wenn ich Commands unter 30ms sende. Ich kann mir zwar nicht so recht vorstellen, dass das Betriebssystem hier solche Effekte rein bringt (das würde den TCP_NODELAY ja gerade aushebeln), aber ganz ausschließen kann ich es auch nicht. Der Aufruf von setResponseExpected(BrickServo.FUNCTION_SET_POSITION, true) bringt schon mal eine deutliche Verbesserung (bedeutet aber auch, das jegliche Kommunikation zum Stack brav seriell abgearbeitet wird - oder?). Ein erster Test sieht soweit gut aus . Was mir aber auffällt: ich setze ja im Abstand von 1-2 Sekunden Monoflop Impulse für 0,2s Dauer auf ein Quad-Relais. Die werden sehr schnell gesendet, da sie ohne Response sind. Aber gerade wenn der Monoflop aktiv ist und setResponseExpected für Servo auch, scheinen die Servos träge zu reagieren und immer wenn der Monoflop ein ist, hakt es kurz. Was macht der Master in der Zeit, wo der Monoflop ein ist? Kann der Relais-Monoflop überhaupt eine Servo-Response blockieren? Wenn ich diesen Effekt noch weg bekomme, wäre die Kommunikation ausreichend.

Hallo Borg, die Totalausfälle sind weg , ich konnte keinen mehr reproduzieren. Allerdings laufen die Servo jetzt wesentlich 'ruckliger' . Bei gleichmäßiger Datenübertragung sollten sich die Servos einigermaßen gleichmäßig bewegen. Hier hatte ich in der alten Version vereinzelt kleine bis mittlere Ruckler. Jetzt habe ich fast nie eine flüssige Bewegung. Es ruckt ca. im 5 Hz Takt, auch wenn ich die Daten langsamer übertrage. Über USB läuft es schööön flüssig -> liegt also an der WLAN-Kommunikation. Der Effekt war in der alten Version aber wesentlich geringer. Ist noch was anderes verändert, was das bewirken kann? Oder schlägt jetzt ggf. der 200ms Sekunden-Delay (TcpNoDelay - von Stack zurück zum Client) zu, weil weniger Responses vom Stack zurück gesendet werden? Es ruckelt irgendwie zu gleichmäßig. Viele Grüße

Hallo Loetkolben, die Lötpunkte im LCD sind bei mir 'ab Werk' bereits mit Lötzinn gefüllt, d. h. einfach reinstecken wie auf eine Lochrasterplatte geht ja nicht. Das muss erst alles heiß gemacht werden und zwar alle Lötpunkte gleichzeitig, ohne dass am Ende zu viel Lötzinn die Punkte überbrückt. Wenn man einen Pin der Stiftleiste reindrückt und nicht alle Löcher heiß sind, drückt sich ein Pin auf der gegenüberliegenden Seite hoch (verkantet). Zu heiß darf es auch nicht sein, sonst schmilzt der Kunstoff der Stiftleite oder die Platine wird ggf. beschädigt ... Irgendwie bekommt man das schon hin, eine 8-fach LED-Leiste mit 16 Kabeln zu verbinden fand ich einfacher ... Viele Grüße

Kurze Frage dazu: und ich kann mich von einem anderem Computer mit dem Master am Pi verbinden... D. h. über die externe IP des RasPI lässt sich der brickd ansprechen, von localhost aber nicht - korrekt? - Steht der localhost in der /etc/hosts des PI? - Ist das loopback-device gestartet? Der Befehl ifconfig müsste u.a. sowas ausgeben: lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 inet6 addr: ::1/128 Scope:Host UP LOOPBACK RUNNING MTU:16436 Metric:1 ...

Super! Teste ich morgen an.

Das hier hört sich doch nach ähnlichen Problemen an, wie bei mir (http://www.tinkerunity.org/forum/index.php/topic,1339.msg9767.html#new). Aussetzer habe ich auch, mal kurz mal lang, wobei "lang" auch 1 ganze Sekunde sein kann, bis zu dem Punkt, wo sich die WLAN Extension dann ganz verabschiedet. Das ist noch kein "normales" Verhalten, auch für potentiell unsichere Verbindungen.

Hallo Borg, Guter Hinweis, beim Lesen der Beschreibung war mir diese Stiftleiste im Shop nicht im Hinterkopf. Allerdings frage ich mich, wie man als Heimbastler diese Stiftleiste eingelötet bekommt. Einen Lötpunkt heiß zu bekommen und was anzulöten ist schon nicht leicht. Wie macht man das mit 6 Kontakten quasi gleichzeitig? Habt Ihr einen Trick? Außerdem gibt es bei Euch im Shop nichts zum drauf stecken auf die Leiste. Was ist da angedacht? Einen schönen Abend noch.

Hallo TF Team, eine kleine Anmerkung zur Artikel-Beschreibung im Shop: ich habe gerade festgestellt, dass z. B. die 4-Pol Buchse nicht auf eine "Standard"-Lockrasterplatte passt. Vielleicht ergänzt Ihr im Shop noch den PIN-Abstand der Buchsen (2..8-Pol). Beim LCD 20x4 steht noch dieser Text: Das ist nicht mehr aktuell - oder? Ab Version 1.2 hat das LCD doch kleine Taster + Lötpunkte. Die Lötpunkte sind schon ganz schön klein und dicht bei einander. Eine 4-Pol-Buchse für die 4 Taster (Masse dann direkt) wäre für Version 1.3 eine echte Verbesserung . Die kleinen Taster braucht man dann nicht unbedingt. Die sind nett für einen Test. Ist das Display aber eingebaut, dann helfen die eh nicht weiter. Darum wäre mein Vorschlag eine 4-Pol Buchse ... Viele Grüße

Ich habe zu der Zeit nichts geschaltet, am Relais hängt auch noch keine Last. Ich habe jetzt alle Bricklets abgesteckt, Kontakte geprüft, neu ran und auch die Master mal vertauscht: Effekt tritt aktuell nicht mehr auf - vielleicht war ein Kontakt doch nicht ganz dran? Aber ich merke mir mal, dass 0V zurück kommen müssten. Vielen Dank

Hallo, eigentlich liefert Master.getStackVoltage() doch nur dann einen Wert > 0, wenn eine Step-Down PWR-Supply drunter ist. Nun habe ich gerade 2 Master-Bricks übereinander, mit 8 Bricklets dran - über USB verbunden. Sporadisch (alle paar Minuten) liefert getStackVoltage() nun einen Wert > 0, so im Bereich 1.2 bis 1.8 V, dabei frage ich 1x pro Sekunde die Spannung ab (C/C++ API). Ist Euch sowas schon mal aufgefallen? Normal? Mit nur einem Master war der Wert immer 0. Erst mit dem 2. Master der 2 Quad-Relais, 1 Dual-Relais und ein Ambilight dran hat tritt der Effekt auf. Viele Grüße

Abends bin ich wohl nicht mehr voll konzentriert : das "nachholen" der Servobefehle kommt aufgrund der Queue, die ich Client-seitig drin hab. Die ist dafür, damit kein Servo-Befehl verloren geht, wenn gerade ein anderer Befehl aktiv ist. Normal stehen da vielleicht 2-5 Befehle drin. In diesem Fall passiert es aber, dass der Socket-write für 0,5-1,5 Sekunden blockiert und in dieser Zeit viele Befehle auflaufen. Das dürfte aber erstmal kein Problem sein. Aber wenn diese "Blockade" zu oft auftritt, ist irgendwann der Stack der WLAN gar nicht mehr ansprechbar. Das Herabsetzen des Delays zum Auslesen der Spannung (Main.java, sleep) auf z.B. 1165ms verstärkt den Effekt noch etwas.