QSL's / Bestätigungen via e-qsl - wie verarbeiten?

[DL1DTL]

Hi Peter,

mit Deinem LotW-Standing kannst Du voll zufrieden sein.
QSL-Moral hat sich eher verschlechtert. Direkt-Karten werden auch oft sehr zögerlich beantwortet, manchmal auch gar nicht.

Zum DCL:
Die Datenbasis beruht auf dem Pool an Contestlogs, die für DARC-Conteste eingehen. Außerdem wurden Logs von den CQ-Contesten eingespielt.
Und man hat die Möglichkeit als LotW-User seine LotW-Bestätigungen ins DCL zu übertragen.
Auch von e-qsl kannst Du Bestätigungen ins DCL übertragen, aber nur, wenn Du mindestens Bronze-Member bist.

Aber schau es Dir an.

73

Klaus DL1DTL

[DG9VH]

... und hier gilt, dass, soweit ich das sehe, auch nur die QSLs übernommen werden, wenn die Gegenstation einen (AG)-Status besitzt...

73, Kim, DG9VH

[DL1DTL]

richtig!

73

Klaus DL1DTL

[DL7UCX]

Hallo,

ich werde wohl oder übel doch mal über die Implementierung von eQSL nachdenken müssen.
Welche Unterschiede zu LOTW gibt es bei der Behandlung im Logprogramm?
Wo sollte eQSL zusätzlich oder alternativ zu LOTW angezeigt werden (Edit log - Full, QSL-ADIF-Import/Export, View-..., Scan-..., ...)?
Sollen geänderte QSOs erneut zum Export markiert werden (wie bei LOTW)?

73 Ben

[DG9VH]

Hallo Ben,

Welche Unterschiede zu LOTW gibt es bei der Behandlung im Logprogramm?

Da ich jetzt LoTW nicht kenne und nutze, kann ich darauf mal keine verlässliche Antwort geben.

Wo sollte eQSL zusätzlich oder alternativ zu LOTW angezeigt werden (Edit log - Full, QSL-ADIF-Import/Export, View-..., Scan-..., ...)?

Da EQSL bezogen auf seine Awards die "Logik" im Portal versteckt hat, brauchts hier eigentlich keine großen statistischen Dinge, denke ich. EQSLs vom Blickpunkt her eher wie traditionelle QSLs zu betrachten, wäre denke ich mal eher ein Weg, der die Sache logisch klarer fasst. Du hast bei EQSL die Möglichkeit, deinen Karteneingang (die sogenannte Inbox) als ADIF zu exportieren und lokal weiter zu verarbeiten. Jetzt denke ich wäre hier eine Funktion auf UcxLog-Seite gut, die dieses Adif einlädt und bei den erfassten QSOs ein EQSL-Eingangsfeld auf True setzt.

Stellt sich jetzt die Frage, was man mit den QSOs macht, die im Inbox-Export sind, zu denen es aber keine Entsprechung im UcxLog gibt. Hier würde ich evtl. dazu tendieren, diese in ein eigenes ADIF-File zu packen (z.B. "NotInLog.adi"), damit der Nutzer selbst entscheiden kann, ob er diese QSOs in sein Log in einem zweiten Schritt importieren möchte oder nicht. Ich persönlich würde das wirklich Einzelfall abhängig sehen.

Für den Export wäre es wiederum so, dass man wie beim normalen QSL-Druck ein Feld hätte, welches man im einfachsten Fall einfach auf True oder False setzt (evtl. mit einem Datum gekoppelt, wann man es exportiert hat).

Um die Frage also zum Ende nochmal zu beantworten: Mir persönlich würde eine Anzeige im Edit-Log-Full vollkommen ausreichen. Wie das andere sehen, kann man ja mal im Laufe der Diskussion hier abwarten.

Sollen geänderte QSOs erneut zum Export markiert werden (wie bei LOTW)?

Würde ich als sinnvoll betrachten. Denn es ist in der Praxis so, dass bei EQSL auch Karten "Rejected", also abgewiesen werden können wegen formaler Fehler (z.B. falscher Mode, falsches Band etc.). Da diese Fehler häufig durch Tippfehler oder dergleichen verursacht werden, wäre es sicherlich nicht schlecht, wenn man sich nun sagt: UcxLog ist für das Log das führende System, also sollten solche Fehler im Log selbst korrigiert werden und dann eben diese QSOs nochmal exportiert werden zum erneuten Upload.

Für mich stellen sich also folgende Baustellen dar:

