borg

Welche Programmiersprache verwendest du denn? Bei Python würde man dafür für gewöhnlich eine Lambda-Funktion verwenden, also sowas wie: register_callback(lambda x: my_callback("UID", x))

Die Algorithmen die man dafür braucht liegen sozusagen "direkt hinter der Antenne". Das GPS Modul was bei uns drauf ist gibt ja schon direkt GPS Koordinaten aus, ich glaube nicht das es möglich ist sowas mit dem GPS Bricklet nachzubauen kann. Wenn da jemand ein besseres Verständnis von der Materie hat lasse ich mich aber auch gerne vom Gegenteil überzeugen .

So wie der Master im Moment programmiert ist, ist er immer voll ausgelastet. Wenn nichts zu tun ist fragt er seine Stack-Teilnehmer ununterbrochen nach neuen Daten. Die Frage ist was du machen möchtest, viele Dinge könnte man in Theorie direkt auf dem Master Brick machen. Wenn du aber z.B. viele Floating-Point-Berechnungen brauchst, bist du ganz schnell an der Leistungsgrenze. Kann man so allgemein nicht beantworten.

Ich könnte da noch eine Statistik vom tinkerforge.com Webserver beitragen: Das entspricht allerdings nicht unbedingt den aktiven Nutzern unserer Produkte.

Sowas in der der Art, ja . Der Prototyp mit dem ich hier arbeite hat eine Ziffernhöhe von 10mm. Die Größe gefällt mir eigentlich auch ganz gut.

Die "Arbeitsrechner" und der "Versandrechner" im Lager usw laufen bei uns hier alle unter Linux. Zusätzlich haben wir ein MacBook Pro sowie VMs für alle gängigen Windows Versionen zum testen.

Ha, genau daran arbeite ich gerade. Fällt bei uns unter dem namen "Multi Touch Bricklet". https://github.com/Tinkerforge/doc/commit/874f479e1f3388cae1d5a5d37958aea1c4d58a5a Der MPR121 hat sehr viele Einstellungsmöglichkeiten, bin gerade noch dabei herauszufinden welche wir einfach festlegen können und welche wir per API Einstellbar machen sollten .

Die Plugins der Bricklets werden einmal pro ms aufgerufen. D.h. die Bricklets selbst können auch nur mit einer Auflösung von einer ms einen Puls auswerten. Wir planen ja auch schon seit längerem selbst ein Ultraschallsensor-Bricklet anzubieten, genau wegen dieser Problematik ist das leider nicht so einfach. Da gibt es im Prinzip nur zwei Möglichkeiten: Entweder wir werten die Pulslänge irgendwie über einen weiteren IC aus oder wir nehmen teurere Ultraschallsensoren die selbst schon I2C o.ä. sprechen. Kurz gesagt: Für dein Problem gibt es leider keine einfache Lösung . Am einfachsten wäre es wenn du einen Ultraschallsensor nimmst der eine analoge Spannung ausgibt und diesen am Analog In oder Voltage/Current Bricklet anschließt.

Zu kaufen wird es ein vergünstigtes Starter Kit: Wetterstation geben. Beim Hardware Hacking Kit haben wir leider gerade Lieferschwierigkeiten zum ungünstigsten Zeitpunkt... Angucken kann man sich die Kits, Bricks/Bricklets und einen weiteren Testaufbau (den es schon auf der Elektor LIVE gab). Einen Prototypen des nächsten Starter Kits wirds auch geben. Zusätzlich haben wir eine Überraschung für jeden Besucher des Stands die man sich vor Ort selbst zusammenbasteln kann. Und wer möchte kann sie dann zuhause auch an einen Brick anschließen .

Ein Flankenzähler ist ja das gleiche wie ein Tastendruckzähler , das eine würde also automatisch mit dem anderen kommen.

Man könnte einen Flankenzähler in die IO Bricklets einbauen. Allerdings würde der Zählerstand sich trotzdem zurücksetzen wenn der Strom ausfällt oder das Brick aus anderen Gründen neustart! So ein Flankenzähler steht schon auf der TODO Liste.

Ist das denn wieder ein WLAN Problem? Also hast du die Probleme auch wenn du es direkt per USB anschließt? Ich teste deinen Beispielcode heute Abend, mal gucken ob ich das reproduzieren kann.

Es ist in der FAQ vermerkt, vielleicht könnten wir das aber an anderer Stelle auch nochmal vermerken: http://www.tinkerforge.com/de/doc/FAQ.html#mein-brick-taucht-nicht-als-serielle-schnittstelle-fur-s-flashing-aus

