Quantasy

P.S. Ich sehe grad, dass bei euch das selbe Verhalten sogar filmisch festgehalten wurde! Achtet mal auf eure Frequenzangabe durch die ganze Aufnahme!

Problem: Die angegebene Netzfrequenz ist stets zu tief: << 49.9Hz. ... Im Schnitt 49.55Hz. Effekt: Swissgrid meldet: 50 Hz Aktuelle Frequenz 50.009 Hz Aktuelle Frequenzabweichung 0.009 Hz Aktuelle Netzzeitabweichung -8.534 s Aktuelle(s) Datum/Uhrzeit 12.11.2021 11:56:18 Datum / Uhrzeit der Werte 12.11.2021 11:56:10 Zwei Energy Monitor Bricklets 1.0 melden zum gleichen Zeitpunkt: 49.48Hz. Diese extreme Diskrepanz kann ich seit gut zwei Jahren durchwegs beobachten. Aber: Uhr am Ofen... ist Netz synchronisiert und stimmt aber seit zwei Jahren im angegebenen Range von Swissgrid.... Und ist nicht aus dem Ruder gelaufen, was sie ja müsste, wenn die Messungen des Bricklets stimmten. Was ist falsch? Aufbau: brickv(2.4.19)-> brickd-> Master 3.1 (2.5.0)-> 2x EnergyMonitor 1.0 (2.01), 2x von euch gelieferter Spannungs-Trafo, 230V Steckdose.

Wäre es denkbar, die gemeinsamen Methoden der CoProzessor-Bricklets über ein Java-Interface verfügbar zu machen? Sonst können diese Methoden, die stets die selben sind, nicht generisch angesprochen werden. Nur als Beispiel: public interface CoProcessorDevice { public BrickletMotionDetectorV2.SPITFPErrorCount getSPITFPErrorCount(); public int setBootloaderMode(int mode); public int getBootloaderMode(); public void setWriteFirmwarePointer(long pointer); public int writeFirmware(int[] data); public void setStatusLEDConfig(int config); public int getStatusLEDConfig(); public int getChipTemperature(); public void reset(); public void writeUID(long uid); public long readUID(); }

Während ich mit dem neuen SoundPressureLevel Bricklet rum-probiere... fällt mir folgende Exception auf, wenn ich nach dem Setzen der SpectrumCallbackConfiguration diese gleich wieder zurücklesen will... .getSpectrumCallbackConfiguration() java.nio.BufferUnderflowException at java.nio.Buffer.nextGetIndex(Buffer.java:506) at java.nio.HeapByteBuffer.getInt(HeapByteBuffer.java:361) at com.tinkerforge.BrickletSoundPressureLevel.getSpectrumCallbackConfiguration(BrickletSoundPressureLevel.java:426) Da ich momentan die Sourcen von 2.1.18 via Maven nicht erhalte kann ich nicht viel mehr dazu beisteuern.

Ich wollte mal nachfragen, ob sich da was tun lässt? Wenn ich's richtig verstehe, soll das Android im USB-Host-Mode an das Masterbrick angehängt werden. Dabei ist ein laden offenbar möglich: https://electronics.stackexchange.com/questions/34741/can-an-android-tablet-serve-as-usb-host-and-be-charged-simultaneously-through-a Den brickd direkt auf dem 'alten' Android laufen zu lassen und das TF-Konstrukt damit über USB zu speisen (Mit Daten und mit Energie), wäre ein geniales Recycling-Projekt (Gibt sicher EU-Subventionen dafür ;-) ) Dabei würde sogar ein kurzzeitiger Powerloss vom 'alten' Akku des Android-Phones überbrückt werden. Würde das TF-Team sowas in Angriff nehmen wollen? Wenn nicht, gäbe es eine genauere Spez des brickd, sodass das in einer Projektarbeit extern erarbeitet werden kann? Oder gilt hier: Code = Doc? (Ist nur eine Frage, keine Anschuldigung) Ziel: brickd als .apk runterladen können und TF-Bricks über USB am Android-Gerät anschliessen.

