Félreértesz, itt nem az USB és Wifi biztonságának összehasonlításáról van szó! Hanem a böngészőbe épített közvetlen hardware elérés és a wifi biztonságosságáról. Ha így nézzük annyira már nem egyértelmű a dolog.

Amúgy szerintem a wifivel nincs gond, a WPA2 is csak elméletileg törhető, a gyakorlatban pedig csak akkor, ha valaki bekapcsolva hagyja az egyszerű VPS (pin kódos) azonosítás lehetőségét, mert az a gyenge láncszem. Annak idején kipróbáltam, hogy fel tudom-e törni a saját (akkor még TPLink) routerem wifijét. BackTrack linux + néhány netes leírás alapján, a VPS-t sikerült megtörni, és ebből valahogyan visszafejtette a WPA2 jelszót is a program - de ehhez is egy teljes napig kellett futnia 3 különböző programnak a linuxon. Kikapcsolt VPS esetén ugyanez kb. párszáz évig tartana - kivéve ha ez alatt párszor jelszót cserél valaki, mert akkor valamivel tovább...

Apósom fingreszelésnek hívja... Amúgy meg általában azok használják a "kocka" kifejezést, akik az adott témához nem értenek (magyarul műszakilag nulla tudásúak), és egy csavarhúzónak sem tudják melyik végét kell megfogni, ezért megpróbálják a másik embert lekicsinylő módon előadni, a valójában információtartalom nélküli véleményüket a témában. De amúgy elismerem, ehhez (is) tényleg kissé kockának kell lenni (meg persze a magnetométerhez is), de inkább vagyok kocka, minthogy együtt bégessek a birkákkal

Igazándiból simán lehetne beszédfelismeréssel is, manapság már nem akadály.

Akkor mindkét kézzel lehet dolgozni, például:
- Páka, fűtsél.
- Igen uram. Hány fokra?
- 385,2.
- Rendben uram.
- Miért nem meleg a hegy?
- Nem azonosította magát, helyezze a tenyerét a leolvasóra.
- De akkor el kell engednem mindent, és kezdhetem előről.
- Az ön biztonsága az első, ameddig nincsen azonosítva, nem fűthetek.
- Hogyan másként tudom azonosítani magam Ő páka, anélkül hogy a tenyeremet a leolvasóra helyezném?
- Billentyűzze be a 8 jegyű PIN kódot a vezérlő számítógép konzolján.
- Elfelejtettem a PIN kódot.
- Akkor hívja fel a helpdesket, ehhez szüksége lesz a regisztráláskor megadott felhasználói névre és a 8 jegyű PIN kódra.
- Dehát pont az a baj, hogy nem emlékszem a 8 jegyű PIN kódra.
- Az előbb még azt mondta, hogy forrasztani akar, és nem PIN kódot kér. Kérem döntse el.
- Forrasztani.
- Helyezze a tenyerét a leolvasóra.
- Nincs már lehetőség?
- Fáradjon be az ügyfélszogáltunkra, ott lehetősége van DNS minta alapján személyes azonosításra.

A lehetőségek száma ne(ke)m 8 (90 fokkal elforgatva)?

