Jump to content

Quantasy

Members
  • Content Count

    76
  • Joined

  • Last visited

Community Reputation

0 Neutral
  1. 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 getChipTe
  2. 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 be
  3. 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 '
  4. 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.
  5. 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ückm
  6. 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 ü
  7. 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!
  8. 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 eine
  9. Hechel hechel Los, schreibt jetzt endlich, dass ihr es im Shop habt!! Ich will schon lange auf den Bestell-Knopf drücken...
  10. 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?
  11. 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
  12. 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 (IMAG
  13. 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.HighContrastImageLowLevelList
  14. 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.
  15. 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 Fal
×
×
  • Create New...