borg

Wir können das neue Protokoll heute leider noch nicht veröffentlichen, wir haben in letzter Minute noch Fehler im USB Code gefunden, an dem ich jetzt schon den ganzen Tag rumdebugge. Desweiteren wollen wir nochmal die kompletten neuen Enumeration/Connect/Disconnect/ResponseExpected Funktionen in allen Sprachen gründlich durchtesten, da wir dort unerwarteterweise noch Bugs gefunden haben in den C# und Java Bindings.

Weiterentwickelt gar nicht. Schwere Bugs werden wir noch fixen. v1 Firmware für neue Bricklets wirds nicht geben. Der neue Brick Viewer kann automatisch alte (V1) Bricklets an einem neuen (V2) Brick updaten. Bricks selbst müssen "händisch" aktualisiert werden. D.h. in den Bootloader Modus bringen und im Flashing Menü den passenden Brick Typ auswählen. Wir haben einen "Transitioning Guide" in dem für alle Sprachen die relevanten Änderungen kurz mit Codeschnippseln dargestellt werden: http://www.tinkerforge.com/doc_v2/Transitioning_Guide_1To2.html Bei den allermeisten Sprachen muss nur der Enumerationsprozess überarbeitet werden, der wurde Aufgrund der vielen Fragen und des vielen negativen Feedbacks komplett überarbeitet (Device IDs anstatt Strings parsen, genug Informationen um die komplette Brick/Bricklet Netzwerk Topologie aufzubauen etc). In fast allen Sprachen dürften Anpassungen im Code nur ein paar Minuten dauern. Ausnahme ist da evtl C#, dort hat sich relativ viel geändert (CLS-Compliance, sender Objekte, neue Callback Syntax etc). Das waren aber alles sehr häufig angefragte Änderungen!

Habs mir auf die TODO Liste geschrieben, hat aber keine hohe Prio .

"selection_mask" gefällt mir, das hab ich gleich überall übernommen: https://github.com/Tinkerforge/generators/commit/f6891ca88ce2e6656bf3487b13ce25f892bde115 Die Implementierung folgt dann jetzt. PS: Wir werden dann jetzt definitiv auch diese Woche noch Protokoll V2 veröffentlichen.

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.