FabianB

Das mit dem Speicherchip fänd ich auch ziemlich gut, auch, wenn mir nicht so 100%ig klar ist, wie genau der funktionieren soll. Bzgl. Python oder C: Für mich hängt es maßgeblich davon ab, wie hardwarenah das Schreiben einer eigenen Firmware wirklich wäre. Wenn es einen Lösungsweg gäbe, der so aussieht, dass man quasi ein fertiges Firmware-Grundgerüst nimmt und nur noch relativ abstrahiert, d.h. mit vorgefertigten Methoden wie wir sie schon kennen, die Programmlogik implementieren muss, dann fänd ich den besser. Deswegen hatte ich nach einem Beispiel gefragt, wie das in etwa aussehen würde. Der Knackpunkt ist wirklich, wie einfach das zu benutzen/programmieren ist. Das posten ja auch viele andere hier. Wenn man quasi nur in der Lage sein muss, ne for-Schleife und ne if-Verzweigung in C hinzubekommen und die TF-typischen Funktionen aufzurufen, dann kann das vermutlich jeder ohne Einarbeitung in C hinbekommen. Um das vernünftig beurteilen zu können, wäre es echt gut, das genaue Konzept und die Anwendungsweise zu kennen.

Wow ich muss sagen, ich hätte diese schnelle Reaktionszeit nicht erwartet. Natürlich wackelt das Bild ein kleines Bisschen, aber die Verzögerung der Ausgleichsbewegung ist im Spiegelbild nicht zu sehen.

Wenn "nur" eins von beidem geht würde ich eher zu der On-Device API für C tendieren. 1. Bietet das in meinen Augen deutlich mehr Möglichkeiten, du sagst ja selber, dass man kein vollständiges Python unterstützen könnte. 2. Ist das für On-Device Anwendungen eher das typische/gewohnte. Leute, die aus dieser Ecke kämen, würden sich direkt heimischer fühlen. Für die Python-Variante spricht, dass sie (wenn man Python beherrscht) für User einfacher ist. Das hängt in meinen Augen aber auch stark davon ab, wie genau die C-API realisiert werden würde. Wenn man gut angeleitet wird und die Benutzung sehr einfach ist, würde das den Python-Vorteil zunichte machen. Es hängt also wirklich von der Umsetzungsqualität der Dokumentation und Anleitung ab. In der Hinsicht vertraue ich euch aber, das habt ihr bisher ja auch gut gekonnt. -> C-API Vielleicht hilft hier eine Abstimmung weiter? Dafür wäre es aber gut, je ein Beispiel zu bekommen, wie das in etwa aussehen würde/könnte.

Sorry für den Doppelpost, aber der alte war mir für einen weiteren Edit zu lang :-) Ich schließe mich benatwebs Einschätzung an. Kern aller Zielgruppen ist auf jeden Fall, dass alle mit wenig Wissen möglichst schnell und einfach Hardware-Anwendungen realisieren wollen. Dementsprechend nochmal das Plädoyer für noch mehr Beispiele in der Doku. Ich denke, dass das dieser Zielgruppenkategorie besonders weiterhilft. Zu eurer Sorge, dass man nicht so genau weiß, für wen das alles geeignet ist: Das Video (wie bereits gepostet) gibt wirklich einen sehr guten Eindruck. Vielleicht könnte man das noch ergänzen? Eine zusätzliche Version auf Deutsch, noch ein paar Beispiele, die die Einfachheit der Anwendung herausstellen.... Damit mehr Leute Ideen haben, was man mit TF machen kann, und deren Kreativität entlastet wird, wäre es noch gut, wenn ihr auf der Webseite mehr kompatible Produkte anderer Hersteller (Motoren etc.) verlinken würdet. Alles könnt ihr ja nicht selber anbieten. Auf diese Weise könntet ihr einen Bauvorschlag mit passendem Zubehör machen, der gar nicht groß dokumentiert werden muss. Hauptsache, eine Umsetzungsidee steht im Raum und man weiß, was man braucht. Was ich persönlich aber insgesamt für den wichtigsten offenen ToDo-Punkt halte ist die On-Device-Geschichte. Das würde, wenn das gut umgesetzt und ebenfalls einfach zu machen ist, meiner Einschätzung nach die Zielgruppen noch erweitern. Für mich wäre das der Schritt, der euch mittelfristig am weitesten weiterbringen würde. Ich werde, wenn ich Leuten Tinkerforge zeige, IMMER danach gefragt. Ich weiß, dass das nicht so leicht umzusetzen ist und es deshalb auch nicht sofort kommt. Wäre das aber in eurem Programm mit drin, würde die Webseite dadurch schon gewaltig ergänzt/beeinflusst werden.