Sziasztok,
Hát a téma elment egy olyan irányba amire nem is gondoltam, de mindenképp tanulságos volt.
Ellenben haladtam a projectemmel. Megalapoztam a RISC-V átállást. A több csatorna ADC konvertálását meg kellett oldjam és a végeredménnyel elégedett vagyok. Scan módban DMA -val ciklikusan egy bufferbe kitöltetem több csatorna értékét és abból képzett átlaggal dolgozom (nyilván csatornánként). A PWM -el is voltak megoldandó feladatok, mert az alternatív pin használatot is ki kellett tapasztaljam. A választott mikrovezértlőm egy SOP16 CH32V003 MCU, aminek így nincs olyan sok használható lába, de sikerült végre megoldjam hogy két időzítővel összesen öt csatornán tudok végre PWM-et előállítani (3 az RGB-nek, 1 a MOSFET meghajtásra egy meg talonba).
De lenne egy kérésem is. Megjött a JCB handle amit rendeltem. Nagy elánnal ugrottam neki, de rögtön azzal szembesültem, hogy zárlatot csinálok és a teszt tápom védelme leold.
Tapasztaltam ilyen T12 használatakor is, de itt jóval kisebb a fűtőelem ellenálása, így jelenleg 10%-os kitöltéssel tudom csak meghajtani. Ellenben így is sikerült forrasszak, méghozzá a teszt firmware-emmel, ami PC-ről szabályozta a fűtést. Nekem bevált ez a megközelítés, mert ahelyett, hogy C-ben írtam volna a teszt kódot amit lefordítok, majd rátöltöm az MCU-ra és elindítom, majd megtapasztalom, hogy elhal, csak a gépen kellett módosítsak a kódon és pár perc alatt már meg is volt az a PWM kitöltés amivel még hajlandó volt működni. Utána két perc alatt írtam egy egyszerű szabályzást és már forrasztottam is.
A kérdésem, hogy van ötletetek arra, hogy a JBC C210 -es heggyel hogyan lehet egyenáramról forrasztani úgy hogy ne egy ~10A -es táppal kelljen? Nekem 19,5V 3,3A -es laptop tápom van erre a célra, de az mint írtam csak 10% -os kitöltéssel tudja jelenleg meghajtani, különben leold.
Dióda van a kimenetnél.

Az a táp akkor kb. 64W-os. Ekkora teljesítménnyel azért már lehet jól forrasztani, csak ugye nem passzol a táp a fűtőbetét ellenállásához. Viszont nem írtad mekkora PWM frekvenciája, mert ha ez elég nagy, akkor az áram ki tud "átlagolódni" a táp kimeneti pufferén, de ha nem, akkor viszont már az elvárhatónál kisebb teljesítmény esetén leold táp. Segíthet ha lehetőleg minél nagyobb PWM frekvenciát választasz, és raksz további nagykapacitású kondenzátort (n*1000....10000uF) a táp kimenetére, hogy kissé elsimítsa az áramot. Persze még így is limitálni kell majd a maximális PWM értéket, de már egy akkora értéken, ami bőven elég ahhoz, hogy gyorsan tudjon fűteni a páka, és jól lehessen vele forrasztani.

Egyszerűbb megoldás lehet egy erősebb táp is. Illetve valószínűleg a meglevő táp is tuningolható kicsit nagyobb áramra, úgyis csak rövid időre kell nagy áram - addig meg kibírja.

Képzeld el ha forrasztás közben pedig még reklámozna is, pl. a legújabb hüvelygomba elleni szerre akarna rábeszélni mert ha két dobozzal veszel, akkor kedvezményes kupont kapsz forrasztóón vásárlásra is.

Huhh, köszi a gyors választ.
Pont a te oldaladon láttam, hogy 1Khz -es frekvenciával kezdted, majd később az megvátoztatható lett. Én ugyanúgy dilemmában voltam, hogy most mit válasszak, így a te értékeddel próbálkoztam, azaz 1kHz.
Köszönöm még egyszer, próbálkozom a frekvencia módosításával (azt is beleteszem én is paraméternek a protokollba). A kondenzátor is egy jó ötlet, azt is keresek hozzá.

ok, meglesz. Az igazsághoz hozzátartozik, hogy a tesztek alatt egy python kódból küldöm ki és fogadom a JSON-öket és a vezérlés is innen megy, nem browserből. De van egy régi poén ami mindig a fejembe van, ami a linuxos ATM-ről szól. Éppen ezért egy karakteres, inputokkal dolgozó konzolos alkalmazással forrasztottam fel a lábakat a szintén a mai postával érkezett RP2040-re.
keep 400 + ENTER után a 400 -at tartja, halt + ENTER-re pedig leáll
és persze működik a fel/le nyílakra a legutolsó parancsok között lépked

