Einstein

@Frostie Ich verlink mal auf meinen Post da ich mit den 1142n auch schon getestet hab. http://www.tinkerunity.org/forum/index.php/topic,1412.0.html Antwort 4

Auf nach dem Punkt 6 bezieht sich das. Wenn ich den Master resette ist es immer noch das gleicher verhalten. Mein Problem ist eher das ich das gerät mit einer Step-Down verbauen wollte ohne USB-Verbindung, daher kann ich es nicht anders machen.

Hatte ich vergessen... 1) Master auf Step-Down setzen 2) LCD mit Master verbinden 3) Step-Down unter Strom setzten (12V) 4) LCD bekommt Streifen (aber im Brickviewer sichtbar) 5) USB mit Rechner verbinden 6) Brickv starten und s.o. alles durchprobieren

Kein Problem tritt bei jedem mal auf (ich hab leider auch nur LCD20x4 sonst würde ich mal gegentesten) 1) Master auf Step-Down setzen 2) LCD mit Master verbinden 3) Step-Down unter Strom setzten (12V) 4) LCD bekommt Streifen (aber im Brickviewer sichtbar)

Im heilen Zustand: LCD lässt sich komplett steuern (Buttons reagieren, Beleuchtung geht an aus, Blink und Cursor lassen sich einschalten und ausschalten, Text lässt sich schreiben und Display löschen),Temp-Bricklet "malt" einen Graphen Im kaputten Zustand: Am LCD geht gar nichts (sporadisch ein Button, keine Beleuchtung oder Cursor, oder schreiben auf LCD), Temp-Bricklet "malt" einen Graphen

Fast Korrekt. Am Anfang trat es am Master 2.0 nicht auf aber bei meinem letzten Tests über Ostern tritt es auch an Master 2.0 auf (also an allen Master Versionen).

Entschuldige das ich mich erst wieder so spät melde aber es kam was dazwischen. Es tritt nur auf wenn die Step-Down von Anfang an mit Strom versorgt wird. Stecke ich während des USB-Betriebs die Step-Down an den Strom läuft das LCD 20x4 ohne Probleme. Hardware version 1.1 steht drauf Alle andere Bricklets funktionieren. Ich habe getestet: Am gleichen Master-Brick (v1.1), Barometer, Temperatur, Temp-IR, IO-16. an einem anderem Master (auch 1.1) und (2.0) die gleichen Bricklets. Keine Probleme und immer Ansprechbar nur eben das LCD nicht (mit Streifen s.u.) Im Anhang habe ich noch ein Bild angehängt wie sich das LCD verhält. Das LCD geht nur, wenn ich es nur per USB mit Strom versorge.

Wenn ich mich nicht arg täusche ist im Barometer auch ein Temperatursensor verbaut. @TF gute Idee. Ich denke als Farben klar, schwarz, weiß.

Software ist auf den aktuellsten Stand. Minimalster Aufbau wo das Problem auftritt ist Step-Down->Master->LCD. Mit abziehen meinte ich wenn ich nur Master->LCD betreibe, also die Step-Down ab ist. Ich vermute eben das es ein Problem mit meinen 2 Master v1.0 ist, denn ein etwas ältere Master v1.0 funktioniert (habe ihn gerade noch einmal zum testen aus einem Stack ausgebaut).

Aktuell ist es bei mir so das ich Karten habe mit Mifare Standard (sprich 13,56Mhz). Wenn ich das bei NXP richtig verstanden habe können der ihre Chips sowohl RFID (was ich für Mifare Karten bräuchte) und NFC. Wichtig sind eben die 13,56Mhz.

Zu meinen neuesten erkenntnissen. Master-Brick v1.0 funktionieren nicht (mehrzahl! ich hab 3 probiert). Ich hab das Problem sobald ich eine Step-Down darunter schraube bekomme ich Probleme (s.o.). Die Step-Down funktioniert aber definitiv, ich hab schon mehrere Probiert. Wenn ich einen Master v2.0 nehme geht jetzt alles ohne Probleme. Was ich auch festgestellt habe das ich mit den Master v1.0 mit step-down mein LCD20x4 nicht mehr ansprechen kann (Zeile 1 & 3 sind komplett schwarz). Es lässt sich weder die Hintergrundbeleuchtung einschalten noch was schreiben (egal an welchem Master-Port). Ziehe ich jetzt die Step-Down ab, sprich per USB an den Rechner funktioniert alles. Ich gehe daher von einem Problem Step-Down -> Master v1.0 aus. Ich hoffe das alles war nicht zu unklar geschrieben. Wenn nachfragen sind versuche ich sie zu beantworten. VG

@Tinkerforge-Team Ich müsste hier mal fragen. Gibt es pläne für ein RFID Bricklet? Konkret geht es mir darum das ich ein benötigen würde um eine Art Zugangssystem zu realisieren. Wenn erstmal keins in Planung ist wäre das auch nicht weiter schlimm, ich würde dann selber ein Bricklet entwerfen und anbinden. Jedoch wäre es bequemer wenn es von TF kommen würde. VG

