On 3/1/23 5:54 AM, btomek@... wrote:
I changed the code to accommodate your files. One offending point for
OPEN_CHANGED.s1p occurs at 300 MHz. That may provide a clue::
@Brian - My s1p was generated in NanoVNA-App. Whether there is a period or a comma probably depends on operating system's regional settings.
According to wikipedia more countries use a comma instead of a period.
In NanoVNA-App, the lower left corner says what the decimal separator character is. In NanoVNA device, you can choose what the separator should be: Menu/Config/Expert settings/More/Separator
I think both separators should be supported when reading the file.
For SnP (Touchstone, S1P, S2P, etc.) files it's easy, because the values are space delimited.
What's *not* easy is that most of the libraries won't do it for you. You have to parse the data fields, split it at the delimiter, then convert the left and right side and combine them.
When writing, it should be as the standard specifies. If it specifies.
it does not. (If someone wants to get involved in standards making, this would be a nice thing to add. Just define the "decimal separator", either specify one, or say that it's localized and could be either, or whatever. The spec just says "you can use scientific notation".
is a great explanation
is the spec (linked from the Microwave101 site)
Going back to the test, I wanted to check whether the calibration data from the frequency 888750625 is responsible for the measurement result on 888750625 or maybe for something else, such as a bug on a neighboring result. However, it came out that every single calibration point affects 4 results, which was a surprise to me. The value of the result is not important, because the calibration data at the changed points is random, but such that it deviates significantly from what it was. Hence, the result will also be random, and may be > 1.