Sziasztok,
Haladtam a projecttel (így munka után), köszönöm Skori-nak, mindkét tippje jól jött.
Most még csak egy nagyon szimpla megjelenítés egy nagyon "buta" vezérléssel.
Készült pár diagramm (realtime). Én a T12-höz voltam szokva, ez a JBC nagyon gyorsan felhevül.
A képek értelmezéséhez. Egy időegység 100ms, lehetne rövidebb is, 576000 -es bitrátát állítottam ami így 57600 byte/s ~500 kérés válasz is lehetne mpenként, így ez nem szűk keresztmetszet.
A WCH Link-nek van soros port vonala is, végülis azt is kitapasztaltam, most azzal teszteltem, ezért a CDC elnevezés.
Minden érték RAW, nincs konvertálás. A piros vonal a 10bites ADC a szaggatott pedig a PWM kitöltés amit 8 bitre csökkentettem.
A szürke gombok az elérni kívánt érték a kék gombok pedig a max kitöltés.
A kívánt érték eléréséhez közeledve csökkenti a PWM kitöltést 40% majd 70% -al.
Ez a vezérlés a T12 esetén még elég is lehet, ellenben a JBC -nél durva ugrásokat eredményez.
Természetesen lesz PID vezérlés is implementálva és majd azzal is finomhangolok, csak először rendbeteszem a megjelenést és a működést, mert csak összedobtam, mert érdekelt, hogyan fog teljesíteni.
Több táppal is kipróbáltam, ezt a grafikont egy 12V 3A-es táppal készítettem, de próbáltam USB PD-vel is.

A 210-es JBC hegy tényleg rettenet gyors, a T12-nél kb 10x gyorsabb! 1 sec alatt kinyírhatod 24V-on egy véletlenül elkefélt vezérléssel!! Csak óvatosan....

A 100ms időegység csak az ide berakott adatokra vonatkozik? A JBC 210-es pákahegy rendes szabályozásához ennél sokkal rövidebb időközzel célszerű mérni, és beavatkozni. Gondolom ezen majd módosítasz. Javaslom, hogy a fejlesztéshez készíts valamilyen páka-szimulátort, ne élesben tesztelj mindent, mert nem olcsó egy 210-es pákahegy.

Sziasztok,
Igen, köszönöm a hozzászólásokat. Nem volt tapasztalatom a JBC-vel kapcsolatban a T12-ővel volt csak, úgy indultam neki, hogy ami ott jó volt itt is jó lesz, de már látom, hogy nem úgy van és teljesen igazatok van.
A JBC heggyel kapcsolatban, köszönöm az aggódásokat, már túl vagyok a kiégetésen.
Nem programhiba hanem kiváncsiság okozta, de láttam vörösen izzani. Fájna is a szívem, ha nem egy kínai klón lenne 1000 Ft-ért (igazából 3000 volt 3 darab).
Este még nem hagyott nyugodni a dolog, mert elég lépcsőzetes volt a vezérlés (ugye én a T12-höz szoktam ott szinte lanykás a meredekség), először arra gondoltam, hogy a hőtehetetlenség, de közben rájöttem, hogy a vezérlés volt rossz.
Itt is úgy van mint T12 nél, hogy vagy fűtünk vagy méricskélün és én ritkán mértem, hogy fűthessek.
Most átírtam a firmware-t ( ha lehet ilyen fellengzősen nyilatkozni a kódomról ), mert 300 ms -ig fűtöttem és ez volt a lépcsőzés oka. A kód még a régi mért érték alapján dolgozott pedig már nem kellett volna a fűtés.
Változtattam a fűtési időn (vagyis a mérési időközön másik megközelítésben), de így meg nem volt olyan látványos a felfűtés.
A megoldás az lett, hogy bevezettem egy mód választót a mérési időre, amit szintén a brózerből vezérlek. A vezérlésben pedig ha még messze a mért a beállítottól, akkor ritkábban mérek (felfűtés mód), ha pedig közelebb van akkor sűrűbben (mérési mód).
Így most a mellékelt képen a jelenlegi állapot. Van még mit csiszolni, de láthatóan jobb .

