I am not sure if i will stumble on effects related to the switching points, but I will try to keep their existence in mind. The Inverse Chirp Z-transformation sounds interesting. I will try to read the paper in the next weeks and see if I can understand it.
In the meantime I invested roughly a liteVNA64 value in better adapters. I am glad I did so, because that lead to a bunch of new insights (part of which had already been predicted by the more experienced members in this thread). Basically, I got several types of SMA to BNC, SMA to SMA and BNC to BNC adapters from Telegärtner, including what looked like a decent quality 50Ω Terminator and some port savers.
As far as I can see, this BNC-M terminator seems to perform even better than the Fairview Microwave ST3B-F I originally had in mind for terminating the cable. The following picture shows an S11 measurement taken with the liteVNA, calibrated with the supplied cal set. The black curve is the S11 of the liteVNA SMA calibration load, the red curve shows my old 50Ω terminator, i had lying around and the other three curves show the new TG terminator for three different connection states (e.g. extra pushing or pulling at the BNC connection before measurement). When comparing with the curves from the respective datasheets it performs better that the ST3B-F and the Mini-Circuits BTRM-50+.
My next (expected) finding was that my no-name SMA to BNC adapters are crap. On my new set of adapters all connections give an incredibly better haptic feedback when establishing an loosening the connections. Everything feels way more precise. Also they perform much better in a direct comparison. For that, I calibrated the liteVNA and then connected my H155 BNC cable via an SMA-M to BNC-F adapter to the liteVNA cable with the SMA through adapter. On the other side of the cable I connected a 50Ω termination and measured the TDR with Solver64. Then I swapped out the adapters and terminations at both sides of the cable between the no-name and Telegärtner ones and attached the liteVNA SMA load, the old 50Ω BNC termination and the new Telegärtner 50Ω BNC termination. The test setup and variations are shown here (the golden SMA adapters are the no-name ones):
One could immediately see that at least the SMA part of all the no-name adapters is unusable and produces a downward spike in the TDR graph that is not there with the quality adapters. The upwards spikes in the graph are caused by the BNC connections. I verified that via another measurement with an improvised bad quality BNC cal kit which made the curve start at the top of the first spike and go downward from there. As expected there are two spikes at the end, when connecting a BNC terminator via a double BNC-F adapter. My old BNC terminator produced a spike at the end that went up to over 80Ω, and some oscillations. As expected, the cable part measured the same on all measurements, except for temperature drift variations and the offset caused by the SMA to BNC adapter between the cable and the liteVNA through adapter. Regarding the observed offset, my brain is still not sure why the hiccup caused by an adapter should influence the absolute value of the cable measured after the adapter. Is that because of an insufficiently dense sampled input signal resulting in integration errors on the way to calculating the TDR, which then of course sum up over the integration distance?
I hope I will find the time to redo the recent S21 measurements with the new adapters this weekend.
@joeqsmith: While playing with exporting Touchstone s1p and s2p files from Solver64, I noticed that Solver64 respects the locale of the PC it is used on pretty much everywhere in the UI, including said export. However, the Touchstone file format seems to be only defined for using the English decimal separators. Consequently, Solver64 outputs unreadable Touchstone files on all PCs with a locale using other decimal separators. Of course this also affects the SnP load function. Solver64 will not load correct Touchstone files on PCs with other locales. I fixed this by post-processing the files and replacing all commas with a point, so METAS VNA Data Explorer can open them, but maybe there is an easy fix for this in future releases.