Posts by Zentris

  • CPU-Takt auf 20x4 LCD

    Quote from noisefloor

    Du hast einen Server und darauf läuft veraltet Software, die _keine_ Sicherheitsupdates mehr bekommt. Das ist so ziemlich die schlechteste Kombination, die es gibt - und das ist dir egal?

    Grundsätzlich magst du ja Recht haben, aber bei isolierten Systemen ist das ziemlich egal.


    Was meinst du, wieviel Kleinst-Kontroller (Server) innerhalb ihrer Lebenszeit (>10 Jahre) NIE ein Update bekommen (Waschmaschine, Kaffeemaschine usw.) und dennoch zuverlässig laufen?


    (ja, da läuft vielleicht kein Python drauf, aber weißt du es genau in jedem Fall??)

  • Folding at home auf Raspberrypi

    Man lese bitte meinen Beitrag #8 noch einmal sorgfältig...


    Die Ablaufzeit der Folding-WUs (WorkungUnit / Arbeitspakete) wird dimensioniert auf meist so 30-60h (steuerbar durch die Anzahl der Itterationsschritte) , weil die in den einzelnen WUs enthaltenen Einzelaufgaben letztlich aufeinander aufbauen und weiter verarbeitet werden - Pipeline-Prinzip.

    Weiterhin werden die WUs mehrfach vergeben, um zu vermeiden, dass, wenn einer nicht fertig wird (weil z.B. dessen Rechner ausgefallen ist), die ganze Pipeline zum stehen kommt.


    Die CPU-WUs sind ausgerichtet auf genaue Fliesskommazahl (doppelte Genauigkeit)-Berechnungen, die GPU auf einfachen Genauigkeit...

    Der Raspi ist sicher genau da nicht der Überflieger bzgl. Performance..


    Klar kann man versuchen, mit dem RasPi mit zu "rennen", aber das würde etwa wie so ein "Hase und Igel"-Spiel laufen: Die anderen sind immer schon da bzw. bei der übernächsten WU..., die berechnete WU wird letztlich verworfen, weil schon zig-mal bestätigt.


    Zur Zeit ist es z.B. so, dass nicht genügend CPU-WUs bereitgestellt werden: Die Wissenschaftler haben offenbar Probleme aufgrund der hohen (Durch Corona getriggerten) Beteiligung (auch kräftiger Rechner) die Pipeline mit WUs zu füllen... Im FAH-Forum gibt es da diverse Threads...

    Ich habe hier inzwischen 2 Rechner laufen, einer davon mit GPU... selbst die GPU-WUs werden knapp....


    Einfach mal realisieren, dass der RasPi ein schönes Teil ist, aber eben nicht die Performance-Schleuder, die man für derartige Aufgaben benötigt.

  • Sensor für Bodenfeuchtigkeit welcher länger hält.

    Luft- und Bodenfeuchtigkeit haben nur bedingt miteinander zu tun:


    Die Luftfeuchtigkeit kann man recht schnell anheben (Verdunster, Vernebler), was sich aber fast überhaupt nicht auf die Bodenfeuchtigkeit auswirkt:

    Diese wird ja "an den Wurzeln" in ca. 3-5cm Tiefe ermittelt und zeigt quasi an, was den Pflanzen an Wasser zur Verfügung steht.


    Es gibt nur sehr wenig Pflanzen, welche ihren gesamten Wasserbedarf über die Blätter stillen: Tillanzien z.B. ...


    Was ich damals nicht getestet habe:

    Das wäre vielleicht ein Forschungsthema mit deinem Sohn in Zeiten der Krone? :)

  • Raspberry läuft wie alter PC :-(

    Node.js und in Prinzip das ganze JavaScript-Geraffel ist die Pest der Programmier-Neuzeit...


    Ich habe auf Arbeit damit zu tun (Angular) und finde, das Zeug gehört in die Tonne:

    Klar, mit "richtigen" Programmiersprachen kommen die meisten Studies offensichtlich nicht mehr klar, zu kompliziert, zu langsam in der Projekterstellung usw....

    UND: In Zeiten knapper Rescourcen (CPU/RAM/Plattenplatz) macht man sich schon wesentlich mehr Gedanken bzgl. der Umsetzung als heute...


    Nun, wir haben "damals" auch nicht alle 4 Wochen ein neues Release raus gehauen, sondern entsprechend geplant und getestet...

    Ach, was soll's...

  • Folding at home auf Raspberrypi

    Die WUs, die für Rechner ohne GPU verteilt werden, haben eine bestimmte Zeit, bis sie "erfüllt", also durchgerechnet werden müssen.

    Diese liegt so im Mittel bei 2-3 Tage.


    Ich lasse hier einen NUC seit ca. 1 Woche dauerhaft (24h) rechnen, mit 4 kernen... der braucht so zw. 6-16h für eine WU, je nach Komplexität.

    Mit einem RasPi wird das Zeitlimit kaum einzuhalten sein, so dass die Bemühung umsonst ist und letztlich rausgeworfenes Geld/Zeit/Rescourcen.


    Der FAH-Client ist auch nicht dafür ausgelegt, auf einem RasPi-Cluster seinen Job nochmals zu verteilen...

  • Sensor für Bodenfeuchtigkeit welcher länger hält.

    Ich hatte "damals" das Glück, den Trend vor dem Hype zu erkennen:

    Erst ein Teil bestellt (ca. 9$), dann weitere 3 (ca. 11$/stk)) und dann nochmal 10 (ca. 13$/stk).


    Die Investition hat sich maximal gelohnt.

    Der erste Sensor ist nun seit ca. 3 Jahren im Dienst, hat seine Batterie ca. 1x/Jahr erneuert bekommen und läuft und läuft und läuft...

    Die anderen (insgesamt akt. 11 Sensoren) spinnen nur, wenn die Batterie leer wird, ansonsten werden sie per BT alle 15min durch einen RP-Zero abgefragt, der so etwas lustlos in Fensterbrett im WZ rumbaumelt...


    Die anderen Sensoren, die du da angeführt hast, sind teilweise absoluter Schrott (die mit der galvanischen Messung) bzw mittlere Schrott (die Kapazitiven):

    Diese haben ein massives Problem mit der Langszeitstabilität, ich hatte hier einen rech tweitschweifenden Thread zu diesem Thema, das Konzentrat ist in meinem Blog (link in meinem Footer) bzw. https://www.n8chteule.de/zentr…ant-sensor-1-einfuehrung/.


    Die Lackierung ist das entscheidende Thema, PUR-2-Komponenten-Lack ist der Schlüssel, alles andere hilft nur mittelfristig bis gar nicht...

    Das Problem ist, dass viele andere Autoren keine Langzeit-Untersuchungen gemacht haben. Nur mal so kurz am Küchentisch, Beitrag geschrieben, Kohle bzw. Aufmerksamkeit kassiert und dann weiter gezogen sind.


    Nun gut.

    Wenn du was kurzes mit viel Gebastel willst, nimm so einen "billigen" kapazitiven Sensor.

    Wenn du was dauerhaftes willst, nimm den Xiaomi... auch wenn er teuer ist: Das gesparte Geld für den/die billigen Sensoren musst du sonst in Form deiner persönlichen Freizeit ausgeben... jeder wie er will und alle nur ein Kreuz (!) :)

  • RPi Zero W und 220V AC

    Quote from luemar

    Noch eine letzte Frage: Warum soll Arduino zuverlässiger sein als RPi ? Weil er kein OS benötigt ?
    Dachte Linux/Debian sei sicher. Mir geht Programmieren mit Python viel leichter als mit C.

    Ist vieles schon geschrieben worden, warum ein RPI bei bestimmten "reinen" Mess- und Schaltaufgaben" ggü. einem AVR bzw. ESP die schlechtere Wahl ist.


    Ich möchte noch hinzufügen:

    • Strombedarf: Ein RPI braucht relativ viel Strom, den er letztlich in Wärme umsetzt, die dann u.U. wieder weggekühlt werden muss. Besonders bei engem Aufbau und/oder im eingebauten Zustand entsteht schnell ein thermisches Waterloo...
    • Zuverlässigkeit: Die SD Karte hat jar schon erwähnt, die thermische Belastung der Bauteile auf einem RPI ist im Dauerbetrieb wesentlich höher als auf einem AVR/ESP...
    • Platz: Vergleiche mal die Abmaße der Baugruppen...
    • Virenschutzt: Beim AVR/ESP hast du (ausser dem Bootloader) ALLES selbst in der Hand. DU baust das "OS" selbst. Solange du das nicht selbst Schadcode einbaust, wird im Normalfall (gesperrtes Update over Air) keiner etwas hacken können.

    Ich habe hier so einige Tools unter ESP laufen, seit >3 Jahren, Dauerbetrieb... die sind teilweise so alt, da muss ich den Code erstmal wiederfinden... :) die laufen und laufen und laufen ... Stromausfall (ja hatten wir) : Na und, die sind schneller wieder da als der ganze Rest der Messkette (RP zur Erfassung/Sammlung und NAS als Storage...).

  • Covid-19 Beatmungsgeräte | Schlafapnoe / Atemtherapiegeräte modifizieren

    Du scheinst zu übersehen, das dieses Forum hier ein "Bastler-" aka "Maker-"Forum mit beschränkter Reichweite und Kapazität ist.


    Soweit dein Vorschlag relevant ist, kontaktiere das RKI oder meinetwegen auch das Virus-Hackatron.

    Oder den Hersteller (Damit er das testet und eine qualifizierte Handlungsanweisung bzgl. des Umbaus/Umkonfiguration rausgibt).


    Oder bau eine Webseite/Blog, wo du das beschreibst und veröffentliche das auf den soz. Kanälen...

    Damit erreichst du eine viel bessere Breitenwirkung, jedoch auch unter der Gefahr, das Fehler bei der Umsetzung passieren.

  • Covid-19 Beatmungsgeräte | Schlafapnoe / Atemtherapiegeräte modifizieren

    Quote from unimatrix

    könntest du bitte den völlig sinnfreien Beitrag löschen und den Covid-19 Thread übersichtlich halten ? Bitte. Allerdings, die Meinungsfreiheit ist ein sehr hohes Gut. TC4U ux

    Bei allem Einverständnis bzgl. deines Engagements akzeptiere, dass jemand, der auf so ein Gerät angewiesen ist, nicht daran herumschraubt.

    Das hat mit sinnfrei bzw. Beitrag übersichtlich halten nichts zu tun.


    Und mal im Ernst:

    Im absoluten Notfall ein manipuliertes Gerät zu verwenden, nun ja... wenn es um Leben oder Tod geht, mag akzeptabel sein.

    Im "normalen" Unterstützungsbetrieb der Lungenfunktion möchte ich nicht derjenige sein, der am Tod eines Patienten durch eine Fehlfunktion des durch mich umgebauten Gerätes schuld ist.


    Med. Geräte werden sehr ausführlich getestet und erhalten erst ihre Zulassung, wenn alle Tests fehlerfrei absolviert werden.

    Bei einer Modifikation durch Fremde erlischt die Zulassung (egal ob SW oder HW-Modifikation).

  • 4x Load-Cell-bridge an einen hx711

    Quote from jar

    hmmm das ist aber irgendwie anders als der gemeine run in

    auch wird mir dadurch nicht klar ob das driften damit unterbunden oder minimiert wird.

    Es wäre interessant zu wissen ob ein run in, also im Wechsel über 72h die Temperaturen zu ändern zur Stabilität der Messungen beiträgt.


    Ich weiss aus meiner Industriezeit das sowas sehr aufwändig ist, erst Recht als Hobby mit wenig privater Freizeit. Das muss man und der Partner mögen.

    Tut mir nun echt leid, dass ich keine industriemäßigen Prozesse durchführen konnte <sarcasm off>