Mixed-mode analysis on CloudSprite¶
Theory lives in the RF-domain pages: formulas, CMRR, port mapping. This page is the product loop.
Store the four port-pairs¶
Each 2-port S2P is its own dataset in the same project:
- Shared serial (
sn=6) - Pair parameter (
mixed_mode=p13/p14/p23/p24, or polarityPP/PN/NP/NN) - Optional instrument / lot / temp as usual
If you have a true S4P, store that as one dataset instead and skip the four-file hunt.
Confirm mapping, then compute¶
Wrong mapping looks fine. Before arithmetic:
- Filter the four siblings (
sn+mixed_mode). - Read filenames and parameters. If they encode both a port-pair and a polarity, check they agree.
- Ask the operator to confirm P/N in and out (and whether
PNis[output][input]). - Align frequency grids. Convert in complex linear with the 0.5 formulas (or scikit-rf on an S4P).
- dB at the end. CMRR =
SDD21_dB - SCC21_dB.
Publish and plot¶
cs.set_project("cable-qual")
cs.track_script(__file__)
cs.publish(traces=[sdd21, scc21, cmrr], name="sdd21-sn-6")
Copy sn (and lot) onto the result. Notebook: source S21s optional; SDD21 (and CMRR) next to them. Do not overwrite the four source datasets.
Assistant path¶
A typical mixed-mode request (“compute SDD21 from these four datasets”) is a port-mapping confirmation first, then a script that uses the confirmed map with the 0.5 identities (or scikit-rf Network.s2sdd on an S4P), then Save as Script / Run. Mixed-mode conversion is not a REST path, and publish stays behind operator confirm.
Viewers can inspect published mixed-mode results; they cannot publish.