Beiträge von Seppl1

    Zur Funktionsweise (mehr "educated guess" als tatsächliches Wissen):

    Bei den kleinen Teilen wird ein Peltierelement verwendet um die Luft abzukühlen. Kalte Luft kann weniger Wasser halten, es kondensiert also und tropft in den Behälter.

    Bei den größeren wird die Luft m.W. komprimiert, wodurch das Wasser darin auch kondensiert. Das bedeutet natürlich es läuft ein Kompressor, der deutlich hörbar ist. Bei den kleinen hört man nur einen Lüfter.

    Ist auf jeden Fall schonmal eine andere Hausnummer als das Teil was meine Frau mir geschickt hat welches nur 20W verbrauchen soll.
    Nach welchem Prinzip arbeiten die Dinger eigentlich?

    Ist das zufällig so eins?
    https://www.ebay.de/itm/125055375224

    Wenn ja: davon kann ich nur abraten. Hab ich mal ausgetestet, hatte gehofft der könnte die Luftfeuchtigkeit in einem 15 m^2 Kellerraum wenn er dauernd läuft auf nem akzeptablen Niveau halten, aber nein, es hat keinen messbaren Unterschied gemacht. Daraufhin hab ich den Trotek TTK50e gekauft, der ist da jetzt fast schon überdimensioniert, funktioniert aber seit ca. 5 Jahren einwandfrei.

    Ich habe insgesamt 3 Solokeys, von 2 Kickstarter Kampangen.

    1x Solo 1 USB-C
    2x Solo 2 (1x USB-C, 1x USB-A)

    Bisher nutze ich sie als 2. Faktor für Webseiten wie z.B. github.

    Insgesamt finde ich sie schon gut, sie tun was sie sollen und sind komplett open source (Firmware und Hardware!). Was mir nicht so gefällt: Die Entwickler sind etwas "wankelmütig" wenn es um die Software geht, insbesondere beim Updater zum aktualisieren der Firmware.

    Es gab einen Updater im Browser, der nicht mehr weiter entwickelt wird und ein Desktopprogramm, welches (noch?) nicht offiziell eingestellt wurde, aber schon seit 2 Jahren nicht mehr weiterentwickelt wurde. M.W. unterstützen beide nur den Solo 1.
    Dann gibt es ein Kommandozeilentool in Python für den Solo 1 und eines in Rust für den Solo 2. Beim Solo 2 ist auch die Firmware in Rust geschrieben, die vom Solo 1 ist in C. Der Updater als Desktopprogramm war/ist in Javascript geschrieben, genauso wie auch der Webupdater. Da fragt man sich, ob die Qualität des Codes nicht womöglich darunter leidet, wenn man so viele unterschiedlichen Sprachen verwendet.

    Gleichzeitig scheinen sie durch dieses "rumprobieren" auch nie mit etwas fertig zu werden (außer der Firmware, glücklicherweise). Keiner der Updater kann als stabil angesehen werden. Selbst der in Python für den Solo 1 trägt Versionsnummer 0.0.30, hat aber keine Warnung im Gegensatz zu dem für den Solo 2: "This repository is incomplete and under active development." Beim Desktopprogramm steht "Not yet ready!"

    Wenn es dann tatsächlich mal einen kritischen Bug gibt und man wirklich ein Firmwareupdate machen sollte/muss, müssen sie zumindest für manche eine detaillierte Anleitung schreiben, in der dann erklärt wird, wie man diese unfertige Software installiert und nutzt.

    Obwohl ich vieles davon damals schon wusste, habe ich den Solo 2 trotzdem unterstützt, da ich hoffe, dass sich die Situation langfristig bessert, insbesondere auch wegen dem Opensource-Ansatz. Vielleicht schreibt ja irgendwann jemand (unabhängiges) eine GUI, die am Besten gleich beide CLIs vereint.

    Das sieht für mich nach einer Transversalmode (TEM10) aus. Dann ist wahrscheinlich einer der Spiegel der Lasercavity (also einer der Spiegel in der Röhre) nicht korrekt eingestellt. Da kannst du soweit ich weiß nichts machen, also würde ich die Röhre zurückschicken.

    Das hat aber nichts damit zu tun, was der Plasmastrahl macht. Das müsste m.W. normal sein.

    Wer wird denn hier gleich aufgeben :P

    @raabenaas Hast du das nicht gemacht:

    Auch von deinem XUbuntu-Rechner...falls die Datei existiert:

    cat ~/.ssh/config

    oder hab ich das übersehen?

    Falls die Datei nicht existiert (wird sie nicht, falls du sie nicht manuell angelegt hast), könntest du mal in /etc/ssh/ssh_config einfach alles auskommentieren, was nicht sowieso schon auskommentiert ist. Standardmäßig sollten das folgende Zeilen sein:

    Code
    SendEnv LANG LC_*
    HashKnownHosts yes
    GSSAPIAuthentication yes

    Dann nochmal versuchen zu verbinden.


    Wann hast du denn das Xubuntu das letzte mal aktualisiert? Vielleicht gab es zufällig als du es installiert hast gerade einen Bug in openssh-client.

    Bei mir lief es gerade "quasi problemlos" durch. Das es scheinbar hängen bleibt (tatsächlich dauert es einfach nur sehr lange und der Fortschrittsbalken aktualisiert sich solange nicht), kann seit dem letzten Update je nach Chrome OS Image passieren. Da arbeite ich gerade an nem Fix. Aber wieso es bei dir rebootet verstehe ich nicht. Kannst du da mal ein [definition=12,0]debug[/definition] [definition='1','0']log[/definition] machen?

    @DaVu Ich denke du hast übersehen, dass @raabenaas sich wieder mit "/bin/bash -i" eingeloggt hatte. In dem Fall werden die profile Dateien m.W. nicht ausgeführt, weil das dann eine "non-login shell" ist, statt wie normalerweise eine "login shell".

    Ich vermute aber, das irgendeine der profile Dateien einen Fehler hat, wodurch es ewig hängt. Aber wohl keine von denen, die mit /etc/profile ausgeführt werden.
    Es muss aber ja noch mehr geben, die z.B. den folgenden "LibreELEC Schriftzug" erzeugen, den man beim einloggen sieht:

    Code
    ##############################################
    #                 LibreELEC                  #
    #            https://libreelec.tv            #
    ##############################################
    
    
    LibreELEC (official): 10.0.2 (RPi4.arm)


    Weißt du, welche Dateien das alles sind?

    @tavoc Geht es wirklich um reines Benzin? Bei (selbst gemischtem) Benzin-Öl-Gemisch für 2-Takter ist das ja durchaus bekannt, dass es sich mit der Zeit entmischt und der Motor dann z.B. fast nur Öl bekommt. Aber normales Benzin hält eigentlich schon mehrere Jahre ohne Probleme.

    ich müsste für die achse eine richtung, also pos oder neg ausschalten. hau ich dem ding nämlich eine vor den latz, löst er 2 mal aus.

    Da du bei SENSE_Y_NEG_KEY 0 hast, ist das eigentlich schon deaktiviert. Du könntest vielleicht mal die debounceTime (Zeile 109) vergrößern. Falls du die lieber für jede Achse separat einstellen willst, braucht es eine kleine Codeänderung.

    Also, der Reihe nach:


    dir sind nicht zufällig dehnmesstreifen (oder ähnliches) in erschwinglich preislicher art bekannt, die man an so 'nen arduino dran machen könnte?

    Nicht wirklich. Piezos erzeugen ja eine Spannung, wenn sie Druck abbekommen bzw. minimal verformt werden. Die werden bei Arduinos z.B. als Vibrationssensor verwendet, aber wenn man da z.B. ein Gummiband befestigen könnte, müsste das eine Spannung abhängig vom Zug am Band ausgeben. Allerdings nur so rein theoretisch.
    Wenn du googelst findest du aber bestimmt auch Dehnmessstreifen die man mit nem Arduino auslesen kann.


    wegen meines start-programms - müsste da einfach als zeile 1 "Keyboard.println(" C:\Users\the ratman\Spiele\pbfx3.bat");" rein?

    [bv] Naja, auf jeden Fall nicht in Zeile 1. Aber wenn man es ans Ende der setup Funktion setzt, wird nichts anderes passieren, als ob du diese Zeichenfolge einfach per Tastatur eintippen und Enter drücken würdest. Also wenn du schon die Kommandozeile offen hast, würde das sogar funktionieren, aber im Allgemeinen nicht. Man müsste aber im Prinzip nur noch per Tastenkürzel die Kommandozeile öffnen, dann könnte das hinhauen.


    wenn der sensor auslöst, was er grade wirklich super macht, dann drückt quasi der arduino z.b. die space-taste nicht lange genug.

    Das ist schnell gelöst: Du musst nur zwischen Keyboard.press() und Keyboard.release() in Zeile 101 und 104 jeweils noch eine Zeile mit delay(50); einfügen. Kannst auch mit dem Wert noch etwas rumspielen, das ist einfach wieviele Millisekunden es gedrückt bleibt.

    Also, dass es ständig "m" schreibt, liegt sicher an den noch nicht gesetzten Referenzwerten.

    Der 2. Code schreibt nur in die Konsole, die Textdatei würde nämlich sehr schnell sehr lang werden. Wenn dir das aber lieber ist musst du nur in Zeile 44, 53 und 55 Serial.println durch Keyboard.println ersetzen.

    Der 2. Code wird nach dem einstecken sofort anfangen ständig eine Zahl zu schreiben. Wenn die Tastatur ruhig steht sollte das immer (nahezu) der gleiche Wert sein, den trägst du dann als Referenzwert für die x-Achse ein. (Im ersten Code Zeile 46, im 2. Code Zeile 22). Solange dieser Referenzwert noch nicht stimmt, wird es auch ständig "negative hit" oder "positive hit" schreiben.
    Danach kannst du testen, ob der Grenzwert zum triggern i.O. ist, dafür am Besten in Zeile 44 (2. Code) das Serial.println (bzw. Keyboard.println) auskommentieren. Dann sollte es nur bei einem erkannten Hit entsprechend "positive/negative hit" schreiben. Wenn dir das zu früh/spät kommt den Wert in Zeile 47 (1. Code) bzw. 23 (2. Code) ändern.

    Dann machst du das Gleiche nochmal für die y-Achse, also im 2. Code in Zeile 69/70 die x-Achse auskommentieren und y aktivieren.