batti

Ich versuche mal auf die verschiedenen Dinge zu antworten: Andere haben hier ja auch schon etwas geschrieben. Ich fasse mal unsere Ideen dazu zusammen: Beschränkt man sich auf eine Sprache, dann gibt es günstigere Möglichkeiten. Naheliegend wäre es zum Beispiel C oder C++ direkt auf den Prozessoren der Bricks zu programmieren. Dazu wollen wir unsere Kunden aber nicht zwingen. Wer das möchte kann es jetzt auch schon tun. Für diejenigen, die aber gerne "high-level" Sprachen und insbesondere untypische Embedded Programmiersprachen wie Java, PHP o.ä. programmieren möchten ist das wohl keine Alternative. Dazu sehe ich persönlich einfach den Vorteil von Hochsprachen, wie zum Beispiel Python. Ich bin damit einfach viel schneller als wenn ich etwas in C Programmieren muss. Insbesondere wenn dies direkt auf einem Mikrocontroller ausgeführt wird! Die Programmierung da ist ja schon etwas anders. Alternativ hatten wir schon darüber nachgedacht einen eigenen Interpreter für eine, noch zu bestimmende, Sprache auf den Bricks zu implementieren. Das klingt in der Theorie toll, da jedes Brick praktisch standalone sein könnte. Offensichtlicher Nachteil ist dann aber, dass wieder genau eine Sprache unterstützt wird. Was ist mit den anderen? Wir würden Nutzer wieder Zwingen. Mindestens genauso schlimm sind aber die Beschränkungen die dann wieder existieren. So ist zum Beispiel der RAM sehr begrenzt. Würde man Sprachen wie Python nutzen, so könnte nur ein gewisser Funktionsumfang implementiert werden etc. etc. Ein Programmierer der Python gewohnt ist würde über X Dinge stolpern. Die Idee, dass der Anwender dies einfach nutzt ist damit aus unserer Sicht gestorben. (Beispiel: PyMite, scheint schon länger tot zu sein) Daher jetzt der Weg mit dem RED Brick. Im optimalen Fall bekommen wir es hin, dass der Anwender sein Programm einfach auf das RED Brick hochläd, es zu den Bricks steckt und schon ist die Anwendung standalone. Da es sich bei dem RED Brick defakto um einen PC handelt, existieren ähnliche Einschränkungen wie auf dem PC an dem die Anwendung entwickelt wurde. Aus unserer Sicht ein riesen Vorteil gegenüber dem C oder Interpreter Ansatz. Bezüglich des Preises haben ja andere hier auch ihre Meinung geäußert. Danke dafür! Es wird so sein, dass das RED Brick teurer sein wird wie ein Raspberry. Wir sind nun mal aber keine Stiftung die ein Board zu den Herstellkosten vertreibt. Dazu kommt, dass wir vermutlich nicht so schnell an die Stückzahlen eines Raspberrys herankommen werden (hätte aber nichts dagegen ). Ich weiß ehrlich gesagt nicht wie ich das Signal aus dem Ding noch rausbekommen soll. Werden bald noch einen Blogeintrag mit weiteren Bildern machen, da sieht man dann besser wie eng es doch beim Prozessor zu geht. Finde ich auch toll. Insbesondere weil es fast nichts kostet. Mussten dieses aber sehr früh von der Liste streichen weil dafür einfach kein Platz ist. Die Buchsen müssten auf die Oberseite und da ist einfach nichts mehr frei. Die Hardware kann prinzipiell zwischen mehreren RED Bricks in einem Stack unterscheiden, so dass sich einer als "Master" des Stacks verhalten kann. Lasst uns abwarten was man damit vll. tun kann. Aktuell geplant ist da noch nichts.

Es ist ein normaler USB Host Anschluss. Es können USB Host Geräte wie USB Hubs, Tastaturen, Touchscreen Controller etc verwendet werden. Auf unserem Image sollen alle Sprachen vorinstalliert sein. Es spricht nichts dagegen.

Hallo Loetkolben, Du wirst dich wundern wie groß auf einmal eine SD Karte ist. Wir sind sehr froh den Kram überhaupt dadrauf bekommen zu haben. Der Prozessor und RAM haben so viele Durchkontaktierungen, dass diese Bereiche für alle anderen Bauteile gesperrt sind. ein großer SD Karten Slot passt daher da nur schwer drauf. Auch die Abblockkondensatoren wollen ja schließlich irgendwo hin. Definitv. Die Footprints sind da standardisiert. Wir werden mal gucken was das größte ist was man bekommt. Wo möchtest du dann mit dem USB Host hin? Danke für die Anregungen. Grüße, Bastian

Hallo Joerg, wir haben Chibi (nutzte Zigbee Hardware mit eigenem Software Stack) immer für zwei Anwendungsfälle gesehen: 1) Günstige Möglichkeit zur Funkvernetzung Anwendungen wie ein draußen angebrachter Funk-Temperatursensor sollten nicht so viel kosten. Da tue ich mich bei Xbee und ähnlichen Modulen sehr schwer. Diese kosten ja nahezu genauso viel wie unser WIFI Modul. 2) Große Reichweite Gerade die hochpreisigen Module sollen eine große Reichweite bieten. Ich sehe hierfür durchaus Anwendungen. Allerdings denke ich das in den meisten Fällen, die mir einfallen, WLAN ebenfalls eine Alternative ist (ggf. mit Richtantenne etc.). Vorteile wie größerer Datendurchsatz, Kompatibilität mit anderen Geräten (Smartphone, Tablet etc.) und ein nahezu ähnlicher Preis relativieren diese Xbee Module sehr in meinen Augen. Lasse mich aber auch gerne von etwas anderem überzeugen. Ich hätte in Zukunft gerne wieder eine Art Chibi Ersatz im Programm. Dieser Ersatz sollte sich preislich aber deutlich von den Kosten einer WIFI Extension unterscheiden um deutlich erkennbare Vorteile bieten zu können.