I agree with raphael_vogel.

Ich greife mal gerade diesen Punkt raus, auch wenn der nicht Kern der Diskussion ist: Für Lehrer/Schulen ist Tinkerforge an Eignung kaum zu überbieten. Programmierbar mit Java, ohne Elektronik-Vorkenntnisse machbar, optimal um Objektorientierung zu vermitteln, schnelle Fortschritte und damit schnelle Erfolgserlebnisse und vieles mehr. Alle Lehrer, denen ich das gezeigt habe, waren davon genauso begeistert wie ich. Starterkits o.ä. wären für diesen Zweck optimal. Die Sache hat nur einen Haken: Den Preis. Schulen haben (leider) kein Geld. Ein solches schulgeeignetes Starterkit müsste also auf Preisgünstigkeit bei akzeptablem Funktionsumfang getrimmt sein. Das hier wäre dem (für das konkrete Schulbeispiel) abträglich. Aber dafür ließe sich bestimmt auch eine andere Lösung finden. Z.B. könnten Schulen (mit offiziellem Nachweis) direkt über Tinkerforge speziell ausgerichtete Kits in kleineren Mengen zum Rabattpreis bekommen. Wie wäre diese Option? Edit: Als Grundlagen-Kit für Schulen fänd ich die Zusammenstellung aus - Master Brick - Temperature Bricklet - Linear Poti - IO4 (LEDs) Geeignet. Schön wäre eigentlich, das LCD dazuzunehmen, das macht es aber direkt sehr teuer. Mit diesen 4 Bausteinen kann man 4 Schüler sinnvoll beschäftigen, es bieten sich verschiedene Bauprojekte an und es ist in Rrelation zu anderen Kombinationen sehr günstig und überschaubar. Natürlich kann man damit nicht sehr viel realisieren, aber schon einiges. Will man mehr machen und findet man Sponsoren in der Schule, kann man es erweitern. Ende Edit Zur Gestaltung der Seite: Ich habe mittlerweile ein bisschen Erfahrung darin, Schüler mit Tinkerforge arbeiten zu lassen. Dabei habe ich sowohl eure offizielle Dokumentation verwenden lassen als auch ein von mir zusammengestelltes Heft mit einer Kurzdokumentation zur Verfügung gestellt. Diese Kurzdokumentation ist nur ein verkürzter und auf das Benötigte reduzierter Ausschnitt aus eurer Doku. Dabei ist mir aufgefallen, dass Schüler (also Leute mit wenig Programmiererfahrung) recht gut mit eurer Doku klarkommen, diese aber noch optimierbar wäre: Es wäre noch einfacher zu verstehen, wenn zu den einzelnen Funktionen jeweils ein (sehr) kurzes Beispiel beigefügt wäre, in dem die Funktion verwendet wird. Das würde ohne Kontext ausreichen, also einfach jeweils ein Quellcode-Einzeiler. Die Beispiele oben in der Doku sind extrem hilfreich, aber leider umfassen sie nicht alle Funktionen. Für Programmiereinsteiger, und davon sind mir hier im Forum auch schon einige begegnet, wäre das in meinen Augen eine große Erleichterung. So müsste man keinen Programmierkurs daraus machen, kann Einsteigern aber trotzdem weiterhelfen. So ließen sich Programme per Copy-Paste zusammenbauen.

Man könnte meinen, das Projekt basiert auf Tinkerforge :-D : So oder so, interessante Sache.

Tja also... ich schließe mich da Luxor an. Ehrlich gesagt hatte ich mir die Frage auch schon gestellt. Die Programmiersprachen, die ich persönlich für Einsteigerfreundlich halte und die du für die Tinkerforge-Sachen verwenden kannst, wären Java und Python. Dazu gibt es auch eine Menge Tutorials etc. im Internet.

Screenshots von was genau??? Wenn du wissen willst, wie die einzelnen Programme aussehen, verweise ich mal auf google. Da findest du mehr...

