Fórum témák

» Több friss téma
Fórum » 135.6 kHz-es HGA22 vevő
 
Témaindító: zenetom, idő: Dec 31, 2025
Témakörök:
Lapozás: OK   7 / 7
(#) sdrlab válasza zenetom hozzászólására (») Márc 12, 2026 / 1
 
Igen, valahogy úgy )
(#) k81zoty válasza sdrlab hozzászólására (») Márc 12, 2026 /
 
Magyar websdr-ken látszik a jel. Meg az a terv hogy összerakok raspberry-vel egy fake adót. Ilyen számtalan van a neten
(#) zenetom válasza k81zoty hozzászólására (») Márc 12, 2026 /
 
Nem is a jelerősség ott a gond szerintem hanem a borzasztó pici löket. 162 kHz-hez képest a 6 Hz, azt szép munka demodulálni. Bár én kezdő vagyok e téren.
(#) sdrlab válasza k81zoty hozzászólására (») Márc 12, 2026 /
 
Nem a térerő a fő nehézség, bár az is kb a DCF77-el vetekszik, ami önmagában szép teljesítmény lesz, hanem a kis modulációs mélység, ami kb egy nem túl stabil oszcillátor zajával vetekszik ))
(#) k81zoty válasza sdrlab hozzászólására (») Márc 17, 2026 / 1
 
Sikerült úgy módosítanom az algoritmust, hogy a lehető legkisebb jelnél is működik a detektálás (a 2. fokozatú erősítőt teljesen kikapcsolva, ADC-n ±80 digit 12 bites ADC-vel). Detektálja a HGA22-őt szinte antenna irányérzékenység nélkül.

Frissült a GitHubon a HW és a SW is.

Szkópon a DCF49 -39 is egyértelműen látszik, ugyanazzal az antenna-csatolással. A 162 kHz is egyértelműen kivehető.

Ha érdekel valakit, készíthetek majd szkópképeket.

Az ALS162 nem FSK-val van kódolva, hanem fázismodulációval. Nem összekeverendő egy 6 Hz-es FSK szoftveres detektálásával. Kódolása egyébként nagyon hasonló a DCF77-hez, csak míg a DCF77-et 50 kW-tal sugározzák (kb. 1500 km távval), addig ezt 800 kW-tal (kb. 3500 km).
(#) sdrlab válasza k81zoty hozzászólására (») Márc 18, 2026 /
 
Nem állította senki sem, hogy FSK a moduláció..., csak azt, hogy értelemszerűen átjárás van a fázis-frekvencia modulációk között, és a kb 6Hz FSK a fázismoduláció mellékhatása!
A TDF adó hiába sokkal erősebb, a távolság miatt nem jobb a térerő pl Budapesten, vagy legalábbis nem számottevő a különbség(amúgy is folyton hullámzik mindkettő)
(#) k81zoty válasza k81zoty hozzászólására (») Csü, 15:12 / 1
 
Sziasztok,

Ha valakit érdekel, és szeretne az adatokkal játszani hw nélkül, a docs mappába raktam fel példaprogramot.

https://github.com/koszozoltan/HGA22
(#) GPeti1977 válasza k81zoty hozzászólására (») Pé, 8:46 /
 
A rajzon az R3/R4 arány túl nagy, valójában itt mennyit erősít ez a lassú műveleti erősítő? Illetve a keverő FET source lába nincs DC potenciálra rögzítve
(#) k81zoty válasza GPeti1977 hozzászólására (») Pé, 9:17 /
 
Az erősítés elméletben 6-7 szeres ( a slew rate miatt) a gyakorlatban kb 10 szeres. a fet source rc tagon keresztül közép tápfeszültségre van kicsatolva.
(#) Feri007 válasza sdrlab hozzászólására (») Pé, 13:20 /
 
Jaja, kicsi a modulációs mélység, de egy kis zajú PLL-t rá lehet húzni a vivőre - pl a VCO egy hangolt kvarcoszcillátor -
és koherens demodulációval 3dB nyereséged is van.
(#) GPeti1977 válasza k81zoty hozzászólására (») Pé, 14:00 /
 
A C8 miatt 1500Hz a törésponti frekvencia, szerintem az elhagyható
(#) HeZ válasza k81zoty hozzászólására (») Pé, 14:12 /
 
"Ha valakit érdekel," - engem érdekel, de az adatokkal játszani??? A program íróján - Rajtad - kívül nincs ember a földön, aki értené a programod... Próbáltam legalább blokk szinten megérteni más platformra átírás (ESP32) végett, de esélytelen, bár látszik, hogy bevált, tömör, kiforrott kódrészleteket máshonnan vettél át (nem is kell kitalálni a spanyolviaszt...).
Nem kérhetem a részletes(ebb) leírását a programodnak, de legalább a forrásaidat megosztanád?
A hozzászólás módosítva: Pé, 14:14
(#) tki válasza HeZ hozzászólására (») Pé, 15:21 /
 
Valahogy így futnak végig a bitek:
TIM1 trigger jön --> mérés az ADC1-en --> DMA --> q_signal tárolása --> a loop() a main()-ben feldolgozza, vagyis --> Goertzel (FFT), ebből lesz az --> FSK bit (q_fsk) --> UART frame dekóder (mert a vett infó a soros vonali átvitelre hasonlít) --> q_byte --> parse_frame(), itt dekódoljuk az időt --> unix_us frissítése + kiírás.

Valamint vannak még:
- UDP NTP válaszok - így hasznosul a project, hogy lekérdezhető az idő a számítógépről, rá lehet állítani egy/az NTP klienst (lesz a panelnek IP-címe USB-n keresztül) és
- TCP shell
A hozzászólás módosítva: Pé, 15:26
(#) sdrlab válasza Feri007 hozzászólására (») Pé, 17:15 /
 
Mármint? 162kHz-en gondoltad mindezt? Ha nem is lenne lehetetlen...nem lenne valami egyszerű így megoldani!
Szerintem lekeverve, digitálisan demodulálva sokkal biztosabb..., még ha az sem a legegyszerűbb...
A hozzászólás módosítva: Pé, 17:24
(#) zenetom válasza sdrlab hozzászólására (») Pé, 17:22 /
 
Az ALS162-re gondolt szerintem.
(#) sdrlab válasza zenetom hozzászólására (») Pé, 17:23 /
 
Ja...igen...én is, csak elhangolódott a fejemben a frekvencia
(#) k81zoty válasza HeZ hozzászólására (») Pé, 23:21 /
 
Lehet igazad van.
Készítettem egy pc-n forduló programot ami feldolgozza kb ugyan azzal az algoritmussal az analog jelet, mint az mcu.

Fix 8khz es mintavétel az adc-n. (Az oversampling sokat segített).
Ezen az adaton 1 ms ként lefuttatom a 4 ms ablaknyi adatra a dft algoritmust. Ebből van egy bit stream, majd byte stream. És dekódolás.

Majd próbálok dokkumentációt is készíteni, bár most az IQ Dekódoláson dolgozom, háta jobb.
Az adatot a hw segítségével vettem fel normál hangkártyával.
Ha sikerül lefordítani, akkor azt érdemesebb nézni, mert jobban átlátható.Ez a dok mappában van, cmake -al generálható make.
(#) Feri007 válasza sdrlab hozzászólására (») Szo, 7:10 /
 
Ahogy írod, sem az egyenes, sem a lekevert módszer nem egyszerű. Csak annyit akartam kiemelni, hogy míg az ASL162-nél lehetséges a vivő helyreállítása, ezáltal a koherens demoduláció,
a HGA22-nál nem. (Illetve lehetne a HGA22-nál is vivőt helyreállítani, de az már tényleg eszetlenül bonyolult, nem éri meg.)
(#) zenetom válasza Feri007 hozzászólására (») Szo, 8:03 /
 
Nem fordítva?
HGA22 demodulálása sokkal egyszerűbb. Bár a két freki elég közel van egymáshoz a vivőhöz képest. De az ALS PSK-hoz képest (szerintem) jóval egyszerűbb.
ALS162-nél 25ms alatt történik 1 radián eltolás, ezt most hirtelen el se tudom képzelni hogy néz ki, hiszen 25 ms alatt 4050 periódus lemegy a vivőből
(#) sdrlab válasza Feri007 hozzászólására (») Szo, 11:35 /
 
Ja érem, mire gondolsz, egy szinkron demodulátorra! A 162kHz-en ez továbbra is problémás lenne, de lekeverve már nem látom akadályát neki... Sőt, egy mikrovezérlővel, belső, jusztálható RC oszcillátorral egy egyszerű FLL-el rá lehetne állni a pontos lekevert vivőre, és úgy végezni az FM(PM) demodulációt )
Hardveres szempontból még mindig az erősen lekevert, akár 100Hz magasságába, jel digitális demodulálása lehet a legegyszerűbb...., mióta nincs rajta műsorszórás, nincs rajta az - erősen zavaró - ehhez képest brutális AM moduláció...
(#) tki válasza sdrlab hozzászólására (») Szo, 11:46 /
 
Tegnap kora este megnéztem egy magyar websdr-en, ahol kevés zaj van és elég nagy antenna: az ALS162 egy S-fokkal jobban jött, mint a DCF77, kb. S9-cel. Ez sok mindenen múlhat, de akkor sem rossz. Szépen remeg, hajladozik, jól hallani a modulációját.
(#) sdrlab válasza tki hozzászólására (») Szo, 12:34 /
 
Van, amikor gyengébben jön, alig vehetően(Bp)! Bár felszíni terjedés, de vagy ott is játszanak a teljesítménnyel(a DCF77-né biztosan), vagy ennek ellenére van még így is jelentős hullámzása a nagy távolság miatt!
A mindenféle (web)sdr igen csalóka tud lenni, mert ott eleve lekeverten hallod valahol 500Hz-1kHz között a vivőt, amin az emberi fül már viszonylag jól hallja azt a még mindig elég pici modulációt... Egész más tészta azt üzembiztosan demodulálni
(#) tki válasza sdrlab hozzászólására (») Szo, 12:50 /
 
Persze, nem is füllel akartam írni a biteket. : -) Valóban, egy rádióban elég sok minden történik, amit egy ilyen óraadatokat vevő célszerszámban nem gazdaságos megvalósítani. Bár ilyen alacsony frekire és ezáltal számítási teljesítményigényhez lehet, hogy egy kész FPGA-s hobbipanel simán megfelelne egy szintén direktvevőhöz (mint a websdr-ekben, pl. a Kiwi-ben, amit hallgattam, ill. nekem is van egy, csak sok a zavar). Az FPGA-programozás nekem mindig kimaradt, nem volt rá idő, más csinálta, így nem tudom megsaccolni, mekkora kellene hozzá, ill. hogy hogyan érné meg, hogy a gyors-lassú átalakítás, előfeldolgozás után mennyi feladatot kellene meghagyni a rákötött processzornak, ami amúgy is szükséges az eszközhöz, vagy akár a rádiós részből mindent az FPGA-ba belefordítani.
A hozzászólás módosítva: Szo, 12:51
(#) sdrlab válasza tki hozzászólására (») Vas, 10:48 /
 
Ez így erősen ágyúval verébre kategória lenne! Az FPGA-s feldolgozás ott nyújt előnyt, amikor széles spektrum és/vagy széles sávban kellene magas minőségben vételezni! Egy pontos idő adó sohasem ilyen. Ott mindig egy határozott frekvenciát kell csak venni, szofisztikáltabb esetben mondjuk vagy 3-at, de többnyire csak egy a cél. Ahhoz sehogy sem kifizetődő sem anyagilag, sem a hozzá szükséges programozásba ölt idő arra, hogy pusztán egy egyszerű vételt/demodulálást megvalósítsunk!
(#) tki válasza sdrlab hozzászólására (») Vas, 11:19 / 1
 
Én ezt másként gondolom. Léteznek rá példák, elég régiek is. Ez itt még külön A/D átalakítót sem használ: https://hackaday.io/project/170916-fpga-3-r-1-c-mw-and-sw-sdr-receiver : -)

"This project has been created as a way to learn Verilog and have some fun with FPGA and SDR. Main goal is to receive AM broadcast stations with as little components as possible. The FPGA chosen, Lattice MachXO2, is also among the simplest components that can be used. I was able, with 20 meters of electrical wire as an antenna, to receive stations from thousands of kilometers, located in three continents. Smallest BOM consists of a 30 euros Lattice MachXO2 breakout board, three resistors, one capacitor and a speaker. For better performance it is best to add a crystal oscillator, sensitivity and audio quality are better than with the internal oscillator."

Természetes, hogy többre alkalmas egyetlen állomás vételénél, de az nem jelenti, hogy túlzás használni, más szempontok is vannak. Sok mindent egyszerűbbé tesz egy direkt konverziós SDR, a precíz demodulációt is.
A hozzászólás módosítva: Vas, 11:23
(#) sdrlab válasza tki hozzászólására (») Vas, 12:17 / 1
 
Ne viccelj már....ez egy 6(!) bites ADC érzékenységét adó rádió max, ami arra elég hogy Bp-en fogd a HGA jelét vele, esetleg néhány izmosabb műsorszórót is még mellette, de egy távolabbi adóhoz olyan gyenge mint a hangyafing...
A websdr-ek FPGA-i mellett többnyire natív 14-16bites ADC van! Ennek megfelelően nagyságrendekkel érzékenyebb rádiókat adnak...., de mint mondottam, az nem ez a móricka FPGA rádió szintje ))
(#) tki válasza sdrlab hozzászólására (») Vas, 12:56 /
 
Ezt a példát azért hoztam, mert érdekes játék volt a lehető legegyszerűbb megoldással. Másfelől leírta az illető, hogy miket volt képes venni vele. De mennyivel kell nagyobb sávszélességű (vagyis drágább) FPGA egy 8 vagy 10 bites A/D-hez és az mennyibe kerül? Te tudod konkrétan? Ha már egyszer van működő példánk... Egyébként nem az érzékenység a probléma, azt önmagában oda állítjuk be, ahova akarjuk, hanem a dinamika a kérdés, hogy az erősebb állomások mellett hány bit jut a gyengébbekre az A/D túlhajtása nélkül - bemeneti szűrővel némileg javítható a helyzet.

Én csak azt tudom, hogy több népszerű, bár szerény képességű vevő is jól elvan 8 bittel, pl. az RTL-SDR és a NooElec NESDR. Persze ez csak a bitek számára példa, mert ezekben az olcsóságuk miatt a feldolgozás a csatlakoztatott számítógépben történik. Ahol egyébként nagyon kis számítási teljesítményt igényel a mai viszonyokhoz képest, vagyis nemcsak PC-vel lehet feldolgozni, ami az A/D-ről jön, csak eddig még a CPU-s, mikrokontrolleres feldolgozásnál előnyösebb szokott lenni az FPGA, de akár egy kisebb ARM-ot is emlegethettem volna, kereshetek olyan projectet is. És valószínűleg léteznek specializált FPGA-k is, amik gyorsak, de pl. nincs hatszáz lábuk, mert más a cél.

A hosszúhullám annyira alacsony frekvencia, hogy ugyanazok a megoldások használhatók, mint a keverős (hibrid) rádióvevőkben, SDR-ekben, ahol az utolsó KF vagy akár egy tizenvalahány kHz-es hangfrekis sáv van bedigitalizálva és önállóan feldolgozva. Sok múlik a konkrét áron, de ezek már régebb óta tömeges megoldások, egyáltalán nem néz ki olyan élesnek a határvonal, mint írod.
A hozzászólás módosítva: Vas, 12:58
(#) sdrlab válasza tki hozzászólására (») Vas, 14:54 /
 
De mitől lenne ez az irány egyszerű?? Mert letöltöd a valaki által kiizzadt hex-et, és felprogramozod??! Na ez eddig tényleg egyszerű, "csak" az FPGA árát kell mellé tenni, ami nem éppen egy bluepill modul ára szokott lenni..., tehát eleve nem lesz olcsó!
Ha nem más tollával akarunk ékeskedni, hanem magunk akarjuk leprogramozni, akkor hajrá..., majd az első VHDL/VERILOG projektednél, ahol nem egy kész letöltött modult próbálsz életre kelteni, atomgyorsan rájössz, ez bizony nem bit tologatás egy 8-32bites mikrovezérlőn, hanem valami merőben más! Míg egy kicsit is bonyolult hardvert összeraksz benne, ami működik is..., az nem lesz egyszerű, sem olcsó...tehát konkrétan erre a célra továbbra is tartom, hogy erősen ágyúval verébre kategória lesz.
Abban igazad van, hogy 1 vételi frekvenciára, jó előszűrésekkel, elegendő lehet még talán az a 6bit is, hatékony AGC-vel megtoldva. De ha nincs ezekben a részekben nagy tapasztalatod, 0-ról megírva vért fogsz izzadni, mire megszólal, és semmivel se lesz se egyszerűbb, se gyorsabb, mint a klasszikusabb, de sokkal biztosabb utat járva...
A hozzászólás módosítva: Vas, 15:00
(#) tki válasza sdrlab hozzászólására (») Vas, 15:49 /
 
Tény, hogy emberek hobbiból készítenek hasonlókat (még ismerkedős projectként is), hogy a komplett panel az adott példában egydarabos áron 30 euró alatt volt sok éve a valamilyen szintű megvalósításhoz (most szerintem egy 5-10 dolláros FPGA nevetve dolgozna fel sokkal többet is), hogy nem kell profi 14-16 bites A/D-khez való, sok-sok megabites FPGA-s feldolgozás, hogy a bonyolultság a reprodukálhatóság szempontjából csekély - nekem ennyi elég.

Egyébként a legtöbb hobbista úgyis csak utánépíteni szokott, még csak nem is kíváncsi a forrásokra, de lehet, hogy a célokat és feltételeket nem egyeztettük időben itt, a topikban, hogy meddig szabad elmennünk árban és munkamennyiségben.

Nem tartom annyira nagynak a különbséget az FPGA és a CPU programozása közt, az FPGA-kód is hasonló függvényeket, blokkokat valósít meg kész könyvtárakból. Azzal eléggé tisztában vagyok, hogy más szempontokból mennyire kényes tud lenni, dolgoztam FPGA-s készülék fejlesztésében bő 25 éve, csak más részét, ill. drivert programoztam. Készült pár változat, mire használható lett (egyébként nem rádió volt).
(#) sdrlab válasza tki hozzászólására (») Vas, 15:58 /
 
Ahogy az is tény a legokosabbak mindig a partszélről dumálók szoktak lenni(nem rád célzok itt, mielőtt magadra vennéd), akik még sosem csináltak olyat, többnyire nem is tudnák megtenni, de a naiv optimizmusuk végtelenhez konvergál ))
Nézd, távol álljon tőlem, hogy lebeszéljelek erről a megvalósítási irányról...kíváncsian várom, mikor sikerül majd megvalósítanod az első FPGA-s rádiódat Az biztos, hogy jó móka lesz hosszú időre....
Következő: »»   7 / 7
Bejelentkezés

Belépés

Hirdetés
XDT.hu
Az oldalon sütiket használunk a helyes működéshez. Bővebb információt az adatvédelmi szabályzatban olvashatsz. Megértettem