batti

Kurzer Hinweis: Versuchen so etwas immer in der FAQ zu sammeln. Hier der Eintrag dazu: http://www.tinkerforge.com/de/doc/FAQ.html#eines-meiner-bricklets-wird-im-brick-viewer-nicht-angezeigt

Hallo Einstein, das ist aber echt schwierig. Wird die Step-Down mit stromversorgt wenn du das Problem hast? Sprich macht es einen Unterschied wenn du sie mit Strom versorgst oder nicht? Welche Hardware Version vom LCD hast du? Das das LCD nicht geht kann man auf ein nicht funktionierendes I2C zurückführen. Kannst du den Test bei dem das LCD nicht funktioniert mit einem anderen Bricklet wiederholen? Funktioniert das?

Hm, das ist wirklich komisch. Was ist denn der minimale Aufbau bei dem der LCD Bug auftritt? (Kann das hier nicht nachstellen). Ist die Software auf aktuellem Stand (Brickd, Brickv, Firmwares)? Was meinst du mit abziehen? Die Stromversorgung von der Step-Down oder entfernst du die Step-Down komplett?

Mh, das ist echt mysteriös. Beobachte das mal bitte weiter und schreib uns wenn es etwas neues gibt.

Wir setzen auf dem Master Brick 2.0 einen Schalter ein, der aktiv die 3.3V durchschaltet. Dies wird von einem IC namens RT9701 übernommen. Im Vergleich zu der zuvor genutzten Dioden Lösung ist der Spannungsabfall hier minimal und es kommen wirkliche 3.3V im Stack an. Ist der Prozessor noch am Booten oder im Bootloader, so würde dieser Schalter durchschalten. Daher ist ein Pulldown bestückt der in diesem Fall dafür sorgt, dass der Schalter nicht schaltet. Problematisch hierbei ist, dass der Schalter wirklich bidirektional genutzt werden kann. Sprich ist die Spannung im Stack größer wie die 3.3V auf dem Board, so fließt der Strom in umgekehrte Richtung. Dies kann dazu führen, dass die Stromversorgung auf dem jeweiligen Brick aus dem Takt kommt oder im Worst Case irgendwann kaputt ist. Da eine vernünftige Aussage zu machen ist allerdings sehr schwierig. Z.B. ist bei den Stromversorgungs ICs die wir einsetzen nicht dokumentiert was in dem Fall passiert. Dauerhaft sollten also nicht mehrere Schalter in einem Stack geschalten haben. Dann ist man denk ich auf der sicheren Seite.

Kurz zu dem was hardware-technisch Sache ist: Wenn die Step Down Power Supply nicht im Stack ist, ist die Leitung über die die Spannung gemessen wird nicht angeschlossen. Würde man hier dennoch eine Spannung messen, so würde man beliebige Werte messen können (Leitung ist "floating"). Um dies zu verhindern haben wir einen schwachen Pulldown (100k) auf jeden Master Brick gebracht. Eine stärkerer Pulldown würde die Messung verfälschen und die Last auf der Leitung deutlich erhöhen (können ja bis zu 9 Master Bricks in einem Stack sein). Wenn man den Pin berührt kann man z.T. händisch den Effekt erzeugen. In deinem Fall frage ich mich, ob er nur auftritt wenn du mit den Relais etwas schaltest. Ist dem so? Falls ja, scheint der Aufbau den du da schaltest soviel Störungen zu produzieren, dass es reicht den Pulldown zu überlagern.

Haben die Raspberry Pi Dokumentation abgeändert.

Wie ist denn dein RS485 Netzwerk konfiguriert?

Ja, die ersten Ergebnisse sehen gut aus. Zum Glück! Allerdings müssen wir noch ein wenig mehr testen, da es natürlich sehr viele verschiedene Möglichkeiten gibt Dinge zusammenzustecken. Ich bin aber zuversichtlich, dass die alle klappen werden.

Hm, musste es auch testen. Ein APK direkt hochzuladen geht in der Tat nicht. Wenn du dieses APK aber Zipst lala.apk -> lala.zip, dann solltest du es hochladen können. hab es gerade nochmal getestet. Grüße

Diese 200N/sek bezogen sich auf Java. Weil die Implementierung davon halt recht komplex ist. Eine deutlich einfacher gestricke Sprache, die vll. auf nem Basic basiert sollte auch die besagten 1000N/s erreichen. Eine Idee wäre es sich eine wirklich minimale Sprache zu Suchen und diese dann ggf. um eigene Keywords zu erweitern. Z.B. sowas wie registerCallback o.ä. Am Ende hätte man dann eine "eigene" Sprache, z.B. sowas wie TinkerBasic