Hey, was meinst du mit Programm? In welcher Entwicklungsumgebung? Das hängt in meinen Augen ein bisschen von der verwendeten Programmiersprache ab. Falls du Java verwendest, könntest du zum Beispiel Eclipse oder Netbeans benutzen, der Java-Editor ist eine schlankere Alternative. Ich persönlich benutze aber nie IDEs, ich arbeite immer nur mit einem Texteditor, der Syntax-Highlighting und so unterstützt, und dem Compiler. Das ist am schlankesten und man muss sich nicht erst in das Programm einarbeiten. Viel Spaß jedenfalls

Ich habe den Thread nur überflogen, sorry, wenn ich was Sinnfreies schreibe: Das Shannon-Theorem besagt, dass eine Abtastfrequenz mindestens doppelt so hoch sein muss wie die höchste Frequenz im abgehörten Signal. Das kann man vom Schema her wohl übertragen würde ich sagen: Wenn die Speiche also vorbeirauscht und dabei jeweils(je nachdem, wie dick sie ist) eine 100stel Sekunde vor dem Sensor ist, dann muss der Sensor mindestens jede 50stel Sekunde abtasten, damit die Speiche nie "übersehen" wird. kannst du über die Abtastfrequenz nichts verbessern? Hilft der Hinweis? EDIT: Sorry, hab gerade erst gesehen, dass Nic das in etwa schon gesagt hat.

Wie der Titel schon sagt: Rechtzeitig zum Last-Minute-Weihnachtsgeschäft hat Golem.de wieder einen ausführlichen Bericht über Tinkerforge gebracht: http://www.golem.de/news/tinkerforge-neue-bausteine-zum-stapeln-1212-96290.html

Hallo liebes TF-Team, gestern war zwar genau genommen nicht der wirkliche Geburtstag von TF, aber am 8.12.11 habt ihr euer Vorstellungsvideo online gestellt. Mit diesem Schritt seid ihr ja dann erst so richtig bekannt geworden, kurz darauf hattet ihr schon im Blog gepostet, dass ihr überrannt wurdet. Also: Vor einem Jahr ist der Laden so richtig ins Rollen gekommen. Es ist viel passiert seitdem. Ihr habt euch wacker geschlagen. Herzlichen Glückwunsch dazu und dass euch auch in Zukunft die Puste nicht ausgeht.

Das wäre super. Das Ergebnis würde mich nämlich interessieren. Meiner hängt übrigens auch an einem Gigabit-Port. Das ist der eingebaute Switch meines Routers. Also einfach am Routerport. Das Kabel ist 50 cm lang.

Ich habe das gerade mal gegoogled: Hier wird das Problem geschildert: http://www.raspberrypi.org/phpBB3/viewtopic.php?f=28&t=21963 und hier scheint es gelöst worden zu sein (Ist unter dem ersten Link gepostet worden): https://github.com/raspberrypi/linux/issues/151 Angeblich soll ein rpi-update das Problem beheben. Damit ist aber wirklich rpi-update gemeint und nicht apt-get update, also: sudo rpi-update Dafür musste das natürlich installiert haben, wovon ich aber mal ausgehe. Hilft das bei dir?

Hab nochmal 3 Artikel umgesiedelt. Funktioniert alles top. Allerdings bleiben die alten Artikel mit einem Verweis auf den neuen Ort erhalten. Willst du diese alten Seiten dann später löschen? Da müsste glaube ich sowieso mal ein bisschen aufgeräumt/ausgemistet werden in der Seitenübersicht. Ich werde in den nächsten Tagen nach und nach alle übrigen Projekte übersiedeln. Wer sich beteiligen möchte, kann sich vielleicht noch die Nicht-Projekt-Artikel vornehmen.

Merkwürdig, hast du das bei beiden? Bisher ist meine Uptime zwar nur 14 Tage, aber alles läuft vorzüglich. Komisch. Läuft auf beiden exakt die gleiche Software? Du hattest das Problem doch mit beiden, oder?

Ok, dann weiß ich bescheid. Die nächsten werde ich dann mit "move" umziehen lassen. Den alten "Jalousie Automation" kannst du dann löschen, ich habe zumindest keinen Button dafür gefunden. Ich denke, dass das sinnvollerweise eh nur Admins dürfen. Dann behalte ich bei den nicht übersetzten Projekten erstmal das Verfahren bei, den jeweils anderssprachigen Artikel ebenfalls anzulegen aber mit dem Hinweis zu füllen, dass die Übersetzung noch fehlt. Dann ist die Struktur einheitlich und man braucht später nur noch die Übersetzung einzufügen.