Die Veröffentlichungen lesend fiel mir der Bug im Moving-Average-Setter des Dust Detectors 2.0.1 ins Auge: Könnte es sein, dass das selbe Problem (mindestens) auch beim DistanceUS zu finden ist? Wenn ich ein setMovingAverage(100) mache, kommt bei getMovingAverage() der Wert: (256-100 = 156) zurück.

Nun muss ich auch noch eine kompatibilitäts-Frage loswerden: Wenn ich z.B. mit dem 'alten' RemoteSwitchBricklet folgendes absende: B-Switch: address: 18551756 unit: 13 switchTo: 0 repeats: 20 Und mit dem 'neuen' RemoteSwitchBrickletV2 auf 'B' horche... Warum kriegt dann das RemoteSwitchBrickletV2 nix mit? Selbiges Telegram aber mit dem Schalter (Typ Intertechno ITW-852) abgesandt... kriegt das V2-Bricklet aber wunderprächtig mit (sogar ab 1 repeat)! Selbiges gilt auch für A-Switch und C-Switch. Egal was ich mit dem alten Bricklet sende... mit dem neuen krieg ich nie eine Rückmeldung, auch nicht, wenn ich Repeats auf 120 setze. Soll das so sein? Hab ich was verpasst?

Wie bereits beschrieben, haben wir nur einen ersten Test im tieftemperatur Bereich gemacht und festgestellt, dass der Sensor (für sich) scheinbar* nicht Akkurat ist. *(Scheinbar deshalb, weil wir das bloss mit zwei Sensoren gemacht haben und der Versuchsaufbau nicht reproduzierbar (mal schnell auf dem Labortisch) war.) Was wir noch nicht wissen ist, wie präzise der Sensor in den extremen Bereichen ist. <Traum> Falls er präzise genug ist, können wir mit Hilfe einer Korrekturtabelle (wahrscheinlich pro Sensor und Sensortemperatur) die 'Accurarcy' so weit erhöhen, dass die Messungen über einen grösseren Bereich nutzbar werden. </Traum> <Realität> 'Leider' haben die Vorlesungen wieder begonnen und wir können erst wieder in der vorlesungsfreien Zeit (ab Mitte Juni) mit praktischen und !nachvollziehbaren! Experimenten an das Thema herangehen. </Realität> <Klinkenputz> Natürlich wären wir jederzeit für ein finanziertes Forschungsprojekt zu haben, denn so können wir uns von den Vorlesungen 'freikaufen'. </Klinkenputz> @Developer: Wir wollen also genau Deine Fragestellung auch geklärt wissen... Geduld oder Geld... wir arbeiten dran und teilen die Erkenntnisse auf jeden Fall mit. :-)

Ok, ich seh's, da wird dann die Luft bzw. die verfügbaren Takte knapp... Dann wird die Eichung und die daraus erstellte Tabelle wohl in die "Business-Logik" einfliessen müssen. Danke für die Erklärungen!

Wir konnten Messungen mit flüssigem Stickstoff machen und die Werte mit einer FLIR-für Smartphones und zwei Thermal-Imaging Bricklets vergleichen. Unsere ersten (nicht ganz wissenschaftlichen) Tests ergaben, dass sich die Sensoren in diesen tiefen Temperaturen nicht so ganz einig sind und statt der 77.355K ​(−195.795°C) Werte bis zu 0K (-273.15°C) anzeigten. Also eine Abweichung von bis zu 80K aufweisen, wobei die Streuung der einzelnen Messwerte pro Sensor (positiv) überraschend gering war. Je näher wir bei der Erwärmung der 300K Marke kamen desto genauer wurden die Sensoren, mit einer Abweichung untereinander von nur noch ca. 1-2K. Höhere Temperaturen haben wir bisher nicht so getestet, werden wir aber noch machen. Frage: Gäbe es eine Möglichkeit, eine 'lineare Eichung' oder gar eine Eichtabelle ins Bricklet zu schreiben (so ähnlich wie bei der LoadCell)? Disclaimer: Diese Erkenntnisse sind nicht wissenschaftlich fundiert und die Abweichungen können auch durch einen falschen Testaufbau entstanden sein.

