borg

Firmwares: Master Brick 1.4.0 Bugfix: 2 Master in einem Stack haben in 1.3.5 und 1.3.6 zu einem Neustart geführt Support für Master Brick HW Version 2.0 hinzugefügt Download Firmwares: Master Brick

Sorry! Hatte das Problem schon entdeckt, gibt gleich noch eine neue Master Brick Firmware Version! Ich hab durch das messen der USB Spannung einen Fehler in der USB Hotplug Logik eingebaut .

@The_Real_Black: Beim rumspielen mit dem Ad Hoc und Access Point Modus haben wir gerade noch eine bessere Einstellmöglichkeit gefunden und auch gerade schnell noch als 1.3.6 hochgeladen. Ein unverschlüsseltes Netz sollte jetzt besser funktionieren! Da sind auch noch Darstellungsprobleme im Brickv, dafür gibt es morgen eine neue Version.

Dieses Feature ist ja eher für die wenigsten Leute interessant, ich befürchte das eine weitere Spannung im Brick Viewer nur verwirrt.

Der reconnect sollte nur auftreten wenn die Verbindung gewaltsam getrennt wird. Die einzige alternative wäre hier, die Callbacks immer an alle Sockets zu schicken. Das ist auf dem PC vermutlich ziemlich egal. Auf dem Raspberry PI macht das aber z.B. einen riesen Unterschied!

Firmwares: Master Brick 1.3.6 Nutze WSEC=1 anstatt auth mode = open für keine Verschlüsselung (liefert bessere Ergebnisse) Download Firmwares: Master Brick

Firmwares: Master Brick 1.3.6 Use WSEC=1 instead of auth mode = open for no encryption Download Firmwares: Master Brick

Die LED zeigt den Traffic auf den WLAN Sockets an (genauso wie die blaue LED vorne, nur für WLAN). D.h. wenn sie am blinken ist gehen Daten drüber. Ich will auf die anderen LEDs auch noch Status Infos der Extensions legen, wenn das fertig ist hau ichs auch mal in die Doku !

"," im WPA-Schlüssel geht jetzt in Master Brick Firmware Version 1.3.5 (das konnte ich escapen). Was allerdings nicht geht sind Anführungsstriche. Umlaute gehen leider gar nicht, weder in SSID noch Schlüssel. Das GS1011 WLAN Modul sieht nur ASCII Zeichen vor.

So, hab das jetzt mal in 1.3.5 hinzugefügt. Dazu der Hinweis: Diese Spannung dort ist die, die per USB reinkommt. Am Ende bei den Bricklets auf der 5V-Schiene kommt weniger an, da noch ein Diode dazwischen ist!

Worum genau das reassociating nicht funktioniert konnte ich leider nicht ausfindig machen, das GS1011 antwortet einfach nach einer Zeit gar nicht mehr wenn sehr viele Verbindungsversuche stattgefunden haben. Ich hab jetzt in 1.3.5 einfach eingebaut, dass ein komplettes Reset des WLAN Moduls ausgeführt wird wenn es mir für 3 Minuten nicht auf eine Anfrage geantwortet hat. D.h. ihr müsst nach einer langen Auszeit des AP bis zu 3 Minuten warten bis die Verbindung wieder aufgebaut wird.

Firmwares: Master Brick 1.3.5 GetUSBVoltage API hinzugefügt Autoneustart nach 3 Minuten ohne Antwort von GS1011 WLAN Modul Unterstützung für "," in Passphrase hinzugefügt Download Firmwares: Master Brick

Firmwares: Master Brick 1.3.5 Add GetUSBVoltage API Add autorestart after 3min without answer from GS1011 Add support for "," in passphrase Download Firmwares: Master Brick

Bin gerade bei dem reconnect Problem dabei, mir ist im Moment noch unklar warum er irgendwann aufhört sich wieder zu verbinden. Ich kann es aber reproduzieren. Ist halt eine langwierige Geschichte, ich muss nach jeder Änderung erst ne halbe Stunde warten .

Das parsen von den ganzen Werten ist leider vergleichsweise Aufwendig, daher ist das GPS Bricklet Plugin mit dieser API schon voll, einzelne Getter werden wir da unmöglich noch hinzufügen können . Sonst hätte ich das schon getan. Ich denke das ist aber keine Katastrophe, das GPS Modul hat eine update Frequenz von 10hz, sprich man kann einfach beide Callbacks auf 100ms stellen und immer alle Daten zur Verfügung haben ohne irgendwas auch nur annähernd auszulasten.

