For documentation on UFF 18 go to
http://www.sdrl.uc.edu/sdrl/referenceinfo/universalfileformats/file-format-storehouse/universal-dataset-number-18

@Vin Sharma, It should be working reliable now. I have done a couple of fixes especially for uneven binary data.

readuff on binary data type 58 works on some files and does not work on other files. Translated data of even time distribution to uneven distribution. Unreliable code.

I noticed that measered data saved as binary uff 58 (*.bunv) is not complete. I have the Problem if I save my results from an experimental modal analysis as *.bunv I see the frequency response functions but no coherence. If I save the same data as *.unv I get both measuraments.
Do anyone know why I get this problem?
Thanks in advance
Volker

Finding the blocks does not work correctly for 58b binary files.
Reverting to old strfind temporarily fixes the problem.
%--------------
% Find all valid blocks, data between -1 and -1; pointers to blocks of
% data; include the first -1 but exclude the last -1;
% the first -1 will be skipped further later on in get_block_prop
%--------------
ind = strfind(FILE_DATA, ' -1');
%ind = regexpi(FILE_DATA, '(?<=^|[\r\n])( -1 *)(?:$|[\r\n])');

This is due that the end of binary block there is no newline characters, at least when exporting from Test.Lab:
...
Á·‚½¸Øº¸hØ·À-‰·~’7ní¡·\Ú:¸Á¿ä7Âò­·³Ó+7Å|÷¶ -1
-1
58b 1 2 11 2179072 0 0 0 0
Time for Voltage:+Z
NONE
...

I successfully completed my homework @ Master Degree with this toolbox.
readuff helps you to read FRF's in uff format

I tried test_uff.m whit this file generated by LMS Test.Lab

-1
58
Harmonic Spectrum for A0001X:+X
NONE
22-Mar-16 09:27:40
Record 1 of section "MM_SQLX1", run "SineRed_7"
Sweep 1
12 0 0 0 A0001X 1 1 A0001X 1 1
5 973 0 0.00000e+00 0.00000e+00 0.00000e+00
18 0 0 0 X-axis Hz
12 0 0 0 120 g
0 0 0 0 NONE NONE
0 0 0 0 NONE NONE
5.00000e+00 6.32878e-01 -6.10272e-02 5.02111e+00 6.57713e-01 -6.88457e-02
5.03501e+00 6.80860e-01 -6.70124e-02 5.09096e+00 7.17241e-01 -6.78049e-02

.......

The original file is in the form:

Frequency Real Immaginary

The problem is that the file I obtain in output is quite different.
This is the results.

Harmonic Spectrum for A0001X:+X
NONE
22-Mar-16 09:27:40
Record 1 of section "MM_SQLX1", run "SineRed_7"
Sweep 1
12 0 0 0 A0001X 1 1 A0001X 1 1
6 973 1 5.00000e+00 2.11100e-02 0.00000e+00
18 0 0 0 NONE Hz
12 0 0 0 NONE g
13 0 0 0 NONE NONE
0 0 0 0 NONE NONE
6.32878000000e-01 -6.10272000000e-02 6.57713000000e-01 -6.88457000000e-02

........

In the form:

Real Immaginary (equispaced in frequency)

this is the matlab code i used:

% Test for reading and writing of UFF files.
clear;

% First, let's read all the data-sets from the dam0.unv file

[DS, Info, errmsg] = readuff('dam0.unv');
DS{1}
writeuff('dam0_out.unv', DS, 'replace');

only read and write the result file should be the same of the original.

Can someone help me?

Thanks in advance,
Vincenzo

I am working with writeUFF (the 14 Nov 2015 version) and I found a couple bugs.

The first bug is with uneven spacing in the abscissa. I made a MWE to write an FRF at frequencies [11,20,30]. The resultant UFF has a 58 card with even spacing starting at 11 and increment of 9 instead of the appropriate uneven spacing.

The second bug I found is when I was mixing complex and real FRFs. I am exporting 2 FRFs, one is all real ordinates and the other is complex ordinates. I need all the 58 cards to have complex ordinates. Is there a way to make writeUFF consistently output all complex ordinates even if some are real? I did try using MATLAB's complex function on the real ordinates prior to writeUFF but it still produces a 58 card with real ordinates.

Thanks for your help.

There is a bug in reading dataset 58b.
If first byte of binary block corresponds to newline character it is skipped and block is considered to have incorrect length. Consider the following fix.