Hechel hechel Los, schreibt jetzt endlich, dass ihr es im Shop habt!! Ich will schon lange auf den Bestell-Knopf drücken...

Bei Arbeiten mit dem MotorizedLinearPoti ist uns folgendes Feature noch aufgefallen: Eine dedizierte Methode, um den Hold ein/auszuschalten. Also so was: public void setHoldPosition(boolean hold); Dann würde man z.B. folgendes machen können: - das Halten nach 3 Sekunden terminieren - das Halten terminieren, wenn der Slider zu weit weg bewegt wird - das Halten nach 3 Sekunden einschalten - ... Wäre da was zu machen?

Wuups! Sorry, ja, das funktioniert genau so wie borg es sagt und getestet hat! Ich nehme alles zurück bezgl. 'kann nicht stoppen' und unterstütze das Gegenteil: Es stoppt. Tschuldigung

Danke für die Antworten! Das mit den Chunk-Listenern habe ich verstanden, ist abgehakt. Das mit den Temperaturen... alleine ein Blick in den Hauseigenen Tiefkühler verrät, dass die Temperatur tiefer als -10°C gemessen werden kann.(ca. -23°C) Aus Deinem Post entnehme ich aber, dass der 'kleine' Bereich nur runter auf -10°C (263.15K) gehen soll?! Ich werde nächste Woche mal mit flüssigem Stickstoff messen und mitteilen, ob die FLIR bis 'runter' 'sieht'... Nun habe ich aber noch eine neue Frage: Wie kann das Bricklet wieder 'abgeschaltet' werden, wenn es im Callback-Modus war (IMAGE_TRANSFER_CALLBACK_HIGH_CONTRAST_IMAGE)? Ich dachte, ein Wechsel auf MANUAL (IMAGE_TRANSFER_MANUAL_HIGH_CONTRAST_IMAGE) würde das Bricklet wieder 'zum Schweigen' bringen... aber das blinkert lustig weiter und auch die Callbacks kommen weiterhin!? Ich möchte ja nur programmatisch das Bricklet stoppen (nicht resetten), damit die Kamera geschont und die Bandbreite wieder 'frei' wird. Hab ich was übersehen?

Ich wollte da was implementieren und bin über ein paar Unklarheiten gestolpert: 1. Doku zu den Auflösungen: -10°C to 140°C mit einer Auflösung von 0.01°C -10°C to 450°C mit einer Auflösung von 0.1°C API zu den Auflösungen: von 0 bis 6553 Kelvin (-273,15°C bis +6279,85°C) mit 0,1°C Auflösung von 0 bis 655 Kelvin (-273,15°C bis +381,85°C) mit 0,01°C Auflösung Was würde denn da nun stimmen? (Ich tippe auf das API ;-) ) 2. Da gibt es zwei Listener: BrickletThermalImaging.TemperatureImageLowLevelListener BrickletThermalImaging.HighContrastImageLowLevelListener Gehe ich recht in der Annahme, dass wir 'Normalos' diese nicht nutzen sollen, da sie die gleiche Dokumentation aufweisen wie die 'non-LowLevel' Pendants? Oder würden die uns mit diesen 'Chunks' was spezielles bieten?

Nach Einspielen der Firmware kann auch ich vermelden, dass sämtliche unsere Potis den beschriebenen Fehlerzustand auch nach über 8h Dauertest nie mehr erreicht haben. Wir haben dabei sämtliche Modi (Hard/Smooth) und (Hold: true/false) berücksichtigt. Super! Ich erkenne das Problem als gelöst.

