borg

Firmware: WIFI Extension 2.0 2.1.0 Mesh-Netzwerk Funktionalität hinzugefügt Download: WIFI Extension 2.0 Firmware: Master Brick 2.4.2 Mesh-Netzwerk Funktionen für WIFI Extension 2.0 hinzugefügt Ethernet Extension Socket listen/establish Race Condition gefixt Download: Master Brick

Den Typo hab ich gefixt. Grundsätzlich funktioniert die Update-Funktion, auch mit dem neuen Server. Hat macOS da vielleicht irgendwie eine art DNS cache und versucht auf die alte IP zuzugreifen? Wäre vielleicht ein Versuch Wert den zu löschen: https://coolestguidesontheplanet.com/clear-the-local-dns-cache-in-osx/

The code is on github: https://github.com/Tinkerforge/imu-barometer-fusion/blob/master/imu_barometer_fusion.py See "compute_altitude" for the algorithm.

Die Temp IRs sind angekommen und laufen jetzt seit zwei tagen durch hier . Auf die Gefahr hin wie eine defekte Schallplatte zu klingen: Könntest du bei deinem Master Brick nochmal schauen ob keine Pinne krumm sind? Das würde auch erklären warum am Ende eines der Bricklets gar nicht aufgetaucht ist etc.

Huch? Das kann ich nicht reproduzieren. Bei mir zeigt der "Bricks" Link immer auf "Bricks.html". Das gleiche für die anderen Menüpunkte.

Im Shop sind die "Obermenüpunkte" Teil vom Shop. Wenn du auf Bricklets klickst bekommst du alle Bricklets angezeigt. Wenn es komplett gleich sein sollte wie in der Doku würde oben ein klappbares Menü "Shop" fehlen. Das macht aber auch wenig Sinn .

Ich denke du musst einfach warten bis der Browser das Icon nochmal lädt (Firefox hat jetzt einmal gesehen es gibt keine Logo und wartet dann eine Zeit bis er wieder anfragt). Oder ein paar mal strg+r drücken kann vielleicht auch helfen .

Das favicon sollte jetzt wieder da sein .

Die Startseite ist bis auf "Neues aus dem Blog" in der Tat eher auf Neueinsteiger ausgerichtet. Also meint ihr wir sollten das Video nach ganz unten schieben und "Neues aus dem Blog" nach ganz oben?

Der Shop hat eine Suche. Für den Rest müssen wir mal schauen ob wir da noch etwas bauen können oder ob wir wieder auf google zurückfallen müssen dafür.

Oh, das ist beim Serverumzug in der Tat kaputt gegangen, kümmere ich mich gleich drum. edit: Die Seite ist wieder online .

Ah, also du meinst lieber kein autoplay? Da hatten wir auch bereits drüber diskutiert. Das ist übrigens nur ein Video, wir packen sicher kein Flash auf die Seite . Edit: Hab das autoplay erstmal ausgemacht.

Wo blinkt denn da was?

The new servers with the new homepage are now finally online. The new DNS entry should be known by all of the nameservers by now too. If you find bugs, dead links or you have improvement suggestions please tell us here .

So, die neuen Server mit der neuen Homepage sind jetzt endlich online. Der neue DNS Eintrag sollte sich auch bei allen Nameservern bereits herumgesprochen haben. Bugs, tote Links und Verbesserungsvorschläge bitte in diesen Thread .

The microcontrollers are indeed a little bit more expensive then the EEPROM (which they replace). We currently plan to use the XMC1X00 series industrial MCUs from Infinion for most Bricklets. Modern cortex-m0 micros are probably less expensive then you expect, see here for an idea about the price: http://www.mouser.de/ProductDetail/Infineon-Technologies/XMC1100Q024F0064ABXUMA1/?qs=sGAEpiMZZMuoKKEcg8mMKKywyJ6nXWno8US%2fnU9Cn6GgzMDTUpM3rw%3d%3d