1) introduce
ind_bb1 = blockLines(11,2) + 3; % index of first byte of binary block

2) replace where appropriate blockLines(12,1) by ind_bb1

I found that the binary uff 58 file read in and then written out from MATLAB could not be read into nCode or Head Acoustics Artemis. Problem appears to be in header section formatting. I can send you a screen shot of the comparison using gvim.

there a field named "ordDenomDataChar" in the writeuff.m, but there is not a same field in the readuff.m
when I want to write a chaged uff structure, I should to added it.

Fixed the issue Ozan pointed out, i.e., using numpt.

There is a mistake in the extract58 data reading, which causes wrong plotting.

Instead of using "end-1" and "end" values to fill "measdata" and "x" values (((i.e. UFF.x = values(1:2:end-1);))), you should use "numpt" which is defined already as the number of measured data points.

This is neccessary in some uff recordings, as there are extra "zero" values at the end of the recorded data, which are not real measured data and used only to complete the columns and lines of UFF or UNV recording. Using "end" causes you to have these false data points.

See this:

*********************************
% Abscissa and ordinate values
if (ordDataType == 2 || ordDataType == 4)

% non-complex ordinate data
if spacingType == 0 % uneven abscissa
UFF.x = values(1:2:end-1);
UFF.measData = values(2:2:end);
else % even abscissa
UFF.measData = values;
nVal = length(UFF.measData);
UFF.x = UFF.xmin : UFF.dx : UFF.xmin + (nVal-1)*UFF.dx;
end
elseif (ordDataType == 5 || ordDataType == 6)

% complex ordinate data
if spacingType == 0 % uneven abscissa
UFF.measData = values(2:3:end-1) + j*values(3:3:end);
UFF.x = values(1:3:end-2);
else % even abscissa
UFF.measData = values(1:2:end-1) + j*values(2:2:end);
nVal = length(UFF.measData);
UFF.x = UFF.xmin : UFF.dx : UFF.xmin + (nVal-1)*UFF.dx;
end
else
errMessage = ['error reading measurement data at:' num2str(lineN)];
return
end

********************************

Guys,

I am trying to read a UFF58 data. I can only plot the "data description" part, but couldn't manage to plot the measurment data.

Can you give a hint please? Is it possible at all?

Thank you!

Great program, thanks.

it does not work to read a certain data type only with readuff.m . Please consider replacing:
if ~find(dsTypes==data_set_type)
by:
if dsTypes~=data_set_type

And moving:
dataSetN = dataSetN + 1;
just before:
UffDataSets{dataSetN} = ds_data;

Greatings

I have found an excel sheet for reading uff file here : www.noisestructure.com/products/Read_UFF.php

I had problems reading binary data into Ideas, so added single precision write capability and now it works.

If I ever get to Europe, you pick the spot and I'll buy dinner! And if you ever get to Pittsburgh, I know where to eat and I'm still buying. Thanks again for a very useful program! It is the cornerstone of my vibration post-processing GUI.

Thank you for this function. You also saved me a lot of work. As much as I would enjoy writing a function to read uff files, I just didn't have the time for this particular task I was working. Thanks again.

Very cool. U saved me lot of work. Thank you so much. now i can transfer data from Onosokki to CADA-X through matlab

I used it to read UFF data and create data from Matlab to CADA-X /LMS software. It was incredibly useful

Wow... I am in your debt. You just saved me a ton of work.

I tried it on a .unv file output from LMS Virtual.Lab with results from a modal test (format 55). It works fine. This just saved me at least a day to write my own. Very cool!

Worked fine on Universal ascii 58 type of data (imported from Cada-X LMS).

Using ver. 0.9.9b2, I have read 58b data embedded in a proprietary file format that was actually a universal file with added data- this reader still managed to extract the data, so I'm not sure what your problem might be. I stand by my 5 stars for now, good luck!

I don't seem to be able to read Universal binary 58b type of data. The ASCII part seems OK.

Worked wonderfully on IOTech's Zonicbook 618 universal files. I embedded it in a calling function & graphed reams of spectra in minutes. Good work!

our instrument (polytec laser) kicked out a file that had invisible carriage returns in the windows environment. these had to be stripped out of the data file so that this m file could read the data.

Exactly what I was looking for. Tanks you Primoz, you're a star !

Nice file.....one of the better ascii uff writers/readers i've seen.

Great program. Thanks!