Guter Hinweis. Was sollen wir mit Artikeln machen, die nur in einer Sprache vorliegen. Ich habe jetzt z.B. Jalousie_Automation umgezogen, das gibt es nur in englisch. Hab in der deutschen Version eingetragen, dass die Übersetzung noch folgt. Was passiert mit den "alten" Artikeln? Werden die dann von euch gelöscht?

Das sieht doch gut aus soweit. Ich werd ein paar Artikel übersiedeln, aber erst morgen.

Aber absolut nicht so cool wie ein Bricklet Vergleicht man beide Werte, so stellt man fest, dass das Gehäuse die Wärme ordentlich staut bzw. der Chip sie ohne Kühler schlecht abgeben kann. Nicht wirklich eine Überraschung. 54 °C gibt er mir aus. Ab 85 °C gibts laut den Entwicklern wohl bleibende Schäden, er soll sich vorher aber wohl automatisch runtertakten. -> Spätestens im Sommer wirds ein bisschen enger.

Ich habe mal ein kleines Experiment mit dem Temperature-Bricklet gemacht und die Temperatur des Raspberry Pis gemessen: Folgende Rahmenbedingungen: - Uptime: 8 Tage - Last: kontinuierlich 0,6 - Taktung: 800mHz - Modell B, 512 MB RAM - Messdauer: 15 Minuten - Raumtemperatur: 18,5 °C - Raspberry Pi ohne Kühlkörper, Lüfter oder sonstige Kühlvorrichtungen RS-Standard-Gehäuse, Lüftungslöcher nach oben. Ich habe den Sensor direkt auf die Lüftungslöcher gelegt (Sensor unten, Platine oben). Nach 15 Minuten hatte sich der Wert eingependelt, der höchste gemessene Wert war 29,25 °C. Der Durchschnitt lag bei 29,18 °C. Im Gehäuse, besonders der Chip selber, dürften deutlich wärmer sein, vermute ich. Wie warm wird eurer so? Ich würde mal sagen, die Temperatur ist in Ordnung, um nichts dagegen zu unternehmen. Allerdings könnte es im Sommer ein wenig sehr heiß werden. Kühlt ihr euren? Wie?

Wie sieht denn momentan deine Planung aus? Die ersten Artikel machst du noch selber fertig? Ich denke, dass das vor allem für die Artikel in der Community-Ecke sinnvoll wäre. Es gibt schon was, was auf den Einzug in die neue Wiki wartet: http://www.tinkerunity.org/forum/index.php/topic,1192.msg7227/boardseen.html#new

Jap. Ich konnte die 256 MB Variante nie ausprobieren, deswegen fehlt mir der direkte Vergleich. Aber ich muss echt sagen, dass ich von der Performance positiv überrascht bin. Die RAM-Vergrößerung hats wirklich gebracht. Den Ram umverteilen zu können ist auch eine super Sache. Und ich kann auch nur jedem raten, keine billige Class 4 SD zu nutzen, sondern sich was flottes zu gönnen. Es gibt auch kompatible Class 10 Karten. Zumindest, wenn man im Betrieb öfters SD Zugriffe hat, macht sich das bemerkbar. An die, die den Pi mit TF-Produkten nutzen: Wie performant verhält er sich denn da? Gibt es Schwierigkeiten mit den Listenern bei hohen Mess-Frequenzen oder so? Irgendwo wurde schonmal darüber geschrieben, aber ich habs nicht mehr gefunden.

Hey, cooles Projekt. Zu deiner Autostart-Frage: Wie du ein Java-Programm in der Konsole ausführst, weißt du vermutlich: javac programm.java java programm Unter Linux kannst du z.B. das Runlevel-Konzept nutzen und ein eigenes Autostart-Skript anlegen. Wie das im Detail funktioniert, ist hier ganz gut erklärt: http://wiki.ubuntuusers.de/Dienste Diese Anleitung ist zwar für Ubuntu geschrieben, funktioniert für Debian bzw. Raspbian genauso. Hat dir das geholfen oder habe ich deine Frage falsch verstanden? Sonst frag einfach nochmal nach.