borg

Ich hab hier z.B. gerade eine Bestellung offen mit folgendem Inhalt: * 3x WIFI Extension * 3x Master Brick * 3x Motion Detector Bricklet * 3x USB Netzteil Bestellungen dieser Art sehen wir häufig. Darauf basiert die Idee im Prinzip. Also ein neues Baukastensystem (mit neuem Protokoll usw. welches auf Low-Power ausgelegt ist), richtig? Wie viel dürften denn die einzelnen Funksensoren in diesem Baukastensystem maximal kosten? Der Tchibo-Aussen-Temperatursensor ist so billig weil die ihre eigenes Ding bauen und dafür eine Funkabnahme machen. Die Kosten der Abnahme fallen bei 100000er Stückzahlen nicht so ins Gewicht. Wir müssten ein Modul mit Funkabnahme nehmen (z.B. XBee). Diese Module sind wie gesagt aktuell erheblich teurer als WiFi oder BLE Module.

Zwei Bilder vom aktuellen Prototyp:

Mir gefällt aktuell WIFI Bricklet Extension gut. Grundsätzlich gibt es zwei Gründe warum der erste Prototyp nur ein Bricklet-Anschluss hat: 1. Wir hatten gehofft ein bisschen Energiespar-Magie zu machen indem wir die Bricklet Firmwares aufbohren (dies hätte nur mit einem Bricklet-Anschluss funktioniert). Das bringt allerdings nach aktuellem Kenntnisstand nicht viel, da der Stromverbrauch sowieso von den WIFI Beacons dominiert wird. Das was ich hier geschrieben hab http://www.tinkerunity.org/forum/index.php/topic,3323.msg20394.html#msg20394 scheint mir aktuell eine bessere Alternative zu sein. 2. Es gibt die Überlegung ein (richtiges professionelles Spritzguss)-Gehäuse anzufertigen welches durch strategische Ausfräsungen die WIFI Bricklet Extension + ein beliebiges Bricklet aufnehmen kann. Also es würde ein Gehäuse geben, welches wir durch Fräsungen zu jedem Bricklet kompatibel machen könnten. So könnte man dann bei uns fertige "WIFI Sensoren" kaufen die wir direkt zusammengebaut in einem hübschen Gehäuse verkaufen können. Falls das gut ankommt könnte man dann mit einem weiteren Gehäusen z.B. auch "Ethernet Sensoren" verkaufen. Das geht natürlich nur mit einem Bricklet, da die Kombinationsmöglichkeiten bei zwei Bricklets zu groß werden (und auch das Gehäuse dann sehr groß sein müsste). Der Markt überschlägt sich auf Grund von "Wearables" und "IoT"-Kram in dem Bereich gerade. Aktuell nutzen die günstigsten Module welche inklusive Funkabnahme kommen WiFi. Eine "XBee Extension" wäre preislich einfach zu teuer. Vor allem weil man ja auch gleich zwei davon benötigt um eine Funkstrecke aufzubauen. Da vor allem im Konsumer-Wearables-Bereich alle entweder BLE oder WiFi nutzen, wird die Preisdifferenz zwischen den beiden Funkstandards und allen anderen in Zukunft sogar eher noch wachsen befürchte ich. Um zeigen wie sehr sich die Preise dort gerade ändern: Das WIFI Modul welches auf der neuen WIFI Master/Bricklet Extension sein wird, kostet ungefähr 1/8 von dem Modul auf der alten WIFI Master Extension. Vor ~2 Jahren als wir die alte WIFI Master Extension rausgebracht haben war es noch das günstigste Modul mit den Eigenschaften die wir haben wollten...

Neue RS485 Extension Blogeintrag

New RS485 Extension Blogentry

Das ist das Hauptproblem denke ich. Ist das nur wegen der Callbacks? Warum könnte man nicht das Nugget komplett in den Standby Modus schicken und nur bei Bedarf aufwecken ? Mhhhhh... Was man machen könnte ist sowas wie "setDeepSleep(int sekunden)". Dann würde die WIFI Bridge für X Sekunden komplett ausgehen (in den Deep-Sleep Modus wechseln) und erst danach wieder erreichbar sein. Das wäre dann als wäre es für X Sekunden komplett aus gewesen (also alle Einstellungen die man eventuell gemacht hatte gehen verloren). Aber das ist ja nicht so schlimm. D.h. die Vorgehensweise wäre z.B. (Pseudocode): do forevener { bricklet.configure(); bricklet.getSensorValues(); wifiBridge.setDeepSleep(60*5) system.wait(60*5); } Finde ich nicht dumm .

Die WIFI Bridge kann direkt per WLAN mit dem Host-PC kommunizieren (und auch einen AP aufmachen). Sie kann alles was die alte WIFI Extension kann. Nur auch noch ein bisschen mehr (z.B. einen AP mit WPA). Das gefällt mir auch .

