borg

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!

Mh, vielleicht hat Windows sich gemerkt dass der AP einen Key verlangt und glaubt das fälschlicherweise noch? Also du den Key eingetragen hast, war er im Hexadezimal Format und 64 oder 128 Bit groß? http://www.andrewscompanies.com/tools/wep.asp

Ist jetzt im Shop . Übergeben des QNH ist im Moment nicht drin, wir hatten Probleme die maximale Plugin Größe für die Bricklets (4kb) einzuhalten. Das einzige was mir dazu einfällt, ist vielleicht beim calibrate den Luftdruck angeben zu können und 0 zu nutzen um ihm auf den aktuellen zu setzen. Mhh, würde jetzt natürlich die API brechen wo sie schon veröffentlicht ist. Mal schauen ob wir da am Montag noch schnell einbauen bevor die ersten Barometer Bricklets angekommen sind . Aber wenn wir es nicht mehr reinkriegen kann man das ja auch vergleichsweise einfach extern berechnen.

Mh, keine Ahnung wie wir es anders darstellen sollten?

Lastschrift und Kreditkarte wird über Heidelpay abgewickelt (http://www.heidelpay.de/).

Ui, gefällt mir! Hattest du die Aluwinkel gerade passend rumliegen oder sind die extra dafür gedacht?

Interessant, hab ich so noch nicht getestet. Probiere ich gleich mal aus!

Mh, gedacht sind die Befestigungskits ja im Prinzip um Stapel zusammenzuschrauben. Da ist dann unten im Stapel das Außengewinde und dir fehlt noch ein Abstandshalter und eine Mutter um alles perfekt festzuschrauben (also du schraubst noch ein Abstandshalter drunter, im Hartkarton ist ein Loch und unterm Hartkarton schraubst du mit Mutter fest). D.h. hier musst du dir noch ein zusätzliches Brick Befestigungskit pro Stapel kaufen und es kommt perfekt hin! Du willst jetzt einen einzelnen Brick befestigen, dazu den Abstandshalter "falschrum" an den Brick schrauben und dann fehlt eine Schraube. Muss ich dir recht geben. Du könntest einfach zusätzlich ein Bricklet Befestigungskit kaufen, da sind schrauben drin . Ich schreib es mir aber auf, wenn wir das nächste mal die Brick-Befestigungskits bestellen machen wir einfach Schrauben mit rein.

Firmwares: Master Brick 1.3.4 Möglichkeit zum setzen der WIFI Regulatory Domain (Anzahl der Kanäle) hinzugefügt Download Firmwares: Master Brick

Firmwares: Master Brick 1.3.4 Add API for setting of WIFI regulatory domain Download Firmwares: Master Brick

Den Kanal kannst du auf der Fritz Box unter WLAN -> Funkkanal nachgucken. Die Anzahl der Kanäle kann werde ich aber in der nächsten Master Brick Firmware einstellbar machen (siehe anderer Thread).

Sieht einfach so aus als wäre ein Voltage Bricklet Plugin auf dem IO-16. Warum geht denn das Flashen nicht? Was sagt er denn?

Oh, kann das Probleme machen? Das könnte ich umstellbar machen (oder einfach fest auf die vollen Kanäle stellen, muss ich mich nochmal informieren wie das rechtlich ist). Edit: Neue Master Version ist da, neue Brick Viewer Version folgt im laufe des Tages.

Wir benutzen eine USB Endpunkt Größe von 64 byte aus und die ganzen Nachrichten sind darauf ausgelegt. D.h. inkl. dem Overhead für das Protokoll was wir schicken ist damit die komplette Paketgröße ausgeschöpft. Ist also ein rein technische Begrenzung.

Wir würden vor allen auch gerne wieder Tests zur Entfernung im freien und mit unterschiedlichen Antennen machen, wie damals mit Chibi. Setzt allerdings gutes Wetter voraus .

Wir haben hier seit heute morgen einen WIFI Stack im Dauertest am laufen, bisher hat er sich noch nicht aufgehängt. Ich schreib mehr dazu sobald wir das reproduzieren konnten, wenn da ein Fehler im reassociating Code ist sollte das eigentlich leicht auffindbar sein. Wenn die Verbindung zum AP für kurze Zeit verschwindet, und ein reconnect stattfinden muss ist es immer kritisch. Dann kann es passieren dass die Socket-Verbindung geschlossen wird. Im Moment muss dann ein neues Enumerate stattfinden. Dafür wird es morgen neue Bindings geben, die nach einem Verlust der Socket-Verbindung versuchen sich wieder zu verbinden um so ein weiterlaufen zu erlauben (ohne neues Enumerate!). Das sollte die ganze Sache schon viel robuster machen.

Firmwares: Master Brick 1.3.3 Add Hoc und Access Point Modus Unterstützung hinzugefügt Download Firmwares: Master Brick