Wir haben die neuen Potis einem brutalen Dauertest unterzogen: 1. Befehle dem Motor, das Poti an einen beliebigen Ort zu fahren 2. Warte bis die Position erreicht wurde (Callback positionReached) 3. Warte eine gewisse Zeit (bis zu einer Sekunde) 4. Goto 1 Bei sämtlichen Potis ist dann folgendes zu beobachten: Manchmal (etwa 1/800 mal) kann der Motor die Position nicht 'exakt' erreichen... und der Motor summt vor sich hin... Der Wert des Potis (per getPosition im Brickviewer) flackert dabei auf dem gewünschten Wert und einem daneben. Der Callback (positionReached) wird in diesem Fall aber nie ausgelöst. (Dabei ist es egal ob sanft oder hart gefahren wird, und ob die Position gehalten wird oder nicht. Der Hänger tritt in jedem Fall auf.) Eine subtile Erschütterung erst lässt die Endposition dann aber doch zu und der Motor verstummt... es geht weiter... bis zum nächsten 'Hänger'... So ein 'Hänger' kann über Stunden aufrecht erhalten werden und lässt sich nur 'manuell' lösen. (Der Motor summt dabei stets, wird aber nicht weiter warm) Wäre es denkbar, dass ihr da intern ein wenig am PID korrigiert, oder dass ihr den Callback ein bisschen 'lascher' auslöst? Sonst können wir die Poti's nicht im Show-Room neben der Warp-Spule laufen lassen (oder nur auf einer Rüttelplatte :-) )... Und das wäre ja wirklich schade ;-)

Ja, Deine Erklärung ergibt für mich Sinn und entspricht der Beobachtung. Wir senden euch das fragliche Poti somit zu. Dann würde ich dieses Topic als 'gelöst' sehen.

Nein, dieses eine Poti scheint ein echtes Problem zu haben: Habe die calibrate()-Funktion durchgeführt, dabei fuhr der Slider wie von borg beschrieben hin und her, an beiden Seiten bis zum Anschlag. Doch danach hatte dieses Poti genau den gleichen 'Range' wie vorher... also nur so ca. 3/4 der Strecke. Ich habe die calibrate()-Funktion auch mit anderen Potis (welche allesamt bereits perfekt liefen) gemacht, da war das Verhalten so wie erwartet und der 'Range' wird anschliessend zu 100% genutzt.

