how do I transfer .dat test file into matlab?

I am trying to sample from a script written by someone in 2015. Everything else in my code should function correctly if I can get this file to be mined. I need to get it into [channels,data] in order for my code to function properly. Being from such an old version of matlab, I'm sure there's an different way to do this now. Any help would be greatly appreciated.

%Directory of test file
filename='Test_1';
filedir='C:\Users\admin\Documents\Testing\Test_1\';
%Calls sub function to mine data from .dat test file
[channels,data]=getfile(filedir,strcat(filename,'.csv'));

This is the error message that I get:

Undefined function 'getfile' for input arguments of type 'char'.
Error in OBS_ONE_Reduction (line 10)
[channels,data]=getfile(filedir,strcat(filename,'.csv'));

[dpb]

R2015x didn't have any such function as getfile, you're missing a corollary m-file that goes along with the file you have -- and, maybe some others as well when you get past this point.

First recourse is to go back to that someone and ask for the rest of the application files...a test data file and output to go along with it would always be good...

[Les Beckham]

If you attach your file, I'm sure someone can help with how to read it.

[dpb]

That's second recourse if first doesn't work,@Les Beckham... :)

Answer 1

[Oguz Kaan Hancioglu]

I understand that getfile is a function that was already developed in your application in 2015. Now, Matlab has a getfile function and needs some hardware object as a first argument. Maybe changing "getfile" function name solves this problem.

[dpb]

"...Now, Matlab has a getfile function and needs some hardware object as a first argument."

Excepting that function is <getFile>; MATLAB is case-conscious.

The function the OP's main level function calls clearly returns data from a specific file structure used for the purpose; as @Les Beckham notes, if we knew the file format it could be redeveloped, but if that routine/m-file is available from the same source as from whence the other function came, then may as well short-circuit reinventing it.

[Oguz Kaan Hancioglu]

You are right. I missed the case sensitivity of the function name.

[dpb]

Easy enough to miss...but as a side note to TMW, that's a TERRIBLE function name to introduce into base or toolbox product -- that one's bound to clash with thousands of user-written functions of the same name (including the camelCase spelling).

[Steven Lord]

There's no clash unless you try to call a user-defined getFile function with an rosdevice or ros2device object as input. The getFile method of rosdevice or ros2device objects is at level 7 of the function precedence order.

You could override that by writing a nested or local function named getFile (levels 3 or 4) or a private function by that name (level 6) and calling those with the ros*device object input. Or you call your getFile without specifying an object whose class has that method defined, that can call functions in the current folder or on the path (levels 10 or 11.)