First, I was wrong with my speculation that the r-squared formula would be off by a division by "n".
The formula is OK (it's just the squared version of Pearson's product-moment correlation coefficient).
The following regression is also correct.
However, there is an error when calculating the intersection between the regression line with the -60 dB line.
Your code is:
rt = round(abs(60/slope(1))-yintercept);
This works if yintercept is (very close to) zero (as it is in the nice picture above. But in the general case (and in my case), yintercept is a non-negligible negative value and the resulting reverberation time is wrong.
The correct line would be:
rt = -(yintercept + 60)/slope;
As I said, the regression is correct, however it could be written a little more compactly like this:
1) Can you please provide the original formula for the "r-squared" you used?
It seems to be related to the squared "sample Pearson correlation coefficient" but I think it could be off by a division by "n".
I searched in some statistics books and on the web and the problem is there are many different definitions of "r-squared".
2) By default, your function discards the first 50 ms of the result of the "cumulative r-squared". Is this a value you found by experience? In which situations would you suggest different values?
@Kevin: Thanks for your response and for the adaptation of your code!
Just for the records: I was also running Matlab on Linux and I did have problems sending binary zeros.
I didn't try it on other operating systems.
I didn't try other strange characters either, just binary zeros and plain ASCII letters and punctuation.
I had a similar problem when I wanted to send strings which contained binary zeros (\0) as separators.
This didn't work with writeBytes() because the binary zero was interpreted as end-of-string.
Also, when I analyzed the IP traffic with wireshark, I saw that sometimes (strangely not always) an IP packet was sent for every single character of my message-string, which seemed quite inefficient to me.
I did it :)
Still the jTCP serialization is off and i use my own one with the use of typecast.
The solution is to send a constant length of the data stream for example 40 bytes.
Then i used the NUMBYTES parameter in jTCP read and deserialized again with typecast.
Now i'm not flexible with the data i send but it's no problem because the sender and receiver know about that.
Unfortunately not. I turned the jTCP serialization off but i need some sort of serialization to send my data.
I wrote my own then with some undocumented MATLAB functions.
If i try it on the same computer my program works but again if i use two different PCs i get an error.
At least it is a new one, a MATLAB and not java error: "Bad version or endian-key"
Maybe you know something about it, seems like jTCP can't read the data properly?!
@Carsten--The OptionalDataException appears to be associated exclusively with serializable objects. I don't know why this is happening, but you could presumably get around this problem by setting 'serialize' to false and converting the payload data to int8 (see last example in jtcp.m header). Would this be an option for you?