60m-Band

Moderator: DL7UCX

Benutzeravatar
DL7UCX
Beiträge: 5360
Registriert: Donnerstag 8. August 2002, 19:23
Wohnort: Dabendorf
Kontaktdaten:

Re: 60m-Band

Beitrag von DL7UCX » Freitag 13. September 2019, 19:37

Hallo Peter,

der automatische Import läuft in UcxLog immer ab der letzten Stelle im ADIF-Log von WSJT-X.
Alte QSOs werden nicht neu geladen. Das funktioniert.
Ob 2 OPs gleichzeitig QRV sind, ist nicht das Problem.

Wenn Du vom Club nach Hause kommst, bist Du dann wieder auf dem einem PC oder auf einem zweiten ?
Muß dieser OP-Wechsel sein ?

73 Ben

DM5DX
Beiträge: 11
Registriert: Mittwoch 5. September 2018, 12:22

Re: 60m-Band

Beitrag von DM5DX » Dienstag 17. September 2019, 12:50

Hallo Ben,

habe die Antwort erst jetzt gesehen als ich auf den Reiter "2" aufmerksam wurde.

Nun ist es am Wochenende oder gestern wieder passiert, dass unnötig alte WSJT-X-QSO's importiert wurden und zwar fast alle vom OP DM_KAT (zu Hause) vom 07.03.2019 1616 UTC (die ersten 2 QSO's vom 07.03. nicht) bis zum 14.09.2019.