So ganz kann ich dem nicht folgen Ein Neigungssensor z.B. ist sicher nicht schlecht aber dazu gab es im Forum weniger Nachfrage als etwa zu einer Neuauflage der Chibi-Extension oder ein Schnittstellen-Bricklet für RS-232 :'( Wir planen einen Schwung von neuen günstigen Bricklets vorzuziehen bevor wir wieder teurere Hardware machen. Wir können nicht jeden Monat ein Projekt der Preisklasse einer Ethernet Extension veröffentlichen, das geht einfach finanziell nicht . Wenn sich das auf die OnDevice-API bezieht, so sollte man das Thema nicht ganz aus den Augen verlieren, denn dazu war das Feedback hier im Forum zu groß. Wenn es technologisch (noch) nicht lösbar ist, so würde ich kleinere Schritten in diese Richtung mir mehr wünschen, als eine mo­no­li­thische API die niemals kommt. Erste Schritte wären z.B. ein Tutorial wie die komplette Entwicklungsumgebung dazu einrichtet wird und wie man die dabei entstehenden Fallstricke und Besonderheiten sicher behandelt. Hierzu gibt es zwar Beiträge im Forum, die m.E. aber für Anfänger zu kryptisch und unvollständig sind. Ideal wären Schritt-für-Schritt Anleitung wie die FW bzw. Plugins der Bricklets um einfache Funktionalität erweitert werden kann. Ev. reicht es auch für viele Zwecke aus, das direkte Ansprechen von Bricklet-Daten am Brick, z.B. Endlagenschalter via IO Signale ohne Umweg direkt am Brick auszuwerten. Die Aussage bezog sich auf Entwicklung neuer Hardware, wie lange es dauert eine OnDevice-API zu bauen wissen wir ganz gut denke ich. Wir haben da diesbezüglich auch schon eine Entscheidung getroffen wie das genau aussehen soll, wir werden unsere Masterplan diesbezüglich denke ich nach dem neuen Schwung von Bricklets veröffentlichen. Es wird ein wenig anders werden als wir es erst selbst vorgeschlagen haben, aber die allermeisten der Anforderungen erfüllen die wir von euch gesammelt haben .

Ja, wir wissen auch nicht so genau was wir da machen sollen. Die Feststellung ist: Wir können Termine bzgl. Hardwareentwicklung nicht wirklich einhalten. Da gibt es einfach zu viele Ungewissheiten. Ich denke wir sollten da vielleicht eine "Produkthistorien"-Seite draus machen mit einer Vaporware-Sektion unten drunter wo Produkte aufgelistet sind die evtl in näherer Zukunft kommen könnten . Es gibt bei uns übrigens immer die Möglichkeit auf github die letzten paar commits durchzugucken, wir entwickeln ja schließlich öffentlich .

Für mich sieht das so aus als würden irgendwelche Abhängigkeiten fehlen, vermutlich qwt? sudo apt-get install python python-qt4 python-qt4-gl python-qwt5-qt4 python-opengl python-serial pyqt4-dev-tools

Interessant. Gut zu wissen!

Ob wir die Callbacks jetzt am Ende wieder ausschalten oder nicht ändert ja nichts daran das Brickv an den Einstellungen rumstellt. Entweder Brickv zeigt Daten an und stellt auch entsprechend dafür alles ein oder Brickv zeigt keine Daten an. Man könnte höchstens Brickv so umstricken, das nur noch getter verwendet werden. Das ist aber bei Sachen die reaktionsschnell seien sollen (IO-4/16, Ind. Digital In etc) blöd, da man dadurch Lag reinbekommt.

3.3V, SCL/SDA und ADDR sind nur am EEPROM angeschlossen, aus dem die Firmware für das Bricklet gelesen wird. Du musst also nur GND, 5V und IO_1/AD anschließen. Die Entfernung wird als analoger Wert über IO_1/AD ausgegeben, der analoge Wert geht nicht höher als 3.3V du kannst es also problemlos am RPi anschließen.

Der Brickv setzt wenn du ihn schließt alle Callbacks die er selbst aktiviert wieder auf Default zurück. Das ist aber kein Standardverhalten der Firmware oder sowas, das macht der aktiv.

Da auf dem PTC Bricklet die Klemmleiste ist brauchen wir sowieso den THT Lötprozess (d.h. das Panel muss durch die Welle fahren). Dazu kommt das ein SMD fähiger DIP Switch ganz schön teuer ist, das Plastik muss ja die Hitze des Reflowlötens aushalten. In Summe wäre eine Lösung mit DIP Switches teurer gewesen. Prinzipiell hast du aber recht, das setzen und anlöten eines THT Bauteils kostet mehr als 10x soviel wie bei einem SMD Bauteil .

Ja, sinnvoll klingt das. Ist halt viel Arbeit, vielleicht füge ich es ein wenn ich das nächste mal etwas größeres an den Firmwares ändere. Versprechen tue ich da aber nichts . Das kannst du relativ einfach selbst bauen. Setz einfach irgendeine Eigenschaft die du nicht brauchst (z.B. einen Threshold-Callback-Wert oder so). Den kannst du dann regelmäßig auslesen und er springt nach einem Neustart wieder auf Default zurück.

Ha, da hab ich sogar eine Antwort drauf: Der Übergangswiderstand bei DIP Switches ist größer als bei der Jumper-Lösung (Zumindest nach meiner Messung mit den DIP Switches und Jumpern die wir hier hatten). Das PTC Bricklet misst ja Widerstand, das ist also relevant. Zusätzlich nehmen die Stiftleisten auch noch ein weniger Platz weg und kosten ein bisschen weniger .

Na das ist doch gar nichts. Da wird der Festspannungsregler auf dem Master von sich aus ja schon viel wärmer, kann mir eigentlich nicht vorstellen das es dadurch Probleme gibt.

Das ist natürlich schwer zu sagen. Wenn du sagst es tritt auf wenn es sehr warm ist, deutet es ja darauf hin das es ein Hitzeproblem ist. Wie warm wird es denn in dem Gehäuse wo du die Bricks einbaust?