Da du eine andere ARM Architektur (armel) verwendest als das vorgebaute Paket (armhf) müsstest du dir den brickd selber kompilieren. Beschrieben ist das hier. du müsstest also git clone git://github.com/Tinkerforge/brickd.git eingeben und dann unter src dein paket erstellen

Auf dem PI natürlich noch vim (mit Syntax Highlighting).

Schönes Design...sieht gut aus...bisher hab ich keine toten links gefunden

Wenn ich Zeit dazu finde werde ich es sicherlich machen. Da ich bisher eigentlich nur eine WLAN-Station anspreche, suche ich nach einer Lösung in die Firmware auch einen SNMP-Daemon einzubinden und diesen dann abzufragen. Ähnlich hier: http://asf.atmel.com/docs/2.11.1/avr32.services.freertos.lwIP_example.uc3_c2_xplained/html/snmp__msg_8h_source.html Habt ihr da schon was versucht/probiert in die Richtung?

For those who are interested in scripts for cacti, I've done some Templates and scripts for that. Look here.

Nachdem es eine Weile gedauert hat sind, habe ich jetzt die Skripte für die Monitoringsoftware Cacti online gestellt (inklusive Templates). Weiteres hier.

Sooo mein ein kleiner "Erfolgsbericht". Nachdem ich eure beiden Ratschläge nochmals befolgt und alle Netzkomponenten getauscht hatte brachte es keine Besserung. Dann hab ich den Rechner und den WiFi Brick in das gleiche Netz gehängt, einen Prozess laufen der alle Minute die Werte von der Temp-IR ausgeliest und nach 5 Minuten immer die gleichen Werte ausgespuckt hat. Ich habe also den Master im Stack getauscht und nun läuft alles sehr zufriedenstellend, egal in welcher konstellation. Den (möglicherweise) defekten Master werd ich mir einmal genauer betrachten und noch berichten. Ich hoffe das war nicht zu verwirrend. Grüße

Soo nach mehreren Testreihen hier die Ergebnisse: Brick und Rechner am gleichen AP im gleichen Netz -> funktoniert Brick und Rechner am gleichen AP in unterschiedlichen Netzen -> funktioniert Brick am AP und Rechner per Kabel im gleichen Netz -> funktioniert teilweise, jedoch Timeoutrate ca. 50% Brick am AP und Rechner per Kabel in unterschiedlichen Netzen -> funktioniert sehr schlecht, Timeoutrate ca. 90%

Hallo Loetkolben, also Doppelte IP kann ich definitv ausschließen weil ich in dem Bereich nur die Bricks unterwegs sind und ihre Einstellungen alle per DHCP beziehen. Ich denke auch das ich Hardwareprobleme ausschließen kann. Nen Iperf Liefert mir meine konstanten 100Mbit/s von einem IP-Bereich in den anderen. Zur eingesetzten Hardware: Router ist ein Cisco 2821 mit einer HWIC-9ESW-POE Switchkarte. Der AP (Cisco AIR-AP1142n) hängt an dieser und nimmt sich Strom über POE. VG

Also Gateway ist konfiguriert, da Ping sonst nicht gehen sollte Das kuriose ist eben, dass der Brickv sich verbindet und erst einmal alle angeschlossenen Geräte listet (auf der Startseite). Wenn ich dann auf irgendein Gerät gehe kommen Timeouts (oben rechts der Counter). Wenn es denn dochmal läuft liefert die extension nach einer abfrage nur noch konstante werte (Grafik im Anhang).

Hast du denn ein Gateway das zwischen beiden Teilnetzen vermittelt? Ansonsten ist das ja quasi expected behavior für Netzwerkgeräte. Ja der ist vorhanden und funktioniert auch. Ein Ping an das WiFi device geht ohne Probleme, sie treten eben nur bei einer gerouteten Verbindung auf.

Wieder ein paar Probleme gefunden. Das WiFi-Modul untersützt kein OFDM/Beamforming (ist bei 802.11b was das Modul kann nicht vorgesehen, sollte es also ignorieren) und kein power-send (Teilt Gerät mit, mit wieviel Leistung es senden darf/muss). Nachdem ich dies alles deaktiviert habe meldet sich das Modul am Cisco AP an (für die, die es interessiert es ist ein AIR-AP-1142n). Noch eine Erkenntnis: Wenn ich das Modul in ein anderes Subnet stecke (Modul: 192.168.2.x -> Abfragender Rechner: 192.168.1.x) dann kommt es zu Timeouts und das Modul inklusive anhängender RS485-Extensions ist nicht mehr ansprechbar. Ich hoffe das Hilft ein wenig. Viele Grüße

Sooo also an einer normalen FritzBox (ehemaliger Speedport) funktioniert es. jetzt muss ich mir noch Gedanken machen warum es nicht an einem Cisco AP Funktioniert, wo es eigentlich bisher kein Problem gab. MFG