Mi érkezett?

Folyamatosan rendelgetek mindenféléket különböző helyekről, csak sokszor nem írok róluk.
Itt van három dolog ami valamilyen szempontból érdekes.
Nemrég elkezdtem dolgozni a műszereim PC intergrációján. Ez egyre fontosabb kezd lenni, ahogy olyan méréseket forgatok a fejemben amelyekhez erre szükség van.
A műszereim változatos csatolókkal rendelkeznek: USB, RS232, GP-IB, Ethernet. Az első háromról beszélve, mire a PC-hez érünk, ígyis-úgyis USB lesz belőlük. Ehhez pedig USB portra van szükség. Sok USB portra.
Tehát rendeltem egy USB hub-ot az AliExpress-en.
Remélem, 16 port elég lesz:

Folytatva a műszer témát: Ahogy látom, mindenki tényként kezeli, hogy a méréstechnika folyamatiránytása a National Instruments LabView termékén alapul. Ezt a szoftvert sok mindenre használják. Még a Lego is ezt használja a Mindstorms robotok programozására.
Jó sok ideje leginkább ingyenes és nyílt forráskódú szoftvereket használok, ami meg ilyen formában nem elérhető, azt megveszem.
A LabView mint olyan egy horrorisztikus árcédulával rendelkező szoftver. Csak most vettem észre (te már biztosan tudod), hogy az NI évekkel ezelőtt elérhetővé tett egy Home Bundle verziót. Igen, ez nem a legutolsó kiadás, igen, ez nem használható profit szerzésre, csak otthoni használatra. Viszont $50-ba kerül ami egy elkötelezett hobbista által kifizethető. Tehát én beszereztem:

Remélem segíteni fog automatizálni a méréseimet.
Elindult egy promoció/verseny a Microsoft és az Avnet szervezésében
(https://www.element14.com/community/docs/DOC-92683/l/sensing-the-world-challenge). Az Azure IoT-hez való kapcsolódásról szól.
Ráadásul van egy MAPS előfizetésem, tehát van havi $100 szabad felhasználású keretem az Azure-ban.
Az elmúlt 6+ évben AWS gyerek lett belőlem. Úgy érzem, hogy ez a verseny egy jó lehetőség, hogy szélesítsem a látóköröm és egy kicsit többet tanuljak meg az Azure-ról.
Tehát megrendeltem az ingyen kitet. Tegnap meg is jött:

Még ötletem is van, hogy mire akarom használni.

GP-IB 3.

Több mint két hónap telt el mióta írtam a GP-IB adapter projectemről.
Ebben a két hónapban sok minden történt:
Hardver:
Átterveztem a penelt egy picit (v1.1). Az új verzió egy picit trükkös. Eredetileg anya típusú csatlakozót használtam, ami nem ideális, miután nem lehet közvetlenül a műszerekre csatlakoztatni, csak kábellel. Az ok: elsőre csak ilyet találtam emberi áron. Később tovább keresgéltem, és mostmár van apa típusú csatlakozóm. Nem akartam túl nagy energiát belerakni az újratervezésbe, így csak egy opciót adtam hozzá, hogy az USB csatlakozó átfordítható legyen a panel másik oldalára.
Így, ha a panelt anya GP-IB csatlakozóval ültetjük be, mindkét csatlakozó az alkatrész oldalra megy, ha pedig apa csatlakozóval akkor mindkét csatlakozó a forrasztási oldalra megy.
A panelt még nem rendeltem megy, mert más projectemmel akarom kombinálni.
Git:
Átszerveztem a project repoját. Van hozzá publikus és privát repóm. A publikus a project megosztását szolgálja, a privát a munkát rajta. Jelenleg a publikus repóban csak a hardver tervek vannak (több dolog jön még). A tervek keresztűl mentek a szép, új KiCAD csomagolómon. Ez legalább a kapcsolási rajzot olvashatóvá teszi bárkinek. Cím: https://gitlab.com/suf/suf-electronics-gpib
Szoftver:
A szoftver téma kicsit zavaros lett.
Vannak bajaim az eredeti forráskóddal:
1. Az eredeti licensz "inkompatibilissé" teszi a szoftvert a saját hardveremmel
2. Minél többet olvasom a forráskódot, annál kevésbé szeretem. Az egyetlen .ino fájl használata egy növekvő projecthez, olvashatatlanná, karbantarthatatlanná teszi a projectet számomra.
3. Sok minden hiányzik a megvalósításból.
Elkezdtem írni egy teljesen új szoftvert a problémáim alapján. Sajnos nem néztem szét eléggé körültekintően szoftverért. A saját megvalósításom több mint 50%-ban kész volt (nagyjából már működik) amikor Szigeti Szabolcs e bejegyzésem https://www.facebook.com/groups/muszerek/permalink/2481846092072731/ megjegyzéseiben rámutatott, hogy egy másik megvalósítás is létezik: https://github.com/Twilight-Logic/AR488
Még nem teszteltem, de úgy néz ki, hogy megoldja a problémáim jó részét:
- A szerző (szerencsés egybeesés) ugyanazokat lábakat választotta az eredeti megvalósításból hiányzó jelekhez (REN, SRQ) mint én. Ez azt jelenti, hogy a szoftvernek módosítás nélkül működnie kell az én hardveremen.
- Benne van a legtöbb hiányzó funkció.
Ettől függetlenül a kód struktúrával kapcsolatos fenntartásaim megmaradtak (ez mostmár több mint 3000 sor egyetlen fájlban)
Tesztelni még nem volt időm, de ha megfelel arra a célra, amire használni akarom, lehet, hogy kidobom a saját kódomat (vagy legalábbis elhalasztom a folytatást). Esteleg kicsit gatyába rázom a jelenlegi állapotot és ebben az állapotban publikálom.
Következik:
- Kipróbálni amim most megvan.
- Megrendelni és megépíteni a javított tervet.
- Dönteni a project további sorsáról.

KiCAD csomagoló

Ahogy azt már korábban említettem itt: http://it-pro-hu.blogspot.com/2019/07/esemenyek-lancolata.html, elkezdtem írni egy programot ami megoldja a problémákat amikbe rendszeresen belefutok, amikor meg próbálom osztani a terveim.
Kiraktam egy működő (valószínüleg bugos, és hiányos verziót) ide: https://gitlab.com/suf/packagekicad. Ha akarod használni a 0.2Beta taget érdemes.
Ez képes arra, hogy egy új symbol könyvtárat (a többi később jön) építsen az aktuális környezetből, az összes az aktuális tervben használt alkatrésszel, majd lecserélje ezeket a terv fájlban. Tehát, amikor mozgatjuk a tervet akár verziókövető rendszeren keresztül, akár más módon, bárki ki tudja nyitni a tervet annélkül, hogy hiányzó alkatrészekbe futna. Igen, a rescue lib majdnem ugyanezt csinálja, de felesleges kérdéseket tesz fel, ha hiányzó alkatrészt talál, és sajnos a neten publikált KiCAD gitignore fájl, pont kizárja azt a cache libraryt amit a rescue használ. Ezen túl, ez a megoldás a könyvtár upgrade-eket is kezeli (még nem teljesen).
Doksi sajnos még nincs. Tehát itt a cucc használata:

dotnet PackageKiCAD.dll <project név/mappa>
Options:
-R Rekurzív
-cl Törli a likális symbol könyvtár táblát. Csak a csomagolt könyvtár marad a listán.

Én TortoisGIT-et használok a projectjeimhez. Ez megengedi, hogy automatizáljuk a "csomagolást".
Tehát a project becsomagolódik, még a git commit előtt, ha megfelelően konfiguráljuk.
Itt van a hogyan:
Megnyitottam a TortoiseGIT felületét és kiválasztottam a Hook Scripts menüpontot:

Hozzá adtam az új scriptet:

A "Run when working tree path is under"-nek a szóban forgó repository root könyvtárára kell mutatnia. Ennyi.

A további fejlesztés útban.

DC SSR 1.

Ezzel a cik(ek)kel már régen tartozom magamnak.
Különböző fórumokon rendszeresen feltűnik, a "milyen DC SSR-t" vegyek kérdés, vagy ennek módosulatai. A rövid válasz: semmilyet.
Kicsit hosszabban (most így saccra sok részes cikk lesz belőle):
Először is nézzük meg mi az az SSR (Solid State Relay - vagy Szilárdtest relé).
A szerkezet a mechanikus relé kiváltására született. A következő tulajdonságokkal rendelkezik:
- Galvanikusan leválasztott
- Mind a vezérelt, mind a kapcsolt oldalon kétpólus
- Széles bemenő feszültségtartomány
- A relével szemben, nincs mechanikai kopás
- Zajmentes
- A mechanikus relénél nagyságrendekkel gyorsabb
- Az AC verziói, típustól függően nullátmenten kapcsolnak
Amit most vizsgálok, az ennek a DC verziója. Első nekifutásra a filléres, mindenhol hozzáférhető darabokból indulok ki. Egy ilyet korábban szét is szedtem:
http://it-pro-hu.blogspot.com/2014/07/fotek-ssr-40dd-szetszedve.html
A Fotek ide vonatkozó szériájának az adatlapja itt található:
http://www.fotek.com.hk/solid/SSR-3.htm
(Halkan jegyzem meg, hogy nagyjából minden az eBay/Aliexpress vonalon kapható Fotek DD relé hamisítvány, ugyanakkor amit írok az az eredetire is vonatkozik az adatlapon található rajz alapján)
Itt van egy rajz ami mutatja a szerkezet belső működését:

Hogy megértsük mi ezzel a baj, vegyünk egy tipikus felhasználási próbálkozást: egy 3D nyomtató fűtött ágyának a kapcsolását. Legyen mondjuk az ágy 12V és 120W azaz 10A.
A kimenő oldalon lesz "némi" feszültségesés. Nézzük meg, hogy ez mennyi. Ha felületesen nézzük azt hihetjük, hogy a Q2 Vcesat feszültsége lesz ez a feszültségesés. Ami esetünkben mondjuk tipikus 0,8V (ok, ha más tranzisztort választunk, ez még kissebb is lehetne - akár 0,2V).
De sajnos a helyzet nem ilyen jó. Miután az áramkörben a kapcsolt oldalon a J2 1-2 pólusai közötti feszültég a maximum ami bárhol előfordulhat az áramkörben. Nézzük meg, hogy ez mennyi lehet:
1. U1 Vcesat + Q1 Vcb = 0,25V + 0,6V = 0,85V
2. Q2 Vcb + Q1 Vcesat = 0,6V + 1V = 1,6V
A fenti kettőből a nagyobb lesz a minimális feszültségesésünk. A jó Fotek relén 2V-ot mértem az ideális 1,6V helyett.
Ez a fenti összeállításban 20W veszteséget produkál. Hát nem épp ideális.
Mi ennek az alapvető oka? Az, hogy a kapcsolt oldalon a működési elvből adódóan nem áll rendelkezésünkre külön tápfeszültség. Ha rendelkeznénénk ilyennel - mint ahogy a gyakorlati problémák jelentős részénél rendelkezünk - le tudnánk menni a Q2 Vcesat feszültségéig, csökkentve a veszteséget (vagy MOSFET alkalmazásával még ennél is jobban)
Akkor most nézzük meg a bemeneti oldalt.
Azt írja a Fotek dokumentáció, hogy 3-32V feszültségről lehet használni.
A fenti kapcsolásban az R1 1,5K értékét nem az eredeti bontott eszközből vettem, hanem számoltam az adatlapból. Nézzük meg, hogy mit produkál ez 3, és mit 32V-on:
Az optocsatolóban alkalmazott LED nyitófeszültsége 1,2V.
Ez 3V-on ((3V-1,2V)/1500ohm) = 1,2mA-t jelent, 32V-on pedig ((32V-1,2V/1500)=20,5mA-t.
Ami az optocsatoló 20% minimális CTR értéke mellett azt jelenti, hogy 3V bemenő feszültségnél az optocsatoló maximális kollektor árama 6mA 0,24mA lesz. Ha az abszolult maximumokkal számolunk:
Q1 hFE = 200, Q2 hFE = 15, tehát 6mA 0,24mA x 200 x 15 = 18A 720mA. Ez a kapcsolás elméleti maximuma 3V kapcsoló feszültség esetén. De ezt biztosan nem fogjuk elérni (a Q1 betája nem lesz 200, az optocsatoló pedig nem fog 20% CTR-t produkálni).
Csak remélni tudom, hogy az optocsatoló ennél a 20%-nál jobbat produkál, mert ez így elég sovány. 
Némi konkluzió a cikk első részéhez:
Nem érdemes DC SSR-t használni, ha rendelkezésünkre áll a kapcsolt oldalon tápfeszültség, vagy nincs szükség galvanikus leválsztásra. A vezérelt oldal alacsony árama egy konstrukciós hiba az adott kapcsolásban, jobb tervezéssel kiküszöbölhető lett volna.
Folyt. köv.
A következő részben némi méréssel próbálom alátámasztani a fentieket.

Események láncolata

Mindíg elgondolkozom azon, miért kezdek bele több projectbe mint amit befejezek.

Az egyik ok, az "Események láncolata". Belekezdek valamibe, kiderül, hogy valami hiányzik belőle, a hiány új projectet szül, majd abból is hiányzik valami - újabb project és már meg is született az események láncolata.

Van jónéhány nyitott dolog és semmi sincs befejezve.

Nézzük az aktuálisat:

Újra akartam gyártani a zene lejátszó környezetemet. Az első jelút a bakelit lemez lenne.

1. Megjavítottam a Mission 705-ös hangfalaim keresztváltóit (kicseréltem egy pár őskövület Tesla kondit)

2. Megjavítottam a NAD 5120-as lemezjátszóm (kidobtam a növesztett kábelét, RCA aljzatokat kapott, kicseréltem a szíjjat, beállítottam a karliftet)

3. Akartam egy új RIAA korrektort, építettem is egy HFM-I-et picit újragondolva a tápját (http://it-pro-hu.blogspot.com/2019/02/hfm-i-ujragondolva.html, http://it-pro-hu.blogspot.com/2019/03/hfm-i-2.html, http://it-pro-hu.blogspot.com/2019/04/hfm-i-3.html)

4. Ez az a pont ahol az "események láncolata" elindul. Az jutott eszembe, hogy meg akarom mérni a korrektor átvitelét mielőtt bekötöm a rendszerbe. Vettem egy HP 8903B Audio Analizátort (nem csak ehhez a projecthez, ez már régen tervbe volt véve).

5. NT1. Van egy rakás műszerem, de valahogy sosem kellett PC-hez kötnöm ezeket mindeddig (gondolkoztam rajta, hogy majd egyszercsak). Grafikonok rajzolása a 8903B-ből ennélkül viszont nem megy. Sajnos nem találtam olyan GP-IB interfészt a piacon ami tetszett volna, tehát megszületett az első "nem tervezett" project. Találtam egy Arduino alapú megoldást, de abszolult utáltam a hardver megvalósítását, így terveztem hozzá saját hardvert  (http://pakahuszar.blogspot.com/2019/04/gp-ib.html, http://pakahuszar.blogspot.com/2019/04/gp-ib-2.html)

NT2. Nem tetszett az interface szoftvere sem, sem a megvalósítás, sem a licensz. Tehát elkezdtem írni egy teljesen új szoftvert nulláról (még nincs kész, de lassan már tesztelhető lesz, ha nem landol ez is a befejezetlen projectjeim listáján, mint sok más korábban).

NT3. A bejegyzéseimre reagálva valaki megkérdezte, hogy nem akarom-e árusítani a GP-IB interface-t amit csináltam. Elkezdtem gondolkodni - miért ne?

Ha árusítom, korrektül akarom kezelni a hardver terveket és a szoftvert. Nem akarok befejezetlen terveket, vagy szoftvert publikálni, tehát felépítettem magamnak egy git branching modelt, hogy ezt el tudjam érni. Itt újra felszínre került egy régi gondom. A KiCAD alkatrész könyvtár kezelése horror. A hardver terveimet külső függőségek nélkül szeretném publikálni (Ez alatt azt értem, hogy ha valaki megnyitja a kapcsolási rajzomat, az igazi komponenseket kapjon és ne dobozokat kérdőjelekkel). Megpróbáltam használni a KiCAD archive plugin-ját. Sikertelenül. Beregisztráltam, de el sem indult. Egy pár nap keresgélés, kérdezősködés után sem lett eredménye.
Tehát megszületett a Nem-Tervezett-3 project. Írni egy alkalmazást (nem KiCAD plugin-t) ami automatikusan kezeli a káoszt a hardver projectjeimen (.Net Core 2.1-ben kezdtem el írni, van is valami előrehaladás, de ez egy későbbi bejegyzés témája lesz)

Na szóval. Ez az egyik módja, hogy befejezetlen projectek szülessenek.