gagahhag

Die Kabel und Anschlüsse sehen gut aus. Ich habe mir aber noch überlegt, ob es Probleme mit der rechtwinkligen Stiftleiste geben könnte. Auf den ersten Blick sehe ich da kein Problem, muss das aber mal genauer anschauen. Könnte mir vorstellen, dass beim Löten etwas schief gegangen ist, v.a. da es gleich bei 2 Bricklets das gleiche Problem gibt. Ich habe es noch nicht geschafft, diese falsch herum einzustecken ;-) Aber, habe das überprüft, dass sie richtig sind.

Hallo zusammen ich habe ein ähnliches Problem wie Borg hier: http://www.tinkerunity.org/forum/index.php/topic,1602.msg10705.html#msg10705. Bei mir wird der LCD zwar richtig als HW 1.2 erkannt, jedoch wenn ich den 4ten Button drücke, meldet er sich als Button 3. Mein Stack ist folgendermassen aufgebaut und alle FWs sind aktuell: WIFI Extension | | +--A--> Temperatur | +--B--> | +--C--> | +--D--> | | Master (HW 1.1) | | +--A--> Barometer | +--B--> Humidity | +--C--> LCD20x4 1.2 | +--D--> Ambient Light | | Master (HW 2) Ich habe den Display noch nicht an andere Ports angeschlossen und kann daher keine Aussagen diesbezüglich machen. Das gleiche Problem habe ich aber auch mit anderer Hardware mit folgendem Aufbau: WIFI Extension | | +--A---> Ambient Light | +--B---> Barometer | +--C---> Humidity | +--D---> LCD20x4 1.2 | | Master (HW 2) Kann dies jemand nachvollziehen? Grüsse Gagahhag

Eine ähnliche Diskussion hatten wir schon kürzlich: http://www.tinkerunity.org/forum/index.php/topic,1621.msg10834.html#msg10834

Da gebe ich dir voll und ganz recht und stellt insofern kein Problem dar. Ich persönlich (und anscheinend auch andere) finde das ganze Verhalten etwas 'undurchsichtig'. Soweit so gut, ich werde mich damit abfinden können.

Quadrocopter? Zusammen mit GPS und Servo wäre das theoretisch möglich. Praktisch würde ich das gerne ausprobieren