Die Idee ist ein Bricklet möglichst günstig per WIFI ansprechen zu können. Wenn du 4 Bricklet Ports brauchst (oder später eventuell auch mehr) kannst du ja den Master und eine WIFI Extension nutzen. Den Master und die WIFI Extension so wie sie sind auf eine Leiterplatte zu bringen macht ja keinen Sinn, da sparen wir nur ein paar Euro für die BTB-Stecker. Aktuell gibt es Grundkosten von 90€ um ein Bricklet per WIFI anzubinden. Mit dem "Nugget" würden wir diese auf 30€ drücken. Wenn du sagst LiPo ist sinnvoll, wie lange sollte denn ein 2000mAh LiPo-Akku halten damit du es für sinnvoll betrachtest?

Die Stecker die wir verwenden gibt es natürlich nicht 90° gewinkelt und ich wüsste auch nicht wie man das technisch überhaupt vernünftig umsetzen sollte . Man bräuchte ja zwei Leiterplatten: Eine mit Board-to-Board Stecker unten und einem "90°-Stecker" und eine mit dem Gegenstück zum 90°-Stecker unten und einem Board-to-Board Stecker oben. Auf der könnte man dann wieder Bricks stapeln. D.h. 2x Einrichtungskosten, 2x Schablonen usw. Da wir davon sicher keine riesigen Stückzahlen verkaufen würden wäre das exorbitant teuer .

Wir denken darüber nach ein günstige Möglichkeit zu schaffen ein einzelnes Bricklet über verschiedene Schnittstellen anzubinden. Kategorie: Die neue Kategorie von Produkten hat eine USB Schnittstelle (zum flashen und bestromen) und eine WIFI/Ethernet/RS485 Schnittstelle sowie einen Bricklet Port. Es hat keine Board-to-Board Stecker, ist möglichst klein und einseitig bestückt. Als erstes Produkt dieser Kategorie würden wir WIFI anbieten. Produktname: Die Produkte in der neuen Kategorie sind offensichtlich keine Bricklets. Da sie weder stapelbar noch 4x4cm groß sind würden wir sie auch nicht Brick nennen wollen. Wir schwanken aktuell zwischen diesen zwei Namensideen (Beispiel WIFI): * WIFI Bridge: Es schlägt eine "Brücke" zwischen WIFI und einem Bricklet. * WIFI Nugget: Es ist kein stapelbarer Ziegelstein (Brick) sondern ein Stein den man nicht stapeln kann. Ist aber schön klein und hat tolle Eigenschaften. Also ein Nugget . Welches findet ihr besser? Bessere Namensideen? LiPo oder nicht LiPo: Speziell für WIFI hatten wir uns überlegt vielleicht eine Schaltung zum laden/nutzen von LiPo Akkus mit einzubauen. Man könnte dann einen LiPo Akku anschließen und verwenden sowie über USB laden. Wenn wir weiterhin unser normales Protokoll beibehalten wollen, muss eine WIFI Verbindung durchgängig bestehen bleiben. D.h. der "WIFI Nugget" muss mit dem AP verbunden bleiben. Was soviel bedeutet wie, das alle 100ms ein Beacon Paket vom AP reinkommt. Nach unseren Messungen benötigt die Abarbeitung dieses Pakets ca. 8ms bei 100mA Stromverbrauch. Bei einem sonst durchschnittlichen Stromverbrauch von 1mA würden wir mit einem 2000mAh Akku auf eine Laufzeit von höchstens einer Woche kommen. Je nachdem welches Bricklet man anschließt und wie oft man es anspricht sinkt die Laufzeit natürlich. Diese LiPo-Schaltung würde ca. 10€ Aufpreis kosten. Ist das noch sinnvoll oder ist das Blödsinn? Was meint ihr? Wir hatten uns längere Laufzeiten erhofft, unsere komplette Softwareinfrastruktur und Benutzungsweise über die APIs ist aber einfach nicht auf Stromsparen ausgelegt. Als Alternative hatten wir die Idee vielleicht einfach eine USB Powerbank mit in den Shop aufzunehmen (und natürlich kann man den WIFI Nugget auch über ein USB-Netzteil o.ä. betreiben). Preis: Der Preis (des WIFI Nugget ohne LiPo-Schaltung) wird zwischen 29,99€ und 39,99€ brutto liegen. Was haltet ihr allgemein von der Idee?

Um 90° auf der Fläche des Bricklets drehen? Oder meinst du wirklich um 90° abwinkeln ?

Ich befürchte das würde nicht auf die Größe eines Bricks passen, schon alleine wegen den Steckern.

Ist mir völlig unklar warum die WIFI Extension als AP funktionieren sollte aber nicht als Client. Ist das U.FL Kabel richtig angeschlossen? Nicht das einfach die Verbindung schlecht ist und im AP-Modus funktioniert es nur weil der Client sehr nah dran ist. Ansonsten gehen mir auch die Ideen aus woran das liegen könnte .

