batti

Wenn du ein Foto von deinem Aufbau hättest, dann würde ich den miteinbauen. Bin gerade dabei einen Wiki Artikel dafür anzulegen.

Ich hab mal einen Wiki Artikel angelegt: http://www.tinkerunity.org/wiki/index.php/DE/Projekte/Wohnzimmer_LED_Beleuchtung Der Inhalt ist hauptsächlich der, den du hier gepostet hast. Ich hoffe das ist ok so. Darfst gerne daran rumschreiben.

Ich habe mal eine Wiki Seite hierzu angelegt: http://www.tinkerunity.org/wiki/index.php/DE/Projekte/RC_Fernsteuerung_%C3%BCber_Tablet Kannst du zusätzlich zu den Fotos noch weitere Informationen (z.B: Sourcecode) zur Verfügung stellen? Perfekt wäre es natürlich wenn du den Artikel füllen könntest. Grüße, Bastian

Hallo Jan, erstmal Danke für den Wiki Eintrag. Bitte verzeih mir, ich hab ein bisschen in deinem Wiki Artikel drin rumgeschrieben und ihn grob ins englische Übersetzt. Als Dateiname sollte immer DE/Projekte/Name oder EN/Projects/Name genutzt werden, damit die Sprachenumschaltung funktioniert.

Hallo Gunter, Sorry! Wir können deinen Einwand komplett nachvollziehen. Ich habe mal ein Foto von Encoderscheiben und dem Encoder Bricklet angehängt. Seit Ende 2011 existieren diese. Nach einem Funktionstest haben wir aber nicht mehr viel daran getan. Warum haben wir nichts damit gemacht? Es fehlt noch an der Software. Es ist angedacht, dass DC und Stepper Bricks das angeschlossene Encoder Bricklet erkennen und dann erweiterte API freischalten (z.B. setSpeed etc.). Die Software dafür zu schreiben ist leider einiges an Aufwand, da neben der Implementierung einer Regelung vorallem das interruptbasierte Handling der Ticks vom Encoder nicht ganz einfach ist. Problematisch wird das, wenn z.B. gerade im Stack kommuniziert wird und dann ein Interrupt auftaucht bei dem der Schrittzähler inkrementiert werden muss, man aber gerade eigentlich das nächste Byte per SPI durch den Stack schieben musste. Je nach Priorisierung kann dies dann dazu führen, dass die SPI Nachricht kaputt ist und neu gesendet werden muss oder dass der Tick vergessen wird. Im ersten Fall könnte das dazu führen, dass auf Grund zu vieler Ticks die SPI Kommunikation überhaupt nicht mehr möglich ist (keine Nachricht kommt durch). Bei der Lösung dieser möglichen Probleme muss man also sich noch einige Gedanken machen und wird einiges Testen müssen. Wir sehen die Encoder Geschichte als eine wichtige Erweiterung, die die Treiber Bricks interessanter machen werden. Die Nachfrage dafür war, im Vergleich zu anderen "Wünschen", aber vergleichsweise gering. Daher haben wir das immer weiter vor uns hergeschoben. Beim Stepper Brick ist diese Software Geschichte nochmals schwieriger als beim DC Brick. Um das ganze mal endlich vorran zu bringen wollen wir mit der Implementierung für den DC Brick beginnen. Für diesen ist dies wohl am sinnvollsten. Ich habe den Punkt auf die Timeline gesetzt. Grüße, Bastian

Cooles Projekt, wenn du jetzt noch nen gut ausgeleuchtetes Foto von deinem gesamten Hardwareaufbau machen könntest...

Moin, danke für euer Feedback! Hilft uns dabei wiedermal den Blick zu schärfen. Was haltet ihr denn für interessanter? Eine On Device API für C, mit der ihr eigene Firmwares schreiben könnt und die ähnlich wie bei Arduino zugriff auf den ADC ermöglicht etc. Oder eine Implementierung der Python Bindings auf den Bricks? D.h. man könnte ein Programm in Python schreiben, dies auf dem Rechner testen und dann das Programm auf die Bricks übertragen. Danach würd das ganze Stand-alone ausgeführt. Wobei kein "vollständiges" Python von uns unterstützt werden könnte. Es würden alle grundlegenden Spracheigenschaften unterstützt aber z.B. nicht externe Bibliotheken. Beide Möglichkeiten sind sehr viel Aufwand und ermöglichen es nur "eine Sprache" zu nutzen. Java wäre z.B. nicht nutzbar. Habt ihr eine Meinung dazu?

Hi, wenn wir bei "Wünsch dir was" wären, dann hätte ich gern ein Bild auf dem man das Tablet mit der Oberfläche + den Unimog sieht. Es geht darum auf einem Bild klarzumachen was bei dem Projekt gemacht wurde. Detailaufnahmen wie z.B. der Innenaufbau sind da nicht so wichtig. Grüße, Bastian