Habe noch ein bisschen getestet. Diesmal nur mit einem Stack aus 2 Master (ohne Bricklets). Ich habe dabei die IPConnection-Demo etwas abgewandelt um das Verhalten zu testen: import java.util.Scanner; import com.tinkerforge.IPConnection; public class Test { private static final String host = "localhost"; private static final int port = 4223; // Note: To make the example code cleaner we do not handle exceptions. Exceptions you // might normally want to catch are described in the documentation public static void main(String args[]) throws Exception { // Create connection and connect to brickd IPConnection ipcon = new IPConnection(); ipcon.connect(host, port); // Register enumerate listener and print incoming information ipcon.addEnumerateListener(new IPConnection.EnumerateListener() { { System.out.println("Added EnumerateListener"); } public void enumerate(String uid, String connectedUid, char position, short[] hardwareVersion, short[] firmwareVersion, int deviceIdentifier, short enumerationType) { if(enumerationType == IPConnection.ENUMERATION_TYPE_CONNECTED) { System.out.println("UID: [" + uid + "] connected"); } else if(enumerationType == IPConnection.ENUMERATION_TYPE_AVAILABLE) { System.out.println("UID: [" + uid + "] available"); } else if(enumerationType == IPConnection.ENUMERATION_TYPE_DISCONNECTED) { System.out.println("UID: [" + uid + "] disconnected"); } } }); System.out.println("Plug in USB and press Any Key\n"); new Scanner(System.in).nextLine(); System.out.println("\nEnumerate #1:"); ipcon.enumerate(); new Scanner(System.in).nextLine(); System.out.println("\nEnumerate #2:"); ipcon.enumerate(); System.out.print("Press Any Key\n"); new Scanner(System.in).nextLine(); ipcon.disconnect(); } } Der Output ist dabei wie oben beschrieben, dass beim Verbinden per USB nach dem Verbinden zu brickd der EnumerateListener aufgerufen wird; EnumerateType CONNECTED. Das komische dabei ist, dass der erste Master 2x gemeldet wird. Das sollte so nicht sein, oder? Output: Added EnumerateListener Plug in USB and press Any Key UID: [6rjyf7] connected UID: [6rjyf7] connected UID: [68xGay] connected Enumerate #1: UID: [6rjyf7] available UID: [68xGay] available Enumerate #2: Press Any Key UID: [6rjyf7] available UID: [68xGay] available Das gleiche Spiel ohne geänderten Code (nur Host wurde angepasse), sieht der Output folgendermassen aus: Added EnumerateListener Plug in USB and press Any Key UID: [6rjyf7] connected Enumerate #1: UID: [6rjyf7] available UID: [68xGay] connected UID: [68xGay] available Enumerate #2: Press Any Key UID: [6rjyf7] available UID: [68xGay] available Ich hätte jetzt nach dieser Diskussion den gleichen Output erwartet. Es scheint, dass das Verhalten mittels brickd oder WLAN nicht das gleiche ist und sollte IMHO angepasst werden.

Habe gerade nocheinmal etwas komisches in diesem Zusammenhang entdeckt. Aufbau des Stacks wie gehabt: 2 Master, 1 WLAN Extension (zuoberst). Am 1. Master habe ich 4 Bricklets, am 2. Master 1 Bricklet. Jetzt verbinde ich per WLAN und das darauf kommende Enumate-Event bringt mir nur die Brick/lets des 1. Master. Der EnumerateListener wird also 5x aufgerufen. Vom 2. Master weiss ich aber bis jetzt noch nichts! Wenn ich jetzt aber das enumerate() forciere, werden alle Brick/lets vom 1. Master UND diejenigen vom 2. Master aufgerufen. EnumerateListener wird 7x aufgerufen. Nach den Erklärungen von vorhin hätte ich jetzt erwartet, dass auch beim ersten Enumerate ALLE angeschlossenen Brick/lets gemeldet werden. Habe ich da wieder etwas falsch verstanden?

Ok, ich habe jetzt angenommen, dass es keine Rolle spielt, ob ich per USB oder per WLAN verbinde. Zitat aus der WLAN Extension Dokumentation: "From the programming perspective this is completely transparent..."; Oder aber ich habe ein Verständnisproblem von WLAN vs. USB. Das connect() verbindet dann mal auf den Deamon (USB: brickd, WLAN: whatever), soweit so gut, da passiert ja noch nicht viel. Wenn ich aber ein EnumerateListener hinzufüge, löst dies bei WLAN sofort ein enumerate() aus, bei USB aber nicht? Für mich tönt das nicht ganz logisch. Vielleicht kann mich da jemand etwas erleuchten.

So, habe noch ein bisschen rumgetestet und bemerkt, dass ich wahrscheinlich irgend etwas noch nicht richtig begriffen habe (oder es wirkling ein Bug ist). Wenn ich ein neue Verbindung zum Stack aufbaue (über WLAN) und anschliessend bei der IPConnection ein EnumerateLister hinzufüge, wird dieser sofort aufgerufen. Ich brauche keinen Aufruf von ipCon.enumerate() mehr. Ist das so gewollt? Ich habe mal das Beispiel von http://www.tinkerforge.com/en/doc/Software/IPConnection_Java.html#ipcon-java ausprobiert mit dem selben Ergebnis, dass alle Bricks und Bricklets 2x ausgegeben werden. Den ganzen Stack per USB angeschlossen und das gleiche Programm (Verbindung auf localhost) führt jedoch zum erwarteten Ergebnis. Alle Bricks und Bricklets werden nur 1x ausgegeben. Ich denke, so sollte es auch über WLAN sein?

Ich habe mir einen Stack mit 2 Master Bricks und einer WLAN Extension gebaut. Die 2 Master benutze ich, damit ich 5 Bricklets anschliessen kann. Das Problem, welches ich jetzt habe ist, dass die Kommunikation über WLAN extrem langsam ist; d.h. ich kriege immer eine TimeoutException, wenn ich z.B. versuche ein CallbackPeriod zu setzen. Der ganze Stack per USB verbunden funktioniert super und ohne Problem (auch über Netzwerk mittels Raspberry Pi; nur eben nicht über WLAN. Kann es sein, dass die WLAN Extension direkt auf den untersten Master gesteckt werden muss? Ebenfalls sind die Master 2 unterschiedliche HW Versionen (1.1/2.0) aber beide haben die gleiche Firmware. Ich werde mal versuche, ob die Kommunikation mit nur 1 Master besser ist aber vielleicht kann das jemand meinen Stack mal nachbauen und ausprobieren?

Ja. Ich habe jedoch zusätzlich zum Step-Down meine 2 Stepper direkt an der Stromquelle angeschlossen. In einem anderen Thread habe ich mal ein Bild davon eingestellt, wo man das (knapp noch) sehen kann: http://www.tinkerunity.org/forum/index.php/topic,875.msg6099.html#msg6099. Notwendig wäre das Ganze aber nicht gewesen, da der Step-Down bis 3A liefern kann und alleine reichen würde.

Hallo Jonas die 4.7 bis 5.4 Vold ist die Spannung, die USB selbst hat. Das Beste ist, wenn du zusätzlich noch einen Step-Down Power Supply verwenden würdest. Dann ist ein LiPo kein Problem mehr, habe ich auch so gemacht und einen 5S LiPo angehängt. Die andere Möglichkeit wäre, wenn du einen zusätzlichen Widerstand zwischen Master und LiPo schalten würdest und so die Spannung des LiPo (ich denke, ein 2S?) für den Master auf 5V bringen würdest... aber ob das Sinnvoll ist sei dahingestellt.

Natürlich darf hier die Stack-to-Stack Verbindung der Chibis nicht fehlen

@AuronX: Danke für deine Antwort. Irgendwie sind wir hier etwas abgedrifted mit der Diskussion. Wie ich die TF ins eigene WLAN mittels SoftAP (oder wie auch immer) kriege, ist eigentlich kein Thema. Ursprünglicher Gedanke war die Möglichkeit einer Brick-to-Brick Kommunikation mittels WLAN-Extension. Aber anscheinend bin ich der einzige, der so komische Ideen/Wünsche hat PS: Und ja, ASCII-Art ist immer wieder was schönes!

Genau, nur, dass ich dann über USB und 'Master-TF' die anderen Slaves ansprechen kann. Ich will eben den zweiten AP vermeiden.

So hast du natürlich recht, hab ich auch so schon gemacht, da reicht eigentlich auch nur ein AP wobei der Stack und der Laptop/PC am AP hängt und der Laptop/PC zugleich an Ethernet. Das ist auch nicht so ein Problem und aktuell im machbaren. Dies setzt aber voraus, das ich Ethernet UND WLAN habe. Mein aktuelles 'Problem' ist, dass ich Ethernet und ein Corporate WLan habe wobei ich mit TF nicht ins WLAN komme (leider). Daher eigentlich auch die Idee, dass sich TF ein 'eigenes' Netz aufbauen. Als Beispiel könnte hier das Sonos Soundsystem erwähnt werden, die das gleiche machen. Konfigigurationsmässig könnte das in etwa so funktionieren: Master-TF wird definiert mit fixer Adresse (192.168.1.1) und fungiert als Gateway mit PC über USB. Slave-TF kriegt fixe Adresse (192.168.1.x) und versucht sich beim Start an Master-TF 'anzumelden', dieser merkt sich die anderen Slaves und 'routet' sie über USB an den Rechner weiter. Einzelne Meldungen vom Rechner kann der Master dann normal von USB auf WLAN 'routen' und entsprechen and die Slaves weiterreichen. Ich könnte das auch weiterdenken: Ein Master-TF wird mit (kommendem) Ethernet-Brick und WLAN wie oben konfiguriert. Die Kommunikation geht dann nicht über USB<->WLAN sondern halt Ethernet<->WLAM, wobei der Master noch über PoE betriegen wird :-D.

Die Möglichkeit hätte man schon, aber ich kann mit dem PC oder Laptop nicht immer zwischen zwei Netzen wechseln ;-)

Genau, das wollte ich eigentlich erreichen, v.a. da ich keine Chibis mehr kaufen kann :'( Theoretisch wäre dies aber sicherlich möglich, oder?

Hallo zusammen Ist es möglich mittels den WiFi-Extension eine Many-To-One Verbindung hinzukriegen? Ich denke da an die Möglichkeit der Chibi-Extension, dass ich einen Stack per USB an einen Rechner schliesse und dann über diesen auf weiter Stacks transparent zugreifen kann. Die Problematik ist die, dass ich entweder a) am Rechner kein WiFi habe oder b) ich mit dem Rechner per WiFi verbunden bin, die Stacks aber nicht ins gleiche Netz anmelden kann/will. Hat dies schon jemand versucht?

