Nödvändig bandbredd för FSK?

[xxargs]

Hittade ett lib om 'soft-modem' med källkod hos microchip för dsPIC och implementerar upp till 2.4 kbit modem (V22) med allt vad det innebär inklusive equlizer (med hilberttransform), klockrecovery (tror också det var hilberttransform där), både PSK och FSK. Dock ingen V32bis eller V42 med med viterbi/trellis då det är något man får/fick betala för.


Om det är användbart vet jag inte än och det är inte helt lätt att ge sig på redan mer eller mindre optimerad Assemblerkod (förvisso kommenterad) och framförallt hur man skall peta på koefficienterna som används i algoritmerna där.

[AndersG]

Intressant! Länk?

[xxargs]

Jävlar mig inte lätt att hitta - himla massa länkar som pekar på tillhörande pdf-dokumentet från alla riktningar men inget som pekar på var själva såsen finns......


http://ww1.microchip.com/downloads/en/D ... emFree.EXE

självuppackande .exe-arkiv så är man känslig för sådant...

skulle du mot förmodan hitta versionen med V32bis och V42, så får du gärna säga till...

[AndersG]

skulle du mot förmodan hitta versionen med V32bis och V42

De var tydligen inte gratis: http://ww1.microchip.com/downloads/en/D ... 70128a.pdf

Manual

[AndersG]

Filen från i går

1kHz MF, litet svag signal i början medan jag trimmade spolarna. Dessutom litet störningar från laptopen jag spelade in på. Pekplattan genererade ett irriterande vissel och nätdelen var inte att tänka på att ha inkopplad..

[AndersG]

Hittade ett lib om 'soft-modem' med källkod hos microchip för dsPIC och implementerar upp till 2.4 kbit modem (V22) med allt vad det innebär inklusive equlizer (med hilberttransform), klockrecovery (tror också det var hilberttransform där), både PSK och FSK.

Enligt dokumentationen är V.21 och v:23 FSK, V.22 är PSK/QAM. Problemet med NAVTEX är ju bristen på startbit. Har skrivit ut delar av manualen och skall kolla. Kanske man kan få ut ngt av koden.

Edit:

Kod: Markera allt

; -----------------------------------------------------------------------------
;  Description:   In the V23 demodulator, the instantaneous sample is
;                 multiplied by a sample that arrived PI / 2 samples earlier. 
;                 The product_signal contains double frequency component and
;                 the baseband signal. This signal is filtered using a low
;                 pass filter to remove the high frequency component.The low 
;                 frequency base band signal is input to the slicer. The 
;                 slicer checks the zero crossings and identifies a sample 
;                 for decision.The zero crossings of the LPF are monitored 
;                 for adjuusting the local sampling clock.
;                 In data modem data transfer is enabled after validating 20
;                 continous binary 1's in the received bit stream.
; -----------------------------------------------------------------------------

Mao, kvadraturdemodulering?

[AndersG]

Denna artikel: Improved Automatic Threshold Correction Methods for FSK, har en hel del intressanta synpunkter på just FSK-demodulering.

[guckrum]

Det är ju vad jag gör nu. Jag samplar denna mitt i en symbol, men för att hitta denna mitt så kollar jag nollgenomgångarna. Om denna uppträder för snabbt efter en symbolmitt, justerar jag samplingspunkten framåt om den sker för snabbt justerar jag bakåt.

Ok, jag missade det. Är med nu.

Tror förresten att jag har en obesvarad fråga litet tidigare upp:

Bitrate och symbol rate är väl samma sak i FSK?
(KLIPPT BORT SAKER HÄR)

Dvs om jag adderar signal och brus 1:1 i Octave. Då är bitrate 100Hz, men vad är bandbredden? Inte helt vitalt för detta, men jag försöker förstå.

Ursäkta ignoransen, den är inte avsiktligt:-) Det här med för lite tid och så...

Javisst (*), i Binär FSK, det som används i NAVTEX, är det en bit per symbol. Då är alltså Eb (energin per bit) = Es (energin per symbol). Ett lite utförligare svar kommer här, där jag försöka ta det ur ett "ingenjörsperspektiv" utan formler först. (Kommentarer har jag för läslighetens skull numrerat och lagt efter). Så.
- Antag att våra matchade filter är "perfekta" och har en bandbredd på 100Hz (1).
- Vår önskade signal kommer att släppas rakt igenom dessa filter. Ingenting tar bort, så signalenergin efter filtrering är samma som före (2).
- Det vita bruset (3) däremot är spritt helt platt över alla frekvenser. Filterna kommer bara att släppa igenom 100Hz av detta per filter. Om vi antar Fs=8000Hz så har vi 4000Hz unika frekvenser under Nyqvist halva, och 100/4000 är 1/40, så 2.5% av brusenergin kommer att släppas igenom av ett filter. För två filter blir det 1/20 = 5%. Så om du la till brus med precis samma energi som signalen (0dB SNR) så kommer det på andra sidan av filterna vara 13dB SNR (10*log10(20)). Och det är ju detta som räknas, hur bruset påverkar avkodningsbesluten.

