Hvala na komplimentima ... ;)
Meni je najbitnije da to nekome nesto proradi, korisnije nego da skuplja prasinu ...
@gane1
Ovde se slazem da je malo problem sa delovima, imao sam slicne probleme, posebno kada je RF u pitanju, jednostavno zabranjen izvoz te-i-te komponente, tacka, nema je :(
Moze samo iz druge/trece ruke da se nabavi ...
LTC2162, znam sta oni prave, to je odlican A/D konverter.
Nego tu ima jedan vro vrlo nezgodan problem koji vise nije vezan za A/D vec za sve iza njega.
Taj A/D kada radi pri tim maksimalnim brzinama, pravi oko 130 - 150 MB/s (megabajta u sekundi) protok informacija za jedan kanal! :(
Sta da radim sa tolikim protokom? Kako to da obradim?
To je sumanuta kolicina informacija koji recimo jedan zesci XEON procesor ima dobro da se pomuci za par najosnovnijih funkcija da odradi (recimo samo da trosimo desetak masinskih instrukcija).
Taj protok je ekvivalentan desetinama full-HD nekopresovanih Blue-ray zapisa!!!! Mnogo mnogo mnogo informacija ...
Da bi se sa tim izborio mora da iza tog konvertera imas neki decimator, verovatno FPGA baziran na nekoliko GHz clock samo da malo skrati tu kolicinu informacija (zvrtvujuci "nesto" od informacija) pre nego sto je prosledis dalje na obradu, ne mozes toliko brzo da preneses u PC, Gigabitni LAN ima 100MB/s (1000MBit/s) ...
A gde je tu tek potrebno vreme za procesiranje signala u realnom vremenu ... To sve je bas bas problematicno ...
Evo opet RTL-SDR da spomenem (igracka u poredjenju sa LTC2162), on dakle ima 4MSPS 8bitni konverter i ima dva kanala (I/Q).
Najprostija (najlosija, ne racunam overhead za kontrolne pakete, crc itd) procena dovodi da on pravi 4M * 8bit * 2kanala = 64Mbit u sekundi ... Taj transfer recimo klasicnim WiFi a/b/g ne mozes da preneses! Isti taj onda konverter guraju na svega 2MSPS da bi mogli da malo lakse prenose kroz standardnu mreznu opremu i da bi prosecno dobar PC mogao da odradi u realnom vremenu ostatak procesiranja ... Cim se neki od ovih parametara (dal potreban trafick ili brzina PC) prekoraci, vise nemamo real-time obradu i pocinje da se gube/preskacu/dropuju frejmovi infromacija sto dovodi do "shtucanja" ili kako to da nazovem, ne znam, ali uvidjas sta je problem.
Pa sad ti vidi gde je RTL-SDR naspram LTC i koliko je to komplikovano raditi sa tako brzim konverterima.
Mnogo "lepo" izgledaju te cifre na papiru, u praksi je to potpuno drugi problem u pitanju.
WebSDR je isto jedan vrlo zanimljiv koncept, isto ima brze A/D konvertere, ali verovatno nemas predstavu sta je autor, Holandjanin, (i sa njim sam bio u kontaktu nekoliko puta) tu sve morao da radi u SW da bi to imalo nekog smisla.
On je morao u onom XILINX Spartan FPGA (kockica sa 200+ nozica) da razvije vrlo specificne klient/strimove jer je skoro nemoguce dovuci klot/suvu informaciju u PC (jedan server koji iza tu "kuva") nego kada se neko "okaci" na web interfejst, iza se uspostavi jedan vrlo uzak prenosni kanal (do 10kHz sirine) i onda u samom onom FPGA ima logika koja "izvlaci" te informacije iz krsha informacija koje prosleduje A/D i to za trenutno izabranu/postavljenu frekvenciju slusanja.
Slicno je i za onaj vrlo sirok waterfall koji vidimo, da bi to nacrtao morao je da izvuce verovatno svaki 100.000 sempl i samo njega da posalje jer drugacije nebi mogao da obradi a spomenuti Linux server koji iz kuva maksimalno efikasno to treba da iskoristi (dakle uzme samo jednom) ali to interno prosleduje svakom okacenom slusaocu nezavisno od onog SDR-a jer kao sto rekoh ne moze drugacije da se izbori sa tolikom kolicinom informacija.
[Ovu poruku je menjao mikikg dana 13.08.2013. u 14:49 GMT+1]