So i decided to try your version 3.
It took me all day long to understand your approch and to implement it myslef. Actually i didn't have an idea about what .mex files are and all this other matlab magic, but I got it working finally. I am not completly satisfied at the moment, but my method could still use some refinement.
I use the Simulink support package for Lego NXT. There i use the 'Bluetooth Outbound Mailbox' with the 'Mailbox Nr.' set to 1. The inport is connectet to a MUX-Block where i 'append' all the signals which i want to transfer simultaneously. The MUX-Block only accepts data of the same datatype, therefor i have to convert the different signals into one uniform datatype. I use the Conversion Block for this task, and select the option not to change the byte representation. My 'transfer datatype' of choice is 'int32'.
I downloaded the package you pointed me to and took the w32serial function from it. I use it to establish a connection on the proper COM port and have a infinite loop reading the bytestream recieved and writing it to a file. The file created is the raw byte stream recieved.
I created a function to extract the data from this byte file. There i use the knowledge about the package format and the typecast function to get the proper representation of the byte data.
The packages are not corrupt but the data does not arrive at its send order. Actually i think that this isn't any faulty behaviour, but just the way bluetooth works. Therefore i use the Timer-Block to send a timestamp with every package. My Simulink modell is pretty simple. I use 3 input blocks(timer, gyro, rotary encoder), draw the signal value on the display and transfer them after conversion to the 'bluetooth mailbox'. The sampling time is 0.1ms for the whole circuit. So if i order my recieved data, the difference between two neighbour packages should be 100ms. This is true for about half of the packages, but there are a lot of gaps in between. varying from 150-250ms.
And there is another thing wich makes me curious: I get a lot of packets with the same timestamp. Some of them are just duplicates, but there are even some which vary in the sensor data. How can this happen?
observing time: 30.5s
packets recieved: 307
unique timestamps: 268