• Exportfunktion für EQSL (wobei hier ähnlich wie LOTW verfahren werden könnte
• Anzeige dreier Felder im Edit-Full-Log (Sent, Received, Datum-Sent)
• Import der Inbox und Abgleich des Received-Feldes sowie Möglichkeit zur weiteren Verarbeitung von "Not In Logs"

Achja, bei den Not In Logs wäre es sinnvoll, wenn hier der Sent-Status Status noch nicht gesetzt wäre, weil ich denke, dass im EQSL (sei denn, man confirmed die QSOs dort von Hand) noch kein Gegenstück besteht. Man müsste also, wenn man das QSO importiert hat, sicher stellen können, dass beim nächsten EQSL-Export, diese importierten QSOs nochmal exportiert und nach EQSL gehen.

"Nice to have" wäre ebenfalls noch ein Kommentarfeld, welches an die EQSLs mit rausgeht. Ich weiß nicht, welches Feld der ADIF-Spezifikation die Kollegen hier verwenden, ich denke aber, es dürfte wohl das Kommentar-Feld sein. Bin mir aber nicht sicher.

So, viel Geschrieben, nun dürfen die Anderen auf mich einschlagen

73, Kim, DG9VH

[DL6ER]

Hallo zusammen,

"Nice to have" wäre ebenfalls noch ein Kommentarfeld, welches an die EQSLs mit rausgeht. Ich weiß nicht, welches Feld der ADIF-Spezifikation die Kollegen hier verwenden, ich denke aber, es dürfte wohl das Kommentar-Feld sein. Bin mir aber nicht sicher.

Laut den Spezifikationen für den ADIF-Import in eQSL (http://www.eqsl.cc/qslcard/adifcontentspecs.cfm) wird für die Kommentare entweder ein Feld QSL_Comment oder QSLMSG verwendet.

Stellt sich jetzt die Frage, was man mit den QSOs macht, die im Inbox-Export sind, zu denen es aber keine Entsprechung im UcxLog gibt.

Soweit ich das verstehe, geht es also um QSOs, die ich nicht geloggt habe? Ob das so praktisch wäre, wenn man die in einer externen Datei auslagert? Wenn ich eine Papier-QSL Karte bekomme, die sich nicht mit dem Log deckt, suche ich immer intensiv nach möglichen Fehlerquellen (Call-, Datums-, Uhrzeitfehler, ...), aber wie gut ist das aus einer irgendwo liegenden ADIF-Datei machbar, bzw. wie oft kommt das überhaupt vor?

73 Dominik

[DG9VH]

Soweit ich das verstehe, geht es also um QSOs, die ich nicht geloggt habe? Ob das so praktisch wäre, wenn man die in einer externen Datei auslagert? Wenn ich eine Papier-QSL Karte bekomme, die sich nicht mit dem Log deckt, suche ich immer intensiv nach möglichen Fehlerquellen (Call-, Datums-, Uhrzeitfehler, ...), aber wie gut ist das aus einer irgendwo liegenden ADIF-Datei machbar, bzw. wie oft kommt das überhaupt vor?

Eigentlich(!) kommt sowas im Idealfall ja gar nicht vor Aber die Realität ist halt die, dass viele OM, die z.B. an Clubstationen qrv waren zwar irgendwo mal zwischendurch ihr eigenes Rufzeichen nannten, man selbst aber häufig ja nur das Club-Call im Log hat. Diese OM schicken aber dann mit dem eigenen Rufzeichen auch gerne EQSLs raus, weil sie das Log ihrer Aktivität ins eigene Log übernehmen und entsprechend auch bei EQSL raufladen.

Es ist also so, dass ich vielleicht im Monat so 2-3 solcher Eingänge habe (was wohl schon "überdurchschnittlich viel" ist), zu denen ich mir anhand der Uhrzeit und so weiter ein QSO im Log finde, was an einer Clubstation stattfand. Weitere Recherchen bei QRZ.com z.B. ergeben dann ein Matching im OV und dergleichen, weshalb ich hier dann zu 99% Sicherheit davon ausgehe, dass diese dann auch die OPs an den Clubstationen waren, zumal der Vorname im Log ja sehr häufig erfasst ist bei mir und dann auch passt.

Es kommt selten vor, läuft aber in der Regel darauf hinaus, dass man diese OMs dann doch gerne auch mit Papier-QSL und EQSL beglückt

73, Kim

[DL7UCX]

Hallo,

hier schon mal eine Zwischenantwort zur Eingrenzung:

Anzeige dreier Felder im Edit-Full-Log (Sent, Received, Datum-Sent)

Mehr als bei LOTW möchte ich nicht machen, d.h. nur Received wird angezeigt.
Das Datum paßt nicht mehr in den Logdatensatz, halte ich auch für verzichtbar.
Das Sent wird unsichtbar verwaltet (Gesetzt beim Export, Rückgesetzt beim Ändern der QSO-Daten), beim Export kann man dann wie bei LOTW wählen, ob alle im Zeitraum oder nur "noch nicht gesendete" exportiert werden sollen.

Von dem extra Kommentar-Feld bin ich nicht angetan, wo soll der auch herkommen?

73 Ben

[DG9VH]

Für den Comment würde ich das Remarks-Feld einfach nehmen

Ansonsten kann ich mit deinem Vorschlag gut leben

73, Kim

[DL7UCX]

Das hieße, das Remarks-Field wird (schaltbar) in alle ADIF-Records ausgegeben oder in keinen !?

Das Feld QSL_Comment kennt ADIF nicht.
QSLMSG gibt es, das ist ein MultilineString, wobei ich nur 1 Zeile füllen könnte.

73 Ben

[DG9VH]

Wenn du QSLMSG nun mit dem Inhalt des Remarks-Feldes füllst, wäre die Sache doch denke ich hier schon soweit ok.

Alternativ könnte man auch hier in der Konfiguration eine Textzeile eingeben lassen, die standardmäßig mit rausgeht, aber die Variante, den eh evtl. schon vorhandenen Kommentar mit raus zu schießen, irgendwie eleganter und flexibler.

Die Mehrzeit wird das Remarks-Feld sowieso dafür nutzen, es auf die Papier-QSLs zu drucken, also warum nicht diesen Text einfach mit an EQSL weitergeben?

Nur so als Gedanke.

73, Kim

[DL6ER]

Alternativ könnte man auch hier in der Konfiguration eine Textzeile eingeben lassen, die standardmäßig mit rausgeht […]
Die Mehrzeit wird das Remarks-Feld sowieso dafür nutzen, es auf die Papier-QSLs zu drucken, also warum nicht diesen Text einfach mit an EQSL weitergeben?

Hallo zusammen,

ich nutze das Remarks-Feld oft für eigene Notizen, falls es mal eine persönliche Notiz gibt, schreibe ich die immer handschriftlich auf die QSL.
Daher würde ich eine (fest) schaltbare Zeile begrüßen, zumindest sollte es keine zwangsläufige Übernahme des Remarksfeldes geben (schaltbar wäre ok).

73 Dominik

[DL1DTL]

Hallo Ben,

bitte in der Übersicht View/Countries.... eine eigene Farbe für e-qsl vorsehen, damit der Unterschied zu LotW und Papier noch sichtbar bleibt.

73

Klaus DL1DTL

[DL7UCX]

Hallo Klaus,

ich fürchte, die Einbeziehung von eQSL in View-Countries führt zu diversen Problemen:

Ich vermute, es wird z.B. für das CQ DX Award gebraucht. Ich finde dort keine Definition, was ein "Country" ist.
Ist das identisch mit DXCC? Oder plus WAE?

View-Countries: Die Auswahl der Wertungs-Kombinationen Papier/LOTW für Summary ... ist schon umfangreich, mit eQSL wird das sehr viel.

Main window: Band-Mode-Kästchen dreifarbig ginge noch.

DX Cluster window: Wkd/Cfmd Filter müßten eQSL schaltbar berücksichtigen, für IOTA gilt es nie.

Die Auswahl Papier/LOTW/eQSL zieht sich dann in die meisten View-... und Scan-... rein.


73 Ben

[DL1DTL]

Hallo Ben,

habe ich mir fast gedacht, dass es recht verzwickt wird, wenn e-qsl eingebunden wird. Aber
wenn schon, dann sollte es mit aller Konsequenz geschehen.

Übrigens: aus den CQ-Rules:

9. Normally the ARRL DXCC country list constitutes the basis for CQ DX Award country status. Deleted countries are not valid for the CQ DX Award. As a country is deleted, country totals of applicants are automatically adjusted accordingly.

Per e-qsl lassen sich z.Z. folgende Diplome beantragen:
CQ-WAZ, CQ-WPX, CQ-USA-CA und etwas umständlicher CQ-DX (offline, aber mit e-qsl-Bestätigungen).

73

Klaus DL1DTL