frikkiemarais

...struggling...

...

ADC reading as fraction Q1.15.

Since I couldn't glean enough information from your post to see (or guess) why your results don't match your expectations, I'll make a couple of general observations and suggest a way that may get you a little further along.

I did a fair amound of DSP work a few years ago (not with PIC devices and libraries), and I found four sticking points, which I will list in order of increasing probability (least likely first):

- Library code is faulty. Probably not, but it's always possible that OPC (Other People's Code) is buggy.
- The library code is correct but I wasn't calling it correctly. Maybe a documentation deficiency, but more probably my fault It's always possible that even my code is buggy. Really. It could happen.
- Results were correct but I interpreted them incorrectly. Happened a lot, especially when I first studied DSP. Way Back When the only bible was Oppenheim and Shafer and examples in FORTRAN were in a couple of hardback IEEE publications.
- Input signals were incorrect. Either incorrectly measured values or values not in the correct order in a properly sized array. That's why I always started with mathematically correct values and made sure everything worked as expected before turning the program loose with real-world data.

I'll start with the last one:

Instead of trying to figure out what the heck is happening with input captured from an ADC, why not just generate a specific set of input data and see if the results make sense?

For example, I made a little python program to generate some time-domain sample values and create the code to put them into an array consistent with the way it is used in CE018. I think this might be something close to what you are trying to test, but I can't really tell whether this is what you had in mind.

// FFT_BLOCK_LENGTH = 64

// Sample frequency = 3200 Hz

// Frequency 1 = 50 Hz, Amplitude = 0.250

// Frequency 2 = 250 Hz, Amplitude = 0.125

//

fractcomplex sigCmpx[FFT_BLOCK_LENGTH]

__attribute__ ((section (".ydata, data, ymemory"), aligned (FFT_BLOCK_LENGTH * 2 *2))) =

{

{0x0000, 0}, {0x0AAE, 0}, {0x138C, 0}, {0x1936, 0},

{0x1B07, 0}, {0x193C, 0}, {0x14E6, 0}, {0x0FA8, 0},

{0x0B50, 0}, {0x096D, 0}, {0x0AEA, 0}, {0x0FDA, 0},

{0x1771, 0}, {0x2031, 0}, {0x2846, 0}, {0x2DF5, 0},

{0x3000, 0}, {0x2DF5, 0}, {0x2846, 0}, {0x2031, 0},

{0x1771, 0}, {0x0FDA, 0}, {0x0AEA, 0}, {0x096D, 0},

{0x0B50, 0}, {0x0FA8, 0}, {0x14E6, 0}, {0x193C, 0},

{0x1B07, 0}, {0x1936, 0}, {0x138C, 0}, {0x0AAE, 0},

{0x0000, 0}, {0xF552, 0}, {0xEC74, 0}, {0xE6CA, 0},

{0xE4F9, 0}, {0xE6C4, 0}, {0xEB1A, 0}, {0xF058, 0},

{0xF4B0, 0}, {0xF693, 0}, {0xF516, 0}, {0xF026, 0},

{0xE88F, 0}, {0xDFCF, 0}, {0xD7BA, 0}, {0xD20B, 0},

{0xD000, 0}, {0xD20B, 0}, {0xD7BA, 0}, {0xDFCF, 0},

{0xE88F, 0}, {0xF026, 0}, {0xF516, 0}, {0xF693, 0},

{0xF4B0, 0}, {0xF058, 0}, {0xEB1A, 0}, {0xE6C4, 0},

{0xE4F9, 0}, {0xE6CA, 0}, {0xEC74, 0}, {0xF552, 0}

};

The attachment shows a plot of the 64 real-valued samples that were used to generate the

~~Q15.1~~ Q1.15 entries in the above table.

Bottom line: What happens when you try this in your program?

If this doesn't help, then how about showing what is in your sigCmpx array before and after the call to the FFT function? What is in the array after you do the Bit Reverse?

Note that I simply never depend on the IDE to show me what is in an array (or any bloomin' thing else) for my test/evaluation programs. I just print out the values. That way I can save the results for my notes and I can share the results with others who might be interested.

Regards,

Dave

post edited by davekw7x - 2019/09/20 16:23:28

#### Attached Image(s)