I guess I was not thinking that the double->int cast would just truncate...
Which could still be a problem. Does it work with int16, or with explicit casts?
I wasn't following all the previous discussion on this. How do you verify
correct results with the multiplies (a,b) and how does c==128 at some point
in the loop indicate an error?
If I remember you said it worked with TOSSIM, so it must(?) be a compiler
or library problem if sqrt() is really failing now...
MS
[EMAIL PROTECTED] wrote:
I know that the sqrt() function doesn't return an int value, but for me
it's ok, I tried to use this function and I accept this kind of
approximation with the truncation of the value, I'm working with integer
for the FFT.
Ing. Alessandro Balvis
Centro Ricerche ENEL - Pisa
[EMAIL PROTECTED]
any idea what sqrt() function you are linking to?
I doubt that a 'normal' root func would return an int.
MS
[EMAIL PROTECTED] wrote:
I dont' have problem with the packet maximum size, everything works ok
in
this way.
The problem is still with the int32_t data types:
...
int32_t a,b,c;
for (i=0,m=0;i<NSIGNAL;i+=2,m++) {
a=((dat[i]/10)*(dat[i]/10));
b=((dat[i+1]/10)*(dat[i+1]/10));//ALL DATA UNTIL THIS POINT ARE
OK
c=sqrt(a+b);
if((c == 128) && (m == 10)) call Leds.yellowOn();
...
I checked the data with the tinyviz, I reply the FFT algorithm to run
with
the simulator. Until the computation of "a" and "b" variables, I found
the
same values of the simulation (I used the check with the led).
After, when I calculate the "sqrt(a+b)", I don't found the same values,
something goes wrong.
Maybe there's some error? Thanks
Ing. Alessandro Balvis
Centro Ricerche ENEL - Pisa
[EMAIL PROTECTED]
Remember that packet maximum size is 28 bytes.
int32_t should not cause any problem .
[EMAIL PROTECTED] wrote:
This is a good advice, I'll try this first check.
For the packet structure I have no problem, I'm developping a little
application for MDA300, and I can read the other datas that I put in
the
payload without problems, well the problem is not with the packet.
It's possible that there's some problem with the management of data
type
int32_t? I can use this kind of data as well as the int16_t?
Thanks.
Ing. Alessandro Balvis
Centro Ricerche ENEL - Pisa
[EMAIL PROTECTED]
Signor Balvis,
una prima (grezza) controprova potrebbe essere quella di (se conosce
quanto deve essere il valore
corretto del risultato in anticipo) accendere dei led se il valore è
quello giusto. Del tipo:
if (zz.s[0] == <VALORE CORRETTO>) && (zz.s[1] == < VALORE CORRETTO >)
&&
.. )
call Leds.redOn();
Se il led si accende il risultato è corretto ma ci sono dei problemi
nell'invio. In questo caso
il problema è quasi sicuramente nel buffer di invio. Perchè accede a
partire dalla posizione 10
di data ? Provi da 0.
Inoltre ha allocato un messaggio di tipo Tos_Msg a cui poi farà
puntare
il puntatore
radio_msg_ptr ?
Si assicuri che tutto funzioni mettendo nel pacchetto quantità note e
vedendo se vengono
visualizzate correttamente.
Cordiali saluti
Andrea
[EMAIL PROTECTED] wrote:
Hy,
I've implemented an algorithm of integer FFT for micaz, but I've some
problems:
1) I tested the FFT with TOSSIM for check the correct result and it
works
2) I tested the FFT on micaz, but I can't read the result of the
computation, because I put the result in a int32_t variable and when
I
go
to write this variable in the packet (to read the packet with
MessageCenter java) it writes "zero". I thought that the problem was
in
the different data types: the value in the packet must be int16_t,
the
result is in int32_t. Then I used a type union:
typedef union {
int8_t s[4];
int32_t i;
} UDATA;
UDATA z;
In this way I can put the result in:
z.i=(int32_t)result;
and when I go to write the result in the packet I use the union:
radio_msg_ptr->data[10] = zz.s[0];
radio_msg_ptr->data[10+2] = zz.s[1];
radio_msg_ptr->data[10+4] = zz.s[2];
radio_msg_ptr->data[10+6] = zz.s[3];
But it still doesn't work. Why??
Can anybody help me? Thanks in advance.
PS: I put the code of the FFT computation
int16_t FFT(int16_t kk[], int16_t fr[], int16_t isign, int16_t *Ampl,
int16_t *Freq) {
//variables for trigonometric recurrences
int32_t a,b,c,d,i,m;
int16_t idx,max,rms;
a = b = c = 0;
call Leds.yellowOn();
BinaryInversion(datas);
Danielson(datas,isign);
max = 0; idx = 0;
rms = 1414L;
for (i=0,m=0;i<NSIGNAL;i+=2,m++) {
a=(int32_t)(kk[i]*kk[i]);
b=(int32_t)(kk[i+1]*kk[i+1]);
c = sqrt(c);
c=(a+b);
c=sqrt(c);
d=((c*100)/NSIGNAL)/100;
fr[m]=(d*rms)/1000;
if(fr[m]>max) {
max=fr[m];
z.i=fr[m];
idx=m;
}
}
*Ampl = max; //memorizzati il valore di picco e la
componente relativa li memorizzo nel pacchetto
*Freq = idx;
call Leds.yellowOff();
post send_radio_msg();
return(0);
}
Ing. Alessandro Balvis
Centro Ricerche ENEL - Pisa
[EMAIL PROTECTED]
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
_______________________________________________
Tinyos-help mailing list
[email protected]
https://mail.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
