Kennt jemand den librevna? Ich habe mir den aufgebaut, was auch soweit
funktioniert nur bezüglich der Kalibrierung gibt es massive Probleme.
Die ist nach einen power cycle völlig unbrauchbar, was sehr suboptimal
ist. Woran könnte das liegen?
Daniel G. schrieb:> Woran könnte das liegen?
Kann das Ding Kalibrierwerte persistent speichern?
Hast du das Ding erstmal ne Weile aufwärmen lassen bevor du kalibriert
hast?
mfg mf
Achim M. schrieb:> Daniel G. schrieb:>>> Woran könnte das liegen?>> Kann das Ding Kalibrierwerte persistent speichern?> Hast du das Ding erstmal ne Weile aufwärmen lassen bevor du kalibriert> hast?> mfg mf
Ich nehme mir die Rohdaten und kalibriere dann in Python. Da ist
definitiv zu beobachten, dass nach nur ein paar Sekunden Abschaltung die
Kalibrierung murks ist.
Daniel G. schrieb:> Da ist> definitiv zu beobachten, dass nach nur ein paar Sekunden Abschaltung die> Kalibrierung murks ist.
Ich würde das als Hinweis sehen, dass die Daten noch im RAM stehen und
erst in permanenten Speicher überführt werden müssen.
Hp M. schrieb:> Daniel G. schrieb:>>> Da ist>> definitiv zu beobachten, dass nach nur ein paar Sekunden Abschaltung die>> Kalibrierung murks ist.>> Ich würde das als Hinweis sehen, dass die Daten noch im RAM stehen und> erst in permanenten Speicher überführt werden müssen.
Da ist nichts im RAM. Ich habe ein Python Skript, das mir
kalibrierparameter generiert und diese dann auch gemessene Daten
anwendet. Das klappt solange wie power da ist einen power cycle und die
Kalibrierung ist hinfällig und die neuen Daten werden falsch kalibriert.
Daniel G. schrieb:> Da ist nichts im RAM.
AHA!!
> Ich habe ein Python Skript, das mir> kalibrierparameter generiert und diese dann auch gemessene Daten> anwendet.
SOSO!!
> Das klappt solange wie power da ist einen power cycle und die> Kalibrierung ist hinfällig und die neuen Daten werden falsch kalibriert.
Also doch im Ram des VNAs gespeichert. Sonst wären die Daten nach dem
Ausschalten ja nicht weg.
Das selbe Problem hat auch der HP8752A
Der speichert zwar die Kalibrierdaten in einer der 5 Memoryplätze.
Diese stehen aber auch im Ram des HP8752A und sind nach dem Ausschalten
des Gerätes weg. Man muss sie auf einen externen Diskettenlaufwerk
speichern.
So ähnlich wird das bei deinen VNA auch sein. Du musst es auf deinen
Rechner speichern.
Ralph Berres
Also nochmal. Ich konfigurieren den VNA so, dass er Rohdaten ausgibt und
zwar unkalibriert. Ich Messe dann mit einen Skript SOLT. Damit berechne
ich kalibrierparameter. Anschließend Messe ich wieder unkalibrierte
rohdaten und wende die Kalibrierung an. Alles auf der Festplatte meines
PC. Der librevna ist wohl kaum mit einem kommerziellen uralt highend
gerät vergleichbar.
Daniel G. schrieb:> Ich konfigurieren den VNA so, dass er Rohdaten ausgibt und> zwar unkalibriert.
verliert der VNA nach dem Neueinschalten, vielleicht genau diese
Konfiguration?
Warum sollte nach Neustart des VNAs sich was ändern, wenn nichts in den
Ram des VNAs geschrieben wird?
Ralph Berres
Die setze ich natürlich neu. Spricht irgendwas hardwaremäßig für einen
Verlust der Kalibrierung? Gerade ein eventuelles weglaufen der PLLs und
der Referenz?
Eigentlich sollte man grundsätzlich bei einen VNA nach jeder Änderung
des Messaufbaues eine Kalibrierung durchführen. Das gilt umso mehr, je
höher die Frequenzen.
Ralph Berres
Ralph B. schrieb:> Eigentlich sollte man grundsätzlich bei einen VNA nach jeder> Änderung des Messaufbaues eine Kalibrierung durchführen. Das gilt umso> mehr, je höher die Frequenzen.> Ralph Berres
Das weiß ich. Das setup ändert sich auch nicht. Ich habe alle kabel mal
festgeklebt. Gleiches Resultat nach der Kalibrierung ohne gewackel am
kabel.
Daniel G. schrieb:> Spricht irgendwas hardwaremäßig für einen> Verlust der Kalibrierung? Gerade ein eventuelles weglaufen der PLLs und> der Referenz?
Wenn natürlich die Frequenz wegläuft ist das unangenehm. Das kann sich
je nach Messbandbreite schon unangenehm bemerkbar machen.
Dann würde ich aber auch erwarten das es während des Betriebes
allmählich wegläuft. Wenn es nur nach abschalten und Neueinschalten
passiert, dann ist etwas mit dem Gerät oberfaul.
Kann es sein das die Konfiguration der PLLs von dem VNA selbstständig
vorgenommen wird und nach jeden Neustart trotz selber Frequenz eine
andere ist?
Ralph Berres
Die PLLs werden vom gerät konfiguriert, richtig. Sehe aber gerade nicht
was da anders sein sollte. Die PLLs sollten ja bei gleicher Referenz
immer in der Phase konstant bleiben ganz gleich, ob ich das gerät
ausschalten.
Zuerst einmal: der beschriebene weg, Rohdaten über externe
Programme/Skripte für die Kalibrierung zu nutzen ist natürlich
vollkommen okay. Da geht nichts im RAM verloren, die gesamte
Kalibrierung findet beim LibreVNA immer in der GUI statt, das Gerät
selbst gibt nur Rohwerte aus. Genau diese Kalibrierung der GUI wird hier
übersprungen und stattdessen werden die (unkalibrierten) Rohwerte
benutzt - soweit alles in Ordnung.
Daniel G. schrieb:> Die ist nach einen power cycle völlig unbrauchbar, was sehr suboptimal> ist.
Kannst du "völlig unbrauchbar" etwas in Zahlen ausdrücken?
Was mich auch interessieren würde, sind die Rohdaten direkt vor und nach
dem power cycle (einfach aus der GUI als Touchstone exportiert). Da
müsste man dann ja auch einen deutlichen Unterschied sehen.
Achim M. schrieb:> Hast du das Ding erstmal ne Weile aufwärmen lassen bevor du kalibriert> hast?
Generell eine gute Idee, der LibreVNA wird ja durchaus etwas warm.
Entweder du spendierst dem noch einen Lüfter oder du wartest bis die
Temperatur sich halbwegs stabilisiert hat (siehe Temperaturen der PLLs
und µC unten in der Statusleiste)
Viele Grüße,
Jan
Ralph B. schrieb:> Dann würde ich aber auch erwarten das es während des Betriebes> allmählich wegläuft. Wenn es nur nach abschalten und Neueinschalten> passiert, dann ist etwas mit dem Gerät oberfaul.
Wart's ab.
Am Ende heisst es wahrscheinlich doch noch "Mimimi - der Fehler war
leider doch in meinem Python-Skript".
Daniel G. schrieb:> Die PLLs sollten ja bei gleicher Referenz> immer in der Phase konstant bleiben ganz gleich, ob ich das gerät> ausschalten.
und wie wird das garantiert?
Ralph Berres
Ralph B. schrieb:> und wie wird das garantiert?
Das wird nicht garantiert, die PLLs (Source-Signal und LO Signale) sind
nicht phasengleich (sogar nicht phasengleich von einem Messpunkt zum
nächsten). Wie auch, sie erzeugen ja unterschiedliche Frequenzen.
Unter anderem genau dafür gibt es ja bei VNAs den Referenzkanal. Das,
was als Rohwert beim LibreVNA übergeben wird ist das Verhältnis aus
reflektiertem (bzw. übertragenem bei S12/S21) Signal zu erzeugtem
Signal. Dabei heben sich die Phasenlagen der PLLs gegenseitig auf und
übrig bleibt nur die Phasenverschiebung aufgrund des DUTs. Und natürlich
auch eine konstante, frequenzabhängige Phasenverschiebung aufgrund
unterschiedlich langer interner Leiterbahnen - aber darum kümmert sich
ja dann die Kalibrierung.
Also nein, solange die PLLs "irgendwie" laufen, können die nicht die
Ursache für Probleme nach Wiedereinschalten sein. Ich bleibe dabei: um
hier richtig helfen zu können, brauche ich die Rohdaten. Auch wenn ich
an der Stelle einen Bug im LibreVNA (abgesehen von Temperaturdrift) für
unwahrscheinlich halte, kann ich das natürlich nicht ausschließen. Dann
würde ich an der Stelle gerne nachbessern, aber dazu brauche ich mehr
als "macht Probleme".
Viele Grüße
Jan
Ralph B. schrieb:> Daniel G. schrieb:>>> Die PLLs sollten ja bei gleicher Referenz>> immer in der Phase konstant bleiben ganz gleich, ob ich das gerät>> ausschalten.>> und wie wird das garantiert?> Ralph Berres
Das ist das Prinzip von phasenregelschleifen. Das solltest du eigentlich
wissen. Die absolute Phase beim VNA ist eigentlich egal. Es geht nur
darum, dass die Phase der Empfangs und sendepfade im VNA phasenstarr
sind. Dann können die auch driften Hauptsache das ist gleich. Deswegen
hat man auch einen referenzquarz und nur einen. Ich glaube von anritsu
gibt eine Ausführung wie VNAs funktionieren. Kann nie schaden.
Eine eigene Frage?
Dieser Thread ist über 4 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.