Yesterday, I tested my MAP decoder with noise for the first time. I decided not to do the 16 state design and fix up the DCLK problem (see the 7 December 1995 report). I was too eager to test the current 512 state design decoder with noise!
The AWGN noise is generated on a 486 PC using a C++ program written by Riccardo Macri in our group. The parallel port on the back of the PC is used to transmit the 8 bit quantised noise samples to the decoder. I put in an adder circuit in the MAPENC Xilinx chip to add the noise to the encoded signal. The adder circuit produces a 6 bit quantised result with a dead zone and 63 quantisation regions.
When I tested the new circuit I found the codec wasn't working anymore with no noise! After messing around for a day I discovered that the encoder was generating the wrong sequence. The code polynomials are serially downloaded into MAPENC on startup. I tried recompiling the Xilinx chip a couple of times, but that didn't work. When I looked inside the Xilinx chip (how did I do that?) I discovered that the clock line to the code polynomial shift register did not have a uniform delay to the registers. The XC3100A series chips that I'm using have a global clock (called GCLK) which goes to all the registers with uniform delay. There is an alternate clock line (called ACLK) which I use for the shift registers. Unfortunately, as I discovered, ACLK may not give uniform clock delays. Thus, for two registers, ACLK went on a long looping path, while the data line was very short! Since lines have delays in PGA technology this meant that the serial data would not be clocked properly. I shifted the two registers so that the clock lines had uniform delay and voila, the codec worked again!
I think the above was also the problem I was having with DCLK on MAP3. DCLK also uses the ACLK line. My latest compilation of the simplified MAP3 seems to have fixed the problem.
After fixing MAPENC I then proceeded to get a PC. Unfortunately, this PC has Windows 95 installed which has the annoying habit of spontaneously returning to Windows 95 from DOS. I went to another PC to produce a boot disk. However, the PC wouldn't boot properly and then Windows 95 wouldn't boot. Oh Oh! Rick had this problem before when the JUNKIE virus got onto his PC. Sure enough, after scanning the PC, the JUNKIE virus was on there. After getting rid of the virus (and telling the rest of the group to be more hygenic) we started the tests.
You can get a plot of the results in
http://www.itr.unisa.edu.au/~steven/turbo/codec/map49.ps
As you can see, the MAP decoder performs significantly better than the Viterbi algorithm (computer simulation results) up to -1.5 dB, after which it performs significantly worse! I believe this to be (I hope!) due to using the same sigma in the decoder, i.e., I used the same lookup tables for the E operation. The current tables were optimsed for an Eb/No of around -3.5 dB. I also did not optimise the signal amplitude for each Eb/No. The signal amplitude was +/- 7 from a maximum amplitide of +/- 31. My next set of tests is to generate a bunch of MAPENCs and MAP1s with the optimum amplitude and E tables. These tests are to be performed next year after I think my much deserved holidays!
There are two new files at our turbo coding web site. There's a Master's thesis by Philip McIllree titled "Channel capacity calculations for M-ary N-dimensional signal sets" (not directly related to turbo coding, but the bounds are useful) and the C programs from Jean Yves Couleaud's report. You can get them from
http://www.itr.unisa.edu.au/~steven/thesis/pem.ps.gz
http://www.itr.unisa.edu.au/~steven/turbo/jyc2.c.gz
I have also created a web page for these status reports. The address is
http://www.itr.unisa.edu.au/~steven/turbo/codec/
Merry Christmas and a Happy New Year to everyone!
Steven S. Pietrobon, Satellite Communications Research Centre
University of South Australia, The Levels SA 5095, Australia.
steven@spri.levels.unisa.edu.au
http://www.itr.unisa.edu.au/~steven/