Gondolj már bele...ha 300msec a fűtés alapegysége, az alatt simán tud 100C-t is emelkedni egy C210-es hegy hőmérséklete!! Hogy lesz ebből használható szabályozás? Sehogy!
Illene legalább +-5C-on belül tartani a hegy hőmérsékletét, és már ehhez is sokkal gyorsabb szabályozás kell...pedig hol vagyunk még egy pontosnak nevezhető +-1..2C- vezérléstől?!
Az én állomásomban kb 3msec a mérési gyakoriság. Ez kb fok pontosságú lekövetést ad... Talán nincs erre szükség egy jól paraméterezett PID szabályozónál, de nem hiszem hogy ennél sokkal ritkább elég lehet egy jó vezérléshez ennél a hegynél....

Gondolkoztam én is, hogy ne fix a mérési időközzel dolgozzak, de végül elvetettem, mert két pákát kell egyszerre kezelni (bár egyfajta ciklus-átugrás lehetőségén azért szintén elgondolkoztam).
Ami miatt mégis elvetettem:
- nem egészen 2msec alatt, 2x 128db mintát tudok venni, azaz ennyiszer mér hőmérsékletet ez idő alatt. Ez még rövid ciklusidő esetén sem okoz számottevő veszteséget a kitöltési tényezőből.
- eleve 22V körüli tápot használok, ami több mint amivel a gyári állomás fűt, tehát még a kitöltési tényező veszteséggel együtt is gyors lesz.
- a 210-es pákahegy felfűtése így is 1sec körül (vagy az alatt) van, szóval belefér... a 245-ös pákahegyek zöme is kb. 6 másodperc alatt felfűt - még az sem vészes. A 150°C-os standby állapotból pedig "egy pillanat alatt" üzemkész bármelyik páka.

Mivel nálad eleve korlátozni kell a kitöltési tényezőt, a jelenlegi hardver esetében, így nem igazán látom értelmét a mérési idő miatti, fűtés kihagyásból eredő, max. PWM kitöltési tényező csökkenésével foglalkozni.

Elgondolkoztam rajta egyébként, hogy (valmikor később, ha ráérek ) az állomásom menüjébe én is beteszek egy beállítható PWM limitet, hogy nagyobb tápfesz, és/vagy mondjuk gyengébb táp is használható legyen.

mint írtam nem voltak tapasztalataim C210-el, csak T12-vel ahol ez az idő elég volt. Most már vannak így most átgondolom.
A meghajtáshoz pedig 12V 2A-es tápont használok most, ami csak kisebb PWM kitöltést enged, így nem történnek olyan gyorsan a dolgok, Vagyis épp az hogy így is gyors, így még átgondolom.

a 3ms mérési gyakoriságra én azt tudom mondani, hogy más oldalon olvastam, hogy 5ms -ot vár fűtés kikapcsolás után, hogy ne a fűtés feszültésgét olvassa vissza hőelem feszültség helyett.
Szóval 3ms -ba hogy fér bele, hogy kikapcsolod a fűtést, kiolvasod többször (én pl a legtöbb ciklusig tartó ADC mérést állítottam minden kiovasott csatornára, mivel scan mode-ban több ADC-t olvasok) és a kiolvasott értékeket átlagolod?
Az én ADC módom
- 241 cycles ADC csatornánként, ez így ~50khz (0.02 ms) mert van az ADC-n egy 2-es DIV
- 3 csatornát mérek (még lesz egy a belső referencia feszültésgre)
- DMA-val egy bufferbe írom ciklikusan ringbe, folyamatosan a mérési ciklus alatt ami 10ms
- 8 mérésre van a buffer beállítva csatornánként
így a 10ms után közel ~100 mérést végez (DMA interrupt-ra tettem egy számlálót) amiből az utolsó 24 van a bufferben. A három csatornára leátlagolom az értékeket és nekem az a mért értékem.
Olvastam angol nyelvű oldalon, hogy valaki még a bufferen végigmegy és az átlaghoz képest 10% -os eltérésű értéket hibára veszi és megismétli a mérést, de én eddig nem tapasztaltam kiugró értéket.
Persze lehet valami nagy órajelű MCU-t használsz , nekem jelenleg 48Mhz, de akkor is mi van a fűtés kikapcsolási utáni várással és a 3ms mérésközben akkor mennyi idő ameddig a fűtés be van kapcsolva?
A PWM nálam 100KHz-re van osztva, de ez bitenként 100KHz, mivel 255 az autoreload, ezért 1 PWM teljes ciklus 2.5ms ha jól számolom.