"der automatische Import läuft in UcxLog immer ab der letzten Stelle im ADIF-Log von WSJT-X."
==> Der Zeitstempel von wsjtx_log.adi war ca. 16.09.19 12:30. (Wenn sich QSO's durch Abgleich mit LOTW/eQSL/Clublog als doch nicht komplett herausstellen, lösche ich diese manuell, damit die Bandslots wieder als gesucht gelten.) Als ich 17:30 Uhr zu Hause UCXLog startete, dürfte es keinen Grund für den Import gegeben haben. Oder speichert UCXLog separat einen Zeitstempel bei der letzten Nutzung von wsjtx_log.adi?


"Wenn Du vom Club nach Hause kommst, bist Du dann wieder auf dem einem PC oder auf einem zweiten ?"
==> Am Club nutze ich einen Desktop-PC oder ein Notebook mit den Datenverzeichnissen jeweils darauf. Unterwegs z.B. mittags auf QRL starte ich UCXLOg auch mal von externer Festplatte. Zu Hause nutze ich stets den selben PC. Nach jedem Rechnerwechsel muss das Backup-Verzeichnis angepasst werden.

Nach wie vor nutze ich ein altes dBase-Programm als Master-Log. Somit ist durch den zusätzlichen Import jetzt nichts gefährdet, aber es bewirkt Unwohlsein bei Nutzung und Verlassen auf das Programm trotz aller super Features, die ich gern nutze. In dBase nutze ich auch gern die Indizierung nach Manager+Calls für den Mehrfachversand an einzelne Manager, was ich in UCXLog bisher nicht fand. Jedenfalls kommen dadurch z.B. die Frequenzen 1.8 etc zustande anstelle von 1840.7 in UCXLog nach dem Import aus dBase als ADIF-Datei.


"Muß dieser OP-Wechsel sein ?"
==> Die verschiedenen OP's legte ich wie gesagt an wegen LOTW, um den Locator korrekt zuzuordnen speziell auf 6m. Dadurch konnte ich beim ersten LOTW Upload 2018 trotz vieler sich überschneidender Standortwechsel über mehrere Jahre alle QSO's auf einmal exportieren.

Ich schreibe alles etwas ausführlicher, um evtl. eigenen Denkfehlern auf die Spur zu kommen oder den einen oder anderen Tipp zu erhaschen, wie etwas einfacher oder besser geht in UCXLog. Die Logdatei 2019, wsjtx_log.adi sowie die CSV-Exportdatei 2019 schicke ich separat als Mail zus. mit Kommentaren. Gerade sehe ich Dateien LOG_2019.UC~ und LOG_2019.UC~201909170331 im Backup-Verzeichnis und werde diese auch mitschicken. Sehen aus wie Absturzprodukte o.ä.
Vielleicht kann man daraus etwas ersehen, warum die QSO's erneut importiert wurden.

73, Peter

Benutzeravatar
DL7UCX
Beiträge: 5360
Registriert: Donnerstag 8. August 2002, 19:23
Wohnort: Dabendorf
Kontaktdaten:

Re: 60m-Band

Beitrag von DL7UCX » Dienstag 17. September 2019, 18:23

Hallo Peter,

das sieht bei Dir ja wirklich kompliziert aus, ich versuche mich schrittweise heranzutasten.

Die "letzte Stelle" ist kein Zeitstempel eines QSOs !
Dann müßte UcxLog ja immer eine evtl. recht große Datei lesen und analysieren.
UcxLog merkt sich die letzte Dateigröße (in Bytes) und liest ab dieser Stelle weiter.
Wenn Du dort ein ADIF-QSO manuell löschst, wird die Datei kleiner und UcxLog muß sie neu von vorne lesen.
Da liegt also die erste Fehlerursache, an der ich nichts ändern kann und will.

Wenn Du verschiedene Rechner (3 ?) nutzt, wie überträgst Du beim Wechsel die Ucx-Logs und das WSJT-Log ?
Ist dann auf allen PCs der Operator gleich?

Den OP-Wechsel verstehe ich, das ist ok.

Die Dateien *.UC~ sind keine "Absturzprodukte" sondern werden vor risikoreichen Operationen (wie z.B. Sortieren) als Backup angelegt.
Das verrät übrigens auch die Help bei der Suche nach "*.UC~".

Um zu ersehen, warum QSOs doppelt sind, brauche ich eine Logdatei LOG_2019.UCX, in der diese noch doppelt sind (nicht sortieren).

73 Ben

Benutzeravatar
DL7UCX
Beiträge: 5360
Registriert: Donnerstag 8. August 2002, 19:23
Wohnort: Dabendorf
Kontaktdaten:

Re: 60m-Band

Beitrag von DL7UCX » Mittwoch 18. September 2019, 10:45

Hallo Peter,

ich habe einige Tests gemacht und konnte auch mit verschiedenen Operatoren keine Mehrfach-Importe aus der ADIF-Datei provozieren.

Es bleiben also diese Fragen von mir:
- Wenn Du verschiedene Rechner (3 ?) nutzt, wie überträgst Du beim Wechsel die Ucx-Logs und das WSJT-Log ?
- Um zu ersehen, warum QSOs doppelt sind, brauche ich eine Logdatei LOG_2019.UCX, in der diese noch doppelt sind (nicht sortieren).
73 Ben

Benutzeravatar
DL7UCX
Beiträge: 5360
Registriert: Donnerstag 8. August 2002, 19:23
Wohnort: Dabendorf
Kontaktdaten:

Re: 60m-Band

Beitrag von DL7UCX » Mittwoch 18. September 2019, 20:48

Hallo,

das Rätsel ist nun gelöst.

Die doppelten QSOs waren zwar mit verschiedener Frequenz im Log (Bandanfang und genaue kHz), dadurch wurde UcxLog aber nicht durcheinander gebracht.

Es lag daran, daß im ADIF-File nicht nur das eigene Rufzeichen, sondern auch ein "Operator" eingetragen waren.
Den hat UcxLog zwar durch den aktuell eingestellten Operator überschrieben, aber zu spät. Deshalb wurde vorher ein anderes, neues QSO erkannt.

Das Problem ist in 7.97 Beta 2 behoben, bei anderen trat es wahrscheinlich nicht auf, weil in WSJT-X kein anderer "Operator" definiert wurde.

73 Ben

Antworten