borg

That would be very hard to realize with the protocol we are currently using to transfer data between the Bricks and a PC. With the protocol we are transfering 1000 messages per second and a message has a max size of 64 byte. That makes a bandwith of 64Kb in total. Also, we can't possibly achieve a similar price to existing USB sound cards: http://www.amazon.com/Virtual-5-1-surround-External-Sound-Card/dp/B000N35A0Y/ref=sr_1_2?ie=UTF8&qid=1358157708&sr=8-2&keywords=usb+sound+card This price is preposterously low, it would cost 10 times as much if we would produce this thing.

Yes, currently you always need a PC connection. But your PC can also be a tablet or smartphone or Raspberry PI!

@Nic: Wir haben jetzt U.FL zu SMA Adapter im Shop: https://shop.tinkerforge.com/accessories/gps-pigtail-cable.html SMA GPS Antennen gibt es überall. Getestet hab ich hier mit: http://www.aldafunk.com/GPS-Antennen/GPS-Antenne-Magnetmontage-SMA-Male::143.html Der Empfang ist damit trotz 5m Kabel sehr gut (ist aber ein bisschen teuer die Antenne).

Klingt sinnvoll. Wir würden dann dafür einfach zusätzlich API hinzufügen. Was haltet ihr von "setValueSelective(pin_mask, value_mask)" oder "setPartialValue(pin_mask, value_mask)"? Wie würdet ihr es nennen?

WTF? Das macht keinerlei Sinn . Wie sieht denn die Software aus, fängst du vielleicht irgendwo Timeouts ab ohne es mitzubekommen?

Mit Protocol V2 (was im Laufe der nächsten Woche veröffentlicht wird), geht das. Du ziehst das LCD Bricklet im laufenden Betrieb ab? Das ist so leider nicht erlaubt . Der Brick hat keine Möglichkeit mitzubekommen ob das Bricklet im laufenden Betrieb an/abgesteckt wurde.

Ui, ich bin gespannt .

@Nemo: 1.1.18 sollte auf einem 10.8.2 Macbook funktionieren. Soweit ich das sehe gibt es nur Probleme bei OS X < 10.8, da es dort noch kein CoreText gab. Wir werden aber noch ein 1.1.19 releasen das wieder kein CoreText benötigt. @boscha: What version of Brick Viewer did crash for you?

Ist gefixt, Danke für den Tipp!

Echt komisch. Du hast aber bei beiden RS485 Extensions auch die gleichen Einstellungen, ja? Ich hatte schonmal ausversehen in einem Netzwerk eine RS485 Extension mit 1 Stopbit und eine mit 2 Stopbits. Das funktioniert dann auch nur sehr sporadisch. Wenn es einwandfrei funktioniert sobald du nur einen RS485 Slave hast, kann es ja nicht am AP liegen, denke ich. Du könntest auch noch einmal Probieren das EEPROM auf allen RS485 Extensions einmal auf Auslieferungszustand zurück zu setzen (im Brick Viewer unten bei "Configure Extension Type" nochmal RS485 auswählen).

Wie ist die WLAN Extension denn konfiguriert (AP/Verschlüsselung etc)? Der Power Mode steht nicht zufällig auf Low Power oder? 200ms roundtrip-time ist in der Tat ein bisschen langsam.

@Einstein: Kannst du mal probieren die WIFI Extension auf AP zu stellen? Um zu gucken ob dein Router oder QOS etwas damit zu tun haben. Wie meintest du das? Wenn du den Aufbau wie oben hast und den "leeren" RS485 Stack entfernst funktioniert es?

Komisch, wir haben ja intern eigentlich ein 2,5 Sekunden Timeout. Da sollten 6-9ms nichts ausmachen.

Kann ich leider auch nicht reproduzieren . Ich hab den gleichen Aufbau nachgestellt. Screenshots von der Konfiguration sind angehängt. Ich lasse das mal über Nacht laufen bis morgen.

Kann ich leider nicht reproduzieren.

Very cool !

Firmwares: IMU Brick 1.0.11 Korrekte Rückgabe aus Interrupt (Fix für Bug im Zusammenhang mit GPS Bricklet) Download Firmwares: IMU Brick

Firmwares: IMU Brick 1.0.11 Return correctly from interrupt (fixes bug related to GPS Bricklet) Download Firmwares: IMU Brick

@Einstein: Kommt als nächstes. Hab ein paar Tage an dem IMU/GPS Problem gesessen: http://www.tinkerunity.org/forum/index.php/topic,1258.0.html

Puh, hab das Problem gefunden. Hat mich ganz schön viel Zeit gekostet und fast zur Verzweiflung gebracht . Der IMU Brick benutzt DMA zum auslesen der Sensordaten über I2C. Beim letztem Interrupt, nachdem der letzte Sensor ausgelesen wird gebe ich die Kontrolle wieder an FreeRTOS ab. Stellt sich heraus, dass dies undefiniertes verhalten auslöst wenn die Priorität vom Interrupt größer ist als vom FreeRTOS task: http://www.freertos.org/a00110.html#kernel_priority Vielen Dank für den Hinweis! In Theorie könnte der IMU Brick dadurch immer instabil gewesen sein, warum es erst spezifisch Probleme macht wenn das GPS Bricklet angeschlossen ist kann ich nicht sagen, undefiniertes verhalten halt. Gibt dann morgen eine neue IMU Brick Firmware Version. Das gleiche Prioritäten-Problem gibt es übrigens auch in der Temperture IR Firmware. Dort kann ich es allerdings nicht so einfach beheben, da die Bricks die passende API dafür nicht bereitstellen. Da muss ich nochmal drüber nachdenken was ich da mache, evtl gibt es dafür nochmal eine neue Firmware für alle Bricks.

Ich denke du meinst das Bild: http://download.tinkerforge.com/press/media/industrial_hutschiene_tilted.jpg Das graue Teil was auf der Hutschiene sitzt ist von WAGO: http://www.reichelt.de/Hutschienengehaeuse/WAGO-288-001/3/index.html?;ACTION=3;LA=446;ARTICLE=67255;GROUPID=3358;artnr=WAGO+288-001;SID=11UOoRIH8AAAIAACUzYoE27a83d737f5211b790480cfd59398c80 Das Plexiglas auf dem die Bricks sitzen ist gebastelt.

Die Maximale Stack-Größe ist 1*Step-Down Power Supply + 1*Master + 8*Brick + 2*Extension 6 Stepper Bricks geht also. Wie groß sind denn die Schrittmotoren? bei > 1.5A ist es vermutlich eine gute Idee die Bricks mit Abstandshaltern zu verschrauben (die nehmen erstaunlich viel Wärme auf) und mit einem Lüfter zu zu kühlen.

Es werden im Stack insgesamt 20 Leitungen für die externe Spannung verwendet (10x gnd und 10x vcc), die je für 500mA spezifiziert sind. An und für sich sollte das also vollkommen egal sein ob der Servo Brick über den Stack oder über den eigenen Anschluss versorgt wird.

Oh. Gucke ich mir an.

Das scheint da immer bei einem Versionmismatch zu stehen, wenn du das in google wirfst findest du das häufiger in bugtrackern und es hat immer mit falschen oder nicht korrekt installierten Versionen zu tun.