Ladies, Gantlemen,

Please let me ask your help on my problem. MATLAB code (at https://metrw-pitch.blogspot.com/ you can see code in .mlx (for run it you want delete comments) and .m format) executing in MATLAB online R2020b, outputs good accuracy even for low fundamental frequencies (fundFreq) but code (originally in my answer to a question of mine) of similar algorithm in C++ (acctually I have translated this code into Matlab's language), executing in Visual Studio 2019, outputs bad accuracy in low (lower than 150 Hz) frequencies.

Question is whether MATLAB's code executing in dsp kit retains its accuracy. I'm homeless (in France) and get internet access in Social Services and Post Offices like this I'm just now. So it's impossible for me to run code in dsp kit. You are kindly requested test MATLAB's code in your dsp kits and say me its output for fundFreq 50, 60, 70 Hz. Be aware when change FundFreq, change, if necessary, FFTfundFreq and/or GridDemiSpan so that grid's span covers FundFreq.

I have asked similar question on 8 Feb 2021 at 13:25, at MATLAB but nobody answered yet.

Copy of Matlab's code without comments is following.

format long;
SampFreq = 16000;
Segm = 1:1600;
FundFreq = 50;
FFTfundFreq = 41;
GridDemiSpan = 10;

FirstHarmAngles = FundFreq*2*pi/SampFreq*Segm+1.9*pi;
SinFirstHarmAngles = sin(FirstHarmAngles);
SecondHarmAngles = FundFreq*2*2*pi/SampFreq*Segm+0.9*pi;
SinSecondHarmAngles = sin(SecondHarmAngles);
ThirdHarmAngles = FundFreq*3*2*pi/SampFreq*Segm+0.3*pi;
SinThirdHarmAngles = sin(ThirdHarmAngles);
Xn = 170000*SinFirstHarmAngles+220000*SinSecondHarmAngles+...

Freqs = FFTfundFreq-GridDemiSpan:0.1:FFTfundFreq+GridDemiSpan;
MagnSqrd = ones(1,201);

for f = 1:201
   Angles = Freqs(f)*2*pi/SampFreq*Segm;
   XnCos = sum(Xn.*cos(Angles));
   XnSin = sum(Xn.*-sin(Angles));
   MagnSqrd(f) = XnCos.^2+XnSin.^2;

[maxMagnSqrd, maxMagnSqrdIndex] = max(MagnSqrd);
GRIDfundFreq = Freqs(maxMagnSqrdIndex);

With regards and friendship, Georges Theodosiou


Yes, C\C++ code generated from Matlab/Simulink code should behave the same as the original code.

However there are a few caveats, here are 3 problems I've experienced in real-life.

1 - Simulink\Matlab performs an implicit reset just before starting the simulation/script. Make sure you perform this reset in your C\C++ code, otherwise your results won't be the same and won't be comparable. Simulink coder generates a reset function for you. I've seen a corner case where the reset function would not reset all global variables, so be careful.

2 - Variable types. Matlab/Simulink typically use double-precision floating point variables. If your code uses doubles then great. The behaviour should be the same. However, for performance reasons, you might choose to use single-precision floating point variable aka floats. Then the behaviour could change slightly. There are ways to mitigates the effect of quantization, some algorithms are really sensitive to precision, others less so. Even if you use doubles there are some difference between platforms. So if you use doubles on an ARM µProcessor, the behaviour could be slightly different in corner cases.

3 - Integer saturation. I made the mistake in the past of using a 32-bit integer in Matlab as a free-running counter. It worked well, but after like 10 days the code would freeze. The counter would be stuck at 2^32-1 instead of wrapping back to 0. Obviously, you won't see that behaviour in simulation. So be careful, test your code thoroughly.

  • $\begingroup$ Mr. Ben, please accept my many thanks for you answered my question. Could you please let me know code's output for FundFreq 50, 60, 70 Hz executing in dsp kit? Regards. $\endgroup$ Feb 15 at 14:47
  • $\begingroup$ Mr. Ben please let me comment your suggestion for double precission. For fundamental frequency 50 Hz, code C++ outputs 53.2 Hz with either double or float precission. Matlab's code (executing in MATLAB online R2020b) with short (float) precission (format) outputs 50.6000 Hz, and with long (double) outputs 50.600000000000001. Default format of MATLAB online R2020b is short (float). Regards. $\endgroup$ Feb 16 at 9:42

As long as your C++ implementation uses the same data types and the same algorithm structures the results should either be very close or even bit-exact, provided both platforms are compliant with "normal" standards, i.e. IEEE-754.

The link to the Matlab code doesn't work ("forbidden"). A quick look at your C++ code shows that you are using float as your main data type, which has 32-bits of precision. Matlab's default data type is double which is a 64-bit type. Unless your Matlab code specifically uses single, I would expect your Matlab code to perform much better than the C++ code.

  • $\begingroup$ Mr. Hilmar, please accept my many thanks for you answered my question. I have posted link's URL itself. Please let me know whether you see code. Matlab's code output 50.6000 is single number. Regards. $\endgroup$ Feb 10 at 13:31
  • $\begingroup$ I would have voted up, but most DSP algorithms should be well conditioned. Their performance should not be affected much by using singles vs doubles. $\endgroup$
    – Ben
    Feb 10 at 13:34
  • $\begingroup$ For example an order-8 IIR filter might be unstable using singles and be stable using doubles. However, a clever DSP engineer would split the order-8 IIR filter in 4 cascaded biquad filters. Biquad filters are less sensitive to quantization. $\endgroup$
    – Ben
    Feb 10 at 13:37
  • $\begingroup$ Mr. Ben, please accept my many thanks for you commented my question. Both codes output same for single and double numbers. $\endgroup$ Feb 10 at 13:38
  • $\begingroup$ Ladies, Gentlemen, please let me say my idea. Binaries obtained by Matlab's Coder in .lib or .dll libraries and are executed in dsp kit should output same accuracy, as code when is executed in MATLAB's compiler. Regards. $\endgroup$ Feb 12 at 13:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.