borg

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?

Falls die RS485 Slaves sich neu initialisieren solltest du auch wieder eine EnumerateCallback bekommen. Ob sie das tun hängt davon ab was genau wirklich passiert in dem Fall .

Hab gerade mit Batti drüber gesprochen, du kannst auch nur - trennen und an GND und M anschließen. Stimmt so nicht, siehe unten .

Du trennst einfach + und - und schließt es wie folgt an: Sensor 1/2 M ----> - + ----> + Supply GND <---- - VCC <---- + Also im Prinzip einfach wie beim Type 2 Sensor:

Die Gehäuse sind alle mit FreeCAD gemacht. Die Designs der Gehäuse stehen unter CC-BY-SA. Also wenn ihr einen Laser Cutter zur Hand habt könnt ihr euch die auch gerne selbst lasern . Hier gibts die Projektdateien: https://github.com/Tinkerforge/cases FreeCAD kann in DXF/STEP etc exportieren, ist also kein Problem das auch in andere CAD-Umgebungen zu übernehmen! Ah, das ist in der Tat noch nicht drin. Außenbemaßung füge ich dann auch noch hinzu.

Puh, die ganzen Gehäuse reinsetzen ist mehr Arbeit als ich erwartet hatte. Blogeintrag ist jetzt raus: http://www.tinkerforge.com/de/blog/2013/7/9/gehaeuse-fuer-bricklets Es sollten keine toten Links oder falsche Bilder oder vergleichbares mehr drin sein. Bitte Bescheid sagen wenn ihr noch was findet, sind bestimmt irgendwo noch Fehler! Was noch fehlt sind Links vom Shop zur Dokumentation und Auswahlmöglichkeiten für Gehäuse direkt bei den Bricklets im Shop. Da kümmere ich mich dann direkt morgen früh drum .

In der Tat, ist im Moment auch noch work-in-progress. ~2 Stunden noch, dann bin ich fertig.

Dokumentation für die neuen Gehäuse und Ankündigung kommt noch heute Abend (dann sind sie im Shop auch nicht mehr ausverkauft), bin gerade dabei alles einzurichten und hochzuladen. Das wird noch ein bisschen dauern. Das LCD20x4 Bricklet ist nicht in unserem 5mm-Raster (da das LCD selbst, welches nicht von uns kommt, schon Löcher hat die wir übernehmen). Die Löcher unten im Gehäuse bringen es aufs 5mm-Raster damit man es auf einer Hutschienenbefestigung oder einer Montageplatte verschrauben kann. Du kannst aber auch ein Brick drunter schrauben wenn du willst .