i want to differntiate the signal. what is logic behind it.??

12 Mar 2013

hello friends

if any signal has to need differentiate it then how can we do it in mbed ?

as we know the differentiation of the sine signal is cos ,so if my input is sin then how can i get cos signal through the it

pls share the logic to differentiate the signals....

thank you.

12 Mar 2013

Differentiation is just a way to calculate the gradient of a curve at any point using the equation that generates it,

I don't think that's what you want?

To calculate the gradient of your signal just divide the new reading minus old reading by 1.

the division by 1 is redundant, but I'm assuming a fixed reading timing so you may need to modify it.

13 Mar 2013

Chris Pepper wrote:

Differentiation is just a way to calculate the gradient of a curve at any point using the equation that generates it,

I don't think that's what you want?

To calculate the gradient of your signal just divide the new reading minus old reading by 1.

the division by 1 is redundant, but I'm assuming a fixed reading timing so you may need to modify it.

thank you for replied i have been taking 200 sample in every cycle of 20msec. so u mean to say (y [i] - y[i-1] / ts) here y is variable inwhich signal is stored;ts sampling time. here 1 is represent the sampling time or the reading time , correct?

13 Mar 2013

signal processing through the mbed

#include "mbed.h"

DigitalOut myled(LED1);
AnalogIn I(p17);
AnalogOut aout(p18);

int main() {
    int i=0;
    float I_a;
    static float Ib=0,Ia[200];
    while(1) {
    Ia[i]=I;
    I_a=(Ia[i]-Ib)/0.000002;
   
    Ib=Ia[i]; 
    aout=I_a;
    i++;
    if(i==200)i=0;
            }
}

above written program i used for the differentiate the signal but result is not satisfactory in short as per above mention program there is no any effect on the signal , i have get same signal which i give to the adc. other thing is that output goes to below the dac range. then it does not see at dac, if you find any error in program then suggest me ..

thank you

13 Mar 2013

Pretty sure this wont get you a cos wave from a sin, I'm not sure how to do this with a signal, I'l have to think about it

14 Mar 2013

Chris Pepper wrote:

Pretty sure this wont get you a cos wave from a sin, I'm not sure how to do this with a signal, I'l have to think about it

thank you chris

i have tried on signal here we divided the signal by 2*10^-6 or sampling time that cause the signal is going to out of dac range.

so we cant divided the signal by that much smaller amount, to show the signal in dac range then we have to set proper value for division.

i can see signal on dac after selecting proper value but signal is too noise and wave shape is not same as cos signal.

i think we are near to the solution, we just need one point to correction.

if you have more batter idea to do it then...

15 Mar 2013

I don't understand why you use an array, the present and previous value are sufficient for your calculation. You account for the sampling time in your calculation but you do not enforce this sampling time. The real results depends on your real signal, this is the difference between a mathematician and an engineer. A real world signal is not just 'sin x' but has a frequency, amplitude, phase, noise, offset etc. Let's assume your signal is s(t)= A*sin(2*pi*f*t+phi) + B; your sampled signal is s(n)=A*sin(2*pi*f*n*T+phi) + B Now you take the difference c(n+1) = (s(n+1)-s(n))/T = 2*A/T*sin(pi*f*T)*cos(2*pi*f*n*T+phi+pi*f*T) for T very small this becomes A*2*pi*f*cos(2*pi*f*n*T+phi+pi*f*T); so here you have your 'cos x' but as you can see is is scaled by 2*pi*f, which is to be expected even for mathematicians when you consider the chain rule.

16 Mar 2013

Ad van der Weiden wrote:

I don't understand why you use an array, the present and previous value are sufficient for your calculation. You account for the sampling time in your calculation but you do not enforce this sampling time. The real results depends on your real signal, this is the difference between a mathematician and an engineer. A real world signal is not just 'sin x' but has a frequency, amplitude, phase, noise, offset etc. Let's assume your signal is s(t)= A*sin(2*pi*f*t+phi) + B; your sampled signal is s(n)=A*sin(2*pi*f*n*T+phi) + B Now you take the difference c(n+1) = (s(n+1)-s(n))/T = 2*A/T*sin(pi*f*T)*cos(2*pi*f*n*T+phi+pi*f*T) for T very small this becomes A*2*pi*f*cos(2*pi*f*n*T+phi+pi*f*T); so here you have your 'cos x' but as you can see is is scaled by 2*pi*f, which is to be expected even for mathematicians when you consider the chain rule.

you are absolutely correct.. i have made mistake there but now i am clear about that . thank you so much.

And new question also arise here is that as we know the sin (2*theta)= 2*sin(theta) *cos(theta)

now if i do it in the external multiplication of the two signal then then it return signal is in double in frequency and complete sinusoidal in nature but same thing i do through the controller then return signal have positive hafl is there but negative half is not proper in shape even the frequency is not exactly double.

second problem is that if i try to take square of the signal then return signal is not correct, is it reason of data type of variable? if i use the function pow(Ia,2) ,in this case also proper signal is return .

as mention above both cases the signals on which i perform the process,are individually verified many of times, they are correct in phase angle and magnitude vise.

so i don't get the point why it not multiplied two signals correctly.

one thing must br noted that in this process i remove the dc offset from the signal and for show on dac i add the dc offset in signal.

title

  #include"mbed.h"
  #include"math.h"
  AnalogIn I(p17);
  AnalogIn I1(p19);
  AnalogOut aout(p18);
  
  main()
  {
  int i;
  double Ia,Ibeta,Ib,x;
  static float dif_th,tan_x,tan_b;
  
  while(1)
  {  
      Ia=(I-0.5);
      Ib=(I1-0.5);
           
      Ibeta = (0.5774*Ia)+(2*0.5774*Ib); 
      x=Ia*Ia;
      //x=pow(Ia,2);     
 aout=x+0.5;
      
           
     }