Kommentarerna:
1. Jag tycker det är en helt okej approximation av hur det ser ut i din mottagare.
2. Om energin skall bevaras genom filtreringen måste man i praktiken normera filterkoefficienterna så att DC-förstärkningen blir ett, men det är trivialt, och spelar ingen som helst roll i detta sammanhanget, eftersom både signal och brus går genom samma filter och vi tittar på kvoten av dessa.)
3. Metakommentar: det finns så mycket att säga (och fråga) om bruset och det kommer inte ut välformulerat så jag avstår tills vidare.




(*) I NAVTEX-fallet är det ju så att datan sänds med redundans. Varje bit skickas två gånger, så det är faktiskt bara ungefär en halv bit per symbol, dvs Eb = 2Es. Jag skriver ungefär för vissa koder ändrar "mod" på vad symbolerna betyder, typ "numeriskt fr.o.m. nu", vilket strular till det så pass att sådana som jag tänker att jag bara skall minnas det när det biter en och i övrigt bara ignorera det.

Att varje bit skickas två gånger betyder att man kan vinna tre dB genom att helt enkelt addera amplituderna från de redundanta bitarna till varandra före man tar beslut (FÖRE kvadrering, och man får skyffla in datan i en FIFO för senare kombinering.). Signalamplituderna kommer då att adderas till det dubbla, medan bruset, som vi antar är vitt, bara adderar till roten ur två. En dubbling av Eb/N.

För att spinna vidare tror jag att man kan öka Eb/N för den avkodade signalen ytterligare eftersom man vet att fyra av sju bitar alltid är ettor, så man tar beslut att sätta de sannolikaste fyra ettorna. (Hade man haft tillgång till en checksumma kunde man experimentera med att ta de näst sannolikaste fyra bitarna osv tills man uppfyller checksumman. Detta liknar en teknik som när den används med faltningskoder brukar kallas "list-Viterbi" avkodning, eftersom man skapar listor på möjliga avkodade meddelanden sorterade i minskande sannolikhetsordning, och så provar man dem en i taget från toppen och neråt till man får träff, slut på minne, tid eller tur, eller ger upp.)

[AndersG]

Så om du la till brus med precis samma energi som signalen (0dB SNR) så kommer det på andra sidan av filterna vara 13dB SNR (10*log10(20)). Och det är ju detta som räknas, hur bruset påverkar avkodningsbesluten.

OK. Då hänger jag med i resonemanget. Eftersom allt jag är intresserad av i frekvens befinner sig inom filtren, så måste jag även bara filtrera ut detta från bruset på det sätt du beskriver.

Edit: så för att få en testsignal med 6dB SN så måste jag ta signalen plus bruset fyra gånger.

[guckrum]

Samma energi i signal och brus ger 0dB SNR på filternas ingång. För 8kHz sampeltakt och de två tidigare givna filterna ökar SNR med 13dB om vi tittar på summan av filternas utgångar. (Denna massiva "ökning" eftersom det mesta av brusenergin ligger utanför signalens och filternas bandbredd därmed filtreras bort.)

Om vi ökar brusets amplitud en faktor två kommer filternas ingång istället att se -6dB SNR. Obs minus, bruset dränker nu signalen. Och en dubbling av amplituden motsvarar fyra gånger mer energi, så inalles -6dB.

Efter filterna borde man då se -6dB + 13dB = 7dB. Eller? Jag brukar skriva en väldigt enkel "kalibreringsbänk" för att mäta sådant här.


Sidnot. Om

Kod: Markera allt

>> n = randn(1,10000);
>> n*n'
ans =  9930.3

är "såklart"

Kod: Markera allt

>> n = 2*randn(1,10000);
>> n*n'
ans =    4.0569e+04

som visar att dubbling av amplitud ger fyra gångers energi, medan

Kod: Markera allt

> m = randn(1,10000) + randn(1,10000);
>> m*m'
ans =    1.9991e+04

visar att två okorrelerade signaler ibland "förstärker" och ibland "dämpar" varandra så att energin bara blir dubbelt så stor vid addition. (I detta andra fallet har vi alltså två separata "realiseringar" av samma stokastisk process.)

[AndersG]

Samma energi i signal och brus ger 0dB SNR på filternas ingång.

Suck... Jag trodde jag fattat detta, men nej.

Det som jag inte begriper är när man skall och när man inte skall beakta bandbredden. Men:

This will ensure that the NAVTEX receiver is provided with an RF S/N of 8 dB in a 500 Hz bandwidth, as stipulated by the IMO.

Så det tolkar jag som om man skall mäta med en 500Hz bandbredd. Då skall signalen vara (8/10)^10 = 6,3 över bruset? Och om jag räknar 500/4000=0,125. Så får jag de facto bara 0,125 brus om jag adderar signalerna 1:1. Eller 9dB?

Jag jag förstått det rätt?

[guckrum]

