Lofar voor en door amateurs ?

[coolepascal]

Misschien kan het voelen dat ik een en ander steeds niet begrijp en jij/jullie het moeten uitleggen aan mij. Voor een gedeelte is dat ook wel zo, maar dit sparren vind ik wel leuk en wie weet heb ik in al mijn lekigheid en blackboxdenken wel een idee waar jullie meer mee kunnen. En anders is het gewoon leuk om wat van gedachten te wisselen.

Als je naar een smalbandig concept wil ondermijn je het hele idee.
Een reden om met SDR te werken is het onafhankelijk kunnen processen van (veel) data.

Het topic is wat mij betreft vooral bedoeld om van gedachten te wisselen met het idee dat er uiteindelijk welicht een werkbaar idee voor een project uitrolt.
Vergeet niet het is zeer zeker niet zo simpel als ik voorstelde, door Pascal werd al aangekaart dat zoveel dataverkeer wel eens een $proleem$ zou kunnen vormen.
Ik zelf hou me QRL matig al te veel naar mijn zin met die dingen bezig dat mogen anderen dus doen.
Veel meer intresse heb ik in het frontend, de te gebruiken sampling hardware.
vergis je daar ook niet in, we willen een budget hignend oplossing dat kan welhaast aleen middels een soundkaart hetgeen een oplossing is waar ik zeker niet blij van wordt maar een die wel voor bijna iedereen haalbaar is.
Tenslote natuurlijk software... das best een flink pak
kijk maar eens
-Server side : alle data verzamelen, selecteren, bewaren, met elkaar oplijnen, eventueel iets aan pre-processing doen, en vervolgens weer distribueren.
- Source Site (ik maak even onderscheid tussen twee soorten clients) netwerk verbinding onderhouden, automagisch aanmelden / afmelden afhankelijk van de beschikbaarheid en kwaliteit van de verbinding
Data compressen (egh wel) en versturen, maar ook de samples van een zeer accurate timing voorzien
Nogmaals ik praat over de nauwkeurigheid van een rubidium klok dat is eigenlijk enkel middels GPS te bereiken.
-Client site : diverse leuke grafische toepassingen afhankelijk van wat met wil.
En vooral... het hele project als een geintegreerd project zien en niet als een zoveolste ICT project ! ICT is gewoon een van de aspecten ervan (en reken dat ik daar heeeeeeel argwanend naar kijk want ik ken mijn pappenheimers maar al te goed)

[pa5cal]

Naamgenoot:

De spijkers op de respectievelijke koppen.

het frontend moet een nuttige bandbreedte hebben wat met zich meebrengt dat er een zekere hoeveelheid kosten aan zal zitten en ook dito bandbreedte (200kb/s op 16bits is op 8bits weer gewoon 400k/s ruwweg dus er verander in dat opzicht niet zo heel veel)

preprocessing op de client is NIET mogelijk (wellicht zaken als notches ofzo, maar zelfs daar zie ik het nut niet zo van in) gezien je nu juist data wilt gaan proberen te extrapoleren en vinden die je "met het blote oog" niet kunt vinden. Kortom een continue stroom van data richting de server.

Compressie is een cpu intensief iets zodra je forse compressie wilt bereiken. Niet alleen dat, maar aan de serverzijde heb je deze power ook weer nodig om te decompressen (tenzij je er voor kiest het zo op te slaan en pas bij bewerking weer uit te pakken). UDP is natuurlijk een leuk idee maar je zult ten alle tijden een tcp crc mee moeten laten lopen, je wil immers (liever) geen data missen. Hoewel een pakketje zo af en toe niet meer dan een fractie van een seconde gewoon een gat opleverd op je set. Dat zou te overwegen kunnen zijn. Feit blijft dat de overhead van TCP vs UDP niet zoveel opleverd in beschikbare bandbreedte.

Realtime processing aan de serverkant kan wel een aardig cpu intensief worden. Wat men bij de websdr's doet is niks anders dan een datastream in memory bufferen, fft eroverheen en een selector maken waarbij je een bepaald segment (xx Khz breed) vervolgens naar je lokale audio kaart gestuurd wilt hebben. Ze slaan niks op, tis allemaal realtime zonder verdere processing. Het enige wat cpu vereist is die fft schrijven. Het omzet werk gebeurd namelijk in de java-muk die op jouw pc draait. Dus wdb is alles client side, ik denk dat onze software gelijk moet werken. Intelligentie in de client, die specifieke data opvraagt op de smurfer.

Als je kiest voor het afkopen van bandwidth ipv traffic dan maakt up of down niet meer uit, zolang je maar binnen de xxMbit blijft (95th percentile) toch nog niet goedkoop

De servers zijn SPARC overigens voor jou beeldvorming (de voorgenoemde sun enterprise bakkies) maar andere hardware is natuurlijk net zo goed mogelijk. Uiteraard moet de software FOSS zijn, en compilen op *

PS dit alles draait natuurlijk op kernergie.

-P

[coolepascal]

Ja ik begrijp dus dat bij websdr het 'tunen' toch middels een fft bij de server gebeurd ? lijkt me ivm datatrafic heel aannemelijk maar 100 maal realtime een fft draaien is ook geen kattenpis.
Ik krijg dingetjes mer hele vette datatrafic fatsoenlijk werkend, maar wat dat voor consequenties heeft voor het netwerk, mijn portemonee en het milieu wil ik niet tot mijn probleem maken.
Ik ben aleen maar geintereseerd in de technologie, en nee ik ben geen mad scientist ik heb gewoon een sociaal leven.
(p.s. of had je echt verwacht dat ik er in zou trappen)

[pa5cal]

De fft wordt zo te zien eenmalig gegenereerd en vervolgens als een stream naar de clients gepushed. Mogelijk krijg je de hele stream zo naar je toe en is alles client side, dat kan ik nu even niet nagaan. De serverkant is iig niet al te zwaar belast in dat opzicht

Ik ben altijd geintereseerd in "groot" Altijd al zo geweest, maar dat neemt niet weg dat ook al krijg ik het werkend dat mijn knip wel een beperkende factor wordt, uiteindelijk.

-P