Jump to content

Quantasy

Members
  • Gesamte Inhalte

    78
  • Benutzer seit

  • Letzter Besuch

Quantasy's Achievements

Newbie

Newbie (1/14)

  • First Post
  • Collaborator Rare
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation in der Community

  1. P.S. Ich sehe grad, dass bei euch das selbe Verhalten sogar filmisch festgehalten wurde! Achtet mal auf eure Frequenzangabe durch die ganze Aufnahme!
  2. 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.
  3. 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(); }
  4. 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.
  5. 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.
  6. 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.
  7. 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?
  8. 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. :-)
  9. 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!
  10. 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.
  11. Hechel hechel Los, schreibt jetzt endlich, dass ihr es im Shop habt!! Ich will schon lange auf den Bestell-Knopf drücken...
  12. 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?
  13. 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
  14. 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?
  15. 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?
×
×
  • Neu erstellen...