Fórum témák
» Több friss téma |
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
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.
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 ))
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).
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ő)
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
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
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.
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.
A C8 miatt 1500Hz a törésponti frekvencia, szerintem az elhagyható
"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
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
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
Ja...igen...én is, csak elhangolódott a fejemben a frekvencia
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.
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.)
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
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ó...
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.
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
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
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!
É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
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 ))
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
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
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).
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.... |
Bejelentkezés
Hirdetés |