Det som jag inte begriper är när man skall och när man inte skall beakta bandbredden. Men:

This will ensure that the NAVTEX receiver is provided with an RF S/N of 8 dB in a 500 Hz bandwidth, as stipulated by the IMO.

(Jag hittar inte det dokumentet, har du länk till det? Det jag hittar är https://www.itu.int/dms_pub/itu-r/opb/r ... -PDF-E.pdf som verkar vara en nyare upphottad variant.)

Det låter kanske konstigt, men bandbredden säger på ett sätt väldigt lite om prestandan på ett digitalt kommunikationssystem. (Man kan ju ändra bandbredden genom att ändra "sampeltakten" på systemet.) Därför abstraherar man bort den genom att använda storheter som Eb/N0. För mig är Eb/N0 en abstraktion som bara säger hur mycket kräm som används per bit i förhållande till bruset. Ingenting annat, dvs ingenting om bandbredd eller överföringshastighet. Det fina med detta är att man kan använda den när man jämför helt olika system eller implementationer mot varandra, eller en implementation mot teoretiska resultat.

Den vanligaste metriken för ett digitalt system är förhållandet BER (Bit Error Rate) mot Eb/N0. Det säger precis hur mycket fel man kan förvänta sig om man bränner si eller så mycket energi i förhållande till bruset.

Sedan finns det ju en verklighet med fysisk bandbredd och termiskt brus, och där är det SNR som gäller. Enkelt att förstå och så där. Men så möts de två världarna... I det här fallet när samma person bygger båda sidorna av systemet samtidigt!

Så det tolkar jag som om man skall mäta med en 500Hz bandbredd. Då skall signalen vara (8/10)^10 = 6,3 över bruset? Och om jag räknar 500/4000=0,125. Så får jag de facto bara 0,125 brus om jag adderar signalerna 1:1. Eller 9dB?

Javisst, om du adderar 1:1 till din 8kHz sampling har du 0dB (SNR) över 4000Hz, +9dB över 500Hz och +13dB över filternas 200Hz.
Skilnaden mellan de två sista är 4dB (10*log10(500/200)), så textens 8dB SNR motsvarar 12dB Eb/N0 för FSK-demodulatorn. En bra demodulator kommer inte att göra fel där så många gånger om året.

[AndersG]

Nä jag glömde spara den länken, men i den du länkade till så står det samma sak.

Du har helt rätt i att BER är ett vettigare sätt att mäta, men som gammal kortvågslyssnare så sitter det där med S/N i ryggmärgen.

Sedan är det ju sant att det i verkliga livet är sällan man har koll på hela kedjan. I verkliga livet kanske en konstruerar RF-delen, en annan DSPn en tredje avkodningen, men nu är ju detta inte ett kommersiellt projekt. Jag angriper det av samma orsak som män bestiger Mt Everest eler nyper servitriser i rumpan - För att den finns där. Rent praktiskt har jag antagligen ganska litet nytta av Navtex då jag seglar, men samtidigt är det kul att pyssla och lära sig nya saker.

Jag kommer att skriva ihop en projektsida då jag blir klarare och lägga ut all info så att andra intresserade kan se hur jag gjort. Det är så jag själv gör, kollar på andras konstruktioner. Ev skriver jag en artikel för Elektor.

Naturligtvis är det så att jag vill klara så dåliga S/N som möjligt, men den biten som är i mjukvara kan alltid förbättras i efterhand, kanske inte ens av mig, så jag skall försöka få ihop hårdvaran till ett litet mera hanterbart paket. Processorkort och RF-delen som piggyback.

Jag får även anse att jag inte kan kasta obegränsat med CPU-kraft på det hela heller. Tänkte klara mig under 100mA, men kanske 200mA är mera realistiskt. Om jag dessutom struntar i att lyssna hela tiden, utan bara då stationen skall sända så blir medelförbrukningen ganska liten.

[guckrum]

Det har varit väldigt roligt att följa ditt ambitiösa arbete. Själv har jag passat på att damma av saker som jag inte jobbat med på tio år, och det har varit mycket givande. Skall bli spännande att se hur det blir när det är klart!

Jag har en kort observation om NAVTEX också som kanske är värd att nämna. Alla spektrumplottar föreställande NAVTEX som jag sett har den egenheten att spektrum inte är symmetriskt, bumpen på höger sida är högre. Varje gång. Det måste väl vara för att det i medel skickas fyra ettor på tre nollor. Så när man mäter över ett antal symboltider får man 4/3 gånger mer energi på den höga frekvensen jämfört med den låga. Intressant design, en konsekvens av att prioritera enkelhet och funktion, tänker jag.

[AndersG]

Ja, jag har lärt mig massor. Har en Octave bok att läsa och en om DSP, avsedd för ingenjörer, inte matematiker på posten.

Det stämmer som du säger om spektrat, men jag har inte reflekterat över det, men det är säkert som du säger. Det är alltid flera ettor än nollor. Minst fyra ettor av sju.