Confused by binary format of data in rtirecord output file

Thank you Roy.  This was helpful to know.  I gave it a try, as you suggested.

Unfortunately,  the converter's output appears to be broken.   Could I get a patch, or tips on how to configure the converter to produce a usable CSV?

• I think it was intended that comma-separated sample values would be on each line, with a timestamp first.  However, The timestamp of each sample is followed by a newline.  The next line is a comma followed by the data.  So, every other line is a timestamp without a comma, and the other lines are commas followed by the rest of the data.  How do I pull this into any CSV reader?  Anything that parses CSV uses newlines to delineate records (I'm currently fighting with xlsread in matlab)
• the file is too big to be edited by any editor I know of (notepad, notepad++, microsoft excel), so I can't fix this with a  search-and-replace (I would replace the sequence "comma-newline" with just a "comma").  FYI I'm waiting for my sysadmin people to approve ultraedit, which handles large files better.
• The first thing in the first row of the file is the table name.  This messes up column alignment of column name/column data.  However, this is asthetic only, so I don't consider it a major issue... just inconsistent.

Could I get a fixed version of the conversion tool that omits the newline after the timestamp so the tool will produce usable output?

Here is an excerpt of what I see.  I invite you to try reading this into any tool that processes CSVs.  Yes, Excell will "display" it, but you will be hard-pressed to plot or compute with any columns (yes the timestamps are off; please ignore).  

$ head convertedTopic-_RECEIVER_STATUS_0_RecordAll_domain0.csv | cat -n
 1 Table Name: RECEIVER_STATUS_0$RecordAll$domain0, TTimestamp,timeOfValidity.seconds,timeOfValidity.nanoseconds,state,obitStatus,gainState,decimationFactor,centerFrequency,generatorState,lastCommandTime.seconds,lastCommandTime.nanoseconds,lastCommandedState
 2 Mon Feb 26 00:13:55 2018
 3 ,1523960649,290905600,1,1,0,0,0.0000000000,2,0,0,1
 4 Mon Feb 26 00:13:56 2018
 5 ,1523960650,291604736,1,1,0,0,0.0000000000,2,0,0,1
 6 Mon Feb 26 00:13:57 2018
 7 ,1523960651,292283648,1,1,0,0,0.0000000000,2,0,0,1
 8 Mon Feb 26 00:13:58 2018
 9 ,1523960652,292964608,1,1,0,0,0.0000000000,2,0,0,1
 10 Mon Feb 26 00:13:59 2018

As a followup, I was able to get matlab to erase the blank lines by searching for the nulls and removing them from matlab's data  (on the small data set...)

However, on the large dataset, matlab's xlsread and csvread fail.  This seems logical, since I think they use the same algorithm that Excel uses, and Excel prints a warningwhen I try to read the files, saying it could not read the whole file.

Therefore, the only way I can do this is by parsing the internal format of the database file.

I understand that you may have support issues... no one likes to release internal documentation subject to change.  However, I really need to verify my application.

This is a signal processing application, but I am running test data through it to verify my application and/or DDS's role in it.  The test data contains known/predicted values for verification purposes (imagine a ramp function), along with my own timestamps as my data was processed at various points in the application. 

What I desire to do is capture my data in matlab so I can plot the ramp values (or rather, the deltas) to identify places where my application might have dropped data (before DDS even enters the picture, I do a lot of data shuffling, and my data source waits for no one).  I would also like to plot the differences in my timestamps to help identify timing bottlenecks.

The good news is that I was finally able to decipher the internal structure of the sql database.  There are some shenanigans in there, but I played along until the data made sense, and am now able to convert my binary data to something I can work on in matlab. (until the recorder changes underneath me, I guess)

Thanks for you help.