Bin gerade mein RaspPi am ausgraben und habe festgestellt, dass es eine kleine Unschönheit in der Doku gibt: http://www.tinkerforge.com/en/doc/Embedded/Raspberry_Pi.html#soft-float-debian-armel 'update-rc.d brickd defaults' und '/etc/init.d/brickd start' sollten auch als root (sudo) ausgeführt werden.

Ist mir leider auch schon passiert. Seither lasse ich ein leerer grüner Stecker immer eingesteckt.... ich kenne mich

Ich melde mich auch wieder mal. Bin zur Zeit ziemlich mit Häuslebauen beschäftig und hatte mal länger kein I-Net . Zum Thema TF und Android habe ich mein letztes Projekt (http://www.tinkerunity.org/forum/index.php/topic,875.0.html) mal auf Android portiert und kann das Ding jetzt über WLAN fernsteuern, sprich einen Weg definieren, welcher dann abgefahren wird. Wenn ich mal Zeit habe, stelle ich den Code hier rein. Die Portierung selbst war sogar einfacher als ich gedacht habe und war in ein paar Stunden ohne Android-Erfahrung gemacht...

Genau, war ein Tippfehler... aber tönt doch gut

+1 - Bitte keine Sonderzeichen in den Namen...

Ich selbst habe eine Priority-Queue von Move-Objektion genommen. Ein Move ist bei mir eine Klasse, welche die Art der Bewegung (Strecke von x mm, Drehung um x Grad, Kurve von Radius x um y Grad, etc.) Diese stelle ich die Queue, welche dann Schritt für Schritt abgearbeitet wird. Wenn ich dazu komme, werde ich meinen Code ein bisschen dokumentieren und dann hier mal reinstellen. Aber ist (noch) nicht so schön, wie ich mir das wünsche -> Prototyping