The direction this discussion is taking is similar to Turboprop's obsession with FDR theory versus empirical evidence. They must both grow from the same tree!
Yes it is. I've been looking at the issue raised and it doesn’t make a lot of sense to me. When the FAA sent us the TRACON data, it was in a text output with tracks and returns all mixed in together. I had to write software to parse the returns from the track data and then export it to csv. What I learned was that each TRACON had it own azimuth rotation to account for, and then there was lat/long for each ASR to determine so that positional values could be calculated. It was a lot of fun. The point is, each TRACON was different and each had its own set of constants that had to be calculated and applied to the data before the csv file data was generating coherent paths for each plane.
I also worked with the C# code developed by Warren Strutt, converting it to VB.net for generating csv outputs for the UAL93 and AAL77 raw data files. The UAL93 was fairly straightforward after the frame structure was determined, but each data field had its own little conversion to convert it into useful data. UAL77 was limited because the data is stored in a compressed form using a modified-Hoffman algorithm. However, both he and I were able to extract some unencrypted frames which verified that it was actually fdr data. I abandoned the project last year because the Hoffman algorithm proved to be far more involved and time consuming to reverse engineer than any potential value of the result (especially since we do have a good RO2).
So all of this dancing around csv file generation is silly. When a raw file is imported into the software (whether Strutt's, mine, or some off-the-shelf software), a frame configuration file of some type has to be inputted too. It contains the variables required to make sense of the data (it is after all a serial bit data stream). The quality of the output, whether it is a csv file or animation will depend upon that configuration (or as we non-fdr guys like to call it, the *.ini file) file.
It is NOT as simple as click on the raw file, import and presto-chango a wonderfully accurate csv file or animation. I know, I spent over a year of my life decoding the frame structure only to learn that it was useless without knowing the Hoffman algorithm used. But such is life
By the way Milner, what software and versions Hokulele uses has nothing to do with an fdr and csv/animation outputs of an fdr. Hokulele was only saying that csv file generation is software specific and is not quite as straightforward as you want to assert. Some translation matrix is involved as an intermediate step.
