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