Hogy ki mennyi várakozásra kényszerül a fűtés kikapcsolását követően az messze a konkrét konstrukció függvénye! Emlékeim szerint nálam 12.5kHz a PWM periódusa, ezzel szinkron van indítva a megfelelő időben a mérési procedúra, ahol csak 4-et mérek gyors egymásutánban. Átlagolás után némi szűrés jön. A fűtés leállítása és mérés indítása között kb 150usec idő telik csak el. A teljes mérés idejére már nem emlékszem...
Nyilván így nem lehet(átlagban) a 100% kitöltés elérni, de mivel 24V-os a táp, így azt sosem szabad amúgy sem megközelíteni, még felfűtéskor sem! Ez amúgy is korlátozott, megadható hány W-al fűtse max a hegyet, mert nem fog neki jót tenni, ha 1-2sec-nél gyorsabban akarjuk elérni a 3xxC hőmérsékletet...
A mikrovezérlő nálam egy 103-as STM, kicsit túlhúzva(nem a vezérlés igénye volt ez, hanem a grafikus megjelenítés határait feszegettem)

Esetemben a PWM kikapcsolása után kb. n*10µs várakozás a tranziensek lezajlására, utána termoelem erősítők bemenetének bekapcsolása, majd további kb. 100us várakozás míg a termoelem erősítő kimenete beáll a megfelelő értékre (mivel az erősítő sávszélessége véges). Utána indul az ADC. Az első néhány mintát eldobom, (tapasztalat szerint az ADC első néhány mérése sokkal gyakrabban hibás, mint a további minták) majd utána további 128db mintából számolom a hőmérsékletet. Ezután az erősítők bemenetét ki lehet kapcsolni (kikapcsolt állapotban egy köztes értékre áll be, hogy következő méréskor ne egy szélső állapotból induljon az opamp beállása), majd a PID számolása után indítható a PWM az új értékkel.
A többi mérés (3.3V, 22V tápfesz, hőmérséklet a dobozban) simán mehet a PWM futása közben is.

Az erősítők bemenetét eredetileg csak a túlvezérlés elkerülése miatt kapcsolgattam, (túlvezérlés esetén a beállási idő, megnövekedne egy további feléledési idővel), de ez a megoldásom, a 210-es páka esetében tulajdonképpen jól jött, mert így a mérőbemenet problémamentesen összeköthető volt a PWM kimenettel. Azok a megoldások, ahol pl. csak dióda védi az erősítő bemenetét jól működnek ugyan, de a túlvezérlést nem kerülik el, így általában hosszabb beállási időkkel kell számolni.

Szegény Minifor páka tudta volna ezt, felkötötte volna magát a saját drótjára..

A Minifor esetében digitálisnak esetleg a ki/be kapcsolását lehetett nevezni. a hőmérséklete meg csak saccolható volt. Amúgy a leírtak talán bonyolultnak tűnnek, de valójában ez csak néhány sor utasítás a programban. Persze a Minifor akkor is felkötné magát, ha megmutatnád neki, hogy manapság milyen SMD alkatrészeket, és milyen sűrűségű elrendezésben kellene beforrasztania Viszont a csehszlovák pillanatpákám, az simán.... Igaz ott a hardveres PWM-et biologiai processzor vezérli, széleskörű optikai adatelemzés mellett.

