|
|
|
|
|
|
|
Wir leben in eine schoenen Zeit, Linux kann fur uns diverse Firmwares und - bei den guten Herstellern - sogar das UEFI aktualisieren. Das ist der halbe Patch fur die Unifying Receiver von Logitech, den einige von euch haben werden.
Ich habe schon mal ein Update etwa einem Jahr bekommen, also habe ich es wieder riskiert. Gaenzlich fehlerfrei ist es nicht, der Receiver braucht laenger zum Neustart als erwartet. Offenbar klappt das Update aber direkt, also entweder mit einem anderen Eingabegeraet nochmal drauf klicken (im Prinzip sinnlos, dann ist die gnome-software jedoch zufrieden  ) oder den Receiver aus- und wieder einstecken.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von hoschi am 29.09.2019 12:13]
|
|
|
|
|
|
|
|
|
das libre phone ist draußen
liest sich nicht so überzeugt, vorallem die kommentare bei lwn sind noch aufschlussreich. :/
das hört sich eher danach an: umweltbewusste nehmen fairphone, richard stallmann würde purism nutzen. auch wenn ich deren ansatz doch sehr mag ist da scheinbar noch luft nach oben :/
|
|
|
|
|
|
|
|
|
|
|
Ich wollte etwas dazu schreiben, aber es wird dann gleich so viel Text.
Mir hat es nicht gefallen, dass die Displaygröße erweitert worden ist. Das Ding ist fast so dick wie alte Mobiltelefone, vermutlich eben wegen der Wahl auf Komponenten die mit freien Treibern ansteuerbar sind und nicht auf einen fertigen SoC mit ein paar Zusatzchips. Ist das jetzt wirklich so, dass die das nicht hin China von irgend einem Auftragsfertiger machen lassen, sondern selbst in den USA produzieren? Lustig finde ich, dass der Autor dann M.2 als Schnittstelle kritisiert, dass ist ja eine moderene flexible Schnittstelle in neuen Laptops - wir können uns davon in Laptops nur mehr wünschen. Da ist das Problem auch eher, dass die Laptops zu flach werden - RAM verlötet, Batterie verklebt statt verriegelt/verschraubt und die Wärme wird nicht ausreichend abgeführt.
Ich nehme meinen Hut davor, dass sie das angekündigt haben, Geld gesammelt haben und es auch durchgezogen haben. Viele andere haben das nicht:
Sieht gut aus, sie haben alles mit libhandy in Gtk3 nochmal neu aufgebaut, wo Gtk2 nicht mehr gewartet wurde seit Nokia* sich selbst aufgegeben hat. Erinnert ihr euch noch, Nokia war bei Gtk2 mit dabei und mit Maemo war ein System für Smartphones fertig, bevor man alles verworfen hat und nochmal mit Qt und Meego angefangen hat. Ich bin mir aber auch sicher, dass Softwareseitig alles fehlt bis auf Telefonie, SMS/MMS und Matrix. Sie werden viele Updates benötigen und die wird es nur geben, wie sie mehr und bessere Hardware nachliefern. Canonical hat das nicht getan, obwohl so viel mehr Geld zur Verfügung stand.
| | | There are already plans for a "Fir" batch in Q4 2020, which features an upgraded "14nm Next Generation CPU" and "Mechanical Design: Version 2." | |
Das interessiert mich mehr. Den selbst als begeisterter Linuxanwender ist das Smartphone derzeit für mich nicht interessant, es ist zu teuer als Spielzeug und ich brauche wirklich Signal als Kommunikationsmittel. Matrix ist gut, aber es ist modernes 1:n IRC.
Was mich immer bekümmert, ist das gute Ideen und Linux im speziellen beim Endanwender kaum voran kommen - weil es keinen Hersteller gibt der viele Geräte mit passender Software auf dem Markt liefert. In der IT muss man als erster eine kritische Masse an Nutzern erreichen, sonst wird man verdrängt oder wartet eben ein Jahr bis die Hardware gut unterstützt wird. Die meisten wissen nicht was ein ThinkPad ist oder ein XPS13 
Pebble ist kein Linux, aber doch irgendwie ein gutes Paradebeispiel. Ich mag persönlich richtige Armbanduhren und keine Smartwatches. Ich weiß nichtmal ob Smartwatches die Smartphones verdrängen werden oder wieder durch etwas anderes ersetzt werden. Pebble war als erster am Markt, hatten eine gute Idee und dann hat Apple Werbung geschaltet, Garmin seine Produktlinie angepasst und Xiaomi massenhaft Armbänder geliefert. Pepple ist jetzt weg. Palm Pre war ähnlich, mangels großer Marktdurchdringen gestorben. Soll heißen, ich denke sie werden nicht die Weltherrschaft übernehmen. Ein Jahr des Linuxdesktops oder Linuxsmartphones oder Linuxirgendwas gibt es nur, wenn wirklich ein oder zwei Hersteller massenhaft viele Gerät damit auf den Markt bringen.
Noch jemand nicht erwähnt? OpenMoko, lange vor Android. Jolla hat, soweit ich weiß, nie den Quellcode vollständig offen gelegt, wie früher versprochen. Das Jolla1 läuft noch und bekommt Updates, wegen der geschlossenen Firmware sind keine Kernelupgrades möglich, die Probleme mit BTRFS somit nicht rückwirkend zu beheben. Bleibt noch das kommende Pinephone, aber da fehlt mir wieder das Betriebssystem. Der Ansatz von Jolla nur noch "nachinstalliert" zu werden, ist jedenfalls schlecht. Dabei ist das Konzept von Sailfish OS („Jolla“ wirklich gut. Ich bleibe erstmal beim iPhone SE, schön handlich und Babbel läuft darauf. Mittlerweile bereue ich, dass es nochmal iOS 13 bekommen hat - die Bugs nerven, Signal ist kaputt gegangen, Bluetooth im Auto überträgt die zuletzte gewählten Nummern nicht mehr, eingehende Mails werden nur nach Schließen/Öffnen angezeigt, kleinere UI-Fehler die man von GNOME x.0 Releases so kennt
* Ich habe mal einen besseren Blogpost gelesen, der erläutert hat wie Nokia keine Anschluss an die quelloffene Gemeinschaft gefunden hat.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von hoschi am 30.09.2019 21:59]
|
|
|
|
|
|
|
|
|
Ich war lange nicht hier, ne, und so. Mucho sorry, werde die Posts ein ander Mal aufarbeiten müssen.
Aber hat noch einer von euch das Problem, dass ein Thinkpad, so bald es am Thunderboltanschluss angeschlossen wird, direkt bootet? Passiert mir nur mit meinem Privatlaptop mit Linux, aber nicht mit dem Bürorechner mit Windows. Ich habe also irgendwas BIOS-mässiges in Verdacht, was man für Linux umstellen muss.
¤: Und ja, Stress halt, ne.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von SwissBushIndian am 01.10.2019 17:06]
|
|
|
|
|
|
|
|
|
Hm 
Thunderbolt ist USB-C, welches wiederum Netzwerk beinhaltet. Ist es vielleicht eine Art Wake-On-LAN? Je nach Ausgestaltung wäre das bereits ein Link-Change und reicht für das Aufwachen d.h. ein magisches Paket ist nicht notwendig, Netzwerkkabel raus/rein gilt auch.
Meine Frage:
Ich kenne die Werkzeuge lsof, iostat, iotop und fatrace. Ich weiß über iostat, das viel los ist. Über iotop, weiß ich welcher Prozess viel schreibt. Über lsof, weiß ich welche Dateien dieser Prozess offen hat. Aber wie viel wird in welche Datei geschrieben? Den lsof listet mir viele Dateien. Ich brauche also ein Werkzeug, welches mir den I/O-Durchsatz zu einer Datei/Dateideskriptoren anzeigt.
Habt ihr einen Vorschlag? Ich versuche mir gerade mit inotify[wait|watch] zu behelfen. Damit wollte ich schon immer programmieren, die Userspactools sind aber auch fein. Nur fehlt mir der Datendurchsatz.
|
|
[Dieser Beitrag wurde 3 mal editiert; zum letzten Mal von hoschi am 01.10.2019 19:01]
|
|
|
|
|
|
|
|
|
ich glaube nicht, dass es dafür irgendeine API gibt, die dir das liefern kann. ich bin mir gerade nicht mal sicher, dass dafür überhaupt irgendwas im kernel existiert.
/e
welche software nimmt man denn so, um schaltpläne zu erstellen?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 01.10.2019 20:15]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ah ok, mist. das ding ist wohl schon jahre alt und...
| |
Device-mapper verity target provides read-only transparent integrity checking
of block devices using kernel crypto API.
| |
so close... oder interpretier ich das falsch?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von [KdM]MrDeath
ah ok, mist. das ding ist wohl schon jahre alt und...
| |
Device-mapper verity target provides read-only transparent integrity checking
of block devices using kernel crypto API.
| |
so close... oder interpretier ich das falsch?
| |
Unter Android wird das genutzt um die system/vendor/boot/sonstnochwas-Partitionen in der secure boot Kette zu authentifizieren. Dynamisch aktualisieren lassen sich die Hashes aber afaik nicht.
|
|
|
|
|
|
|
|
|
|
|
|
Ich würde hier noch KiCad ins Rennen werfen. Bin ich zuletzt von Eagle hin gewechselt. Finde den Worflow dort sehr viel angenehmer und die Bedienung stimmiger.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
ich glaube nicht, dass es dafür irgendeine API gibt, die dir das liefern kann. ich bin mir gerade nicht mal sicher, dass dafür überhaupt irgendwas im kernel existiert.
| |
Ich fuerchte du hast recht. Ich habe mir mit inotify-* notduerftig helfen koennen.
Es sollte ein API dafuer geben 
|
|
|
|
|
|
|
|
|
|
|
ich hatte vor einiger zeit mal von nem PWM fan controller geredet, der ein bisschen mehr als nur lüfter an/aus kann bzw. diesen über temperatur steuern kann.
das mit dem kicad schein einigermassen zu gehen, auch wenn das UX mässig sehr gewöhnungsbedürftig ist und sich teils zwischen verschiedenen systemen unterscheidet. ansonsten nutzbar.
das hier ist der aktuelle stand des schaltplans und der bzw. ich benötige da mal ein wenig input von leuten, die wissen was sie tun. sowohl was den plan angeht, als auch - was wichtiger wäre - was die schaltung angeht.
es fehlen noch ein paar bezeichnungen und werte für teile, die ich noch nicht eingegeben habe, die sind aber auf nem zettel vermerkt. 
|
|
|
|
|
|
|
|
|
|
|
Das wird seit Anfang 2015 am CERN benutzt und von denen auch weiterentwickelt. Wenn du damit keine Lüftersteuerung bauen kannst, liegt es nicht an der Software
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
ich hatte vor einiger zeit mal von nem PWM fan controller geredet, der ein bisschen mehr als nur lüfter an/aus kann bzw. diesen über temperatur steuern kann.
das mit dem kicad schein einigermassen zu gehen, auch wenn das UX mässig sehr gewöhnungsbedürftig ist und sich teils zwischen verschiedenen systemen unterscheidet. ansonsten nutzbar.
das hier ist der aktuelle stand des schaltplans und der bzw. ich benötige da mal ein wenig input von leuten, die wissen was sie tun. sowohl was den plan angeht, als auch - was wichtiger wäre - was die schaltung angeht.
es fehlen noch ein paar bezeichnungen und werte für teile, die ich noch nicht eingegeben habe, die sind aber auf nem zettel vermerkt.
| |
Was mir da so auf die Schnelle aufgefallen ist:
- keine Abblockkondensatoren am ATMega/PCF
- vom MAX232 gibt es auch ICs, die mit kleineren Keramik- statt Elektrolyt-Kondensatoren auskommen
- Drain und Source am IRF9540 vertauscht - so leitet die Body-Diode, selbst wenn der Transistor sperrt
- das Tachosignal müsste AFAIR ein Open-Collector-Ausgang sein - die Diode im Signalweg ist dann falsch herum. Wozu soll die eigentlich gut sein?
- eine Schutzdiode über dem 7805 zwischen VI und VO in Sperrrichtung wäre angeraten
- wenn du die Lüfter auch im Betrieb umstecken willst, solltest du dir Gedanken über einen Schutz gegen Latch-Ups machen
|
|
|
|
|
|
|
|
|
|
|
Das ist so ein Chinaplan, der maximal schwer zu lesen ist.
| | | - eine Schutzdiode über dem 7805 zwischen VI und VO in Sperrrichtung wäre angeraten | |
Unnötig, weil die E-B-Sperrschicht erst ab ca 6.5 V in den Durchbruch geht, d.h. die Eingangsspannung muss nicht nur schneller sinken als die Ausgangsspannung, sie muss sogar negativ gehen.
| | | - das Tachosignal müsste AFAIR ein Open-Collector-Ausgang sein | |
Ist es. Hält mindestens 12 V aus, also einfach Pull-Up Richtung Vcc vom Controller.
Das PWM-Steuersignal ist TTL. Kann also direkt vom Controllerpin abgenommen werden.
| | | - wenn du die Lüfter auch im Betrieb umstecken willst, solltest du dir Gedanken über einen Schutz gegen Latch-Ups machen | |
Indertat, die Lüfterstecker haben auch keine voreilende Kontakte und nix, d.h. im Zweifel davon ausgehen, dass jeder Pin +- 12 V niederohmig abkriegen kann.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Rootsquash
Das wird seit Anfang 2015 am CERN benutzt und von denen auch weiterentwickelt. Wenn du damit keine Lüftersteuerung bauen kannst, liegt es nicht an der Software
| |
ich sagte nicht, dass man die software nicht nutzen kann oder das sie nicht funktioniert, sondern, dass die software gewöhnungsbedürftig zu nutzen ist.
UX => user experience
das software, die an forschungseinrichtugen entwickelt wurde, genau wie in-house software in den allermeisten fällen nicht sonderlich darauf getrimmt ist, dass sie gut genutzt werden kann ist jetzt nichts sonderlich neues. das liegt aber auch daran, dass die software dort nur von einer relativ kleinen anzahl von leuten produktiv genutzt wird, was dazu führt, dass die sich gegenseitig recht effizient helfen können oder geschult werden können.
die software hat einfach ein paar sehr komische eigenheiten. als beispiel nenne ich mal, dass sie sich auf scheinbar keinem system an die standards für mouse / touchpad input hält. man kann das zwar umschalten, aber das greift dann nicht für alle fenster, noch für alle anwendungsfälle, die die software so anbietet.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
Das ist so ein Chinaplan, der maximal schwer zu lesen ist.
| |
wie mache ich das besser?
|
|
|
|
|
|
|
|
|
|
|
|
Dinge mit Linien verbinden, nicht mit kleinen Kästen in denen Buchstaben stehen.
|
|
|
|
|
|
|
|
|
|
|
Ich habe damit eine Nixie-Uhr gestrickt, aber IIRC nicht das OS gewechselt dabei.
Aber wenn ich einen IC verchoeben habe, musste ich alle Traces per Hand korrigieren, was bei so eine Nixie-Uhr mit Schieberegistern und einzelnen Transistoren echt scheiße war.
|
|
|
|
|
|
|
|
|
|
|
Archlinux 2-1 ist bereit zur Installation.
Macht soweit fuer mich Sinn. Ich vermisse in diesem Zusammenhang aber base-devel, da ist weiterhin nur eine package group. Wenn ein neues Package hinzugefuegt wird, muss man die package group neu installieren.
|
|
|
|
|
|
|
|
|
|
|
mal so aus interesse, wenn ich die spannung und den strom der schaltung überwachen wollen würde, was müsste ich da machen?
soweit ich das bisher verstehe:
für die spannung eigentlich "nur" nen spannungsteiler, also zwei widerstände in serie und in der mitte abgreiffen und in nen ADC werfen?
um den strom zu messen bräuchte ich nen shunt der in in der leitung hängt und bei dem ich kurz davor und danach was abgreiffe, das geht dann in was?
wie berechnet man hier, was der shunt so als parameter haben sollte? bei der lüfter sache da oben würde mich primär die 12V versorgung für die lüfter interessieren, die können bzw. sollen jeweils maximal 1A ziehen dürfen.
letzteres bringt mich ebenfalls zu der frage, gibt es da ne einfache möglichkeit die einzelnen lüfter ports auf den strom von einem ampere zu begrenzen bzw da was bzgl. überlastabschaltung zu realisieren?
|
|
|
|
|
|
|
|
|
|
|
| | | für die spannung eigentlich "nur" nen spannungsteiler, also zwei widerstände in serie und in der mitte abgreiffen und in nen ADC werfen? | |
Ja
| | | um den strom zu messen bräuchte ich nen shunt der in in der leitung hängt und bei dem ich kurz davor und danach was abgreiffe, das geht dann in was? | |
Da PC-Anwendung kommt der Shunt in die +-Leitung, entsprechend entweder in-amp (instrumentation amplifier) oder current-sense amplifier (gibt es fertig, kann man auch diskret aufbauen). Beides übersetzt dir die Spannung über dem Shunt in eine massebezogene Spannung (wobei der CSA erstmal einen proportionalen Strom am Drain eines P-Fets ausgibt, der dann äußerst einfach wieder eine Spannung ergibt, indem man den Strom durch einen Widerstand gen Masse schickt).
| | | wie berechnet man hier, was der shunt so als parameter haben sollte? | |
Nach dem verfügbaren Spannungsabfall. Weniger Spannungsabfall am Shunt = schlechteres SNR, schwerer zu messen, braucht ggfs. Vierleitermessung. Mehr Spannungsabfall = Eventuell Problem für die Verbraucher, Verlustleistung.
Hier würd ich einfach mal so 200 mV oder so unter Volllast ansetzen.
| | | letzteres bringt mich ebenfalls zu der frage, gibt es da ne einfache möglichkeit die einzelnen lüfter ports auf den strom von einem ampere zu begrenzen bzw da was bzgl. überlastabschaltung zu realisieren? | |
PTC / "Selbstrückstellende Sicherung". Oder die Edelvariante: Smart High-Side-Switch. Die gibt es auch direkt mit einem Strom-Überwachungsausgang, programmierbarer Strombegrenzung, Anlaufstrombegrenzung, Fault-Pins usw.
Im Fehlerfall schalten die sehr viel schneller ab als jede Sicherung. Die Automotive-Dinger sind idR so ausgelegt, dass sie einen satten Kurzschluss am Ausgang (mit recht hohem dI/dt, was die eigentliche Schwierigkeit darstellt) bei Versorgungsimpedanz ~0 Ω überleben.
Man KANN die kaputtmachen. Aber es ist ziemlich schwer.
Edit: Und wenn man keinen High-Side-Switch findet, der den eigenen Anforderungen entspricht, kann man sich die auch zusammenbasteln aus einem High-Side-Switch-Controller (z.B. LM5069) und einem passendem MOSFET. Das ist dann aber tendenziell nicht ganz so solide, weil es halt einfacher ist einen MOSFET zu schützen, mit dem man zusammen auf einem Die hockt.
|
|
[Dieser Beitrag wurde 2 mal editiert; zum letzten Mal von csde_rats am 12.10.2019 3:08]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
in-amp (instrumentation amplifier) oder current-sense amplifier (gibt es fertig, kann man auch diskret aufbauen).
| |
ok, CSA wäre dann sowas wie die INA219 und co?
| | Zitat von csde_rats
| | | wie berechnet man hier, was der shunt so als parameter haben sollte? | |
Nach dem verfügbaren Spannungsabfall. Weniger Spannungsabfall am Shunt = schlechteres SNR, schwerer zu messen, braucht ggfs. Vierleitermessung. Mehr Spannungsabfall = Eventuell Problem für die Verbraucher, Verlustleistung.
Hier würd ich einfach mal so 200 mV oder so unter Volllast ansetzen.
| |
ok.
das bringt mich allerdings auch zu der, vermutlich, dummen frage, wie das mit der leistung des widerstands auszusehen hat?
12V bei ~4A wären ~48W an leistung bei den verbrauchern, muss der widerstand dann ebenfalls ~50W abkönnen oder wie berechnet sich das?
nach allem, was ich bisher dazu gefunden habe wäre die antwort darauf ja.
allerdings irritiert mich hier gewaltig, wie das dann z.b. bei ner grafikkarte mit nem smd bauteil funktionieren soll, wenn da mal so direkt 300-400 W durch wandern können.
ich hab da so die befürchtung, dass ich hier entweder irgendwas nicht weiss oder etwas sehr falsch verstanden habe.
| | Zitat von csde_rats
PTC / "Selbstrückstellende Sicherung".
| |
gibt es da irgendwas, auf was man da besonders achten sollte / muss?
|
|
|
|
|
|
|
|
|
|
|
| | | 12V bei ~4A wären ~48W an leistung bei den verbrauchern, muss der widerstand dann ebenfalls ~50W abkönnen oder wie berechnet sich das? | |
200 mV / 4 A = 0.05 Ω
200 mV * 4 A = 0.8 W
| | | ok, CSA wäre dann sowas wie die INA219 und co? | |
Jo, das ist dann das Komplettpaket aus in-amp samt PGA, ADC und I2C Interface.
| | | gibt es da irgendwas, auf was man da besonders achten sollte / muss? | |
Da liegt ein Fakor 2-3 zwischen Dauerstrom und "Auslösestrom". Die Dinger haben idR einen nicht ganz zu vernachlässigenden Widerstand. Das ist ein rein thermischer Mechanismus und hat entsprechende Schmelzintegrale und Abhängigkeit von der Umgebungstemperatur (Faktor 3-5 über die Industrial Range), bei Nenn-Auslösestrom dauert das zwischen 1-10 Sekunden (steht im Datenblatt). In erster Näherung: Verdoppelung des Stroms ~verzehntelt die Auslösezeit.
e: Auslegebeispiel
Dauerstrom 1 A bei 50 °C Umgebungstempertur. SMD weil kleiner. Wir schlagen den Littelfuse-Katalog auf und wählen MINISMDC150F/24-2, weil ist nicht das kleinste Bauteil, was das aushält (kleiner=empfindlicher). Bei 20 °C hat das Ding allerdings schon 1.5 A Nennstrom. Bei 8 A kann es maximal 1.5 Sekunden dauern, bis das Ding abschaltet.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 12.10.2019 11:13]
|
|
|
|
|
|
|
|
|
| | Zitat von csde_rats
| | | 12V bei ~4A wären ~48W an leistung bei den verbrauchern, muss der widerstand dann ebenfalls ~50W abkönnen oder wie berechnet sich das? | |
200 mV / 4 A = 0.05 Ω
200 mV * 4 A = 0.8 W
| |
das heisst dann also, dass man hier nicht die versorgungsspannung zur berechnung heranzieht, sondern "nur" den spannungsabfall und darauf dann die berechnung für die benötige leistung des widerstands aufbaut?
könntest du das vielleicht erklären, warum da nur der spannungsabfall relevant ist und warum z.b. die leistung der verbraucher bzw. die spannung die durch den widerstand fliesst, dafür "ignoriert" werden kann?
das leuchtet mir momentan noch nicht so ganz ein.
ich bin bisher immer davon ausgegangen, dass die widerstände auf basis des verbrauchers dahinter dimensioniert sein müssen, also entsprechend auch der watt leistung.
in dem konkreten fall würden die dann halt unverhältnismässig gross werden... da denke ich dann halt immer an die ganzen tollen geräte die nahezu ausschliesslich mit smd bauteilen gefertigt werden und wo dann so ein shunt ein paar millimeter gross ist. das passt dann halt irgendwie nicht mehr so ganz zusammen. 
| | Zitat von csde_rats
| | | gibt es da irgendwas, auf was man da besonders achten sollte / muss? | |
Da liegt ein Fakor 2-3 zwischen Dauerstrom und "Auslösestrom".
| |
bedeutet also, dass die für diese anwendung eher nicht so sonderlich gut geeignet sind.
|
|
|
|
|
|
|
|
|
|
|
| |
das heisst dann also, dass man hier nicht die versorgungsspannung zur berechnung heranzieht, sondern "nur" den spannungsabfall und darauf dann die berechnung für die benötige leistung des widerstands aufbaut?
könntest du das vielleicht erklären, warum da nur der spannungsabfall relevant ist und warum z.b. die leistung der verbraucher bzw. die spannung die durch den widerstand fliesst, dafür "ignoriert" werden kann?
das leuchtet mir momentan noch nicht so ganz ein. | |
Ein Widerstand ist (in guter Näherung) ein Zweipol, d.h. für das Verhalten vom Widerstand ist nur wichtig, welche Spannung über den Klemmen anliegt, und welcher Strom durch die Klemmen fließt. Bei einem 0.05 Ω Widerstand, der von 4 A durchflossen wird, liegt also eine Spannung von 0.05 Ω * 4 A = 200 mV über den Klemmen an. Entsprechend gibt der Widerstand 4 A * 200 mV = 0.8 W in Wärme ab.
D.h. dein Strom-Shunt hat keinerlei Ahnung, welche Versorgungsspannung du da verwendest, schlicht, weil sie nicht am Widerstand anliegt.
| | | bedeutet also, dass die für diese anwendung eher nicht so sonderlich gut geeignet sind. | |
Um Kabel- und Steckerbrände zu vermeiden, reicht's, aber das war's dann im Grunde auch schon. Halbleiter kann man idR nicht mit Sicherungen schützen, und der Überstromschutz von z.B. einer 12 V Schiene eines PC-Netzteils spricht bei modernen Netzteilen äußerst schnell an. Ich hab da mal so ein paar Tests mit Halogenlampen gemacht, die Dinger können die OCP von einem ATX-Netzteil triggern ohne das du einen sichtbaren Kontaktfunken hättest. (Das sind Stromspitzen im Bereich von ~20-30 A bei einer 50 W 12 V Halogenlampe).
Halbleiter schützt man, innerhalb gewisser Rahmen, mit mehr Halbleitern. Das heißt dann z.B. für einen Leistungsausgang, dass man eine sehr schnelle Stromregelung hat (schneller als das dI/dt, also die Induktivität, lastseits), die dann von einer SOA-Überwachung, Under-Voltage/Over-Voltage-Lockout etc. gesteuert wird. So sind effektiv alle Smart-Switches aufgebaut.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 12.10.2019 18:32]
|
|
|
|
|
|
|
|
|
| | | Hydra: A framework that simplifies development of complex applications (fb.com) | |
Genug Hackernews für heute.
|
|
|
|
|
|
|
|
|
|
|
|
Ist natürlich ein blöder teaser, aber die lib klingt gar nicht so unnützlich.
|
|
|
|
|
|
|
|
|
|
|
tmutil 
Ich vermute mal Apple meint damit trashmanagerutil?
|
|
|
|
|
|
|
|
| Thema: Der Linux-Thread 100 != 0x24 ( Ein Kernelupgrade später... ) |
|
