JoergK

Hallo, bezüglich Hardware: - Ja, man verwendet ICs von Herstellern, aber auch die sind im Grunde nur Zusammenfassungen von einfachen Komponenten (Widerstände, Transistoren, etc.) Wie gehe ich an sowas heran (Ausbildung als Nachrichtenelektroniker auch schon gut 20 Jahre her). Ich suche mir in Internet mittels Schlagworten und dem Magic-Schlagwort "Schaltplan" etwas heraus. Meist trifft man dann auf Hinweise, dass es einen schönen IC gibt, der mit etwas Beschaltung das macht, was man möchte (Bspw. MCP23017 Port-Expander). Zu jedem IC gibt es Datenblätter und meist auch mit Beispielschaltungen. Rechenvorschriften sind dort auch gegeben. Klingt jetzt einfach, ist es aber nicht!!! Besonders wenn man EMV beachten muss usw. Zu deinem Beispiel Temperaturbricklet: Suche im Internet nach digitalen Temperatur-IC oder so. Schon triffst du auf Vorschläge für Bauteile. Datenblatt nehmen und sehen, wie das Protokoll abgebildet ist. Meist I2C(TWI) oder SPI aber auch 1Wire... Da steht auch wie du das Ding zu beschalten hast. Aber nun kommt TF ins Spiel. Adressierung des Bausteins muss ja den Regeln von TF folgen. Du wirst erkennen, dass nahezu alle Bricklets den ein oder anderen Baustein gemeinsam haben. Da steckt ein wenig Magic bzw Know-How von TF drin (Speicherbausteine). Da hab ich mich noch nicht ran gewagt. Habe die ein oder andere Hardware selbst gebaut und an das TF System über Bricklets angeschlossen oder halt neuerdings selbst µC genommen und programmiert. TF war die Einstiegsdroge für mich... D.h. Hardware ist interessant aber auch nicht einfach. Google mal Dave Jones. Ein netter umstrittener Australier, der das ein oder andere Basiswissen vermittelt. Zu guter letzt: Nein Tinkerforge sind nicht nur "Anwender". Es sind Entwickler, die vorhandene Bausteine nutzen, um etwas größeres zu erschaffen. Quasi nutzen sie Bausteine wie wir Bibliotheken in der Softwareentwicklung. Gruß Jörg

Hmm, möchtest du die Lichtschranken mit der IO4 auch einschalten? Wenn ja, dann musst du ein wenig mehr Beschaltung hinzufügen. Wenn nein sollte das IO4 auf der dauerstromversorgung (+ und GND Ausgänge) genug sttom liefern können. Heisst aber auch, wenn du Tinkerforge an Spannung anachließt, dann sind die Lichtschranken an und verbrauchen Strom. Die IO Ports sind in diesem fall eingänge und sind hochohmig, also fließt da sehr sehr wenig (vernachlässigbar) strom rein. Habe gerade nachgeschaut (überflogen), leider sagt die Doku nichts über den max. theoretischen Strom am 3V3 Ausgang aus. Ja ja ich weiss alle Spannungsversorgungsausgänge kommen vom Stack. Daher theoretisch

