Hello Votjeck and all, TKS for all the information.
>I do not think that phase delay equalization is needed for MFSK modes. A simple frequency amplitude equalization is what I meant. I think OK I understand now. Yes I thought of a phase delay equalization. In Olivia, there must be a sort of frequency "equalization" in the Olivia bandwidth: you calculate the average for each considered frequency, then from this field of averages you "equalize" so as to have the same weight for each frequency. This is almost compulsory. If not done the decoding is not very good in case of QRM. >I am not sure I understand this statement. Pawel's code runs FFT two >times faster than the symbol speed and with double spaced bins than.... Yes I saw this and I thought it was a good idea so I applied this principle to the RS ID. But for Olivia and modes in general, if your baud rate is not a sub-multiple of the sampling frequency you cannot apply a FFT. So the easiest is to do a bank of matched filters. Note: FFT is also a bank of matched filters but in a configuration which permits to calculate them rapidly. >Do You mean You actually do the AFC exactly and You synchronize the >symbols as in the case of MFSK16? The symbol synchronisation is done as in MFSK16 but the "AFC" is done as it must be done with a very sharp correlation function (Olivia and clones + RS ID), i.e you sweep the frequency and see what band match the best. In MFSK16, there is no such very sharp correlation function, so the AFC is done in a more classical way. > The issue with FFT computed by fixed point arithmetics is that it is far less > exact than the >matched FIR filters. Although it is good enough for > waterfall, it may not be good >enough for the decoder. I calculate all in "Longint" (-2E9 to 2E9). It's sufficient. >I expect the same will hold for any MFSK code like MFSK16 or Throb. Yes normally this principle could be used to MFSK modes but only if you are sure to have an equal probability of presence between all possible carriers, which is not sure in MFSK16. Note: if you know how to decode Contestia, you could add the other Olivia clones as Pax, Pax2 and Voice (mode for blind Hams). All the information is in my help. In PAX and PAX2, you could send Unproto messages as APRS positions, for example. 73 Patrick ----- Original Message ----- From: Vojtech Bubnik To: digitalradio@yahoogroups.com Sent: Tuesday, January 09, 2007 9:33 AM Subject: [digitalradio] Re: Channel Equalization, was: best mode to use for weak signal Hi Patrick. Thanks for the info. I hope it was useful to the othes too. That's the reason I discuss it on the list. Pawel's input processor does basically the following. - Splits input stream to chunks that half overlap - Applies a window to the chunks. - Computes FFT - Averages each FFT bin energy - Equalizes the bins by the averaged bin energies. - Converts back to time by IFFT - Applies a window to the time signal and overlaps the equalized time chunks - Now the time stream is expected to be amplitude limited and amplitude peaks will be cut by a clipper. I think this last step shall resemble burst removal > In HF there would be no interest as the channel transfer function moves all times and too quickly. I believe it. > Moreover it will need some impulse in input so to determine the transfer function with output and input, which is not expected. I do not think that phase delay equalization is needed for MFSK modes. A simple frequency amplitude equalization is what I meant. I think that it may make sense to "callibrate" FFT decoder by a white noise ran through the RX. That would equalize against the RX filters. But I expect that most of the HAMs woud never use it. > Note: Pawel code uses FFT, Multipsk (and surely Mixw) use a bank of matched filters so as not to be obliged to handle only one frequency. I am not sure I understand this statement. Pawel's code runs FFT two times faster than the symbol speed and with double spaced bins than frequency spacing of Olivia symbols. That generates 4 symbol streams. The FFT window is matched against the Olivia symbol envelope. The issue is that the symbol time and frequency will be 1/4 symbol frequency and 1/4 symbol time off in worst case. On the other side it will synchronize to the other side very fast. Do You mean You actually do the AFC exactly and You synchronize the symbols as in the case of MFSK16? My code uses the Pawel's method. The issue with FFT computed by fixed point arithmetics is that it is far less exact than the matched FIR filters. Although it is good enough for waterfall, it may not be good enough for the decoder. I had to rewrite the SFFT filters of gMFSK's MFSK16 to simple FIR filter bank because of numerical problems on fixed point ALU. I tried to generate Olivia to the speakers by MultiPsk and receive it with PocketDigi by the internal mic. If I whissle somewhere in the middle of the olivia stream spectrum, the decoding is totally disrupted. I will try the same test with gMFSK yet, which uses Pawel's code with channel equalization and I expect that the channel equalization may remove the constant carrier and push the data through. I expect the same will hold for any MFSK code like MFSK16 or Throb. > >running on my 200MHz StrongArm PocketPC with channel equalization Sorry, I meant without channel equalization. 73, Vojtech OK1IAK
