batti

Revised Documentation and Kits Blog entry

Überarbeitete Dokumentation und Kits Blogeintrag

Hallo, Was für ein Schütz ist es? Wird mit dem Dual Relay Netzspannung (230V) oder eine kleine Spannung wie 12 oder 24V geschaltet? Kannst du ein Foto des Aufbaus machen? Grüße Bastian

Hallo Plenz, das Magnetfeld wird sicher von diesen Gegenständen beeinflusst. Statische Magnetfelder können aber über die Kalibrierung "entfernt" werden. Problematisch sind dynamischen Magnetfelder, gegen diese kann man nur eingeschränkt etwas tun. Nach Möglichkeit muss der Nutzer einer IMU sehen einen möglichst großen Abstand zu diesen Feldern zu erzielen. Das Magnetfeld einer einzelnen IMU per USB (auch mit Ferrit) angeschlossen kann gut herauskalibriert werden.

Hallo Thorbijoern, was für Sensoren fehlen dir denn? Vll. ist es möglich diese über ein IO Bricklet oder das Voltage/Current Bricklet anzuschließen und auszulesen? Du könntest eine Webcam nehmen und diese an ein Raspberry Pi oder ein ähnliches Board anschließen. Grüße, Bastian

Moin, in der Doku stand HE801SA mit Typ B. Du meintest sicher "C". Ich habe das mal geändert. Du hast recht, da könnten noch weitere Fehler drin sein, leider habe ich noch keine vernünftigen Angaben gefunden in welchen Sets die HE874 drin ist. Daher habe ich den Rest der Doku erst einmal so gelassen. Grüße und Danke für die Info!

Hallo Helmar, Danke für die Info! Wir haben den Typ geändert. Grüße, Bastian

Hallo, die Repeats brauchen nicht so hoch sein (könnte beim Anlernen Probleme machen). 10 sollten reichen. Wenn der "Switch on" Button gedrückt wird, bleibt dieser zufällig länger deaktiviert (ausgegraut) nach dem Drücken? Falls der ausgegraut bleibt ist vermutlich ein Pin im Bricklet Stecker an dem Brick oder auf dem Remote Switch Bricklet verbogen. Ansonsten sollte das ganze so funktionieren wie du es beschrieben hast. Grüße, Bastian

Hallo Loetkolben, wir werden in Kürze dazu noch einen Blogeintrag veröffentlichen. Kurz zur Info: Wir haben jetzt mehrere RED Bricks retten können und es geht bei uns vorran. Grüße, Bastian

Hallo, auf dem Temperature Bricklet ist ein Sensor verbaut, der eine Genauigkeit von 0,5°C besitzt. In deinem Aufbau hören sich ~8°C sehr komisch an. Hast du mal die Temperature/ Humidity Bricklets getauscht? (Falls es ein HW Problem sein sollte, würde ich erwarten, dass der Fehler sich mitbewegt). Grüße, Bastian

Lol a really cool project.

korrekt, da sind wir gerade bei

MATLAB and Octave Bindings released Blog entry

MATLAB und Octave Bindings veröffentlicht Blogeintrag

10% Easter Discount Blog entry

10% Osterrabatt Blogeintrag

Das ist der typische Reset Taster. Er ist nicht beschriftet, weil einfach kein Platz für den Text in der nähe ist. Bedenke, dass Ding ist 4x4cm groß. Den kleinsten Text den wir drucken lassen können können hat eine Zeichengröße von 0.8x0.8mm.

Aktueller Status: Unbekannt. Wir stehen mit Heise im Kontakt, haben aber noch keine Entscheidung getroffen. Die Stände sind nicht ganz billig. Grüße, Bastian

Hallo gagahhag, hast du auch die Möglichkeit ein anderes USB Netzteil zu testen? Wir konnten bisher keine Probleme mit dem Netzteil feststellen, im Fall von Rincewind scheint es aber geholfen zu haben. Grüße, Bastian

Mein Fehler, korrekt. Ich meinte ein Display mit Touchscreen. Beim Raspberry Pi machen es die Leute z.B. so, dass sie das Display per HDMI und den Touchscreen per USB anschließen. Das ist noch eine der Hausaufgaben.

Nicht wirklich. Sie muss ja auch anschließbar sein und ich muss irgendwie das Signal auch noch dahin bekommen. Auf meinen Signallagen habe ich keinen Platz mehr. Ich könnte da jetzt etwas reinhacken, dies würde aber zur Lasten der anderen Signale gehen. Ehrlich gesagt nicht viel. Ich sehe durchaus Anwendungen in denen man ein Touchpad Edit: Display + Touchscreen anschließen möchte. Und das ist HDMI sehr einfach. Auf HDMI liegt kein analoges Audio. Ich kann da also nichts "drauflegen". Es könnte aber sein, dass man einen Audiostream digital per HDMI übertragen kann mit dem Board. HDMI unterstützt das zumindest. Ich habe von Leuten gelesen, die das mit ähnlichen Boards versucht haben. Eine eindeutige Aussage konnte ich aber auf die schnelle nicht finden. Also Kurzfassung: Es kann sein, dass digitales Audio Out doch nach draußen gelegt wird. Analoges Out oder In wird dieses Design aber nicht haben. Im Zweifelsfall müsste dann eine USB Soundkarte genutzt werden. Da liegen Signale für den Anschluss von Kamera-Sensor-ICs drauf (ähnlich wie die Cam beim Raspberry). Das ist im wesentlichen 5V, 3.3V, I2C, UART, und SPI. Wie gesagt, geplant ist da noch nichts mit. Es ist erstmal nur "da". Das hätte man tun können. Vorteil wäre gewesen, dass das Entwicklungs-Risiko minimiert würde. Nachteilig wäre die Abhängigkeit von diesem Board gewesen (was wenn der Hersteller dieses einstellt?) und das es nicht wirklich im Baukastensystem integriert wäre. Prinzipiell könnte man jedes Board nutzen welches eine SPI Schnittstelle und 8 GPIOs besitzt. Rasyberry Pi, Beagle Bone etc. wären alles Kandidaten. Den vorläufigen Schaltplan könnt ihr übrigens hier im PDF-Format finden: link

Hallo Joerg, du meinst mit zwei Brickv instanzen? Da gewinnt dann immer die, die zuletzt die Callbacks aktiviert/deaktiviert hat. Getter funktionieren auch parallel problemlos. Grüße

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