reinweb

Hmm, --- keine Reaktionen - ich bin nachdenklich. Entweder ist meine Erklärung zu wirr, das Problem zu simpel / zu komplex / nicht praxisrelevant, ........ meine aktuellen Versuche:: Ich hab mittlerweile mal die Wifi Extension 1:1 gegen die Ethernet Extension getauscht und das Programm läuft total reibungslos Reduktion auf 1 Master im Stapel:: das erhöht die Stabilität enorm. Ich bin fast geneigt zu sagen, es ist weg (damit warte ich aber noch...) --> ich brauch aber mehr als 1 Master im Stapel. identer Stapel:: ich habe einen exakt gleichen Stapel gebaut, die Verbindungsabbrüche fehler sind dort ebenfalls vorhanden. Es kann also nicht an einzelnen Bauteilen liegen.

hej, stimmt - irgendeinen simplen Getter aufzurufen ist eine optimale Möglichkeit zur Echtzeitprüfung der Verbindung. Danke!

soweit ich das durchblicke, gibt die Funktion IpConnection->getConnectionState nur den zuletzt gesetzten Wert der Klassenvariable zurück und führt keinen aktuellen Test durch. die Funktion IpConnection->receive führt regelmässig eine tatsächliche DisconnectProbe durch. Würde es Sinn machen, diese Echtzeit-ConnectionState Funktion von aussen aufrufbar zu machen (z.B. als IpConnection->getCurrentConnectionState()? dann erkennt man den ConnectionVerlust sofort und nicht erst nach diesem DISCONNECT_PROBE_INTERVAL Timeout? (Meine Frage steht in Zusammenhang mit meinem WLAN-Verbindungsproblem, was ich in meinem vorigen Thread beschrieben habe...) - das bringt mich nämlich ECHT ZUR VERZWEIFLUNG :'(

seit Wochen beschäftige ich mich erfolglos mit folgendem Problem: ich habe mittlerweile 5 verschiedene Stacks die alle mit WLAN angebunden sind. Egal wie und was ich probiere... (unterschiedliche Bausteine, USB oder Step-Down Versorgung, wenig Bricklets, viele Bricklet, Bricklet-Callbacks selten oder häufig, unterschiedliche WLAN-Accesspoints, fix IP, DHCP, Stapel komplett zerlegen und nur Master neu flashen, unterschiedliche Aufstellungsorte, ...) also alles was ich probiere - die Stapel sind irgendwann (ein paar Stunden bis längstens ein paar Tage) nicht mehr vom Raspberry ansprechbar (auch nicht mehr Pingbar, vom Brickviewer auch nicht ansprechber). Fehlermeldung meist:: "no route to host". Natürlich (sonst wäre es ja einfach) nicht alle Stapel gleichzeitig unerreichbar sondern alle stark unterschiedlich. Nach einem Stapel-Reset oder Stapel-Power-Cycle läuft alles wieder ordnungsgemäß an (Reconnect, Enumerate & Co). Wie lange laufen bei euch die WLAN-Extension Stapel (im Echtbetrieb mit Callbacks & Co) durch? Was kann die Ursache sein? Eine Vermutung ist, dass durch (aus welchem Grund auch immer) unsauberer Verbindungsabbruch die (in anderen Threads erwähnten) maximalen 15 Verbindungen (der WLAN-Extension) ausgeschöpft sind und daher der Stapel nicht mehr reagiert? Werden diese "Verbindungs-Zombies" gelöscht/entfernt, wenn ich den Masterbrick via Software resette? Oder nur bei einem Hardreset/Power-Cycle? Ein anderer Stapel mit PoE Brick läuft seit vielen vielen Tagen ohne irgendwelche Problem! Bitte um euche fachgerechte Hilfe!

die 60mA habe ich aus diesem Datenblatt hier: * LED Pixel https://www.tinkerforge.com/de/shop/accessories/leds/rgb-led-pixels-50pcs.html ... hab ich eh oben schon verlinkt... drum versteife ich mich ja so auf diese 60mA->3A

das habe ich befürchtet.. Danke

Einstellungen im LED-Strip Brickviewer: Number of Leds:: 50 Color R:: 255 Color G:: 255 Color B:: 255 die restlichen Werte habe ich default gelassen. Ergibt 1,6A_eff. Mit welchen konkreten Brickviewer-Settings erreiche ich 3A_eff (also 60mA_eff pro LED)?

sorry auch bei mir, ich kann mit deiner Antwort nicht viel anfangen :-( ich verwende: * Step-Down & Master Brick + LED Strip Bricklet * LED Pixel https://www.tinkerforge.com/de/shop/accessories/leds/rgb-led-pixels-50pcs.html * Brick Viewer * Stromversorgung der LEDS 5V (Step-Down Ausgang) Dort kann ich keine Tastverhältnisse einstellen oder sonstwas. Nur diese Einstellungen: http://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_led_strip_brickv.jpg Meine Kernfrage:: mit welchen Settings im Brickviewer schaffe ich die maximale Helligkeit (das sind für mich die 60mA pro LED, also insg. 3A) Danke für deine Geduld.

ok, dann formuliere ich meine Frage so:: Was muss ich machen, damit eine LED tatsächlich 60mA_eff zieht? und damit die maximale Leuchtkraft hat. Oder kann diese LED bei 5V gar keine 60mA_eff ziehen? Es sind ja 3fach LEDs, daher braucht eine 20mA - das scheint doch realistisch zu sein...

ok, aber:: Woher kommen die 60mA in der Doku? Ist das der Spitzenstrom? und wenn statt berechneten 3A nur 1,6A gezogen werden, dann ist das ein Tastverhältnis von ca 60% - also eher weit weg von den 90%

Danke für eure Analyse. Wenn man allerdings maximale Helligkeit der LED haben will, dann müsste das Pulsverhältnis doch 100% sein (sonst leuchtet die LED ja nicht die ganze Zeit - selbst unter Berücksichtigung von Leucht-Trägheit). eventuell macht es Sinn, den maximalen Stromverbrauch in die Doku aufzunehmen. Derzeit steht beim Pixel "60mA (pro Pixel bei voller Helligkeit)" korrekt müsste es heissen:: "ca 35mA (pro Pixel bei voller Helligkeit)" oder verstehe ich da was falsch? ich brauche die maximale Helligkeit der Pixel (weil ich es u.a. als Beleuchtung einsetze)

hallo, ich habe ein volles Bündel LED Pixels (50 Stück) in voller Leuchtkraft (255,255,255). Die Stromversorgung läuft über den 5V Ausgang der Step-Down (die sollte 3A liefern können). 60mA * 50 Leds = 3 A Die Stepdown versorge ich mit 12V /5 A. Mit dem Multimeter messe ich max. 1,6A Stromverbrauch. Gemessen am Ausgang der 5V von der Step-Down. Da stimmt doch was nicht - oder? Erwartet hätte ich 3A

hallo, leider kann man es eben nicht nachvollziehen. Beispiel:: Wenn ich die Funktion BrickletSegmentDisplay4x7::getSegments() jede Sekunde aufrufe (z.b. um den Doppelpunkt im Sekundentakt zu togglen), dann geht das oft viele Stunden ohne Probleme, aber irgendwann kommt dieser lästige Fehler "did not respond in time" (aber nicht erst nach dem Timeout). Ich werde mal einen Versuchsaufbau machen und maximales Debugging einbauen, dann kann ich genaue Telemetriedaten liefern...

ja, ist PHP spezifisch - das stimmt. Tatsache ist, dass der Fehler "did not response in time" geworfen wird, bevor der Timeout abgelaufen ist. Darum glaube ich nach wie vor, dass ein Resultat zurückkommt, dieses aber falsch interpretiert wird (eventuell weil leeres Array) $o = []; if ($o == null) { // Ergebnis ist TRUE }; if (empty($o)) { // Ergebnis ist TRUE };

vermutlich sind etliche Tinkerforge-Anwender auch Besitzer eines 3D Druckers und haben demnach wahrscheinlich schon das ein oder andere 3D-Model für Gehäuse, Adapter, Montageplatten & Co erzeugt. Gibt es Interesse an einem Austausch?

Vielleicht habe ich ein mögliche Ursache gefunden. In den PHP Bindings von IpConnection Device->sendrequest steht: if ($this->receivedResponse == NULL) { throw new TimeoutException("Did not receive response in time for function ID $functionID"); } ich habe den Vergleichsoperator auf === ausgebessert - weil sonst auch ein Ergebnis von "0" als "NULL" interpretiert wird (und vor allem das Ende des Timeouts nicht abgewartet wird bis zur obige Fehlermeldung!) Vielleicht kann man einer der Experten meine Änderung auf Sinnhaftigkeit prüfen. Danke :-) Seither läuft es weeesentlich stabiler

Danke. Sowas hab ich eh schon befürchtet - ist schade, weils teurer und größer ist. Es scheint mir aber gerade bei USB Versorgung wichtig zu sein, dass der Stack nicht zuviel Strom zieht - sonst wird der Stack unzuverlässig... Aber lieber ein "klares nein" als ein "unklares vielleicht" ;-)

Der Post ist mehrfach abgesetzt worden (in Hardware). ich hab dasselbe Problem, daher hier der Link auf mein Problem:: http://www.tinkerunity.org/forum/index.php/topic,3466.msg21326.html#msg21326

ich habe dasselbe Phänomen in unterschiedlichsten Kombinationen (Anbindung USB, PoE, WLAN, unterschiedliche Bricklets, Bricklet am Master oder an anderen Bricks...) Verwendet werden die PHP Bindings. Die Erhöhung des IPConnection::setTimeout(float $seconds) hat offenbar keinen Effekt. Es ist echt ärgerlich, weil es relativ häufig auftritt. Oft bringt echt nur ein PowerOff des Stacks etwas.

die Beispiele sind eine große Hilfe und funktionieren nun einwandfrei mit jeder Bildgröße! Erkenntnisgewinn für mich ist: oled::write muss immer mit 64Byte gefüttert werden, die Bildgröße ist mit olde::newWindow zu steuern. DANKE :-))