Du kannst an eine IO4 bis zu 4 Lichtschranken anschließen, an eine IO16 bis zu 16 Stück. Vielleicht hilft es zum Verständnis (bei 4 Lichtschranken): Den leuchtenden Teil der Lichtschranken kannst du alle parallel an die Spannungsversorgung anschließen (3,3V -> Widerstand -> (+Seite)Lichtquelle der Lichtschranke -> (-Seite)Lichtquelle der Lichtschranke -> GND). Jetzt kommt die andere Seite. Die meisten die ich kenne haben einen Fototransistor. Quasi ein Schalter, der bei Lichteinstrahlung geschlossen ist und wenn das Licht weg geht, dann ist der offen. Wenn du es nun folgenden Aufbau machst: (3,3V -> ("+Seite")Transistor der Lichtschranke -> (D-Seite)Transistor der Lichtschranke -> [Kabel an IO-Port]+[Widerstand 1KOhm] -> GND. Damit schalten dann 4 Lichtschranken unabhängig voneinander. Beste Grüße Jörg

Links: http://www.digi.com/support/kbase/kbaseresultdetl?id=2180 http://www.digieurope.de/de/products/wireless/zigbee-mesh/xbee-zb-module#docs oder einfach nach Xbee googlen. Da gibts ne Menge Lesestoff. Und ich bin ja nicht weg, die TF Komponenten behalte ich und sobald mein Hauptprojekt anläuft (Hausbau, nur das Grundstück fehlt noch) wird TF wieder in meinem Fokus weiter vorrücken. Das Forum lese ich so oder so regelmäßig...

Ja, den C't Hack kenne ich. Wie gesagt, ich find TF gut. Aber um nur zu überbrücken und dafür > 100€ ausgeben, ist nicht wirklich wirtschaftlich, aber gut gemeint von dir. Ja, die Xbee's haben einige Digitalports und A/D Wandler schon beinhaltet und ausgeführt. Für sehr kleine Anwendungen brauchts dann kaum weitere Systeme (beispielsweise Temperaturlogger: Batterie, Xbee-Modul, PT100. Das reicht eigentlich schon, ohne state-of-the-art Elektronik beachtet zu haben.)

Gilt das nicht genauso wie für einen Arduino + XBee Shields ? Und für diese Teile brauchst du ebenfalls eine mobile Stromversorgung. Also die Xbees sind nicht viel billiger, zumal Du auch ein Paar brauchst. Sicherlich bin ich mit Arduino und Xbee für 2 Stationen erstmal geringfügig teurer. Dafür habe ich dann aber pro Empfänger bis zu 128 Kanäle zur Verfügung (I2C MCP23017). Das mit TF aufzubauen ist dann geringfügig teurer, da ich so oder so Zusatzbeschaltung nötig habe (bei Arduino etwas weniger Peripherie, wie bspw. AnalogIn-Bricklets). Um auf 500m WLAN zu kommen, brauche ich aber bei perfekten Bedinungen 4 TP-Links und sehr teure - da hoher dB Gewinn - Antennen. Ich gebe dir Recht, dass ich bei den TPs mit Batterien auskommen würde, Blei-Gel-Akku 12V/~3Ah, ein bisschen Elektronik für die 5V, wasserfestes und WLAN taugliches Gehäuse. Hmm, vielleicht verstehe ich gerade deinen Einwand. TF-Komponenten sind schon in Wetterfesten Gehäuse. Mir gehts um die Tp-Links. Die muss ich irgendwo hinlegen/stellen. Ich will damit sagen, Sender und Empfänger sind wetterfest. Bei deinem Vorschlag WLAN über 500m ausbreiten zu wollen, bedarf es aber zusätzlich noch weiterer Stationen. Das ist wie gesagt für meinen Anwendungsfall nicht praktikabel. Ansonsten tuen sich Arduino und TF nicht viel, Arduino & Co sind länger auf dem Markt und bieten meines Erachtens mehr Komponenten an, TF ist für Elektroniklaien besser geeignet. Jeder hat seine Vor- und Nachteile. Es kommt halt auf den Anwendungsfall an.

Zwischen 200m und 500m. Also worst-case (in Zukunft) 500m. Der TP-Link allein kostet ja schonmal 50 Euros. Zudem ist er nicht wetterfest. Das ganze wird in rauen Umgebungen eingesetzt. Auf Feld und Wiese... Neben der Reichweite finde ich die Möglichkeit der Stromsparfunktion der Xbees ganz nett. Damit kann ich dann auch ein HW-Interrupt mit den Arduinos nutzen und die auch schlafen lassen. Die Systeme werden im Allgemeinen Nachmittags installiert und Testläufe durchgeführt. Dann wird der Abbrennplatz/Abbrennplätze verlassen und die Systeme werden schlafen gelegt. Abends wird aufgeweckt, erneut getestet und dann: Feuer... Zwischenzeitlich geht man nur noch auf den Abbrennplatz, wenn es sich absolut nicht vermeiden lässt. Aber das ist nur ein Zubrot.

Das glaube ich nicht, denn du scheinst doch recht weit gekommen zu sein und nur an der Reichweite zu scheitern ?! Mit dem RED scheint TF ganz gut ausgelastet zu sein Für die Zwischenzeit hast Du noch alle anderen Alternativen ausprobiert wie größere Antenne, mobiler Router bzw. Repeater um die Reichweite der WiFi-Ext. zu erhöhen ? Die zusätzliche elektronik, die ich benötigte, hat etwas mehr Zeit in Anspruch genommen. Das war die meiste Arbeit. Aber dies hat nix mit dem verwendeten Microcontroller zu tun. Sicherlich bin ich von der Idee überzeugt gewesen und mit gefällt das System auch recht gut. Ich denke sogar, dass ich in allen Fällen die Komponenten behalten werde, selbst wenn ich auf ein anderes System für meinen Anwendungsfall wechsel. Ein mobiler Router kommt nicht in Frage, da ich das System im Freien und auch bei Regen verwende. Ich kenne keine kostengünstigen Router mit 12V(DC)-Anschluss, die zudem die Batterie nicht in null komma nix leer saugt. Und mit Xbee/Zigbee benötige ich keine Antennenmasten, die ich mit mir rumschleppen muss. Ich habe mich heute daher entschieden, auf ein anderes System zu schwenken. Silvester wird das heutige System ein letztes Mal verwendet. Sollte ich mit dem anderen System nicht schneller fertig werden, als gedacht. Wie gesagt, das TF-System birgt meines Erachtens noch Potential, aber für diesen einen (meinen) Fall, passts noch nicht. Und wer weiss, wenn die Jungs (und Mädels?!) von TF sich doch noch durchringen können und ein "Shield" für Xbee planen, oder das Chibi kompatibel mit den Xbee's sein wird, dann kann ich mein altes Layout wieder rauskramen und die neue Anlage damit schnell um ein paar Ports erweitern.

Hallo, Ich weiss das Thema nervt. Aber genauso wie es nervt interessiert es auch. Da meine Zündanlage mittlerweile läuft, jedoch bei den ersten events heraus gekommen ist, dass ich mit der viel zu kleinen Reichweite des WLAN Moduls in naher Zukunft nicht annähernd auskommen werde, greife ich das Thema ein letztes Mal für mich auf. Im nächsten Jahr werde ich meine Zündanlage erweitern müssen. Also benötige ich eine relativ verlässliche Aussage über die Verfügbarkeit einer besseren funkanbindung der TF Komponenten. Jede Aussage ist willkommen. Alternativ zu TF sehe ich im Moment Arduino und (udoo). Bei beiden ist entsprechendes vorhanden, lediglich die Sprache muss man ein bisschen lernen. Aber eigentlich kein hinderungsgrund zu wechseln. Das Konzept von TF finden ich zwar gut, aber leider bis jetzt nicht für meinen Anwendungsmöglichkeiten geeignet. Also nochmal meine Frage. Wann wird ein entsprechendes funkmodul (re-)etabliert? Stichwort: Roadmap! Vielleicht, könnte, wir müssen mal schauen Aussagen helfen leider keinen weiter. Dafür sind meines Erachtens die Alternativen zu stark... In der Hoffnung einerseits genaueres zu erfahren und andererseits zu hoffen doch nicht auf das falsche System gesetzt zu haben. Beste grüße aus der S-Bahn... Jörg

Ein Punkt ist da aber noch ungeklärt. Wie groß ist der Messbereich? Generell finde ich eine günstiges Bricklet mit 1 Kanal und hohem Eingangswiderstand und höherer Toleranz gut. Dann sollte es das doppel oder quad Messbricklet geben. Hier ist dann die Toleranz geringer dafür halt auch teurer. 20 Euro für 4 Kanäle mit recht hoher Genauigkeit wäre angemessen (sollte einem billigen Multimeter schon gleich kommen).

Hallo, dann auch mal mein Senf zu neuen Entwicklungen. Ich bin immer noch für eine Funkalternative. WLAN hat eine viel zu geringe Reichweite. Ich habe das Modul im freien Feld getest, mit meinem HP-Laptop (hat recht gute Antennen um das Display herum) und der kleinen Knickantenne. Bei 90m ist Schluss, dann geht nix mehr. Mir persönlich ist das zu wenig. Das reicht nicht mal bis an das Ende meines Grundstücks... Also Chibi nicht aus den Augen verlieren oder wenn Bricklets per Funk an ein Brick angeschlossen werden könnten und eine Reichweite bis 30m haben, wär das auch was

Hallo, darf ich Fragen, welche Kenntnisse du in der Entwicklung von Software du hast? Wenn ich es richtig verstanden habe, dann hast du mal irgendwann C programmiert. Unter der Annahme, dass du wenig Kenntnisse hast, empfehle ich nicht VB.NET zu nehmen. Du kannst neu anfangen und solltest nicht eine Sprache wählen, in der man leicht in alte Schemen zurück fällt. Hier eignet sich meines Erachtens C# viel besser, um in die Objekt-orientierte Entwicklung einzutauchen. Just my 2 cents... Zum angegebenen Code kann ich nur sagen, das dort keinerlei Robustheit vorhanden ist. Du stellst eine Verbindung her, aber wenn die nicht etabliert werden kann, dann bricht dein Programm hart ab. Versuch es mal, nimm TF vom Rechner und starte dein Programm. Ergebnis: BigBang... Besser: AddHandler ipcon.Connected, AddressOf TinkerforgeConnected AddHandler ipcon.Disconnected, AddressOf TinkerforgeDisconnected try ipcon.Connect(HOST, PORT) ... catch Exception e System.Console.WriteLine("Sorry, couldn't establish connection. Program ends...") finally ' Dies hier nur im finally, wenn Disconnect keine Exception bei nicht ' vorhandener Verbindung wirft. Müsste ich nachschauen... ipcon.Disconnect() end try Dann die beiden Methoden der EventHandler implementieren. In TinkerforgeConnected würde ich mir merken, dass die Verbindung besteht und somit etwas in PositionCB ankommt. (Später wenn du eine GUI hast, kann dann irgendwo ein Hinweis stehen). In TinkerforgeDisconnected kannst entsprechend connected verfahren. Ggfs. musst du den PositionCB-Handler entfernen (RemoveHandler) und in TinkerforgeConnected den Handler wieder hinzufügen. Das kommt auf das Verhalten der API an, das habe ich selber noch nicht im Detail geprüft. Ob du ein enumrate ausführst, um dein Bricklet zu finden oder nicht, ist Geschmacksache. Ich persönlich programmiere immer von der Hardware losgelöst. D.h. ich habe in Settings die entsprechenden Daten hinterlegt (Bricklet-UID etc.). In den entsprechenden Konstruktoren erstelle ich dann die Bricklet-Objekte und nutze die Connected und Disconnected-Events, um ein Semaphor zu haben, ob ich auf die Bricklets zugreifen darf oder nicht. Das ist schneller, als wenn ich bei jeden Brickletaufruf ein Try-Catch baue. Aber das kommt auf die Anwendung und Laufzeitverhalten an. Beste Grüße Jörg

Ok, das erklärt einiges. Obschon ich dann nochmal schauen muss, warum das in android auch so ist. Denn dort habe ich eine Device-Factory erstellt, wodurxh nur singletons geben dürfte. Der .net code ist nicht vollständig gleich, da ich aus Zeitgründen einen umbau von java auf .net einfach ein paar dinge unter den tisch kehren musste, um in der timeline zu bleiben. Ich baue die factory ein und berichte über das Ergebnis. Erstmal vielen dank. Btw: bei überschreiben von objekten in einer liste wäre ein hinweis gut. Evtl. Sogar exception wie AlreadyAttachedException oder so.

Cool, RFID ist wirklich eine sehr sinnvolle Ergänzung. Aber bitte denkt auch wieder über ein Funkmodul nach, mit dem man größere Reichweiten als 100m hinbekommt. Beste Grüße Jörg

Ich pack heut Abend mal die alte und neue Version und sende Euch das Projekt zu (VS2010 vorhanden?). Ursprünglich habe ich das ganze auf Android entwickelt, aber als dann dort die Timeouts auftraten und eine .NET Testapp keine Probleme verursachte, habe ich das auf WPF umgestellt und mit einer sehr heißen Nadel gestrickt, denn ich brauche die Software und die Hardware am Wochenende einsatzbereit.

Hallo, ich nutze einen Stack aus PowerSupply - Master - WiFi. Mein Programm ist so aufgebaut, dass ich zyklisch die WiFi-Verbindung prüfe. Wenn eine Verbindung besteht, dann rufe ich die Connect-Methode der IPConnection auf. Vorher habe ich die IPConnection und sämtliche Bricklets instanziert. Wenn nun ein Connect erfolgreich ist, erstelle ich ein Master-Objekt und frage den StackCurrent ab (just for fun). Das erfolgt also zyklisch. Hier kommt es ab und zu zu einer TimeoutException mit ID2. Weiterhin erfolgt nach erfolgreichen Connect, eine Meldung an sämtliche Bricklets (gekapselt in speziellen Klassen), wodurch diese initialisiert werden. Seltsamerweise funktioniert der Aufruf SetPortConfiguration des IO16 ohne Probleme. Wenn dann aber später im Programm ein GetPort oder SetPort aufgerufen wird, erfolgt regelmäßig eine TimeoutException mit ID2. Nach einer halben durchzechten Nacht, habe ich aus Zufall ein neues Bricklet-Objekt vor dem Aufruf der GetPort-Methode erzeugt und dann auf diesem Objekt zusätzlich ein GetPort ausgeführt. Das funktionierte, also hab ich umgestellt und vor jedem Aufruf einer API-Methode erstelle ich nun ein neues Objekt des Bricklets. Sinnfrei aber funktioniert. In einer relativ zeitkritischen Software ist das aber kein dauerhafter Zustand. Hier mal der vereinfachte (Exception-Handling weggelassen und andere nicht hilfreiche Logik) Ursprungscode: private BrickletIO16 bricklet; void InitBricklet(IPConnection ipCon) { if(isConnected) { bricklet = new BrickletIO16(brickletID, ipCon); } } float GetResistance(int channel) { if(isConnected) { byte ports = bricklet.GetPort(bench); // Bang: Timeout // bench = 'B' // Hier Umformung des bytes ports, um diverse Ports zu setzen bricklet.SetPort(ports); float utest = testVoltageBricklet.GetVoltage() / 1000; return utest / 0.075f; } } So funktioniert es dann: float GetResistance(int channel) { if(isConnected) { BrickletIO16 bricklet = new BrickletIO16(brickletId, ipCon); byte ports = bricklet.GetPort(bench); // bench = 'B' // Hier Umformung des bytes ports, um diverse Ports zu setzen bricklet.SetPort(ports); float utest = testVoltageBricklet.GetVoltage() / 1000; return utest / 0.075f; } } Nur warum muss ich jedesmal ein neues Objekt erstellen, damit ich mit TF kommunizieren kann? Find das nicht besonders sauber, da die Zeit zum Erstellen eines Objekts relativ lang ist und ich schon zeit verliere fürs Exception-Handling. Das werde ich aber in naher Zukunft noch weg-optimieren. Beste Grüße Jörg P.S.: War kurz davor TF aus den Fenster zu werfen, wenn nicht der Zufall gewesen wäre, den o.g. weg zu Testen...

So, gestern Abend am Rande der Verzweiflung gewesen. WiFi Verbindung funktioniert nun. Win7 macht hier einem das Leben nicht wirklich leicht und es dauert elendig lange bis die Verbindung steht (Abstand zum WiFi ext. sind 50cm ohne Hindernisse). Firewall etc. ist aus. Adapter muss ich dann jedesmal neu konfigurieren, aber dann klappt es nach einiger Zeit. Jedoch sind andere Probleme aufgetaucht, die ich letztendlich sehr unbefriedigend gelöst habe. Aber dazu mehr in einem eigenen Faden...

Sorry, hatte auf einem IO16 Bricklet eine Lötzinnbrücke am +/- Ausgang, wodurch kurzzeitig mein Master nicht ansprechbar war. Aber das war nach den Tests mit WLAN. Heute/Morgen Abend teste ich das ganze erneut im Feldtest (im wahrsten Sinne des Wortes). Firmware ist komplett auf neuestem Stand und am PowerSupply liegen ~12V an (12V BleiGel-Akku). Ich werde berichten. (Grüne LED ist dauerhaft an, kurz nachdem ich die 12V anlege) Beste Grüße Jörg

Ich hol den Thread mal hoch. Hab gestern das gleiche oder ähnliches Problem. Wäre cool wenn jemand auf die Frage meines Vorgängers antwortet. Fall: Stack mit WLAN-Master-PowerSupply. Alles per USB eingerichtet. Schalte ich nun die Spannung ein (über PowerSupply ohne USB), dann fährt alles hoch, aber ich kann mich nicht per WLAN verbinden. USB anhängen, Reset durchführen, USB entfernen und schon bekomme ich eine Verbindung. Leider ist mein Stack in einem Gehäuse eingebaut und ich hab keine Möglichkeit eines HW-Resets. Evtl. sollte man hier mal Klemmen vorsehen, um den Reset-Knopf an anderer Stelle zu platzieren. Cheers, JoergK

Cool vielen Dank für die schnelle Antwort. Ich hatte im Source Code des IO16 nur eine Liste gefunden, die zyklisch geprüft wird, aber nicht die Stelle, an der diese gefüllt wird. Beste Grüße Jörg

Hallo, ich habe leider bis Montag keine Möglichkeit mit meinem IO16 zu testen, würde aber gerne etwas im Hotel zu Ende implementieren. Bei der Überlegung, wie ich die Ports anspreche, ist mir klar geworden, dass ein Punkt bezüglich MonoFlops unklar ist. Und zwar wenn ich beispielsweise Port 0 mit 1,5s auf High schalte und dann nach 0,5s die Methode erneut aufrufe um Port 1 mit 1,5s in den Zustand High zu versetzen, was passiert dann mit Port 0? Aufrufe quasi: setPortMonoflop('A', 0x00000001, 0x00000001, 1500); sleep(500); setPortMonoflop('A', 0x00000010, 0x00000010, 1500); Wie verhält sich dann Port 0? Geht Port 0 auf Low nach 0,5s oder nach 1,5s, nach 2s oder sogar gar nicht mehr? Hat jemand eine Idee? Danke im voraus. Cheers, Jörg

Also wenn das geht, dann steht einer Malware ja Tür und Tor offen... Just my 2 cents...

String-Vergleiche sind eigentlich immer teuer in der Laufzeit und fehleranfällig. Besser du deklarierst Konstanten beispielsweise auf int-Basis. Die Konstante kannst du dann ordentlich benamen und der Quellcode wird gut lesbar und schnell. Zum Disconnect-Problem kann ich nichts sagen, da ich solche Bricklets nicht einsetze. Cheers, Jörg

Erstmal hört sich das doch gut an. Freut mich dass es mit den Events klappt Wenn es interessiert, dann hab ich noch ein paar Anmerkungen zum Quellcode allgemeinerer Natur. Bspw. If Portal.inBewegung = False oder schlimmer If Portal.inBewegung = True sollte man niemals schreiben. Wie sagte das einer meiner Professoren treffend: "Wer sowas macht, hat es nicht verstanden." If-Bedingungen prüfen immer eine Ausdruck auf true. Wenn du nun einen schlechten compiler hast, baut er aus dem o.g. 2 Berechnungen auf. Erst vergleicht er Variable mit False oder True, dann Prüft er ob das Ergebnis dieses Vergleichs true ist. Besser lesen kann man es auch (hier in .NET Pascal Case): If Not Portal.InBewegung If Portal.InBewegung Weiterhin finde ich den String-Vergleich "Ende" und "Start" ein wenig unschön. Für so etwas nutzt man im Minimalfall Konstanten. Geschickter ist es, wenn man einfach nur das Vorzeichen des Inkrements ändert. Man muss dann nur Prüfen, ob untere oder obere Grenze erreicht ist und ändert in dem Fall das Vorzeichen. Aber das kommt auf den Rest der Implementierung an und daher ist der String-Vergleich nur unschön. Und auch wenn es die Sprache zulässt, man verwendet niemals Umlaute bzw. sprachen-abhängige Sonderzeichen. Länge_X => Laenge_X. Solltest du jemals in die professionelle Implementierung gehen und dann International tätig sein, wird dein Quellcode nicht akzeptiert. Da ist es einfach besser, man macht so etwas von Anfang an erst gar nicht. Ups und noch was: In VB.NET wird ein UND nicht mit AND gemacht. AND ist für Binärvergleiche und es werden immer beide Terme ausgewertet. AndAlso ist hier das richtige. Trifft die erste Bedingung bei AndAlso nicht zu, wird der zweite Term nicht ausgewertet. Unheimlich hilfreich, wenn man Null-Verweis-Ausnahmen verhindern will: If Blah IsNot Nothing AndAlso Blah.Wert = 5 Then Wenn Blah Nothing ist, geht er ins Else oder überspringt. Bei And bekommst du eine NullPointerException... Just my 2 cents... Beste Grüße Jörg

Hallo, cool das sich jemand vom TF-Team meldet. Zum einen habe ich einen Pull-Down vorgesehen, jedoch mit 47K. Ich gehe mit 1K von TF-Port zum Gate und mit 47K vom Gate zu GND. Wollte so wenig Strom wie möglich verbrauchen, aufgrund der 4 bis 5 Stunden Stand-By Zeit. Vielleicht ist in dem Fall der Pull-Down zu groß dimensioniert. Jedoch wenn ich die Firmware ändere, dann habe ich wie oben im Ablauf zwischen Punkt 1 und 3 Zeit. Da TF schon mit der Versorgungsspannung versorgt wird, und die anderen Schaltungen erst mir dem Schalten des Entsperr-Schalters (Schlüsselschalter) mit Spannung versorgt werden, sollte die Firmware soweit die Ports initialisiert haben. Wenn die blauen LEDs für die Bricklet-Ports nicht mehr blinken, sollte doch alles ok sein. Cheers, Jörg