batti

Hallo Jax, das mit der Überhitzung kann ich mir nicht vorstellen. Die Bricks und Bricklets arbeiten eigentlich auch noch bei deutlich höheren Temperaturen. Ich denke man muss hier systematisch dran gehen. Was passiert, wenn du das Schalten des Relais auskommentierst. Läuft dann das System stabil?

Hallo Gabe, sofern die roten am Sensor miteinander verbunden sind und auch die weißen miteinander, dann sollte es egal sein. Du kannst ja einfach mal die Widerstände messen die einen sollten ~Ohm haben und die anderen ~100 bzw 1000 Ohm. Grüße

Bezüglich des Releases haben wir noch keinen offiziellen Termin. Wir fangen jetzt mit der Entwicklung des Prototypen an. Das wichtigste wird dann sein diesen stabil zum laufen zu bringen. Wenn das geschafft ist muss der SPI Treiber für den Stapelbetrieb geschrieben werden und Brickd erweitert werden. Ist dies vollbracht, dann könnte eine Art "Developer Version" veröffentlicht werden, die noch nicht das Webinterface etc. bietet. Zeitlich möchte ich mich hier nicht festlegen. Wir werden euch über den Blog auf dem Laufenden halten.

Hallo Dan, ist der Zustand nach einem Neustart des Raspberrys immer noch da? Wie versorgst du die LEDs? Welche Version vom Raspberry Pi hast du? Die ersten hatten Probleme mit der 5V Stromversorgung über USB. Du könntest mal probieren zwischen Raspberry und dem Master Brick einen aktiven (mit eigenen 5V Netzteil) USB Hub zwischenzuschalten. Grüße

Danke für die Hilfestellung! Ich dachte dabei aber eher an Industrieprodukte die wir dann zum Testen benötigen würden. Das Raspberry Pi nutzt einen Prozessor von Broadcom mit Package on Package (der RAM sitzt auf dem Prozessor) Technologie. Darum haben wir uns zuerst bemüht, da wir mit dieser Technik sehr viel Platz sparen würden. Für keine Firmen wie uns scheinen Prozessoren mit dieser Technologie aber nicht erhältlich zu sein. Texas Instruments bietet ähnliche Prozessoren, unter 100T Stück läuft da wohl garnichts. Ein bestehendes Design zu übernehmen ist aber auch gar nicht möglich, da ich dieses ja nicht einfach ausschneiden kann. Was meinst du damit? Natürlich gibt es für das Raspberry Pi und andere Boards fertige Images. Auf diese können ja auch Brickd etc. installiert werden. Siehe oben. Kann ich nachvollziehen. 30€ ist natürlich auch ein Wort zum Sonntag...

Soweit wie ich das sehe (man möge mich korregieren) würde man dazu eine externe Interruptquelle benötigen (Co-Prozessor). Auf dem RED Brick selbst werden wir da keinen Platz für haben. Vll. kann dieses Thema in Zukunft mit einer speziellen Power Supply angegangen werden, die intelligent die Stromzufuhr steuert oder über eine Interruptleitung weckt. Das ist aber absolute Zukunft! Das kann man natürlich tun. Die Nutzung eines Raspberry PIs mit unserem Baukastensystem ist ja schon länger dokumentiert. Nachteilig dabei sehe ich: 1) Formfaktor/nicht in Stapel integrierbar 2) Unterstützung (Linux Kenntnisse notwendig) 3) Stromverbrauch Damit ich jetzt nicht als Miesepeter dastehe: Andere Embedded Boards werden auch mit dem RED Brick weiterhin eine Option sein. In letzter Zeit sind einige Boards rausgekommen mit verschiedensten Quad Core Prozessoren etc. die leistungsmäßig in einer anderen Liga spielen. Dies aber zu Lastern der Größe und des Stromverbrauchs.

Nachtrag zum Stromverbrauch (getestet mit Olimex A10s Board): 100%CPU Last: <410mA Ich habe gerade nochmal einen 100% CPU Last Test gemacht. Ich bleibe mit dem Demo Board immer unter 410mA (~2W). Unausgelastet liege ich wie gesagt bei <240mA.

Ja, hatte das falsche gequotet.

EDIT: Wie gesagt, können wir nicht versprechen. Eingeplant ist es aber erstmal.