Hi, sorry das wir euch so lange warten lassen. Der zweite Prototyp ist bestellt und trifft nächste Woche bei uns ein. Mehr kann ich euch erst sagen wenn ich ihn getestet habe. Hoffe das dieser jetzt einfach funktioniert und keine weiteren Probleme auftreten. Die Bauteile haben wir so gut wie alle schon eingekauft, so dass wir nur noch auf die Leiterplatten warten müssten wenn wir die Ethernet Extension für die Produktion freigeben (Dauer ca. 3 Wochen). Ich schreibe euch sobald ich mehr weiß. Grüße

Hi Remotecontrol, würden dein RC Projekt gern auf der neuen Homepage verlinken: Siehe: http://www.tinkerunity.org/forum/index.php/topic,1445.0.html Hast du etwas dagegen? Hast du zufällig ein Foto von dem kompletten Aufbau? Grüße, Bastian

Hallo Hawk, würde dein Projekt gerne auf der neuen TF Homepage nennen: Siehe hier: http://www.tinkerunity.org/forum/index.php/topic,1445.0.html Hast du etwas dagegen? Ist es möglich an Bilder des Aufbaus zu gelangen?

Hi FlyingDoc, danke für deine schnelle Antwort. Gern würden wir dein Projekt mit auf der neuen Homepage aufführen. Siehe hier: http://www.tinkerunity.org/forum/index.php/topic,1445.0.html Möchte gern den Screenshot deiner QT Anwendung posten. Ist das ok?

Hallo zusammen, wir arbeiten zur Zeit an einer neuen Homepage. Unter anderem wollen wir die Verständlichkeit verbessern. Dazu wollen wir Beispielprojekte präsentieren, die aus 1-2 Bildern und einer kurzem Beschreibung bestehen sowie ein Link ins Wiki oder Forum. Ich werde mal ein Paar von euch anschreiben, um zu Fragen ob wir die Projekte verlinken können und um z.T. nach besseren Fotos zu fragen. Gerne nehmen wir auch neue Projekte auf. Wir hoffen ja in Zukunft weitere tolle Projekte von euch zu sehen und werden die Liste updaten.

Hallo FlyingDoc, wie ist der aktuelle Stand deines Projekts? Grüße

Haben gerade die Rücksendung bekommen. Auf dem Master Brick ist in der Tat eine Ferrit-Perle abgeraucht. Vermutlich weil sie einen zu hohen Strom führen musste. Wie dieser hohe Strom zustande kam können wir nicht sagen.

Hallo Arminius, sind deine Perl Bindings Protokoll 2.0 kompatibel? Ich sammel gerade die Bindings im Wiki und würde deine dort auch gern verlinken. Grüße, Bastian

Thanks for the Bindings! Are these bindings already protocol 2.0 compatible? Cheers, Bastian

Gibt es hier Neuigkeiten? Grüße Bastian

Ja, das wäre möglich. Hab mir die Dinge angeguckt, was ich so gesehen habe kommuniziert man mit diesen Modulen per serieller Schnittstelle. Das tun wir bei der RS485 Extension auch, was dazu führen würde, dass RS485 und XBEE nicht zusammen funktionieren werden da die serielle Schnittstelle nur einmal im Stack vorhanden ist. Besser wäre da SPI. Habs mir aber notiert und ich sehe es mir an wenn ich wieder mit "Chibi" beginne. Dennoch würde so eine Extension dann natürlich preislich in einem ähnlichen Bereich liegen wie das bei Arduino mit der Modul + Shield Lösung der Fall ist. Euch ein schönes Wochenende

Hallo Jan, wo setzt du den berechneten Wert denn? Ich vermisste ein setPosition in deinem Code. Du solltest GND und den PWM Pin vom Servo Brick anschließen. Die Ausgangsspannung ist unnötig hierbei einzustellen, da das PWM Signal des Servo Bricks immer fest mit 5V betrieben wird (oder was auch immer über USB ankommt). Grüße

Vorher war es eine Eigenbau-Lösung. Diese brachte einige Probleme mit sich. Kann hier jetzt nicht alles wiederholen, aber es gab Probleme bei gewissen Kunden die wir nicht nachstellen konnten. Dazu waren wir mit den Leistungen unzufrieden. Siehe auch unseren Blogeintrag. Unsere Chibi Extension war sehr einfach gestrickt. Die meiste Logik steckte im Master Brick der die Chibi Extension bediente. Viele kommerziell erhältliche Module besitzen einen eigenen Prozessor. Dies führt zu einer besseren Leistung aber halt auch zu höheren Kosten. Wir hatten die Hoffnung ein kostengünstiges Modul zu finden um schnell einen Nachfolger für Chibi zu finden. Wie gesagt, bisher haben wir noch keinen gefunden der unsere Anforderungen erfüllt. Oftmals sind allein die Kosten ein K.O. Kriterium. Momentan ruhen die Arbeiten an einem Nachfolger, wie gesagt es steht aber auf unserer Agenda.