Nálam a HW tuningolása még egy későbbi rész, de mindenképp a te kapcsolási rajzod lesz az elősdleges amiből kiindulok. Plusz van egy Unisolder elnevezésű github project, az is egy komolyabb megközelítés. Jelenleg nálam még az LM358-as sokfelé fellelhető opamp-os kapcsolás van. Márcsak azért is, mert az alapból elbírja a nagyobb feszültséget a VDD-n felül, de azért egy diódával védve van.
Ami még a közeljövő problémája, hogy megoldjam a pákafelismerést. Az unisolder readme-ben szépen leírja, hogy milyen ellenállás értékek melyik pákát jelentik.

Több dologban is haladtam. Először is a kezdeti összetákolt html js-t átírtam egy reactive-ra (én a vue-t favorizálom).
Belekerült egy kódszerkesztő és egy terminál, plusz a diagramot is átírtam és megoldottam, hogy az eddig lekezelt soros portok között lehessen váltani (persze kapcsolódás előtt csak)
A korábbi vezérlésem még mindig nagyon alap volt, az látható is volt, hogy kilengett rendesen.
Volt még egy komoly probléma benne, hogy ha a hiba negatív volt (túlfűtött) akkor lekapcsolt a vezérlés, így a következő mérésnél átesett megint pozitív hibába és így oszcillált. Természetesen erre lenne megoldás a PID.
Próbáltam letudni könnyen, gondoltam veszek egy működő PID kódot és átírom JS-be és meg is vagyok.
Az első probléma amivel találkoztam, hogy nagy hiba esetén az integrál tag nagyon elmegy, de ezt írták is egy forrasztásos oldalon, hogy ne ezzel fűtsünk fel, hanem már csak a közeli értéknél térjünk át (pl addig 0-ás Ki-val)
A másik, hogy egy jól működő P az alap, majd az I-vel kisimítani és a D-vel finomítani.
Ezután végeztem egy olyan vezérlést, ahol egy csúszkán léptetgettem a PWM kitöltést és néztem, hogy kb. milyen hőmérsékletre áll be. Azt gondoltam majd egy exponenciáis függvénynel kell meghatározzam a nulla pontom, de egész lineáris lett.
Lett egy képletem, ahol a beállított érték 15%-a PWM-em, amivel a beállított érték tartható. Azután a hibához még hozzáteszem a beállított érték arányát, abból kiindulva, hogy nagyobb hőmérsékleten nagyobb beavatkozás szükséges.
Ez már egy jóval kiegyensúlyozottabb vezérlést hozott. Ehhez jön majd még az I és a D

tettem bele minimális ID-t a P már megvolt.
Ami tanulság. Fontos a jó P vezérlés, amit korábban csináltam az már elég jól viselkedik, de az csak a 12V-os betápomra és arra a hegyre igaz ami épp benne van.
A 12V-os 60% -os max PWM-re elégséges a 100ms -es mintavételezés, de ez a hegy többet tud, ha 20V-al és erősebb PWM-el hajtom meg, ott már ez édes kevés (ezt többen írtátok is, de mint írtam én a T12-höz voltam szokva).
Bevált nálam az eltérő ADC mintavételezés. Felfűtés alatt lehet ritkábban, közelítve a beállítotthoz pedig sűrűbben mérni kevesebbet beavatkozni.
Fontos mérni a bejövő tápot, mert változik a 0 hibapont PWM értéke magasabb feszültségnél alacsonyabb lesz jóval.
A WEBUSB nekem bejött. Ugyan még csak ismerkedésben vagyok, viszonylag gyorsan akartam eredményt elérni, ezért alap dolgokat használtam csak. Érdemes jobban elmélyedni benne.
Most már körvonalazódik bennem egy project, ami lehet itt is jobb fogadtatást kap mint ez
Egy USB PD-s T210 vezérlő kijelzővel, ahol MCU végzi a vezérlést és ha gépre kötik, akkor nem lehet vele forrasztani, de a beállítások és FW frissítés elvégezhető WEBUSB-n keresztül. Így akkor nem kell menüben lépkedni a paraméterek beállításához, hanem egy HTML-ben megjelennek a paraméterek és elvégezhető akár azok megváltoztatása is.