Es ist geplant Brickd so zu erweitern, so dass dieser direkt per SPI mit den Bricks des Stapels kommunizieren kann. Hierdurch könnten Latenzen die durch USB entstehen reduziert werden. Die Software der Bricks bleibt aber die gleiche. Ein direkte Verarbeitung von Events ist somit nicht möglich.

So, ich bin immer noch nicht ganz sicher was da los ist. Damit es aber vorran geht, kontaktiere uns bitte mal per Email. Dein Industrial Quad Relay Bricklet hat definitiv einen Defekt. Grüße, Bastian

Hallo Novae, ja, wir stehen mit ihm in Kontakt. Ich muss morgen noch etwas testen und melde mich dann. Grüße, Bastian

Hallo Richi, das geht leider nicht, da die Analog Outs dasselbe GND besitzen. Wenn du 5V der einen auf GND der anderen legst machst du einen Kurzschluss. Eine Möglichkeit wäre es einen Opamp hinter die Analog Out zu schalten die aus 5V 10V macht. Grüße

Starter Kit: Blinkenlights now available Blog entry

Starterkit: Blinkenlights jetzt verfügbar Blogeintrag

Hallo Tom, du solltest den Encoder an das DI4 anschließen können wenn du die "+" Eingänge auf 5V legst und die "-" Eingänge mit den Ausgängen deines Encoder verbindest. Der Strom sollte reichen um die DI4 anzusteuern. Grüße, Bastian

Hi, das liest du richtig. Ich werde morgen den Hersteller des Bauteils mal kontaktieren. Melde mich wieder. Grüße

Hallo Joerg, wenn ich das richtig sehe, dann ist die 12.75V (SpannungAmLEDgem) ziemlich genau die Versorgungsspannung, korrekt? -> Am Vorwiderstand der LED fällt keine Spannung ab -> Es fließt kein Strom.

So, ich bin ein wenig schlauer (hoffe ich zumindest). Ich konnte die Probleme reproduzieren und habe ein paar Dinge probiert. Es sieht mir ganz danach aus, als ob der Einschaltstrom zu hoch ist. Ist dies der Fall, dann schaltet das Solid State Relay nicht durch. Das erklärt auch warum dann am SSR so große Spannungen abfallen. Lösen konnte ich es indem ich mehrere Ports parallel geschaltet habe. Bei mir waren mindestens 3 Relais notwendig. Als Last hatte ich eine Step-Down Power Supply angeschlossen deren 5V ein Raspberry Pi sowie einen 8" Touchscreen versorgte.

Hallo Joerg, bitte mess mal mit einem Multimeter. Das Analog In misst ja immer bezüglich GND Bezug. Wie hast du ULED bestimmt? Grüße, Bastian

Ich stelle das mal nach und melde mich wieder.

Dann scheint (aus welchen Gründen auch immer) der Einschaltstrom für ein Relais alleine wohl zu groß zu sein. Die Parallelschaltung funktioniert aber zuverlässig? (Dein Problem ist "gelöst")?

Genau so.

Hm, das deutet darauf hin das die Relais schon geschalten haben, aber nicht richtig. Zumindest scheint das nicht floating zu sein. Korrekt. Du kannst auch mal probieren zwei Relais parallel zum Schalten zu nutzen. Mehr fällt mir im Moment nicht ein.

Korrekt. Verlustfreie Elektronik gibt es noch nicht. Dies ist leider immer so. Die Frage ist wie groß die Verluste sind. Der verbaute Buck-Regler ist schon recht effizient (zumindest im Vergleich zu LinearRegler). **END TECH**

Ich könnte mir vorstellen, dass die gemessene Spannung "floating" ist und du quasi beliebiges Messen kannst.

Hallo Novae, das ist der typische Weg. Du machst zu jeder WiFi Extension (oder auch Brickd) eine eigene IPConnection auf und weist den Bricks/Bricklets dann diesen zu.

Was ich mir vorstellen könnte ist, dass die Relais einen minimalen Strom benötigen um zu schalten. In dem aktuellen Aufbau versorgst du alles per USB, das heißt das die Step-Down Powersupply unter Umständen nicht belastet wird. Schalte mit dem Quad Relay mal bitte den WIFI Stack und schließe diesen nicht gleichzeitig per USB an. Was passiert dann?

Hallo Angler, auf diese Idee wäre ich ehrlich gesagt nicht gekommen. Dafür sind doch viele Bauteile zu klein (oder nicht?). So mal eben ist dafür auch keine Platine gemacht. Ich würde den Bedarf dafür als gering einschätzen. Lasse mich aber gerne eines anderen belehren Grüße Bastian

Bei einer solchen Frage kann man sich weit aus dem Fenster lehnen. Wir haben ein so großes Projekt noch nicht gemacht, von daher ist es schwer abzuschätzen. Wir planen die Hardware (Linux Board) Mitte des Jahres fertig zu haben. Dann gibt es aber noch keine Unterstützung zum Hochladen von Programmen etc.