Das würde die Sache natürlich günstiger machen. Allerdings bleiben die Kosten von Mikrocontroller und Funkmodul. Deine Preiswünsche werden wir damit immernoch nicht erreichen können. Wie bereits geschrieben ist das alles realisierbar. Ich fürchte nur nicht in dem Preisrahmen (zumindest nicht in der Stückzahl) Gebe dir vollkommen recht. Wir wollen ja auch einen Chibi Ersatz/Nachfolger wieder ins Programm aufnehmen. Allerdings sind die Entscheidungen dazu noch nicht getroffen. Gern würden wir da auch ein Fertigmodul nehmen wie bei WiFi, aber die meisten sind auch in 1000er Stückzahlen ähnlich teuer wie unser WiFi Modul.

Hi, technisch realisierbar sind deine Wünsche. Preislich befürchte ich aber, dass dies nicht realisierbar ist. Wir hätten ja folgende Anforderungen: * Bidirektionale Funkschnittstelle * Versorgung per Knopfzelle oder Akku etc. * I2C Bus, Messung von Analog Werten, sowie Digital In/Output auf dem Funk Bricklet verfügbar Es gibt sehr günstige Funkschnittstellen mit denen sich unidirektionale Schaltvorgänge realisieren lassen (Zertifizierung ist dabei noch fraglich). Wenn es bidirektional sein soll, dann werden diese schon deutlich teurer. Wir benötigen aber ein Konzept mit dem wir I2C Sensoren auslesen können, Spannungen messen können (z.B. von Humidity Sensor) und digitales I/O machen können. Ich fürchte da kommst du dann um einen Prozessor nicht herum. Dann möchte man das ganze ja auch per Knopfzelle o.ä. versorgen. Dafür benötigst du dann eine Spannungsversorgung die dir aus der gelieferten Spannung immer stabile 3.3V generiert (je nach Prozessor auf 5V). Die Knopfzelle wird sich ja über die Zeit entleeren. Damit wirst du rein von den Herstellkosten schon im Bereich von ~20€ liegen. Die Idee fänd ich wirklich toll. Aber wie gesagt befürchte ich, dass dies zu teuer wird.

Was dürfte so ein Funk-Sensor denn kosten? Das Problem dabei ist, dass du auf so einem Sensor neben dem Funkmodul einen Prozessor und eine Stromversorgung benötigst. Da wir hier keine Massenmarktprodukte verkaufen fürchte ich, dass den meisten der Preis zu hoch sein wird. Mit irgendwelchen Baumarkt-Funktsteckdosen werden wir zumindest nicht konkurrieren können. Auf Grund der "geringen" Stückzahl müssten wir uns ein fertiges Funk-Modul suchen das die notwendigen Funkabnahmen besitzt. Ich würde vermuten, dass wenn man eine günstige Funklösung findet, ein Temperature-Funk-Bricklet zwischen 50 und 60€ (brutto) VK-Preis liegen würde. Das würde dann wirklich auf 433 oder 828Mhz funken, wäre also keine überdimensionierte WiFi Geschichte. Grüße, Bastian

Hallo Wumpus, wir haben dein Dual Relay getestet. Das Problem war ein defektes EEPROM das sich wirklich merkwürdig verhalten hat. Wir "selektieren" das EEPROM auf den Bricklets über einen besonderen Pin an den EEPROMs mit dem sich deren I2C Adresse konfigurieren lässt. Durch Setzen dieses Pins kann ein Bit in der I2C Adresse auf 0 oder 1 gesetzt werden. Dadurch können wir sicherstellen, dass nur ein Bricklet im I2C Bus eine definierte Adresse hat. Bei den Master Bricks, mit seinen vier Bricklets wird immer von einem Brickletanschluss der Select Pin auf High gezogen, so dass nur eins der vier Bricklets die "1"er Adresse besitzt. Mit diesem wird dann kommuniziert. Dies funktionierte bei dem Bricklet aber nicht mehr da anscheinen ein interner Kurzschluss vorhanden war, so dass Anstatt der erwarteten 3.3V (Pegel High) nur ca. 1.4V vorhanden waren. Beim Servo Brick und allen anderen Bricks mit zwei Anschlüssen liegt der Select Pin der Bricklets bei einem Anschluss auf GND bei dem anderen auf 3.3V. Wegen des internen Kurzschlusses funktionierte nur der Anschluss der den Pin eh auf GND legt. Daher konnte dieser benutzt werden. Ich hoffe mir konnte jemand folgen Grüße, Bastian