Issue Timing Data in matlab mobile sensors

I'm having a fundamental issue with the quality of the data using the sensors in Matlab Mobile.

TO test the logger, I'm performing the simplest operation, logging exactly 180 seconds of data at 100Hz for the 5 sensors, downloading it from the cloud, and processing it in Matlab. When the timestamp of the data shows approximately 170 seconds of data, but approximately 19,000 data points (should be 18,000). I confirmed this issue with a second phone of a different brand (though both phones were android) with recorded 175 seconds of data and roughly 18,500 points. The results in terms of error were also confirmed at slower logging rates, the error was actually significantly worse at 10hz than at 100hz.

Is there a fundamental issue with acquiring quality timing information from a cell phone that i should be aware of, or a way to calibrate matlab mobile so the timing information is better? Thanks!

[Walter Roberson]

I would be wary of latency difficulties.

Answer 1

[Maadhav Akula]

Is there a fundamental issue with acquiring quality timing information from a cell phone that i should be aware of ?

Yes, the mobile sensors have some fixed output data rates at which they give the values, it primarily depends on the manufacturer of that sensor. You can look up the datasheet of that particular sensor to know more about the output data rates and the accuracies for the output data rates.

A way to calibrate matlab mobile so the timing information is better?

Regarding the timing(latency) issue, I feel the best thing to do would be to log the data for more time compared to your required time and extract the required data using MATLAB.

(For instance, you want data for 5 seconds, try logging values for a little longer, and extract the values for 5 seconds).

While I was trying to reproduce the issue I have known that my mobile's accelorometer has a fixed output data rate of 12.5,25,50,100,200,400,800 and 1600Hz with an accuracy of +/-1%. So setting the frequency at 0-12.5Hz, I mostly got them sampled at 12.5Hz and from 12.5-25Hz I have got them sampled at 25Hz and so on. Similarly I found some other sensors have a fixed output data rates of 12.5, 26, 52, 104, 208, 416, 833, 1666, 3332 and 6664 with an accuracy of +/-1%.

Hope this helps!

[Dima]

Can you please reference the data-sheets of the mensioned mobile sensors?

Answer 2

[Walter Roberson]

MATLAB Mobile collects data internally and sends it towards the MATLAB host using udp. Since it is a wireless transmission and there could be other signals interfering, the packet will take a variable length of time to reach the host (and besides, the phone might be busy doing other things for a moment). The wireless ethernet card on the host receives the packet in hardware, and puts it into a memory buffer, and signals an interrupt to the operating system. The operating system on the host is trying to do a number of things at the same time, and receiving a packet is probably not its top priority, so the interrupt goes unserviced for a variable amount of time. Eventually the operating system examines the packet and looks through its tables to figure out which process the packet is for and moves the packet into the memory space of the correct socket of that process, and creates a notification to the process that a packet arrived and schedules the process to run (if it is not already running.) Many different processes are trying to run at the same time in the operating system, so it will take a variable amount of time before the process is actually run. Inside MATLAB, MATLAB notices that it has received an I/O interruption, but it has to wait for a "safe" time to run the callback function, so it can take a variable amount of time before the callback is run.

There is also the issue that if you do not already have sensor logging turned on for the sensors you want, then MATLAB has to create UDP packets to send instructions to the phone to turn out the logging, and then there is the variable amount of time before that will get sent out by the hardware, and variable amounts of time before the phone operating system processes the packet and directs it to the right process, wakes up the process, the process decodes the instructions and makes the appropriate hardware settings changes, and sends acknowledgement back to MATLAB. Only then can it start sending actual readings towards MATLAB.

Then MATLAB has to somehow figure out that 180 seconds have passed and run your callback (or code) to send instructions to the phone to turn off the sending of packets...

All of these "variable amounts of time" add up to a fair bit of uncertainty. I would not typically expect a difference of 10 seconds out of 180, but 1/2 second uncertainty on starting and stopping would not surprise me at all. I have a low opinion of Windows 10 ability to consistently schedule processes for real-time work, mainly because it doesn't. https://www.insight.tech/health/leverage-windows-10-real-time-extensions-for-medical-iot