Virtuelle GTEM-Abläufe ====================== Die modernen GTEM-Skripte im Verzeichnis ``script`` können mit virtuellen Gerätekonfigurationen ohne Laborhardware ausgeführt werden. Der aktuelle Ausbaustand konzentriert sich auf Eintor-GTEM-Zellen. Zweitor-Zellen werden separat betrachtet. Normative Referenz ------------------ Messablauf und Auswertung orientieren sich an der neueren FDIS-Fassung von IEC 61000-4-20. Für die aktuell implementierten GTEM-Abläufe sind insbesondere diese Abschnitte relevant: .. list-table:: :header-rows: 1 * - Abschnitt - Bedeutung im Code * - Anhang A.3.2.3 - Eintor-Wellenleiter-Korrelationsalgorithmus für Emissionsmessungen. * - Anhang A.3.2.3.2 - Spannungsmessungen in drei orthogonalen EUT-Positionen. * - Anhang A.3.2.3.3 - Bestimmung des Feldfaktors ``e0y``. * - Anhang A.3.2.4 - Korrelation der abgestrahlten Leistung zur maximalen Freifeldstärke ``Emax``. * - Anhang B - TEM-Mode-Verifikation und Einstellung des Störfestigkeitsprüfpegels. Die Implementierung nutzt die gemessene Feldverteilung, um eine Referenzfeldstärke und die zugehörige Vorwärtsleistung für spätere Störfestigkeitsmessungen zu bestimmen. Die Dokumentation verweist nur auf Abschnittsnummern der Norm. Die Formeln und Auswerteparameter bleiben in der Norm maßgeblich. Verfügbare Skripte und Konfigurationen -------------------------------------- .. list-table:: :header-rows: 1 * - Skript - Zweck - Virtuelle Konfiguration * - ``tem-e0y.py`` - Experimentelle Bestimmung des GTEM-Feldfaktors ``e0y``. - ``conf/tem-gtem-e0y-virtual/conf.py`` * - ``tem-emission.py`` - Emissionsmessung und Auswertung gegen eine vorhandene ``e0y``-Historie. - ``conf/tem-gtem-emission-virtual/conf.py`` * - ``tem-emission.py`` - Emissionsmessung und Auswertung gegen eine vorhandene Verifikationsreferenz-Historie. Die ``e0y``-Quelle wird aus ``reference_field / sqrt(forward_power)`` abgeleitet. - ``conf/tem-gtem-emission-virtual-from-verification/conf.py`` * - ``tem-verification.py`` - TEM-Mode-Verifikation mit daraus abgeleiteter Verifikationsreferenz. Die Messung speichert Rohdaten von Feldsonde und Leistungsmessern und wertet daraus Tabellen für Referenzfeldstärke und Vorwärtsleistung aus. - ``conf/tem-gtem-verification-virtual/conf.py`` * - ``tem-immunity.py`` - Störfestigkeitsmessung gegen eine vorhandene Verifikationsreferenz-Historie. Die aktuelle GTEM-Strategie regelt auf die aus den Referenzdaten bestimmte Vorwärtsleistung. - ``conf/tem-gtem-immunity-virtual/conf.py`` Zu jedem Textskript gibt es außerdem einen Qt-Starter mit gleichem Namen und ``-qt`` vor der Dateiendung, zum Beispiel ``tem-immunity-qt.py``. Die Qt-Starter verwenden dieselben Konfigurationsdateien und führen die Messung in einem Worker-Thread aus, während die Oberfläche bedienbar bleibt. Historien-Pickles ----------------- Auch die TEM/GTEM-Pickles sind Historien-Container. Eine Folgemessung lädt normalerweise das Ausgabe-Pickle des vorherigen Schritts über ``pickle_input_filename``, ergänzt ihre eigenen Rohdaten und Auswertung und schreibt danach ein neues vollständiges ``TEMCell``-Pickle. Die typische Reihenfolge für eine GTEM-Emissionsmessung ist: .. code-block:: text e0y -> emission Das Emissions-Pickle enthält damit sowohl die ``e0y``-Kalibrierhistorie als auch die neu hinzugefügte Emissionsmessung. Diese Eigenschaft ist für die Rückführbarkeit wichtig. GTEM-Geometrie -------------- Alle GTEM-Messungen in einer Historie verwenden eine feste Geometrie. Die Skriptkonfiguration beschreibt diese Geometrie mit der Typenbezeichnung der Zelle, einer Höhenreihe und dem zugehörigen Abstand ``delta_z``. Die Einträge in ``heights`` sind dabei Höhen ``h_i`` in der Zelle; sie definieren zunächst die Zellgeometrie und müssen nicht mit späteren Verifikations- oder Kalibrierhöhen identisch sein. ``delta_z`` ist der Abstand zwischen benachbarten Höhenpunkten. Die absolute z-Position des ersten Höhenpunkts wird nicht vorausgesetzt. Für GTEM-Zellen wird das lineare Modell ``h = k*z`` verwendet. Der Faktor ``height_per_z`` wird aus den Differenzen benachbarter Höhen bestimmt, also näherungsweise aus ``(h[i+1] - h[i]) / delta_z``. Erst danach werden rechnerische z-Positionen aus ``z = h / height_per_z`` abgeleitet. Für Abläufe, die die analytische GTEM-Formel für ``e0y`` benötigen, enthält die Geometrie zusätzlich ``width_per_z`` und ``gap_per_z``. Die charakteristische Impedanz ist mit 50 Ohm vorbelegt und muss normalerweise nicht explizit konfiguriert werden. Die Geometrie wird in der Messhistorie gespeichert. Neu gemessene ``e0y``-Daten übernehmen die Geometrie bis nach ``processedData_e0y``; eine spätere Emissionsauswertung prüft, ob diese gemessenen ``e0y``-Daten zur aktuellen GTEM-Geometrie passen. Ältere Pickles ohne Geometrie-Metadaten bleiben als Legacy-Daten akzeptiert, können aber diese Konsistenzprüfung nicht liefern. e0y-Daten bei Emission ---------------------- Die Emissionsauswertung kann gemessene ``e0y``-Daten aus einem vorherigen ``tem-e0y.py``-Lauf oder die analytische GTEM-Formel verwenden. Die virtuelle Emissionskonfiguration nutzt standardmäßig gemessene ``e0y``-Daten. Wenn ``use_e0y_GTEManalytical`` auf ``True`` gesetzt wird, muss die EUT-Position über ``eut_h`` oder ``eut_z`` sowie ``eut_x`` und ``eut_y`` bekannt sein. Der analytische Pfad bestimmt lokale GTEM-Breite, Höhe und Spaltweite dann aus der gespeicherten Geometrie statt aus einem separaten ``EUTpos``-Dictionary. Legacy-``EUTpos``-Dictionaries mit expliziten Zellabmessungen bleiben aus Kompatibilitätsgründen akzeptiert. e0y-Quellen-Metadaten --------------------- Ausgewertete ``e0y``-artige Daten enthalten einen Eintrag ``source``, der beschreibt, woher der Feldfaktor stammt. Isolierte Messungen mit ``tem-e0y.py`` speichern ``method = "measured_e0y"`` und die zugehörige GTEM-Geometrie. Wenn ``e0y_h`` oder ``e0y_z`` zusammen mit ``e0y_y`` konfiguriert ist, ist die Quelle eine Punktquelle mit ``source_type = "point"`` und der abgeleiteten Position ``h``, ``z``, ``x`` und ``y``. Ohne explizite Positionsmetadaten bleibt die Quelle ``source_type = "unknown"``. Für Punktquellen mit Geometriemetadaten speichert ``Evaluate_e0y`` zusätzlich ``point_summary``, ``frequency_summary`` und einen informativen ``e0y_comparison``. Dabei wird das gemessene ``e0y`` der ``cell_y``-Komponente, also ``abs(E_y) / sqrt(P_fwd)``, mit dem analytischen GTEM-Wert am selben Punkt verglichen. Wenn Position oder Geometrie fehlen, hält ``e0y_comparison_status`` fest, warum die analytische Kontrolle übersprungen wurde. Verifikationsergebnisse, die auf einer konfigurierten Uniform Area beruhen, speichern ``source_type = "uniform_area"`` mit ``method = "verification"``, ``uniform_area``, ``uniform_area_plane`` und ``uniform_area_points``. Diese Struktur dient der Rückführbarkeit und bereitet eine spätere Quellenauswahl oder Interpolation vor. Sie trifft noch keine automatische Entscheidung darüber, welche ``e0y``-Quelle für eine Emissionsauswertung verwendet werden soll. Die Uniform Area beschreibt die x-y-Fläche, in der die Feldverteilung geprüft oder kalibriert wird. Sie besitzt eine feste Lage in der GTEM-Zelle, meist über eine Höhe ``h`` oder die äquivalente z-Position aus der gespeicherten Geometrie. Diese Lage wird als Verifikationsebene in ``uniform_area_plane`` abgelegt. Die einzelnen Messpunkte in dieser Ebene werden in ``uniform_area_points`` gespeichert. Dadurch kann eine spätere Messung dem Nutzer anzeigen, für welche Ebenen Daten vorhanden sind, ob die EUT-Position in der geprüften Fläche liegt und ob eine Interpolation zwischen zwei benachbarten Ebenen möglich ist. Die Hilfsmethode ``TEMCell.summarize_e0y_sources()`` listet die verfügbaren Quellen aus ``processedData_e0y`` und ``processedData_Verification`` auf. Jede Zusammenfassung enthält die Quellenfamilie, den Frequenzbereich und ``geometry_matches``. ``geometry_matches`` ist ``True`` oder ``False``, wenn beide Geometrien bekannt sind, und ``None``, wenn der Vergleich nicht möglich ist. Die Methode ist bewusst rein lesend; sie zeigt verfügbare Quellen an, wählt aber keine Quelle aus und interpoliert nicht zwischen Quellen. Bei datenbasierten ``e0y``-Quellen vergleicht die Zusammenfassung außerdem die angeforderten Emissionsfrequenzen mit dem gemessenen Quellenbereich. Frequenzen innerhalb dieses Bereichs können interpoliert werden. Frequenzen unterhalb oder oberhalb des gemessenen Bereichs würden eine Extrapolation erfordern und lösen daher eine Nutzerentscheidung aus, bevor die ausgewählte Quelle verwendet wird. Diese Prüfung wird bewusst nicht auf die analytische GTEM-``e0y``-Formel angewendet, weil dieses Modell frequenzunabhängig ist; Effekte höherer Moden liegen außerhalb dieses analytischen Modells und sind kein begrenzter Frequenzdatensatz. Bei punktförmig gemessenen ``e0y``-Quellen kann die Emissionsauswertung zusätzlich die gespeicherte Quellenposition mit der gespeicherten EUT-Position vergleichen. Die zulässige Entfernung ist ``delta_r_max = q * c0 / f_max``. Dabei ist ``q`` der Parameter ``e0y_position_wavelength_factor``; der Standardwert ist ``0.5``. Bei einer höchsten angeforderten Emissionsfrequenz von 1 GHz ergibt sich damit standardmäßig eine Grenze von ungefähr 0,15 m. Größere Abweichungen lösen eine Nutzerentscheidung aus, bevor die ausgewählte Punktquelle verwendet wird, weil der gemessene ``e0y``-Punkt die EUT-Position dann möglicherweise nicht mehr hinreichend gut beschreibt. Bei Verifikationsreferenzquellen mit ``source_type = "uniform_area"`` meldet dieselbe Quellenzusammenfassung, ob die gespeicherte EUT-Position ``x``/``y`` innerhalb der verifizierten Uniform Area liegt und ob die EUT-Höhe bzw. z-Position zur Verifikationsebene passt. Liegt das EUT außerhalb der Fläche oder in einer anderen Ebene, wird die Quelle als nutzerpflichtige Entscheidung markiert, bevor sie verwendet werden sollte. Verifikationsreferenzquellen können außerdem direkt als ``e0y``-Quellen für die Emissionsauswertung ausgewählt werden. In diesem Fall wird ``e0y`` aus den ausgewerteten Referenzdaten als ``reference_field / sqrt(forward_power)`` abgeleitet. Zum nutzbaren Quellenbereich gehören nur Frequenzen, bei denen beide ausgewerteten Größen vorhanden sind. Der Emissions-Konfigurationsparameter ``e0y_description`` muss eine der gelisteten datenbasierten Quellen explizit benennen. Er kann entweder auf einen isoliert gemessenen ``e0y``-Datensatz aus ``processedData_e0y`` oder auf einen Verifikationsreferenzdatensatz aus ``processedData_Verification`` zeigen. Eine automatische Quellenauswahl ist bewusst noch nicht aktiviert; ``None`` oder ``"auto"`` melden die verfügbaren Quellennamen und fordern eine explizite Auswahl an. Emission-Prescreening für Quasi-Peak-Nachmessungen -------------------------------------------------- Die GTEM-Emissionsmessung kann optional eine Peak-Prescreening-Auswertung für spätere Nachmessungen mit dem zum Grenzwert gehörenden Detektor speichern. Dazu wird in den ``measure_parameters`` ein ``emission_limit`` angegeben. Fehlt dieser Eintrag oder ist er ``None``, wird kein Detektor-Prescreening durchgeführt. Ein typischer Grenzwert wird über ``mpylab.limits`` konfiguriert, zum Beispiel: .. code-block:: python "emission_limit": { "module": "radiated_emission.en_55011", "group": "1", "classification": "B", "detector": "QP", "port": "AC (<= 20 kVA)", "distance": "10 m", }, "prescreen_margin_db": 6.0, "prescreen_position_count": 3, "prescan_detector": "PK", Die Limit-Kurve liefert Feldstärkegrenzen in ``dBµV/m``. Für jede Frequenz wird daraus unter der Annahme gleicher Spannungen an allen EUT-Positionen eine äquivalente Einzelpositions-Spannungsgrenze berechnet. Die größte gemessene Peak-Spannung wird mit dieser Grenze verglichen. Liegt sie innerhalb des konfigurierten ``prescreen_margin_db`` unterhalb der Grenze oder darüber, wird die Frequenz als Kandidat für eine Nachmessung mit dem im Limit definierten Detektor markiert. Dieser Detektor ist häufig ``QP``, kann aber je nach Grenzwert auch ``AV`` oder ``PK`` sein. Die Entscheidung wird unmittelbar während ``Measure_Emission`` nach der Peak-Messung getroffen und im Rohdaten-Pickle gespeichert. Nach Abschluss des Peak-Prescans für die aktuelle EUT-Position werden die markierten Frequenzen direkt mit dem im Limit definierten Detektor nachgemessen, bevor die nächste EUT-Position angefahren wird. Die Ergebnisse liegen unter ``rawData_Emission[description]["Prescreen"]``. Wichtige Einträge sind ``field_limit``, ``voltage_limit``, ``measured_peak_voltage``, ``margin_db``, ``remeasure_required``, ``prescan_detector``, ``remeasure_detector`` und ``position_count_assumption``. Zusätzlich enthält ``rawData_Emission[description]["RemeasureRequiredFrequencies"]`` die frequenzsortierte Liste der Kandidaten. Die gemessenen Spannungen sind nach Detektor abgelegt, zum Beispiel unter ``rawData_Emission[description]["voltage"]["PK"]`` für den schnellen Peak-Prescan und später unter ``...["voltage"]["QP"]`` oder ``...["voltage"]["AV"]`` für Nachmessungen. ``Evaluate_Emission`` bleibt für die finale Korrelation zuständig; es verwendet bevorzugt Werte mit dem zum Limit gehörenden Detektor und fällt auf den Prescan-Detektor zurück, wenn noch keine Nachmessung vorhanden ist. Für den finalen Grenzwertvergleich muss derselbe Grenzwert auch in den ``evaluation_parameters`` angegeben werden. Die Auswertung speichert dann unter ``processedData_Emission[description]["LimitComparison"]`` pro Frequenz und Port die berechnete Feldstärke ``Emax``, den Grenzwert, den Abstand ``margin_db``, ``passed`` sowie ``detector_required``, ``detector_used`` und ``detector_fallback``. ``detector_fallback`` ist ``True``, wenn noch keine Nachmessung mit dem zum Limit gehörenden Detektor vorliegt und deshalb der Prescan-Detektor verwendet wurde. Die Standardausgabe von ``OutputProcessedData_Emission`` schreibt diese Ergebnisse als tabulatorgetrennte Tabelle. Wichtige Spalten sind ``freq_Hz``, ``Emax_value``, ``limit_value``, ``margin_dB``, ``passed``, ``detector_required``, ``detector_used`` und ``detector_fallback``. Dadurch kann die Datei direkt im pexplorer oder in Tabellenwerkzeugen weiterverwendet werden. Wird ein Ausgabedateiname verwendet, werden zusätzlich zwei tabulatorgetrennte Detaildateien neben der kompakten Tabelle geschrieben. ``prescreen-...dat`` enthält den invertierten Spannungsgrenzwert, die gemessene Peak-Spannung, den Abstand zum Grenzwert und die Nachmessentscheidung pro Frequenz, Port und EUT-Position. ``e0y-source-...dat`` dokumentiert die ``e0y``-Quelle, die für die finale Korrelation und, falls vorhanden, für den Prescreening-Schritt verwendet wurde. Damit ist die Auswahl einer analytischen, gemessenen oder aus der Verifikation abgeleiteten ``e0y``-Quelle nachvollziehbar, ohne das Pickle öffnen zu müssen. Die EUT-Position muss für analytisches ``e0y`` über ``eut_h`` oder ``eut_z`` sowie ``eut_x`` und ``eut_y`` bekannt sein. Wird eine gemessene oder aus der Verifikation abgeleitete ``e0y``-Quelle verwendet, gelten dieselben Positions- und Frequenzprüfungen wie für die normale Emissionsauswertung. Die typische Reihenfolge für eine GTEM-Störfestigkeitsmessung ist: .. code-block:: text verification -> immunity Das Verifikationsreferenz-Pickle enthält die Rohdaten der TEM-Mode-Verifikation und die ausgewerteten Tabellen ``reference_field`` und ``forward_power``. Da die Interpretation der Statistikformeln für die Feldhomogenität noch fachlich diskutiert wird, kann die Constant-Forward-Power-Auswertung die primäre Feldkomponente dreigleisig bewerten: mit Mittelwert und Standardabweichung in dB, mit Mittelwert und Standardabweichung in linearen V/m sowie mit der alten 75-%-Punktabdeckungs- Methode aus der bisherigen Norm. Die Konfiguration ``field_uniformity_scale = "all"`` speichert alle Varianten unter ``field_uniformity_by_scale`` und ``reference_field_by_scale``; der aktive Modus ``selected_field_uniformity_scale`` befüllt ``reference_field`` für das spätere Leveling. Damit kann die aktuelle Draft-Interpretation im selben Pickle mit der alten Methode verglichen werden. Die flache Tabelle ``reference_field_comparison`` wird von der Processed-Data-Ausgabe geschrieben und enthält pro Frequenz den ausgewählten Wert sowie die Alternativen ``db``, ``linear`` und ``coverage``. Zusätzlich werden die Dominanz des TEM-Modes über das 75-%-Quantil des Verhältnisses sekundärer zu primärer Feldkomponente, ``primary_field_sigma_db``, ``primary_field_sigma_linear`` und ``tem_mode_q75`` gespeichert. Für GTEM-Daten, die auf der Zellkomponente ``cell_y`` ausgewertet werden, speichert die Auswertung zusätzlich einen rein informativen analytischen Vergleich unter ``e0y_comparison``. Pro Verifikationspunkt wird das gemessene normierte Feld ``abs(E_y) / sqrt(P_fwd)`` mit dem analytischen GTEM-``e0y`` aus der konfigurierten Geometrie an derselben x-y-Position und derselben Verifikationsebenen-Position z / h verglichen. Gespeichert werden Messwert, analytischer Wert, Verhältnis, relative Abweichung und Abweichung in dB. Dieser Vergleich dient nur der Kontrolle und verändert weder ``reference_field`` noch ``forward_power`` oder die Pass/Fail-Entscheidung. Die Störfestigkeitsmessung lädt dieses Pickle, nutzt die Referenzdaten für das Leveling auf Vorwärtsleistung, ergänzt die EUT-Daten und schreibt ein neues vollständiges Historien-Pickle. Bei feldsondenbasierten Verifikationsdaten enthält das Rohdaten-Pickle beide Koordinatensysteme. ``value`` wird nach Anwendung des aktiven ``probe_axis_map`` in Zellachsenreihenfolge gespeichert; ``value_probe`` enthält die ursprüngliche Messung in Sondenachsen. Zusätzlich enthalten die Rohdaten ``probe_axis_maps`` und ``field_probe_values_are_cell_mapped``, damit bei der späteren Prüfung nachvollziehbar ist, welche Orientierung angewendet wurde. Die Textdateien ``*.dat`` dienen der schnellen Kontrolle und einfachen frequenzbasierten Prüfung. Das Pickle bleibt der maßgebliche strukturierte Historien-Container. Datenstruktur der Verifikations-Pickles --------------------------------------- Das TEM-Mode-Verifikations-Pickle enthält die vollständige Messhistorie: aktive Geometrie, Rohmessdaten, ausgewertete Verifikationsdaten und Referenz-Metadaten für spätere Störfestigkeitsmessungen. Feld- und Leistungsgrößen werden als ``scuq``-``Quantity``-Objekte gespeichert. Wichtige Keys sind: ``tem.geometry`` Aktive GTEM-Geometrie der ``TEMCell``-Instanz. Enthalten sind zum Beispiel ``height_per_z``, ``width_per_z``, ``gap_per_z`` und ``characteristic_impedance``. ``tem.rawData_Verification["cal"]`` Rohdaten der TEM-Mode-Verifikation für die Description ``"cal"``. ``tem.rawData_Verification["cal"]["geometry"]`` Geometrie, die mit der Rohmessung gespeichert wurde. ``tem.rawData_Verification["cal"]["efield"]`` Frequenzindizierte Rohmessdaten. Die Struktur ist ``efield[freq][port][point_index] -> list[entry]``. Die Einträge enthalten Feldsondenwerte, Vorwärts- und Rückwärtsleistung, Punkt-Metadaten und Leveling-Metadaten. ``tem.rawData_Verification["cal"]["uniform_area"]`` Name der Verifikationsebene. ``tem.rawData_Verification["cal"]["uniform_area_plane"]`` Vollständige Verifikationsebene mit h-/z-Position und allen Verifikationspunkten. ``tem.rawData_Verification["cal"]["probe_axis_maps"]`` Metadaten zur während der Messung verwendeten Feldsondenorientierung. ``tem.rawData_Verification["cal"]["target_efield"]`` Konfigurierte Ziel-Feldstärke der Verifikationsmessung, falls auf konstante Feldstärke geregelt wurde. Dieser Wert ist eine Sollgröße des Messablaufs und nicht automatisch identisch mit dem später ausgewerteten ``reference_field``. ``tem.rawData_Verification["cal"]["target_fwd_power"]`` Konfigurierte Ziel-Vorwärtsleistung der Verifikationsmessung, falls auf konstante Vorwärtsleistung geregelt wurde. ``tem.rawData_Verification["cal"]["verification_target_kind"]`` Kompakte, maschinenlesbare Beschreibung der Mess-Zielgröße: ``"field"``, ``"forward_power"`` oder ``"sg_level"``. Mehrere Verifikationsmessungen derselben Ebene können dadurch über unterschiedliche Descriptions nebeneinander im Pickle liegen und trotzdem nach Zielgröße gefiltert werden. ``tem.rawData_Verification["cal"]["verification_target_value"]`` Zielwert passend zu ``verification_target_kind``. Für Feldstärke und Vorwärtsleistung ist dies ein ``Quantity``-Objekt; für ``"sg_level"`` ist es der Startpegel des Signalgenerators in dBm. ``tem.rawData_Verification["cal"]["verification_target_label"]`` Menschenlesbare Kurzbeschreibung der Zielgröße, zum Beispiel ``"5 V/m"`` oder ``"5 W"``. ``tem.rawData_Verification["cal"]["verification_drive_mode"]`` Messmodus, mit dem die Zielgröße angefahren wurde, zum Beispiel ``"constant_field_strength"``, ``"constant_forward_power"`` oder ``"constant_sg_level"``. ``tem.processedData_Verification["cal"]`` Ausgewertete Verifikationsdaten. Die kompakten ``verification_target_*``-Metadaten aus den Rohdaten werden auch hier gespeichert, damit Auswerte- und Auswahlroutinen direkt auf den verarbeiteten Datensätzen arbeiten können. ``tem.processedData_Verification["cal"]["reference_field"]`` Frequenzindizierte Referenzfeldstärke für späteres Leveling: ``reference_field[freq] -> Quantity(V/m)``. ``tem.processedData_Verification["cal"]["forward_power"]`` Kompatibilitäts-Key für die frequenzindizierte Vorwärtsleistung, die zur Referenzfeldstärke gehört: ``forward_power[freq] -> Quantity(W)``. Für neue Auswertungen ist ``effective_reference_forward_power`` der eindeutigere Name. ``tem.processedData_Verification["cal"]["measured_forward_power_samples"]`` Gemessene Vorwärtsleistungswerte pro Frequenz und Verifikationspunkt. Im ``constant_forward_power``-Verfahren sollten diese Werte im Idealfall gleich sein; Abweichungen beschreiben die praktische Stabilität der eingestellten Vorwärtsleistung. ``tem.processedData_Verification["cal"]["measured_forward_power_mean"]`` Arithmetischer Mittelwert der gemessenen Vorwärtsleistungswerte. Dieser Mittelwert ist eine Implementierungs-Schätzung der im ``constant_forward_power``-Verfahren geforderten einen Vorwärtsleistung ``Pfwd``. ``tem.processedData_Verification["cal"]["measured_forward_power_sigma_db"]`` Standardabweichung der gemessenen Vorwärtsleistungswerte in dB. Dieser Wert ist eine Diagnosegröße für die Stabilität der Vorwärtsleistung. ``tem.processedData_Verification["cal"]["effective_reference_forward_power"]`` Vorwärtsleistung, auf die sich ``reference_field`` tatsächlich bezieht. Im aktuellen ``constant_forward_power``-Verfahren ist dies der arithmetische Mittelwert der gemessenen Vorwärtsleistungswerte. ``tem.processedData_Verification["cal"]["field_per_sqrt_power"]`` Frequenzindizierter Feldfaktor ``reference_field / sqrt(effective_reference_forward_power)``. Diese Größe ist die bevorzugte ``e0y``-Quelle für Emissionsauswertungen aus Verifikationsdaten. ``tem.processedData_Verification["cal"]["target_field"]`` Ziel-Feldstärke aus der Messkonfiguration, falls bekannt. ``tem.processedData_Verification["cal"]["target_forward_power"]`` Auf ``target_field`` umgerechnete Vorwärtsleistung: ``effective_reference_forward_power * (target_field / reference_field)^2``. Dieser Wert ist besonders für spätere Störfestigkeitsmessungen hilfreich, wenn die Verifikation bei einem Sollfeld, zum Beispiel 5 V/m, durchgeführt wurde, das ausgewertete ``reference_field`` aber frequenzabhängig leicht davon abweicht. ``tem.processedData_Verification["cal"]["reference_field_by_scale"]`` Alternative Referenzfeld-Auswertungen pro Frequenz. Die Unterkeys sind ``"db"``, ``"linear"`` und ``"coverage"``. ``tem.processedData_Verification["cal"]["point_summary"]`` Punktindizierte ausgewertete Werte: ``point_summary[point_label][freq]``. Jeder Eintrag enthält den Punkt, ``primary_field``, ``secondary_fields``, ``pfwd`` und ``pbwd``. ``tem.processedData_Verification["cal"]["points"]`` Frequenzindizierte Punktdaten: ``points[freq][point_label] -> list[entry]``. ``tem.processedData_Verification["cal"]["verification"]`` Vollständige Verifikationsauswertung pro Frequenz, inklusive Feldhomogenität, TEM-Mode-Kriterien und Referenzfeldvergleich. ``tem.processedData_Verification["cal"]["field_uniformity_passed"]`` Pass/Fail-Ergebnis der Feldhomogenität pro Frequenz. ``tem.processedData_Verification["cal"]["tem_mode_passed"]`` Pass/Fail-Ergebnis des TEM-Mode-Kriteriums pro Frequenz. ``tem.processedData_Verification["cal"]["tem_mode_in_exception_band"]`` Kennzeichnung pro Frequenz für Frequenzen, die das normale TEM-Mode-Limit nicht erfüllen, aber noch im normativen Ausnahmeband liegen. Die Gesamtzusammenfassung prüft weiterhin, ob die Anzahl dieser Frequenzen innerhalb des erlaubten Anteils bleibt. ``tem.processedData_Verification["cal"]["summary"]`` Gesamtzusammenfassung, unter anderem mit ``overall_passed``, ``field_uniformity_passed``, ``tem_mode_passed``, ``tem_mode_in_exception_band_count`` und Exception-Zählern. ``tem.processedData_Verification["cal"]["e0y_comparison"]`` Informativer Vergleich zwischen gemessenem und analytischem ``e0y``: ``e0y_comparison[freq][point_label]``. ``tem.processedData_Verification["cal"]["e0y_comparison_summary"]`` Frequenzweise Zusammenfassung des e0y-Vergleichs, unter anderem mit ``ratio_min``, ``ratio_max``, ``ratio_mean`` und ``delta_db_mean``. ``tem.processedData_Verification["cal"]["reference_dataset"]`` Metadaten des aus dieser Verifikation erzeugten Referenzdatensatzes. Spätere Störfestigkeitsmessungen nutzen diese Metadaten zusammen mit ``reference_field`` und ``forward_power``. ``tem.verification_datasets["cal"]`` Metadaten zur Roh-Verifikationsmessung. ``tem.reference_datasets["cal"]`` Metadaten zum ausgewerteten Referenzdatensatz für späteres Leveling und Störfestigkeitsmessungen. Verifikationsberichte --------------------- Aus einem ausgewerteten Verifikations-Pickle kann ohne Hardwarezugriff ein vollständiges Report-Paket erzeugt werden: .. code-block:: console python tem-verification-report.py path/to/tem-verification.p --description cal --output verification-report-cal --formats pdf html svg png Das Kommando lädt das Pickle mit dem Kompatibilitäts-Layer und liest ``processedData_Verification[description]``. Das Report-Verzeichnis enthält: ``verification-report-cal.pdf`` Mehrseitiger PDF-Bericht mit Zusammenfassung und Plots. ``index.html`` Statischer HTML-Bericht mit Links auf die erzeugten Grafiken und Tabellen. ``figures/*.svg`` Vektorplots für Referenzfeld, Vorwärtsleistung, Feldhomogenität, TEM-Mode-Kriterium, Anteil der TEM-Mode-Punktverletzungen, analytischen e0y-Vergleich und ausgewählte Punktkarten. Wenn dasselbe Pickle auch ausgewertete ``processedData_e0y``-Daten enthält, erzeugt der Report zusätzlich ``measured-e0y-comparison`` mit dem Vergleich der gemessenen Punkt-e0y-Datensätze gegen den analytischen GTEM-Wert. Der ``tem-mode-q75``-Plot zeigt den 75-%-Kennwert von ``max(E_secondary) / E_primary``. Der ``tem-mode-failed-points``-Plot zeigt den prozentualen Anteil der gültigen Punkte, bei denen ``max(E_secondary) / E_primary > 0.5`` ist; blaue und rote Hilfslinien markieren 5 % und 25 %. Die Punktkarten zeigen die niedrigste Frequenz, die höchste Frequenz und die Frequenz mit dem größten ``tem_mode_q75``. PNG-Kopien werden geschrieben, wenn ``png`` in ``--formats`` enthalten ist. ``tables/*.tsv`` Maschinenlesbare Tabellen für Summary, Referenzdaten, Exceptions, e0y-Vergleich, gemessene e0y-Datensätze und Punktwerte. ``summary.tsv`` enthält auch die kompakten ``verification_target_*``-Metadaten. ``reference-data.tsv`` enthält unter anderem ``effective_reference_forward_power``, ``field_per_sqrt_power``, ``target_field``, ``target_forward_power`` sowie ``tem_mode_failed_point_percent`` und die zugehörigen Punktzähler. ``measured-e0y.tsv`` wird gefüllt, wenn im selben Pickle ausgewertete ``processedData_e0y``-Einträge mit analytischem Vergleich vorhanden sind. PDF und HTML sind für schnelle Kontrolle und Archivierung gedacht. Die TSV-Dateien eignen sich besser für zusätzliche Scripts, Notebooks oder tabellenbasierte Prüfungen. Wenn das Kommando erneut mit demselben ``--output``-Verzeichnis ausgeführt wird, werden Dateien mit denselben generierten Namen überschrieben. Das Verzeichnis wird vorher nicht bereinigt; für einen exakt sauberen Dateibestand sollte das alte Report-Verzeichnis vorher entfernt werden. Die fachlich bevorzugten API-Namen sind ``Evaluate_Verification``, ``OutputRawData_Verification`` und ``OutputProcessedData_Verification``. Sie beschreiben den Ablauf als TEM-Mode-Verifikation, deren Ergebnis als Verifikationsreferenzdaten für spätere Leveling-Schritte gespeichert wird. Hardware-Vorlage für e0y-Messungen ---------------------------------- Für den ersten realen Lauf von ``tem-e0y.py`` gibt es eine Vorlage unter ``conf/tem-gtem-e0y-template/conf.py``. Sie schreibt alle Ausgaben in ein eigenes ``output``-Verzeichnis, ist auf ``preflight_only = True`` gesetzt und verwendet zunächst nur eine Frequenz mit konservativem ``initial_sg_power_dbm``. Der Preflight initialisiert Messgraph und Geräte, setzt den Startpegel bei ausgeschaltetem RF, führt RF-Off/Quit aus und überspringt Messschleife, Auswertung und Pickle-Ausgabe. Vor dem Hardwaretest müssen die ``TODO``-Einträge in den ``*-real-template.ini``-Dateien, die GTEM-Geometrie, der e0y-Punkt (``e0y_h`` oder ``e0y_z`` sowie ``e0y_x`` und ``e0y_y``) und die Feldsondenliste ``names["fp"]`` angepasst werden. Das ergänzende Runbook ``conf/tem-gtem-e0y-template/HARDWARE_TEST.md`` beschreibt den Preflight, den ersten RF-on-Lauf mit kleinem Umfang und die anschließende Prüfung von ``processedData_e0y["e0y"]``. Ein Block ``evaluation_parameters`` wird für dieses Script nicht benötigt. ``tem-e0y.py`` ruft ``Evaluate_e0y(description=...)`` direkt auf. Wenn ein Processed-Ausgabedateiname konfiguriert ist, schreibt das Script eine kompakte Processed-Datei, eine Punkttabelle und eine Tabelle mit dem analytischen e0y-Vergleich. Hardware-Vorlage für Emissionsmessungen --------------------------------------- Für den ersten realen Lauf von ``tem-emission.py`` gibt es eine Vorlage unter ``conf/tem-gtem-emission-template/conf.py``. Sie schreibt alle Ausgaben in ein eigenes ``output``-Verzeichnis, ist auf ``preflight_only = True`` gesetzt und verwendet zunächst nur eine Frequenz. Der Preflight initialisiert Messgraph und Receiver, prüft die konfigurierte e0y-/Grenzwert-Einstellung, führt RF-Off/Quit aus und überspringt Messschleife, Auswertung und Pickle-Ausgabe. Vor dem Hardwaretest müssen die ``TODO``-Einträge in ``receiver-real-template.ini``, die GTEM-Geometrie, die EUT-Position, die Pfaddämpfung vom GTEM-Port zum Receiver und ``EMISSION_LIMIT`` angepasst werden. Für den ersten Preflight nutzt die Vorlage analytisches GTEM-``e0y``. Für rückführbare Endergebnisse sollte danach ``REFERENCE_PICKLE`` auf ein e0y- oder Verifikationspickle gesetzt und ``use_e0y_GTEManalytical`` in Mess- und Auswerteparametern auf ``None`` gestellt werden. Das ergänzende Runbook ``conf/tem-gtem-emission-template/HARDWARE_TEST.md`` beschreibt den Preflight, den ersten kurzen Emissionslauf und die anschließende Prüfung von ``rawData_Emission``, ``RemeasureRequiredFrequencies`` und ``processedData_Emission[description]["LimitComparison"]``. Hardware-Vorlage für die TEM-Mode-Verifikation ---------------------------------------------- Für den ersten realen Lauf von ``tem-verification.py`` gibt es eine Vorlage unter ``conf/tem-gtem-verification-template/conf.py``. Sie schreibt alle Ausgaben in ein eigenes ``output``-Verzeichnis, ist auf ``preflight_only = True`` gesetzt und verwendet zunächst nur eine Frequenz mit konservativem ``initial_sg_power_dbm``. Der Preflight initialisiert Messgraph und Geräte, setzt den Startpegel bei ausgeschaltetem RF, führt RF-Off/Quit aus und überspringt Messschleife, Auswertung und Pickle-Ausgabe. Vor dem Hardwaretest müssen die ``TODO``-Einträge in den ``*-real-template.ini``-Dateien, die GTEM-Geometrie, die Uniform Area und die Feldsondenliste ``names["fp"]`` angepasst werden. Das ergänzende Runbook ``conf/tem-gtem-verification-template/HARDWARE_TEST.md`` beschreibt den Preflight, den ersten RF-on-Lauf mit kleinem Umfang und die anschließende Prüfung von ``processedData_Verification["verification"]``. Die Orientierung der Feldsonde sollte am Feldsondenknoten im Messgraphen konfiguriert werden. Für einfache signierte Achspermutationen wird ``probe_axis_map`` verwendet. Zum Beispiel bedeutet ``probe_axis_map="cell_x:-probe_y,cell_y:+probe_x,cell_z:+probe_z"``, dass die primäre Zell-y-Komponente aus dem probe-x-Kanal gelesen wird. Nach dem Lauf sollte ein Rohdaten-Feldsondeneintrag geprüft werden: ``value`` enthält den auf Zellachsen abgebildeten Vektor, während ``value_probe`` den ursprünglichen Sondenachsenvektor enthält. Für beliebige Verdrehungen der Sonde kann stattdessen ``probe_rotation_matrix`` verwendet werden. Die Matrix transformiert Messwerte in Sondenachsen auf Zellachsen: .. code-block:: text E_cell = R_cell_from_probe * E_probe Eine 90-Grad-Drehung um die Zell-/Sonden-z-Achse kann zum Beispiel als ``probe_rotation_matrix="0,-1,0;1,0,0;0,0,1"`` angegeben werden. Die Matrix muss eine eigentliche orthonormale Rotationsmatrix mit Determinante ``+1`` sein. Die ältere Syntax ``probe_axis_map`` bleibt für exakte Achsvertauschungen und Vorzeichenwechsel sinnvoll; intern wird sie als Spezialfall einer Rotationsmatrix behandelt. Als besser lesbare Alternative kann dieselbe Rotation über Winkel um feste Zellachsen konfiguriert werden: .. code-block:: python probe_rotation_angles_deg = { "about_cell_z": 90.0, "about_cell_x": 0.0, "about_cell_y": 0.0, } Die Konvention startet mit parallel ausgerichteten Sonden- und Zellachsen. Die Sonde wird dann zuerst um die feste Zell-z-Achse, anschließend um die feste Zell-x-Achse und zuletzt um die feste Zell-y-Achse gedreht. Intern werden diese Winkel in dieselbe ``R_cell_from_probe``-Matrix umgerechnet, die auch bei ``probe_rotation_matrix`` verwendet wird. Wichtig: In diesem Pfad ist ``initial_sg_power_dbm`` der sicherheitsrelevante konservative Startwert. ``target_efield`` ist im Messpfad mit konstanter Vorwärtsleistung kein Sicherheitslimit. Leveling-Strategien ------------------- Die implementierte GTEM-Störfestigkeitsstrategie ist ``forward_power_from_reference``. Sie bestimmt die notwendige Vorwärtsleistung am GTEM-Eingang aus ``reference_field`` und ``forward_power`` der Verifikationsreferenz und verwendet anschließend :class:`mpylab.tools.mgraph.Leveler`, um den Signalgenerator so einzustellen, dass der Vorwärtsleistungsmesser diesen Zielwert sieht. Die alternative Strategie ``field_probe_monitor`` regelt direkt auf eine Feldsonde an einer Monitorposition. Aus dem gewünschten Feld am EUT-Ort und den ``e0y``-Werten am EUT- und Monitorort wird zuerst das Sollfeld am Monitor berechnet. Der Signalgenerator wird anschließend iterativ so eingestellt, dass die Feldsonde dieses Monitorfeld misst. ``e0y_source = "analytical_geometry"`` verwendet die analytische GTEM-Geometrie; ``e0y_source = "verification_reference"`` verwendet die gespeicherten Verifikationsreferenzdaten. Mit ``probe_axis_map`` werden einfache signierte Achspermutationen der Sonde auf Zellachsen abgebildet, zum Beispiel ``"cell_y": "+probe_y"``. Für beliebige Verdrehungen kann ``probe_rotation_matrix`` oder ``probe_rotation_angles_deg`` mit derselben Sonden-nach-Zelle-Konvention verwendet werden. Das Vorzeichen kann angegeben werden, ist bei betragsbildenden Sonden aber oft praktisch ohne Wirkung. Bei mehreren Monitor-Sonden, die im DOT-File zum Beispiel über ``condition`` frequenzabhängig aktiviert werden, muss die Orientierung zur jeweils aktiven Sonde passen. Die Orientierung kann aus der Leveling-Konfiguration, dem DOT-Knoten oder der Fieldprobe-INI gelesen werden. Widersprüchliche Angaben werden abgelehnt, damit nicht unbemerkt mit einer falschen Achsorientierung ausgewertet oder geregelt wird. Für reale Hardwaretests sollte ``start_level`` in der Leveling-Konfiguration bewusst gesetzt werden. Der Wert ist der erste Signalgeneratorpegel der Regelung und sollte konservativ gewählt werden. Wenn ``start_level`` fehlt, kann der aktuelle Pegel des Signalgenerators über ``actor.GetLevel()`` als Komfortpfad verwendet werden, ist aber weniger eindeutig rückführbar. Vor einem Hardwaretest kann ``tem-immunity.py`` mit ``preflight_only = True`` in der Konfiguration gestartet werden. In diesem Modus werden Messgraph und Geräte initialisiert, die Leveling-Konfiguration einschließlich ``field_probe_monitor`` geprüft und anschließend RF-Off/Quit ausgeführt. Die eigentliche Messsequenz, Auswertung und Pickle-Ausgabe werden übersprungen. Für feldsondenbasierte Pfade gibt der Preflight zusätzlich die Quelle der effektiven Sondenorientierung, die Matrix ``R_cell_from_probe`` und den daraus folgenden Ausdruck für ``cell_y`` aus, zum Beispiel ``cell_y = +0.707*probe_x +0.707*probe_y``. Damit lässt sich direkt prüfen, ob die für Auswertung oder Regelung verwendete Zell-y-Komponente aus den gewünschten Sondenkanälen gebildet wird. Die Leveling-Ergebnisse werden im Rohdatensatz der Störfestigkeitsmessung gespeichert, unter anderem ``leveling_strategy``, ``leveling_target_monitor_field``, ``leveling_actual_monitor_field``, ``leveling_actor_level`` und ``leveling_samples``. Damit bleibt der konkrete Regelvorgang im Pickle nachvollziehbar. Erster Hardwaretest mit Feldsonden-Monitor ------------------------------------------ Für den ersten realen Lauf mit ``field_probe_monitor`` empfiehlt sich ein stufenweises Vorgehen: Als Ausgangspunkt gibt es eine Vorlage unter ``conf/tem-gtem-immunity-field-probe-template/conf.py``. Sie schreibt alle Ausgaben in ein eigenes ``output``-Verzeichnis, ist auf ``preflight_only = True`` gesetzt und enthält konservative Startwerte. Vor dem Hardwaretest müssen die ``TODO``-Einträge in den ``*-real-template.ini``-Dateien, die GTEM-Geometrie, die Positionen und der Pfad zum Kalibrier-Pickle angepasst werden. 1. ``preflight_only = True`` setzen und das Script starten. Der Lauf darf nur Geräte initialisieren, die Konfiguration prüfen und anschließend RF-Off/Quit ausführen. 2. ``preflight_only = False`` setzen, aber ``start_level`` bewusst klein wählen. Der Startpegel sollte deutlich unterhalb des erwarteten Arbeitspegels liegen. 3. Für den ersten Regeltest ein kleines Prüffeld verwenden, zum Beispiel ``field = 0.1`` oder einen anderen für den Aufbau ungefährlichen Wert. 4. Nach dem Lauf Log und Pickle prüfen. Besonders wichtig sind ``leveling_target_monitor_field``, ``leveling_actual_monitor_field``, ``leveling_actor_level`` und ``leveling_samples``. 5. Erst wenn Ziel- und Ist-Monitorfeld plausibel zusammenpassen, sollte der Prüfpegel schrittweise erhöht werden. EUT-Position bei Störfestigkeitsmessungen ----------------------------------------- Für ``tem-immunity.py`` kann die Position des Prüflings in den ``measure_parameters`` mit ``eut_h`` oder alternativ mit ``eut_z`` angegeben werden. ``eut_h`` ist die in der Praxis besser messbare Höhe in der GTEM-Zelle; ``eut_z`` ist die daraus über die festgelegte Geometrie berechnete Längskoordinate. Es darf nur eine der beiden Größen gesetzt werden. Positionsangaben ``x`` und ``y`` beziehen sich auf das Koordinatensystem der Zelle. Dabei ist ``y`` die absolute Höhe über der unteren GTEM-Platte bzw. dem Boden der Zelle; ``y = 0.25`` bedeutet also 25 cm über dem Boden. Vor der Messung zeigt die Störfestigkeitsroutine die vorhandenen Verifikationsebenen an. Wenn eine EUT-Position konfiguriert ist, werden zusätzlich die Zielposition und der Höhenabstand ``delta_h`` zur jeweiligen Ebene ausgegeben. Die Auswahl wird im Rohdatensatz unter ``reference_selection`` zusammen mit ``target_h``, ``target_z`` und ``delta_h`` gespeichert. Die virtuelle Konfiguration setzt beispielhaft ``eut_h = 0.5``. Liegt die EUT-Höhe zwischen zwei vorhandenen Ebenen, bietet der Dialog zusätzlich eine Interpolation zwischen diesen Ebenen an. Dabei werden nicht die fertigen Werte für ``forward_power`` linear in der Höhe interpoliert. Stattdessen wird frequenzweise der gemessene Feldfaktor ``K = reference_field / sqrt(forward_power)`` gebildet. Für eine ideal skalierende GTEM-Zelle ist ``K*h`` näherungsweise höhenunabhängig; diese Größe wird zwischen den benachbarten Ebenen interpoliert und anschließend auf die Zielhöhe zurückgerechnet. Aus dem resultierenden Feldfaktor wird die Vorwärtsleistung für den gewünschten Prüfpegel bestimmt. Die Interpolation wird nur angeboten, wenn für die angeforderten Messfrequenzen in beiden Ebenen gemeinsame ``reference_field``- und ``forward_power``-Werte vorhanden sind. Im Pickle werden bei interpolierter Auswahl zusätzlich ``mode = "interpolated"``, ``lower_reference``, ``upper_reference`` und ``fraction`` in ``reference_selection`` abgelegt. Immunity-Zielleistung und AM-Headroom ------------------------------------- Verifikationsreferenzen können ``immunity_reference``-Kurven enthalten, die aus ``required_immunity_efields`` erzeugt wurden. In ``tem-immunity.py`` wählt ``immunity_target_efield`` daraus die geforderte Störfestigkeits-Prüffeldstärke aus. Exakt vorhandene Zielpegel werden direkt verwendet. Zwischenwerte werden über ``E**2`` interpoliert. Zielpegel oberhalb des größten verifizierten Pegels werden abgelehnt. Für jede ausgewählte Frequenz speichern Roh- und Prozessdaten die gewählte ``immunity_reference_power_selection``. Darin stehen zwei unterschiedliche Vorwärtsleistungen: ``forward_power_for_required_immunity_efield`` Die Vorwärtsleistung für das normale Störfestigkeits-Prüffeld. ``forward_power_for_am_test_efield`` Die Vorwärtsleistung für das AM-Headroom-Feld ``required_immunity_efield * am_headroom_factor``. Mit dem Standardwert ``am_headroom_factor = 1.8`` entspricht dies der Reserveprüfung für 80 % AM. Der optionale Parameter ``headroom_check`` steuert, ob die Vorwärtsleistungsregelung zuerst ``forward_power_for_am_test_efield`` anfährt und anschließend für den eigentlichen Test auf ``forward_power_for_required_immunity_efield`` zurückkehrt. Der Check ist standardmäßig deaktiviert. Wenn er aktiv ist, werden die Felder ``leveling_headroom_check_*`` im Rohdatensatz gespeichert und in ``processedData_Immunity[description]["leveling_summary"]`` zusammengefasst. Die Feldsonden-Monitor-Vorlage lässt ``immunity_target_efield`` und ``headroom_check`` bewusst deaktiviert, solange der erste Hardwaretest mit kleinem Live-Monitorfeld erfolgt. Beide Parameter sollten erst aktiviert werden, wenn das ausgewählte Verifikations-Pickle passende ``immunity_reference``-Kurven enthält und der HF-Pfad zuvor konservativ getestet wurde. Virtueller GTEM-Lauf -------------------- Aus dem Verzeichnis ``script`` kann der hardwareunabhängige Ablauf so gestartet werden: .. code-block:: console python tem-e0y.py conf/tem-gtem-e0y-virtual/conf.py python tem-emission.py conf/tem-gtem-emission-virtual/conf.py Alternativ kann die Emissionsmessung nach einer virtuellen Verifikationsreferenz die Verifikationsreferenzdaten direkt als ``e0y``-Quelle verwenden: .. code-block:: console python tem-verification.py conf/tem-gtem-verification-virtual/conf.py python tem-emission.py conf/tem-gtem-emission-virtual-from-verification/conf.py Für einen virtuellen GTEM-Störfestigkeitslauf: .. code-block:: console python tem-verification.py conf/tem-gtem-verification-virtual/conf.py python tem-immunity.py conf/tem-gtem-immunity-virtual/conf.py Die Live-Feldsondenstrategie kann ohne Hardware mit einer zweiten virtuellen Konfiguration getestet werden: .. code-block:: console python tem-verification.py conf/tem-gtem-verification-virtual/conf.py python tem-immunity.py conf/tem-gtem-immunity-virtual/conf-field-probe-monitor.py Dieselben Abläufe können über die Qt-Oberfläche gestartet werden: .. code-block:: console python tem-e0y-qt.py conf/tem-gtem-e0y-virtual/conf.py python tem-emission-qt.py conf/tem-gtem-emission-virtual/conf.py python tem-verification-qt.py conf/tem-gtem-verification-virtual/conf.py python tem-immunity-qt.py conf/tem-gtem-immunity-virtual/conf.py Der Stop-Button der Qt-Oberfläche verwendet denselben User-Interrupt-Pfad wie das Text-UI. Er ist damit für Entwicklung und Bedienerprobung geeignet, ersetzt aber nicht die RF-off-Behandlung in den Messroutinen. Die erste Messung schreibt ihr Pickle nach ``conf/tem-gtem-e0y-virtual/output``. Die virtuelle Emissionskonfiguration verwendet dieses Pickle als Eingang und schreibt ihre eigenen Ergebnisse nach ``conf/tem-gtem-emission-virtual/output``. Bei e0y wird die Processed-Ausgabe in eine kompakte Datei und Detailtabellen aufgeteilt. ``out_points_tem-e0y-virtual-gtem.dat`` enthält eine Zeile pro Frequenz und Messpunkt mit Spalten für Feld, e0y, Vorwärtsleistung und Rückwärtsleistung. ``out_e0y-comparison_tem-e0y-virtual-gtem.dat`` enthält den Vergleich zwischen gemessenem und analytischem e0y, wenn e0y-Punkt und GTEM-Geometrie bekannt sind. Die alternative virtuelle Emissionskonfiguration aus Referenzdaten verwendet das Pickle aus ``conf/tem-gtem-verification-virtual/output`` und schreibt ihre eigenen Ergebnisse nach ``conf/tem-gtem-emission-virtual-from-verification/output``. Die virtuelle Verifikationsreferenz schreibt ihr Pickle nach ``conf/tem-gtem-verification-virtual/output``. Die virtuelle Störfestigkeitskonfiguration verwendet dieses Pickle als Eingang und schreibt ihre eigenen Ergebnisse nach ``conf/tem-gtem-immunity-virtual/output``. Die Datei ``out_processed_tem-verification-verification.dat`` enthält dabei auch die Tabelle ``reference_field_comparison``. Sie zeigt pro Frequenz den aktuell für das Leveling ausgewählten Referenzfeldwert sowie die Vergleichswerte ``db``, ``linear`` und ``coverage``. Für eine schnelle Kontrolle kann die Ausgabedatei direkt nach diesem Schlüssel durchsucht werden: .. code-block:: console grep -n "reference_field_comparison" conf/tem-gtem-verification-virtual/output/out_processed_tem-verification-verification.dat Die Begleitdatei ``out_e0y-comparison_tem-verification-verification.dat`` enthält den punktweisen analytischen ``e0y``-Vergleich mit einer Zeile pro Frequenz und Verifikationspunkt. Sie ist hilfreich, um Geometrie-, Positions-, Orientierungs- oder höhere-Moden-Effekte zu erkennen, ohne das Verifikationsergebnis selbst zu verändern. Die Processed-Textausgabe folgt der deterministischen Reihenfolge der Processed-Pickle-Schlüssel und ist für schnelle Reviews gedacht. Tiefer verschachtelte Daten wie punktweise Feldmesswerte lassen sich besser direkt aus dem Pickle untersuchen, zum Beispiel mit ``pexplorer``. Die virtuellen Konfigurationen verwenden ausschließlich virtuelle Gerätetreiber aus ``mpylab.device`` und synthetische Pfadkorrekturen. Sie sind daher für Entwicklung, Fehlersuche und Regressionstests ohne Laborhardware geeignet. Tests ----- Der GTEM-Ablauf wird durch ``test/test_tem_scripts.py`` abgedeckt. Die Tests führen die virtuellen Ketten ``e0y -> emission`` und ``verification -> immunity`` mit temporären Ausgabedateien aus und prüfen, dass die resultierenden Pickles die vorherige ``TEMCell``-Historie erhalten. Die Tests können aus dem Repository-Wurzelverzeichnis gestartet werden: .. code-block:: console PYTHONPATH=src:../scuq/src python -m pytest test/test_tem_scripts.py