30V ist exakt das "Absolut Maximum Rating" für den Spannungsregler den wir verwenden: www.aosmd.com/pdfs/datasheet/AOZ1212DI.pdf Das mag gut gehen. Kann aber auch seien, dass die Step-Down Power Supply nach 30 Minuten "Magic Smoke" erzeugt. Ich garantiere für nichts . AC Input geht definitiv nicht!

Die WIFI Extension sollte überall im Stack funktionieren, am besten einmal den DC Brick und die IMU updaten: http://www.tinkerunity.org/forum/index.php/topic,673.msg5715.html#msg5715

Die API wird gleich bleiben. Solche Optionen wie "Antwort für Setter" sind einfach zusätzliche Optionen die gesetzt werden können (Default ist kompatibel zu älteren Versionen). Da sehe ich keine Probleme.

Das ist schon ein bisschen was anderes, ein Dual Relay das ein Plugin ohne Monoflop hat kann ich ohne weiteres mit einem neuen Master verwenden (oder andersrum). Wir hätten dann natürlich den Zustand, dass neue Bricks und Bricklets die wir verschicken vollkommen unbenutzbar zusammen sind im Auslieferungszustand.

Wir sind uns noch nicht zu 100% sicher, aber wir werden nach current/gps/industrial bricklets/ethernet extension evtl einmal einen Strich ziehen und das Protokoll umändern. Die Frage ist wie groß das Chaos da werden würde. Ich würde gerne die Stack ID aus dem Protokoll entfernen und dafür direkt die UID benutzen. Nachrichten werden dann nicht mehr durch das System geroutet sondern an alle verteilt und die Empfänger von Nachrichten gucken nach ob die Nachricht für sie ist. Nachteil: Mehr Daten zu übertragen (1 Byte vs 8 Byte). Vorteil: Robusteres System. Viele Probleme die wir haben kommen durch die starre Verteilung der stack id zustande. Da wir einmal ganz am Anfang wenn das erste mal eine Verbindung aufgebaut wird die Stack IDs erstellen, muss das System danach starr bleiben. Beispiel: In einem Netzwerk aus RS485 Knoten startet ein Stack aufgrund von EMV Problemen neu. Nun Muss der Master des RS485 Netzwerks neugestartet werden, da eine neue Enumerierung durchzuführen ist. Bei einem direkten ansprechen über die UID gäbe es hier kein Problem. Ähnliche Probleme gibt es beim wechseln von Batterien usw. Ein weiterer Vorteil: brickd könnte auf 25 Zeilen Code verkürzt werden (einfach eine Zuordnung von UIDs zu USB Ports, mehr wird nicht mehr benötigt). Desweiteren würde ich noch ein weiteres Byte für Message Optionen hinzufügen, dort könnte man z.B. ein Bit auf high setzen um bei einem Setter zu sagen, dass es eine Rückantwort geben soll (Sicherstellung das ein Setter auch wirklich angekommen ist). Problem an der Geschichte: Wir hätten dann einen plötzlichen Versionssprung für Brickd und alle Brick und Bricklet Bindings, welcher inkompatibel zu allen vorherigen Versionen ist. Hinzu kommt, dass wir hier von einigen Bricklets tausende fertig verpackt und geflasht liegen haben. Die können wir unmöglich nochmal auspacken und neu flashen. Das würde also ein totales Versionschaos geben... Was meint ihr dazu?

Klar, ich musste dafür sogar damals Support für den sam3s erst zu openocd hinzufügen: http://www.mail-archive.com/openocd-development@lists.berlios.de/msg13361.html Da kann man auch sehen wie lange wir schon an dem Kram gearbeitet haben bevor wir online gegangen sind .

Oh, was hast du denn genau getan um das Problem zu beheben? Gab es da eine spezifische Konfiguration?

Beim Master Brick wäre das sogar die Spannung ungefähr zu bestimmen. Bei den meisten anderen Bricks allerdings nicht (USB VREF liegt nicht auf einem AD Pin).

Kurzer Hinweis: Wir haben heute schon ca. ~25 Bestellungen mit Barometer Bricklet gepackt die morgen rausgehen, die sind jetzt natürlich noch auf Firmware Version 1.0 und müssen erst geupdatet werden um dieses Feature zu haben! Alle Bestellungen die heute reingegangen sind und danach bekommen gleich die neue Firmware Version.

Wenn du den Brick in den Bootloader bringst meldet es sich als neues Gerät an. Dann musst du es in der VirtualBox nochmal durchreichen, auch wenn es vorher schon durchgereicht war!