passt für mich zu 100%! Danke :-)

ich muss erkennen, dass BrickletOLED128x64::clearDisplay() sich auf das zuletzt mit BrickletOLED128x64::newWindow() gesetzte Fenster bezieht. Ist das Absicht?

hallo, kann mir bitte jemand ein Beispiel (bevorzugt in Python oder PHP) bereitstellen, mit dem ich am OLED ein Fenster beschreiben kann das nicht genau 128 oder 64 Pixel breit ist? Ich hab versucht, ein 32 Pixel breites Bild zu transferieren - das geht nicht (auch wenn ich in den Bindings die in "64" Hardcodierung rausnehme). also hier:: https://raw.githubusercontent.com/Tinkerforge/oled-128x64-bricklet/master/software/examples/php/ExampleScribble.php die Werte const WIDTH = 32; const HEIGHT = 32; Danke vorab!

da bin ich zu ungeschickt für...

auch ich würde 25cm oder 30cm Bricklet Kabel brauchen. Ich hab vor wenigen Tagen per Mail angefragt und eine abschlägige Antwort bekommen. "hatten sie schon mal, hat niemand gekauft. 250 STück á 0.83 kann man sich fertigen lassen". ich tu die Kabel jetzt selber kürzen - wenn es nicht anders geht. Vielleicht haben aber ein paar Leute hier Interesse und wir teilen das. ca 50 Kabel würd ich sofort nehmen....