EE 265 Project Labs & Documents
Requirements
1. You should define a ‘variable’ for
your ‘input buffer size’.
Your Matlab code should take only the amount defined in the variable at once
and process it and take the next buffer and so on.
Try to make Matlab prototype be similar to real time C code for DSP.
Your code should work with any reasonable input buffer size. For example, 200 ~ 500.
Change the buffer size you defined and test your code again. You may find out some hidden bugs in
this way.
2. Avoid complex division in your code. Think about how you could implement
complex division for DSP.
You could simply change complex division to complex multiplication.
3. Don’t use ‘corr’ and
‘conv’ functions for sync detection.
We don’t have those kinds of fancy functions in C. Always remember that you will eventually
convert your Matlab prototype into C!
‘ifft’ and ‘fft’ functions are allowed for the
prototype.
Tips
1.
e.g.) input =
wavread('inf_8000.wav');
2. Writing ‘dat’ file: If you want to verify your output
using ‘verify.m’ function, you should write the output using
‘dlmwrite’ function.
e.g.) dlmwrite('inf_8000.dat',
total_output, ',', 1, 0);
3. Use ‘char’ and ‘double’
to change between ASCII numbers and Characters in Matlab. This is only for debugging purpose.
e.g.) char([102 117
110])
double('fun')
Tips
1. Use C55x Compiler
Intrinsics (extracted from C55x DSP
Programmer's Guide) in order to manage saturation.
For example, ‘_sadd’ and ‘_smpy’ would be
particularly useful.
2. Many students spend time to change line numbers
of break points for Matlab verification code.
Use my ‘generate_linenum.m’
code to make your life easier.
First add ‘// MATLAB Break Point ’ as a comment where you want
to put break points in your C code.
Usage)
source_file = 'main.c';
linenum_break = generate_linenum(source_file);
for break_index = 1:length(linenum_break)
insert(cc, source_file, linenum_break(break_index)); % Insert breakpoint
end
3. If your inputs to ‘_smpy’ function are
too small, the function may return zero instead of a correct number.
You could increase size of your inputs using ‘NOSCALE’ version
of ‘cfft’ or ‘rfft’.
4. Avoid ‘Int32’ or 32 bit FFT in your
code as much as possible.
Your basic QPSK receiver should work fine with ‘Int16’ and 16
bit FFT only. Performance also
matters and ‘float’ is
definitely not a way to go.
Tips
1. You don’t need to use
‘readBuf()’ function because the input buffer is automatically
filled in.
Just process data in the input buffer and save
the result using ‘writeBuf()’ function.
2. When you play a ‘wav’ file, mono
signals are transmitted via stereo channel, so the source buffer is filled with
two
identical samples. You should take
every odd or even sample for processing, not both!
3. How to test your code:
1) Run your code in DSP and play your input
‘wav’ file generated by ‘pulsegen.m’.
2) Halt your code after the audio play.
3) Save the processed result stored in DSP memory
into a ‘dat’ file:
CCS Menu -> File -> Data -> Save -> Specify file name & Set
‘Save as type’ to be ‘Integer (*.dat)’
-> Press ‘Save’ -> Address: 0x100000, Length: 0x100000, Page: DATA -> Press
‘OK’
4) Now your result is saved as a ‘dat’
file. You can verify your result
using ‘verify.m’ script.
Tips
1. 16 QAM receiver is an extra work. Now you are allowed to use any fancy
stuff including ‘float’ variables.
I don’t care much about speed and memory usage of 16 QAM receiver. If it works, you will have extra
credits.
Make sure to save your QPSK receiver securely before moving on to 16 QAM.
You have to show me your basic
QPSK receiver even though you
made a fancier receiver.
2. You may need to use ‘q15tofl()’
function. Look at the DSP Library for further information.
3. You could also try 64 QAM modulation. Your 64 QAM receiver may not work
correctly according to my experience.
However, if you try it and discuss why it doesn’t work or something,
you will definitely get extra credits.
Requirements
1. Make a folder with your full name and copy
everything you made for the project into the folder.
Remove all ‘wav’ ‘dat’ ‘asv’
files. Also remove any testing
codes.
I’ll copy the whole folder using my memory stick, so don’t send
anything to me via email.
2. You should also include your Matlab
verification codes. It’s okay
that the verification code is not properly related to
your final receiver. I just
want to see if you used Matlab verification technique or not, because
we’ve learned it and it’s
quite useful technique.
3. Make a ‘ReadMe.txt’ file in your
top folder and include explanations in the ‘txt’ file that which
file is for what.
I’ll go through every code and evaluate it. If you find any bugs before the
deadline, you can submit revised codes again.
If I find your bug during evaluation after the deadline, you’ll
definitely have penalty.
Requirements
1. You should calculate your maximum data rate for the report.
* data rate calculation example in the project description handout
24(carriers) * 2(bits/carrier/symbol) *
8(ksamples/second) / 72(samples/symbol) = 5333 bps
There are several ways to increase your data rate. The easiest way is to change sampling
rate.
You could try sampling rates other than 8 kHz. Your receiver may not work at high
sampling rates.
Another way to increase data rate is to use 16 QAM or 64 QAM modulation.
You could also try to put more than 14 symbols in a packet, but always
remember to save your
unmodified version of basic QPSK receiver securely. That’s the one that I care the
most!!
2. Feel free to use colors in your report, but
don’t include codes in the report.
You don’t need to prepare a hard copy of the report. Just send one ‘doc’ or ‘pdf’
file to jwseo@stanford.edu .
3. If you had any interesting observations when
you play with your receiver, it is recommended to mention about them
in the report. Project report is open-ended, so please
include any discussions you want.
Last
modified: Mar. 19, 2008