Nein, das hat nichts miteinander zu tun. Bei Chibi konnten wir uns unser Protokoll aussuchen (selbst definieren). Der Funk Chip besitzt eine interne Empfangs-FIFO, so dass mehrere Bytes nach einer gewissen Zeit abgerufen werden können. Damit wäre das Problem gelöst, allerdings lässt sich diese FIFO nur nutzen, wenn die Funk-Pakete einen gewissen Aufbau haben (Preambel etc.). Dies ist bei vielen Protokollen nicht der Fall. Daher können wir die FIFO für diese Protokolle nicht nutzen und müssten jedes Bit einzeln auswerten. Die 868MHz Protokolle haben wir noch nicht betrachtet, weil wir bisher nur ein 433MHz Modul zur Verfügung haben. Wenn diese Protokolle ebenfalls nicht zufällig genau die richtige Preambel nutzen, dann haben wir ebenfalls die oben genannten Probleme. Das hängt vom Protokoll ab. In der Tat kann es sein das ein Hinkanal ausreicht um einfach Werte zu setzen (siehe aber auch den Post von BorgelMorgel). Um zumindest komplett HomeMatic o.ä. zu unterstützen müsste der Rückkanal aber auch funktionieren.

Ja, für den Stack gilt das. Wie gesagt momentan ist ein kleiner GPIO Flexkabel Anschluss eingeplant. Dieser ließe sich auch parallel zu Stack-SPI nutzen. Auf dem geplanten GPIO Flex Anschluss liegen 12 GPIO, darauf liegt SPI und ein UART (RS232, allerdings nur RX, TX). Der maximale Strom wird bei 1.1A liegen. Dies kann aber nur funktionieren wenn der Brick per Step Down versorgt wird.

Da sollten wir drunter liegen. Ich teste hier gerade mit einem A10s Board von Olimex. Beim booten komme ich so auf max. ~320mA (stark schwankend). Im Dauerbetrieb (Brickd, Python Script) komme ich so auf 255mA. Das Board hat aber zusätzlich Ethernet mit drauf (das in meinem Aufbau nicht genutzt wird) das vll. auch noch etwas den Stromverbrauch nach oben zieht. Diese Beschränkung ist ersteinmal unabhängig vom RED Brick. Die komplette Software ist auf 1000 Nachrichten ausgelegt (1ms Tick Task etc.).

RS232 mit der Standardbuchse ist deutlich zu groß. Auch ein Pin Header würde Eng, da HDMI bereits in der Micro HDMI Ausführung geplant ist. USB Host möchten wir gerne als USB A lassen, da man ja sonst für alles Adapter benötigt (Beispiel Wifi Stick) Korrekt Richtig.

Moin, prinzipiell gibt es das Funk Modul, welches auf dem Remote Switch Bricklet ist, auch für 868MHz. Selbst das jetzige Remote Switch Bricklet kann auf 868MHz senden/empfangen, wenn auch mit starken Leistungsverlusten (Antennenschaltung ist für 433MHz ausgelegt). Wir wollten mit dem Bricklet auch Module unterstützen, die Senden (Bricklet im Empfangsmodus). Die genutzten Funk-Protokolle führen aber zu dem Problem, dass der Prozessor (auf dem Brick) eigentlich permanent die ausgeworfenen Bits von dem Funkmodul bearbeiten muss um nichts zu verpassen. Dies ist mit unserem jetzigen System nicht möglich, da jedes Bricklet nur einen gewissen Timeslot zur Bearbeitung zugeordnet bekommt. Anschließend ist ein anderes Bricklet an der Reihe. Per Interrupt ist es auch nicht möglich, da diese so oft auftreten würden, dass z.B. ein Betrieb im Stapel mit anderen Bricks nicht möglich ist. Die einzige Lösung die uns bisher dazu eingefallen ist, ist eine Art "Co-Prozessor" auf dem Bricklet. Dies zieht aber einen ganzen Rattenschwanz an Aufgaben nach sich (Toolchain, Firmware für 8-Bit Co-Prozessor, Flashmöglichkeit für den Nutzer, etc. etc.). Diese große Aufgabe sind wir bisher nicht angegangen.

Baue deine Aufbau mal um und schalte mit dem Quad Relay den Eingang der Step Down Power Supply (Brick per USB anschließen). Was passiert dann?

Moin, GND des Voltage/Current Bricklet Anschlusses ist auf dem Bricklet mit GND vom Brick verbunden (ist galvanisch nicht getrennt). Daher hat dein Raspberry Pi immer noch GND, wenn auch jetzt über das Brick. Grüße

