How do I get more digits in the S2P EXPORT. The export file have less digits than the file inside Genesys regardless of how I set number formatting in "tools" "general"
The export output is generated using C++ "%lg" formating, not the Tools / Formatting setting. There is no user control of the formatting in this particular instance.
I'm seeing ~6 digits after the decimal. How many do you need?
The problem is the frequency resolution, it is only 3 digits and MHz, and with high Q circuits it is not enough. I would like to see 6 digits on frequency too.
" The problem is the frequency resolution, it is only 3 digits and MHz, and with high Q circuits it is not enough. I would like to see 6 digits on frequency too.
Roy "
I have seen this issue in the past as well, a good example is s-parameter based data on a SAW or crystal filter. You may easily need steps in the Hz region over a narrow passband (100 kHz or less). It is a good point.
Lance, in your opinion, what would the "best" solution be?
1) To use the Formatting specified in Tools / Options or
2) To use a longer (but still hard-coded) format specifier, like say, 12 digits after the decimal. I prefer this approach, since it doesn't require the user to fiddle w/ the formatting option (to set it and then set it back, so that graphs look resonable).
Roy, Thank you for bringing this to our attention. I have added an Enhancement Request to our bug tracking system.
I've found a possible workaround: In the dataset, set the units for F to Hz; then when you export the S parameters, the freq will be Hz. I'm seeing about 5 digits after the decimal; however, the output is mostly in exponential format (3.24875e+006), so there are still only ~6 digits of precision.
If this is a critical issue for you and the workaround is insufficient, please contact me (via the forum private-message feature) and I'll do a custom export for you via a debug Genesys build.
" Lance, in your opinion, what would the "best" solution be?
1) To use the Formatting specified in Tools / Options or
2) To use a longer (but still hard-coded) format specifier, like say, 12 digits after the decimal. I prefer this approach, since it doesn't require the user to fiddle w/ the formatting option (to set it and then set it back, so that graphs look resonable). "
I think that either 1 or a 3rd option might be best. I don't think hard-coding anything is terribly good. The problem is that the ascii files really bloat quickly.
How about it be part of the export dialog?
The export would normally be controlled by tools/options, then during a manual file export you could have the option to override the precision. Just a thought. The main concern I have about tools/options and setting it there is that it will affect everything (I don't think humans care about those digits really, it is that a machine needs to have that resolution to not have the equivalent of multiple data points for the apparent same frequency). The issue really is the frequency scale.
Or some intelligence could be applied; if adjacent points after formatting are not different, more digits should be applied. I say this because it is probably the safest; since the spacing may not be uniform.
" Lance, in your opinion, what would the "best" solution be?
1) To use the Formatting specified in Tools / Options or
2) To use a longer (but still hard-coded) format specifier, like say, 12 digits after the decimal. I prefer this approach, since it doesn't require the user to fiddle w/ the formatting option (to set it and then set it back, so that graphs look resonable). "
I think that either 1 or a 3rd option might be best. I don't think hard-coding anything is terribly good. The problem is that the ascii files really bloat quickly.
How about it be part of the export dialog?
The export would normally be controlled by tools/options, then during a manual file export you could have the option to override the precision. Just a thought. The main concern I have about tools/options and setting it there is that it will affect everything (I don't think humans care about those digits really, it is that a machine needs to have that resolution to not have the equivalent of multiple data points for the apparent same frequency). The issue really is the frequency scale.
Or some intelligence could be applied; if adjacent points after formatting are not different, more digits should be applied. I say this because it is probably the safest; since the spacing may not be uniform.
Lance "
And more specifically, I think the "adjacent points aren't different" should trigger the addition of more than just enough digits to make them different; skimping on digits there could cause bad rounding issues.
Yes, I agree that would be best, unfortunately, that is by far the most time-consuming solution to implement. I'll add both of your inputs to the enhancement request.
I'm seeing ~6 digits after the decimal. How many do you need?