Für ganz genaue Informationen guck dir das Datenblatt des Beschleunigungssensor-ICs an (3.1: Machanical characteristics): https://github.com/Tinkerforge/accelerometer-bricklet/raw/master/datasheets/LIS3DSH.pdf Die Auflösung die wir angeben ist 0.001g. Der IC selbst gibt sogar 0.06mg an (also 0.00006g). Das sagt nichts zur Genauigkeit aus. Laut Datenblatt gibt es typischweise einen Offset von +-40mg (der ist nicht schlimm den kann man rauskalibrieren) und eine Temperaturabhängigkeit von 0.5mg/°C. Zusätzlich hast du da natürlich noch rauschen drauf, das kannst du aber wieder rausrechnen mit einem großem Mittelwert. Damit kannst du Schwingungen die über einer Bestimmten Frequenz liegen rausfiltern. Jo, wenn du es sehr gerade auf den Tisch legst und die Ebene welche von der X/Y-Achse aufgespannt wird exakt Orthogonal zur Erdgravitation ist und du über viele Werte mittelst .

Die Erstkonfiguration kannst du eigentlich immer im "constructor" finden: https://github.com/Tinkerforge/ambient-light-v2-bricklet/blob/master/software/src/ambient-light.c#L77

Minimale Eingangsspannung ist 8V, ich würde 24V oder mehr empfehlen.

Firmware: Stepper Brick 2.3.2 Externe Spannungserkennung auf 6V erhöht. Download: Stepper Brick

Firmware: Stepper Brick 2.3.2 Increase external detection voltage to 6V Download: Stepper Brick

Die "WIFI Bridge" ist aktuell noch ein internes Forschungsprojekt, da gibt es noch keine Informationen drüber . Der Silent Stepper Brick wird in der Tat ein Stepper Brick sein welcher einen Schrittmotor-IC verwendet der extra dafür gedacht ist Schrittmotoren lautlos zu bewegen. Er wird bis zu 1/256 (interpolierte) Mikroschritte machen können. Die WIFI Extension 2.0 wird nicht auf dem RED funktionieren. Wir brauchen im Stack einen WIFI-IC der TCP/IP selbst bereits spricht (da wir keinen Platz für einen TCP/IP Stack auf dem Master Brick haben). Allerdings haben diese ICs alle keine Unterstützung für Linux, da Linux natürlich einen TCP/IP Stack mitbringt und so ein Chip daher keinen Sinn macht. Sie wird dafür aber andere tolle neue Sachen können .

Das ist mit der API nicht möglich und es ist auch nicht implementierbar. Die Ausgänge der IO-4 sind direkt mit den Pinnen des Microcontrollers auf dem Brick verbunden. Microcontroller haben beim Booten für gewöhnlich immer alle ihre Pinne auf "Input Pull-Up" stehen. D.h. den Zustand könnten wir frühestens ändern wenn das Brick gebootet hat und die Bricklet Plugins geladen sind und der erste Tick ausgeführt wird. Bis dahin sind aber schon 2-3 Sekunden vergangen. Zu dem Zeitpunkt kannst du es dann aber auch einfach über die API einstellen.

Für das Video haben wir ein Labornetzteil genutzt.

Das ist komisch. Die aktuell veröffentlichen Bindings unterstützen leider den Error Callback noch nicht, daher können wir nicht überprüfen ob es ein Parity- oder Framing-Error o.ä. ist. Ich würde versuchen das hier nachzubauen (also RED Brick + Master Brick + RS232 + Nachriten alle 250ms). Mal schauen ob ich das reproduzieren kann. Aber ich befürchte das wird durchlaufen. Wenn du meinst es könnte an irgendwelchen Störungen liegen könntest du versuchen das RS232 Bricklet räumlich mehr von den anderen Komponenten zu trennen. Tritt der Fehler denn immer nur auf wenn du etwas mit dem Display machst? Es ist aber nicht so das die Spannung einbricht wenn das Display an ist?

Die Bricks/Bricklets haben leider keine Real Time Clock. Dadurch würde es dort schnell zu großen Abweichungen kommen. Ich befürchte ein PC/RPi/RED kann die Amperestunden viel besser bestimmen als wir es auf dem Bricklet könnten. Daher macht das denke ich keinen Sinn.

Welche Firmware Version hat das RS232 Bricklet?

Ist egal. Die Virtualisierung funktioniert vermutlich effizienter wenn die VM gleich-bittig mit dem Host ist. osboxes@osboxes:~$ du -h tf/ [...] 3.3G tf/ osboxes@osboxes:~$ df -h Filesystem Size Used Avail Use% Mounted on [...] /dev/sda1 48G 8.3G 37G 19% / [...] Also der tf Source Code braucht ca. 3,3G und die ganzen Pakete brauchen ca. 5G. Ich würde mindestens 15G reservieren.