Jó kis elemzés. :--) A szótár nagy dolog, a tehetségen túl talán tényleg csak ennyin múlik, hogy képesek kezdeni valamit ezzel az extrém sebességgel. Még mindig nem volt rá időm, de tényleg nem tiszta a leírás stb. alapján, hogy a RufZ-ben hány hívójelből lehet válogatni és azok honnan származnak. A QRZ-t ugyan sok program használja (bár már erősen korlátozottak a lehetőségek, mert nagyon rátelepültek arra az online adatbázisra és óriási terhelés okoztak), de nem hiszem hogy olyan lehetőség lenne rajta-benne, hogy adjon vissza véletlenszerűen egy vagy több hívójelet...
Az általam készített vissza csatolt audion 12ZS1L csővel működik- A vezérlő rácsra 100k és 100pF van kötve. A 100pF másik felére csatlakozik a rezgőkör- A 100K másik felére és a test közzé van kapcsolva a 50 mikr. amperes műszer a berezgés előtti állapot jelzésére. A cső anódról a vissza csatoló tekercs / 30 menet / induktiv csatolásban van a rezgőköri tekerccsel / 70 menet / a tekercstest átmérő 30 mm. A hangoló kondenzátor 200 pF axiláis kivitel skálával. Anód + 50V. Az audion 1,6MHz 5,5MHz között működik- GDO ként is használom- Mik-
Ez előző, szoftveres választ köszönöm. Rosszul tettem fel a kérdést, de így is választ kaptam. :-)
A másik ez a RufZ témakör. A tegnapi MRASZ-os bejegyzés kapcsán nyomoztam, matekoztam, aztán szimuláltam kicsit és az jött ki, hogy...
Egyrészt, ez 500 Hz-es jel és tényleg szimulált (függvénygenerátor), de ha a 217 wpm-es sebességet nézzük, a jelenlegi "csúcstartó" hívójel 320 ms körül jött le, a rövid elemek ezen a hangfrekvencián 2,5 hullámot adnak ki, nyilván, magasabb frekvencián többet.
Másrészt. Arról nem találtam adatot, hogy az emberi fül ilyen jellegű "felbontóképessége" hol van határolva anatómiailag (a szemnél az 1 ívperc a határ, de ez is sok mindentől függ), lehet, hogy "bírná", de van egy olyan feltételezésem, hogy ez számottevően gyorsabb, minthogy egyáltalán karakterekre tudná bontani az agy.
Mindebből én arra tippelek, hogy a versenyzéshez is használt szofverrel végtelen mennyiséget gyakorolva egyszerűen bemagolják a szóba jöhető pár száz hívójelet, és egyre növekvő sebességgel kondicionálják az agyukat, hogy a hangképet összekapcsolja a hívójellel. Innentől pedig kis részben szerencse kérdése (hosszú hívójel jöjjön ki nagy sebességnél és beugorjon a hangkép alapján), nagyobb részt gyors írásé. Így elérhetők és egyúttal hihetők azok az eszeveszett eredmények, amiket látunk. Ennek megfelelően az "akár 217 WPM-mel vett" helyett helyesebb lenne az, hogy "felismerte egy 217 WPM-mel adott hívójel hangképét". Az első praktikus és jó gyakorlati tudás, a másik meg... Versenyeredmény. Nyilván nem degradálva azt, hogy embertelen mennyiségű gyakorlás, kitartás vezet ahhoz, hogy valaki egyáltalán képes legyen erre. Ezt erősen alátámasztja a lcwo eredménytáblája is, ahol a vegyes kódcsoportos legjobb eredmények 60 wpm-nél vannak, a hívójeles maximum 124. Ez alig több, mint a fele a mostani rekordnak.
U.i.: Egyébként ez a 217 WPM technikaileg megfelel egy kb. 180 bps, négyszer gyorsabb, mint az RTTY (nyilván teoretikus az összehasonlítás).
Azt nem tudhatom, kinek mi a legmegfelelőbb, milyen kivitelben, milyen vason/op.rendszeren és készültségi fokban, és említettem is már egyet-kettőt. Keresni meg más is tud. De itt van pl. a Mumble/Murmur: https://github.com/mumble-voip/mumble , a PJSIP: https://github.com/pjsip/pjproject , aztán volt pl. Windows-os programpár is, szerver és kliens, amit kifejezetten r.amatőr írt a mi igényeinkhez, tán német. De ha úgy vesszük, a VLC is tud streameket lejátszani, gyakran használom online streamek hallgatására (és küldeni is tud). Mivel eredetileg Linux project, command line-ból is elég jól kezelhető Windows alatt is. Hasonló az Audacious is. Meg VoIP projectek, mert azt sok szoftver támogatja, sőt beépíthető VoIP chipek (mint az RRC-1258-as dobozkában, amit sok remote állomás használ és mindent elintéz és kicsi a késleltetése). Szerintem a socat-re is épült valamilyen direkt hangátvivő project stb.
Igen, a hír igaz! 18 jelentkező volt, "őket nem lehet cserbenhagyni", ahogy tegnap a klubban elhangzott, sőt lett új jelentkező a sportágválasztóról! Egy nagy tudású és lelkesedésű szaki veszett el, de az élet nem áll meg!
Ha nagyon drága és új, akkor, felteszem, Thunderbolt 4 van benne, ami a maga 40 Gbps-ával komoly mérnöki feladat - az egy dolog, hogy mások már megcsinálták és nem ünnepeltetik magukat. És kérdés, hogy lesz-e olcsó kábelük, vagy mindenkivel a maximumot vetetik meg.
A Thunderbolt csendben megváltoztatta a hordozható gépek dokkolóinak világát: 4K 60 fps videostream-ek mellett 10 Gbps-os USB 3-ak is elférnek a kisebbekről nem is szólva - nagy durranás. És mindez USB-C-n át.
"Errefelé megy a világ, a telefonokról is elhagyják a füles csatlakozót, lassan a tápot is."
Másfelől pedig lassan újra visszateszik a 3,5-es csatlakozót, mert az emberek igénylik nem kis számban. :--)
Ezeknek a "fejlődéseknek" egy jelentős része mesterségesen gerjesztett illúzió. Emlékszel? Túl kellett élni a fényes monitor-divatot is (vagyis inkább az erőszakot a szakmán) az Apple-től és követőitől - bármennyit tépték a szájukat, hogy jobb, végül ismét érvényesült a józan ész, hogy nem jobb. Ezt is túl fogjuk élni (Apple és követői), hogy a Jack-aljzat rossz és drága és nem fér el... Az Androidra sok mindent rá lehet kötni vezetékkel is, külső memóriát, még hangkártyát is - a "táp"csatlakozója nemhogy elsorvadna, hanem az is fontos része az ökoszisztémának. Egy Bluetooth fejlhallgatót megértek, én is állandóan használom - egy üzemszerűen WiFi-n át működő rádiót nem.
A mi hobbinkban meglesz annak a nyílt forrású, szabványos, hosszú életű változata is.
Valamelyik fórumon egy csomó ember (fejlesztők is) tárgyalta pár éve, hogy milyen gáz, hogy a WSJT-X nem fogad közvetlenül streamet, mindent a Windows hang rendszerén kell átvinni. Mind egyetértettek, hogy a streameket előállító SDR frontendek korában ez mennyire hasznos lenne, meg kellene írni.
USB-s "hangkártyát" egyszerű csinálni saját áramkörként és bele lehet építeni a rádióba, vagy megvenni - és szintén beletenni a rádióba
Ezt csináltam az ADX-S kittel. Vettem hozzá usb-s audio dugót (valami másfél dollár volt). :-)
A vevőjével nem voltam elégedett, építettem hozzá egy másikat 8 elemű kvarcszűrővel.
Az USB-ben vonzó, hogy PC oldalon nem kell semmit telepíteni. uC oldalon TinyUSB-vel már több készüléket is csináltam.
A WiFi-vel, Bluetooth-szal egyébként nem értek egyet; a rádiós átvitelt kerülni kell. Nem mintha nem működne, de akkor is.
Nekem más az ízlésem, én a vezetékeket próbálom kerülni. Errefelé megy a világ, a telefonokról is elhagyják a füles csatlakozót, lassan a tápot is. Mobilon az USB-t a felhasználók 99%-a kizárólag töltésre használja, ha vezeték nélkül töltenek, el fogják hagyni. Nem lesz semmi vezetékes csatlakozás.
Később - ha minden egyéb jól sikerül - mobilhoz is illeszteni szeretném a rádiót.
A Wifi frekvencia olyan mérékben magasabb a HF-nél, hogy nem okozhat zavart. Így - eltekintve attól, hogy nekem nehezebben megy programozni - nem látom hátrányát.
elfelejtjük a Windows-t, és a rádió egy egykártyás Linuxot tartalmaz
Ezeket nagyon szépen kidolgozták, Hermes, Radioberry pl. Ezen a pályán nem tudok labdába rúgni, egyszerűbb dologgal próbálkozom.
Tetszik, hogy az SI5351-gyel közvetlenül lehet FT8-at előállítani, és az SSB-vel is megpróbálkozom ugyanazzal a módszerrel (persze nehezebb).
Köszi a tippeket! Nézegettem képeket, külföldi fórumokat erről, jó zsúfolt! Nem gond, napi szinten javítok hasonlókat, ott ki is kell szedni az alkatrészt előtte.
"Ha ez a VBAN csomag megoldja a stream<->audio átalakítást,"
Nem szabad, nem érdemes üzleti megoldásokhoz kötődni, ill. hamarabb kiválasztani valamit egyedit, amit éppen találtál, minthogy átlátnád a helyzetet. A mi hobbinkban meglesz annak a nyílt forrású, szabványos, hosszú életű változata is.
Az említett Linux-os, egykártyás gép és a Windows közt szóba jöhet a régi, bevált Linux-os, de Windows-ra is portolt "socat" és "netcat" utility, ami bárminek a TCP/IP-n való továbbítására alkalmas, a hangnak is - lehet, nem a leginkább erre kitalált eszköz, de programozás nélkül össze lehet kötni vele egy hangkimenetet egy másik számítógép hangbemenetével és viszont. És természetesen nyílt forrású. De biztosan előkerül majd direkt erre kitalált program is.
Ha már ötletbörze, USB-s "hangkártyát" egyszerű csinálni saját áramkörként és bele lehet építeni a rádióba, vagy megvenni - és szintén beletenni a rádióba. Zéró programírás, viszont vannak korlátai. Mostanában a Yaesu meg is szokta tenni (pl. FT-991), nem panaszkodnak a latency-re. Szóval nem látom, hogy nagyon riadoznának a fémes összeköttetéstől.
Meg kell nézni a rádiók rajzát, de az USB egy földfüggetlen, szimmetrikus busz (D+/D-), a házát sem szokták a kliens oldalon a testtel összekötni a földhurok elkerülése miatt. Egy ponton kell csak. Magát az USB vonalat drága leválasztani - Full Speed-en amúgy nem gond, és ez az adatátviteli mennyiség nem is igényel többet, de High Speed-en drága, ami viszont jót tesz a késleltetéseknek. Szóval jobb megoldás az, ha önálló eszköz, egy sziget az USB proci a rádión belül, és már a konkrét adatok továbbítása során pl. egy SPI busz van leválasztva a rádió processzorától, vagy természetesen egy soros vonal RxD-je és TxD-je. Legalábbis most így képzelem. Busztáplált megoldásnál a tápfeszültségnek sincs köze a rádióéhoz.
***
A másik lehetőség, hogy elfelejtjük a Windows-t, és a rádió egy egykártyás Linuxot tartalmaz, akár egy erősebb RPi klónt, azokon pedig van I2S busz (és szoftver is hozzá) - így az A/D átalakító után rögtön mehet bele a busz a Linuxba, azon pedig futhat akár egy GNU Radio, amiben csak össze kell kötni a blokkokat és már szól is a rádió... Bizonyos értelemben ez kevés alkatrész. Ezekhez eleve lehet kijelzőt is csatlakoztatni. A kész hangfrekit egy, az egykártyás géphez csatlakoztatott normál hangkártya még mindig át tudja küldeni a PC-re, ha kell. Nyilván adóoldalon is működik, csak a másik irányban. És minden más szoftvert elég sajátra cserélni, ha van idő és megjön közben a tudás is megírni.
A DMIPS-ekből ki lehet találni, milyen minőséget képes egy ilyen rendszer előállítani, de az IIS busz elég univerzálisan használt. Pl.: gyári ADC demo panel valami jobb A/D-vel (meg egy másik D/A-val) - IIS busz - számítógép - kész szoftverek. A bemenet, osztó és előerősítő/kimeneti szűrők és végfok, valamint a VFO + Tayloe keverő, amiket nem lehet megúszni, de rengeteg leírás van hozzájuk. Lényeges még: AGC, Noise blanking. A direkt konverzió ehhez képest sokkal nehezebb: kell egy drága FPGA-s demo panel és sok tanulás/próbálgatás, bár nyilván ehhez is akadnak projectek a GitHub-on meg itt-ott.
A stream előállítása ESP32 oldalon nem gond. A nehézséget az okozza (nekem, mert nem vagyok gyakorlott Win11 programozásban), hogy PC oldalon a streamet le kell venni, és megoldani, hogy meglevő programok, pl. WSJT-X választható hang bemenetnek lássák. És fordítva, a PC-n egy válaszható hang kimenet jelenjen meg, és küldje a streamet az ESP32-nek.
Hogy pontosan milyen a RAW stream, majdnem mindegy, csak legyen jól definiált. Megoldom ESP32 oldalon.
A tömörítő codec-et kerülném. Egyrészt nehezebb ESP oldalon, másrészt - és ez a fő szempont - nem tudom, mit művelne egy pszichoakusztikus codec az FT8 jellel. Az FT8 képes zaj alatt venni, átlapolt nagy hangerő különbségű adásokat levenni, stb. A codec esetleg boldogan kiszűrné a hasznos jelet... :-)
Ha ez a VBAN csomag megoldja a stream<->audio átalakítást, szerencsém van, megúszom a PC oldali programozást.
Java, Android Studio környezetben. Elektromos szörfhöz készítettem okosórára és mobilra kijelzőt. ESP32 mért akkufeszt, áramot, fordulatszámot, hőmérsékletet stb. és wifin továbbította a kijelzőre.