Da sehe ich aktuell kein Problem, die Nase des GH Steckers lässt sich wirklich einfach runterdrücken, viel angenehmer als die SH Stecker. Da wir Stromversorgungen auf den Bricklets vermeiden wollen benötigen wir 5V/GND/3.3V Für die Datenleitungen kommt nur etwas in Frage, das wir per DMA sprechen können und einen Durchsatz von 1000 Nachrichten mit ~80 Byte (64 Byte + Header) pro Sekunde bei 4 Seriell angesprochenen Bricklets erlaubt. Da RS485 oder andere differentielle Schnittstellen zu teuer sind für die kleinen Bricklets bleibt eigentlich nur noch I2C und SPI über. Bei den Datenraten die wir benötigen ist SPI stabiler. Daher die 4 weiteren Leitungen. Wir haben ein eigenes Protokoll für die Co-Prozessor Bricklets, siehe oberster Kommentar hier: https://github.com/Tinkerforge/brickletboot_xmc/blob/master/software/src/bootloader_spitfp.c Grundsätzlich dazu: Die Firmwares auf den Bricklets sind nur kompatibel zu den SAM3/SAM4 MCUs von Atmel. Auf Grund von politischen Änderungen bei Atmel müssen wir aktuell davon ausgehen, dass es für die SAM3/SAM4 Reihe keine Langzeitverfügbarkeit geben wird, wie man es vielleicht von den AVRs kennt. Daher ist ein Umstieg zu einer Lösung mit definiertem Protokoll zwischen Brick und Bricklet alternativlos und bringt auch gleich noch viele andere Vorteile mit. Es braucht sich aber keiner Sorgen zu machen das er irgendwann ein älteres Bricklet nicht mehr ansprechen kann, wir haben kein Problem damit uns nochmal 1000 Master Bricks auf Lager zu legen nachdem wir alle Bricklets umgestellt haben. Die alten Bricks werden immer kompatibel zu den neuen Bricks im Stack sein. Daher kann man das beliebig mischen. So etwas wie Micro-USB, was nicht schon für einen anderen Standard vorgesehen ist und wofür wir günstig Kabel herstellen lassen können gibt es aber leider nicht . Mal davon abgesehen das USB Kabel für Bricklets ziemlich klobig wären.

New homepage and server infrastructure Blog Entry

Neue Homepage und Serverinfrastruktur Blogeintrag

So your fear is that in 3.5 years one of the old Master Bricks breaks and you can't get them anymore so you would have to replace the cables? I don't think this will be a problem, we will still sell Master Bricks that are compatible to the old generation of Bricklets as long as we can get the parts.

SH (alt, http://www.jst-mfg.com/product/pdf/eng/eSH.pdf): Tiefe 4.25mm Höhe 2.95mm Breite 12mm GH (neu, http://www.jst-mfg.com/product/pdf/eng/eGH.pdf): Tiefe 4.05mm Höhe 4.35mm Breite 12mm

I think you may have misunderstood the changes. There is a complete compatibility between the old and new generation of Bricklets during the three years. There are also two different things: There is the switch from "dumb Bricklets" to "Bricklets with co-processor" and there is the switch from 10-pole to 7-pole. The switch from dumb to co-processor Bricklets is necessary, there is really no other viable option. But from a user perspective you won't even notice this. The API and how it is used etc stays the same. If we don't change the connector you won't even notice a difference. The connector change is something for better usability and it is a difference that the user will notice (albeit a small difference). That is why we asked about it. Edit: I added the sentence "In both scenarios the old Bricklets and the Bricklets of the new generation are completely compatible to each other and the old Bricks." to the blog entry and poll to make it more clear !

Das ist der Langzeitplan, ja! Aber wir können die Bricks natürlich erst mit den neuen Steckern ausstatten wenn wir die Bricklets komplett umgestellt haben. Daher wird das ein wenig dauern bis es soweit ist.

Die API wird für den Nutzer gleich bleiben. Da wir die API jetzt einmal für alle Bricklets anfassen, haben wir natürlich die Möglichkeit Verbesserungen durchzuführen und Fehler auszumerzen. Das neue GPS Bricklet bietet z.B. API um an die Position aller Satelliten zu kommen die das GPS Modul gesehen hat und einen Callback für den 1Hz Takt der bei GPS generiert wird. Des weiteren kann es GPS sowie Galileo und du kommst auch an die Satelliten- und Positionsdaten für die Galileo Satelliten. Kann ich mir nicht vorstellen, wenn das die Sorge der Anwender wird, brauchen sie erst gar nicht mit der Programmierung anfangen. U.U. wird es zu Versehen bei der Bestellung kommen, wenn das aber idiotensicher im Shop auswählbar ist, dann kein Problem. Sehe ich Mittlerweile auch so, hat bei uns intern aber zu soviel Diskussion geführt das wir uns dazu entschieden haben einfach die Kunden zu fragen . Bisher ist die Umfrage ja auch ziemlich eindeutig.

Um eine große Auswahl an Sensoren etc nutzen zu können benötigen wir 3.3V, 5V und GND. Dazu haben wir im neuen Standard 4 Leitungen für die Kommunikation. Diese 4 Leitungen sind notwendig um weiterhin 1000 Nachrichten pro Sekunde bei einer maximalen Nachrichtengröße von 64 byte mit vier angeschlossenen Bricklets zu unterstützen. Rein technisch haben wir uns da bereits sehr viele Gedanken gemacht. Ein I2C Bus hätte auch den riesigen Nachteil das wir wieder einen 8m langen Bus bekommen wenn jemand 4x2m Bricklet Kabel verwendet. Angenommen wir wollten über I2C auch den oben angesprochenen Durchsatz erreichen, wären wir weit weg von 400kHz standard I2C. Des weiteren wäre das ein großes Problem bezüglich EMV. CE-Kompatibilität ist bei uns notwendig.