Eines der neuen MotorizedLinearPoti verhält sich so, als ob es ?"falsch kalibriert" wäre... wenns so was gibt: Wenn es auf Position 0 fahren sollte, rast es bis ans eine Ende... mit einem deutlich hörbaren 'klack'. Wenn es auf Position 100 fahren sollte, fährt es aber nur rund 3/4 der Strecke und bleibt dort stehen (bei allen Positionen dazwischen 'summt es immer leicht'. Genau das Selbe Verhalten hat die Abfrage (brickv) von der aktuellen Position... 0 ist beim einen Anschlag, 100 ist bei etwa 3/4 der Strecke. Der Wert im Graph schwingt immer so zwischen 3 bis drei Positionen Wie kann dem Poti beigebracht werden, dass es die vollständige Strecke nutzen soll?

Hallo HerrB92: Tolles Testsetup, danke für die Rückendeckung Zu den Fragen von @Loetkolben: Stimmt, dazu habe ich ja gar nix geschrieben. Es sind allesamt die 'Pixelbündel', welche ich von Tinkerforge bezogen habe. Sie werden mit einer 100W/5V Quelle gespiesen. Jeweils Anfang- und Ende einer 50er Kette... genau so, wie es bei Tinkerforge in der Doku gezeichnet ist: https://www.tinkerforge.com/de/doc/_images/Bricklets/bricklet_led_strip_pixel_wiring_1500.jpg Die ganze Kette beginnt just nach dem LED-Bricklet, also keine lange Leitung für Clock und Data... und somit auch keine Kondensatoren dazwischen. Das läuft absolut perfekt... bis Firmware 2.4.0. (Dass die 2.4.2 auch noch funzt wusste ich gar nicht.) Es sieht nur im ersten Augenblick wie ein 'flackern' oder Wackelkontakt aus... Mit der Zeit merkt man aber, dass egal welchen LED-Strang man dran tut, das ganze sehr präzise reproduzierbar ist, also immer die genau gleichen LED-positionen flackern... Sofern das LED-Bricklet am gleichen Port bleibt. Es ist wirklich fast sicher auszuschliessen, dass es ein externes Problem ist. Irgendwas schreibt ins Memory sobald das LED-Bricklet mehr als das übliche Memory (?240bytes?) benötigt. Am Clock kann es nicht liegen, da auch 2811/2812er etc. betroffen sind. Vielleicht nutzt das Master das restliche scheinbar ungebrauchte Memory... wenn da keine wieteren Bricklets dran hängen? Es muss ein fieser Bug sein, der sich da eingeschlichen hat.

Mal eine Frage zum Status: Macht ihr da noch was, oder sitzt ihr das Problem einfach aus? Es ist immer noch so, dass die Master (v2.0 und v2.1) Firmware 2.4.0 die letzte Firmware ist, bei der das LED-Bricklet (v1.0 und v1.1) (Firmware 2.0.6) noch korrekt läuft. Ab der Version und auch mit der aktuellen 2.4.4 Version läuft die LED-Bricklet nicht korrekt: Ich habe das soeben wieder bitter erfahren müssen: 150 LEDs 2801 Bei Firmware 2.0.6 an Port D: Blau (der erste Kanal) geht durchwegs... aber es flickert manchmal die 81. LED Grün/Rot (die zwei anderen Kanäle) gehen nur bis zur 30. LED Sieht aus wie ein Wackelkontakt... oder ein paar kaputte 2801er... ABER Flashed man die 2.4.0 Firmware auf das Master dann geht alles genau so wie es soll. Flashed man wieder die 2.4.4 Firmware drauf... Symptom wie oben beschrieben. Bitte: Testet das bei Euch mal mit 100 LEDs! Wichtig: Es nutzt nix, 50 dran zu hängen... und zu probieren. Auch dann nicht, wenn ihr einfach rein schreibt, es seien 200 dran, obwohl nur echte 50 angesteuert werden. Der Fehler zeigt sich erst, wenn ihr echte 100 LEDs oder mehr ansteuert. Es ist garantiert ein Tinkerforge Bug! Und sehr wahrscheinlich schreibt irgend was 'von links' ins Memory auf dem Master! Falls euch zum Testen das Material fehlt (200 x 2801/2811/2812), kann ich euch auch gerne beliebige flickernde Setups (mit absolut frischem Master auf 2.4.4 geflashed und LEDBricklet 2.0.6) zur Verfügung stellen! Sagt was ihr braucht... (Korrigiert... Master Brick Firmware 2.4.4 nicht 2.6.0)

Moment... ich habe mit den falschen Bindings getestet... Ich werde das noch einmal für 2.1.13 machen...

Ou, da hab ich einen Task übersehen, der an mich gegangen ist... Was ich weiss: In den 2.1.13 Bindings ist der Memory-Fresser noch drin. (Mit dem Beispielprogramm, von oben frisst der Java-Prozess pro Sekunde etwa 500kB) Aber das ist vielleicht, weil ich hier nie geantwortet habe. Soll ich das hier angehängte noch testen? Es scheint mir, als ob das mit dem 2.1.13 bzgl. aufräument im connect() ziemlich übereinstimmt.

Ich bin begeistert! (Nicht über das schön umschriebene Artefakt, das Loetkolben gefunden hat... da zuckt mir das Auge wie bei Scratty) Die neuen Versionen von brickv, Masterbrick und WiFi2-Extension sind super! Genau so sollte es sein! (Haben auch kurz mit Wireshark das Netz beobachtet... Kein Verrat mehr vom Brick zum BrickV... Umgekehrt... das haben wir nicht so genau angeschaut ;-) ) Nun kann ich fleissig und freudig am privacy-Paper weiterschreiben, bei dem ab nun zu lesen sein wird, dass TF das Problem angegangen sei und es vorbildlich gelöst habe...