Ne vedd magadra,de továbbra is úgy látom, hogy ebben a projektben a webusb inkább csak egy teher... Ha webfelületen akarnám konfigurálni, paraméterezni, és/vagy frissíteni a szoftvert, akkor ESP8266 vagy ESP32 lenne a megoldás. Mindkettőnek viszonylag erős a processzora, és a forrasztóállomás funkciók mellett is könnyedén beleférne wifi webszerver funkció, ami a frissítéstől kezdve, minden beállítást könnyedén megvalósíthat. Persze értem, neked a webusb használata lenne a lényeg - csak itt feleslegsnek tűnik. A wifi egyúttal tökéletes leválasztást is megoldja, és egy webfelületen simán elférnének pl. hardver konfig bellítások is. A webfelületen beállíthtóvá tennék olyanokat is pl., hogy konfigurálni lehessen melyik gombnak mi legyen a funkciója. Így a hardverre "ahogy sikerül alapon" is beköthetném a ledet, nyomógombokat, enkódert, stb... és a webfelületen pár kattintással beállíthatnám, hogy minden jól működjön... Itt lehetne a PID paramétereket menüben,. webfelületen is állítani, akár sokféle egyedi pákahegyhez is optimalizálva. Igazából kissé komolyabb algoritmussal még a PID beállítást is lehetne automatizálni, ami néhány forrasztás alatt megtanulhatná, hogy az adott pákahegyhez milyen beállítás kell. Mondjuk ennyire nem akartam "túltolni" a dolgot, de ha akarnám, akkor ezek lennének a fő irányok. De a felhasználók zöme (én is) nem akarja folyton az állomás menüjét piszkálgatni, csak forrasztani, és esetleg hőmérsékletet állítani - az állomás meg csak tegye a dolgát, a többi nem érdekeli. Tehát nem kell csicsás kijelző sem (csak valami alap), mert a többségnek a piros/zöld led is bőven elegendő infót ad.
A saját állomásomba is elsősorban mások kedvéért került bele a 210-es pákahegy kezelése. Persze forrasztottam párat 210-es pákával, tényleg jó, főleg apró dolgokhoz, de nem jobb annyival a 245-ösél, hogy ne lennék meg nélküle. Másképp fogalmazva, nekem a 245-ös mindene is elég, ebből már sokféle hegyet bevásároltam, a 210-es pákához csak két pákahegyem van, és lehet, hogy ez már így is marad.

Sziasztok!
Kicsit ugyan lassan de elkészült a forrasztóállomásom. Skori kolléga állomástervei alapján készült. Néhány önszivatás és elcserélt alkatrésztől eltekintve egyből indult az áramkör. A dobozolás nem a legkedvesebb foglalkozásom, de sikerült bezárni a készüléket. Még két pákatartó elkészítése hátra van akkor lesz teljes a készlet. Két pákát kötöttem rá, az egyik egy eredeti JBC nyél eredeti heggyel, a másik egy Aliról rendelt nyél és hegy. Még hosszan tartó tesztet nem tudtam csinálni mert csak pár napja készült el, de nagyon jók a tapasztalatok. Kaptam javításra egy smd panelt ennek a pákaállomásnak hiányában az IC kukázható lett volna. 170 EUR-os alkatrészről van szó.
Nagyon köszönöm a lehetőséget és a tervezést, kiváló hasznos szerszáma a műhelynek.
Üdv: Gábor

Jól néz ki, milyen enkódert tettél bele?

Szia!
A lomexben vásároltam nyomógomb enkóder egyben. Bővebben: Link
Üdv: Gábor

Köszönöm a tippet!

Szia! Az állomás a jövőben készült? Vagy az elején nem a dátum van?