Für das 4x4cm Brick planen wir aus Platzgründen mit dem A10s. Dieser ist nur 14x14mm groß anstatt 19x19mm wie beim A10 oder A20. Wenn ich nicht irgendetwas übersehen habe, dann hat der A10s kein CAN. Bezüglich CAN haben wir ein paar Anfragen, allerdings nicht so viele wie für andere Produkte. Neben dem Aufwand eine CAN Extension zu entwickeln (bei der die Zahl der Nutzer dann fraglich ist) stehen wir vor dem Problem, dass wir verschiedene CAN Geräte hier haben müssten um die Kompatibilität zu testen. Aus diesen Gründen haben wir bisher noch keine CAN Extension entwickelt.

Hallo luxor, der A10S hat LAN unterstütung. Es wird aber noch ein externes IC benötigt welches das PHY stellt.Einfach mit einem Kabel nach außen führen ist es leider nicht getan. Grüße, Bastian

So ist es gedacht. Das wäre machbar. Dann müsste vermutlich nur unser SPI Treiber lahmgelegt werden, damit dieser die nicht nutzt. Für den A10s habe ich schon mit Python Bindings gespielt die GPIO setzen konnten. Wir wollen versuchen ein paar GPIOs über ein Flex-Kabel nach draußen zu legen. Ob das klappt wird sich beim Routing zeigen.

Es ist geplant, dass diese "grundsätzlich nicht geht". Die Unterstützung dafür muss aufwändig programmiert werden. Dies ist momentan nicht geplant. Borg schreibt aber noch etwas dazu. Momentan noch nicht. Dies hängt maßgeblich vom gewählten Prozessor ab (Single Core, Dual Core).

Überall wo Ethernet steht könnte auch WIFI-Stick stehen. Die Unterstützung unserer WIFI Extension ist von uns nicht geplant. Hier hätte man ja wirklich die Chance auf einen 5€ WIFI Stick zurückzugreifen. Ethernet bietet prinzipiell Vorteile bei Themen wie Stabilität (Stichwort Wohnhaus mit 100 WIFI Teilnehmern) und der Einfachheit falls DHCP verfügbar ist (Bsp.: "RED Brick" in den Browser eingeben und man ist auf der Weboberfläche. Bei WIFI muss zuerst die WIFI Verbindung konfiguriert werden (ESSID, Passphrase, etc), dafür zieht man aber kein Ethernet Kabel hinter sich her.

Wir würden ein Linux-Image bieten (Speicherkarte) auf dem alle typischen Interpreter, Compiler und Packages für die Bindings installiert sind. Geplant ist, dass die meisten Nutzer keine Probleme mit Abhängigkeiten haben. Ich vermute, dass die installierten Packages in der Anfangszeit wachsen werden. Soll eine Library o.ä. installiert werden, die wir nicht bieten, dann sind gewisse Linux Kennnisse notwendig. Wir sehen da zur Zeit folgende Möglichkeiten: 1) Auf SD Karte extern die Library draufkopieren und per serielle Konsole installieren 2) SSH Login und wie üblich (apt-get) installieren (Ethernet oder WIFI Stick notwendig) 3) Lib parallel zu eigenem Programm legen und einfach mit hochladen Tastatur und Monitor anschließen ginge natürlich auch. Wie gesagt VM wäre schon drauf.

Zur Info: Wir haben angefangen Klarstellungen/Ergänzungen etc. in den Initialbeitrag zu übernehmen.

Hallo Nic, Korrekt. Genauso wie alle anderen Bindings. Also auch Python,C++, usw. Korrekt. Der "normale" Nutzer sieht nicht das da ein Linux läuft. Es soll, z.B. per Webinterface, möglich sein das Programm, was du momentan auf deinen PC ausführst und getestet hast, hochzuladen. Genau, du benötigst keine bestimmte IDE. Du entwickelst einfach dein Programm wie gehabt und lädst es dann auf das RED Brick hoch. Du hast einen "Upload" Dialog, in dem du die Dateien auswählst. Zusätzlich gibst du dem Brick Informationen. Je nach Sprache können das die notwendigen Compiler-Parameter sein (C/C++), Abhängigkeiten, die Main Klasse in Java etc. Zusätzlich ist angedacht Ausführungsoptionen zu setzen, wie z.B. soll einmal ausgeführt werden, soll alle X Minuten ausgeführt werden etc. Genauso wie jetzt auch. Du schreibst dein Programm, z.B. in Java wie gehabt mit unseren Bindings. Lässt dieses jetzt aber nicht auf deinem PC laufen (an dem die Bricks/Bricklets per USB angeschlossen sind) sondern lädst dieses Programm auf das RED Brick. Dabei sind keine Änderungen am Programm notwendig.

Hallo Unex, der Bug ist bekannt und steht auf unserer Liste. Siehe auch: https://github.com/Tinkerforge/temperature-ir-bricklet/issues/1 Grüße, Bastian