Hi Patrick and Simon. My code is derived from Patrick's, only I heavily optimized it to be executed on a less powerful fixed point arithmetics CPU. I am obsessed with optimization to increase battery life of the Pocket PC device.
I am refering to PocketDigi source code, misc/rsid.c. I believe fldigi used my source code as a starting point. rsid_search function receives samples @ 11025 and calculates 1024 point real FFT each time 1024 new samples are received. Therefore the FFT intervals overlap by one half. The sound card runs at 8 kSamples per second, but I have a resampler running outside of the rsid code to resample to 11025. Also the resampler takes care of the sound card clock correction. I have another resampler running for clock correction from 8ksamples to 8ksamples, but this one is only executed if clock adjustment is different from zero to save some battery time. Also resampling with fixed point arithmetics add some error. The main speed up of Patrick's search routine is done by "hashing". In case of RSID we are happy enough that it is possible to setup reverse lookup tables, which have no duplicate hits. The tables are setup in rsid_init. Encoded RSID code consists of 15 nibbles. Patrick decided to only accept a code as valid if it has zero or one error. I therefore prepared two reverse lookup tables from encoded RSID code consisting from 15 nibbles to the mode identifier index, which fits into single byte. Each of the reverse lookup tables have 256 entries, some of them may be empty - they lead to invalid RSID code. The first table is indexed by first and second nibble of encoded RSID, the other table with third and fourth nibble of encoded RSID. The idea behind it is that if there is a single bit error in the first two nibbles, there will be no error in the third and fourth nibble. After the two tables are resolved, the received code hamming distance is verified as in Patrick's original source code. My optimization consists therefore mainly in saving some 100 calls of Hamming distance calculation by using two table lookups, gaining probably speedup of about 50x. Another optimization is in CalculateBuckets(), which calculates maximum of 16 successive tones. It uses result of previous sweep in most cases. This probably speeds up the function about 4x. Not that significant if compared to the hashing trick, but after the hashing was implemented, even this little optimization becomes useful. I believe now the RSID decoding time depends mostly on the real FFT routine. My encoder generates phase coherent MFSK signal @ 8000, no resampling to 11025 is necessary. TX is done in main/trx.c, mainly in trx_txstate(), see case with TRX_STATE_TXRSID_TONE0 to 14. 73, Vojtech --- In digitalradio@yahoogroups.com, "Patrick Lindecker" <f6...@...> wrote: > > Simon, > > >Why must the sampling frequency be 11025? > because the Fourier is done with 2048 samples at 11025 samples/sec. At 8000, > the number of samples would not be a power of 2 and this Fourier could not be > a FFT but a standard digital Fourier (DFT) which takes times to do. So the > simplest way is to base all on 11025. > > For more details, read the "RS_ID_English.doc" file in > http://f6cte.free.fr/PAPERS.ZIP > > 73 > Patrick > ----- Original Message ----- > From: Simon (HB9DRV) > To: digitalradio@yahoogroups.com > Sent: Thursday, April 16, 2009 10:54 PM > Subject: Re: [digitalradio] Mode of the Day? RS ID on SdR bandwidth > > > > > > Hi, > > Why must the sampling frequency be 11025? > > Simon Brown, HB9DRV > www.ham-radio-deluxe.com > ----- Original Message ----- > From: Patrick Lindecker > > No problem, but I program in Pascal not in C...(Votjech did a C source). > The sampling frequency must be 11025, but it is not a problem to work at 8000. >