The primary goal of the On Device API should be that you have the possibility to write standalone programs with an API similar to the currently used High Level API. That means, you should be able to use methods like "setVelocity" etc. This way the development of applications should be similar easy but you are forced to use one specific programming language. If this programming language will be C, of course there is the possibility to offer a (low level) Arduino like API which includes full hardware access. The usage of this low level API will not be as easy since you have to pay attention not to interfere with the On Device API functions.

Hi JavaLaurence, I'm not surprised by your language choice Your point d) is interesting. We had the same discussion in our team. I think you can discuss it in two ways. Firstly the way you have done: "Create a compatibility". The other way is to make it more high level. In short: "Make something new, make it easier". We don't use C, we use a high level language like Python or Java. The high level approach would use some kind of interpreter on the Bricks such that the performance will not be as high as when you use your own compiled C firmware. We don't have formed an opinion so far.

@Arnim: Wenn man immer mit Admin Rechten eingeloggt ist kann man dein "Problem" nicht nachvollziehen sorry. Ich habe die 5Sek mal rausgenommen. Falls uns die Spammer jetzt nicht umbringen lassen wir das natürlich so. @ArcaneDraconum: So wie ich das verstanden habe wollte Nic etwas anderes. Er wollte "Bastler" sehen und findet unsere Metapher nicht optimal (ich übrigends auch nicht). Du möchtest ja eher eine "Team" Seite. Diese würde ich momentan in die Kategorie "Nice to have" einsortieren. Natürlich wäre das schön, allerdings müssen jetzt erstmal die "wichtigen" Dinge weitergehen.

@Nic: Das ist sicherlich immer auch vom persönlichen Geschmack abhängig. Ich tue mich schwer damit mir ein solches Bild vorzustellen. Dazu kommt, das diese "Selbstaufnahmen" sich irgendwie Qualitativ von den anderen Bildern unterscheidet. @ArcaneDraconum: @Allgemein: Wir sind immer für Vorschläge/Alternativen offen. Allerdings sind wir natürlich auch froh überhaupt etwas zu haben was wenigstens ein bisschen passt.

@Arnim: Kann ich nicht reproduzieren. Meines Wissens nach existiert eine solche Sperre nicht. Habe mal gerade nach "Test" gesucht und prompt ein Suchergebnis bekommen. @Nic: Tja Bei diesem Bild haben wir uns ehrlichgesagt die Finger gebrochen. Die verwendeten Bilder wurden von uns auf einschlägigen Bilderseiten gekauft. Leider gibt es dort nur sehr wenige Daniel Düsentrieb ähnliche Bilder. Die die es gibt. sahen uns wiederrum zu verrückt aus. Wir hatten die Sorge, dass sich der jeweilige Bastler beleidigt fühlt. Auch der Versuch selbst so ein Foto zu schießen ist gescheitert. Daher blieb uns eigentlich nurnoch eine Metapher übrig.

Bernd schreib uns mal bitte mehr zu der Konfiguration (z.B. Modus der WIFI Extension: Adhoc etc.)

Ist echt schön soviel Postives zu lesen. Wobei wir etwas Kritik natürlich auch verkraften würden

Hm, soetwas ist immer schwer zu sagen. Diesbezüglich sind uns aber keine Probleme bekannt. D.h. du kannst dich dann auch nicht mehr mittels Brickv verbinden? Musst du den Masterbrick neustarten? Ein Neustart des WiFi Routers bringt nichts? (Nicht das sich dein Router aufhängt).

Mission completed

Es ist geschafft...

Hast du einen Master 2.0 oder was für einen hast du? Wenn das Problem auftauch, leuchtet dann zufällig die rote LED am Master? Wenn der Getter einen Timeout bekommt, kannst du dann noch nen setter aufrufen? bewirkt dieser dann noch etwas? Du könntest dies über ein 2. kleines Programm machen wenn das andere "abgestürzt" ist oder über nen try catch Block um die getter

Habe das auch mal in die Beschreibung aufgenommen: http://www.tinkerunity.org/wiki/index.php/DE/Artikel_Schreiben#Projekt_Artikel

Der Blog ist quasi ein RSS Feed. Du kannst die URL einfach in einen RSS Reader reinschmeißen. Sollte funktionieren

Hi Einstein, coole Sache! Gibt es die Möglichkeit das ganze (auch) ins Wiki einzubauen? Grüße, Bastian