Führende Nullen in der empfangenen laufenden Nummer ab 001

[DL7UCX]

Hallo,

mich interessiert mal die sachkundige Meinung zu dieser Frage:

Soll UcxLog bei einer empfangenen laufenden Kontrollnummer (ab 001) automatisch fehlende führende Nullen auffüllen

Bisher wird die empfangene Nummer unverändert geloggt wie sie vom Nutzer eingetragen wurde, z.B. bleibt "3" so und wird nicht auf "003" aufgefüllt.
UcxLog weiß nicht, ob der Empfänger die Nullen vergessen hat oder der Sender.
Nur der Log-Auswerter kann entscheiden, ob es ein Fehler ist und ob er beim Sender oder beim Empfänger liegt.

Ein Contest-Veranstalter hat nun gefordert, daß die empfangene laufende Kontrollnummer immer auf 3 Stellen mit führenden Nullen aufgefüllt wird.
Begründung: UcxLog soll "die empfangene Nummer erzeugen, wie es in der Spezifikation vorgegeben wurde".
Augenscheinlich soll der Auswerte-Robot das nicht als Fehler werten, kann/will das aber nicht mit eigener Intelligenz lösen.

Um ewige Diskussionen abzukürzen, habe ich das für diesen Contest so eingebaut.
Bei über 200 Contesten gab es über die Jahre nie ein Problem in dieser Richtung, ich tendiere dazu, nichts generell zu ändern.

73 Ben

[dl8dww]

Hallo Ben,
bei KW-Contesten ist mir bisher nicht aufgefallen, daß es Punktabzug gab weil vorlaufende Nullen nicht vorhanden waren.
Bei einem UHF-Contest gab es vor ca.8 Jahren mal das Problem wegen fehlender vorlaufender Nullen. Die Auswertesoftware hatte einfach mit Teilen des Locator die Kontrollnummer aufgefüllt. und dadurch war der LOC unvollständig.
Seitdem ergänze ich in der Contestnachbereitung die Kontrollnummern. Hat nebenbei den Vorteil,daß auch Eingabefehler ( o statt 0) gefunden werden.
Ich denke, daß am PRG an dieser Stelle nichts geändert werden muß. Wenn es bei der Contestauswertung Probleme geben sollte, wäre es doch sinnvoll dort etwas zu tun.
73 Wolfgang

[dl3kvr]

Hallo Ben,
ich habe wirklich nicht wenig Conteste abgerechnet und nie
Probleme dieser Art feststellen können. Das soll nicht heißen,
daß es diese nicht gegeben haben kann.
Sollten bei Contestauswertungen Unstimmigkeiten bemerkt
werden, ist es besser, konkret auf diese zu reagieren und
nicht generell am erprobten Programm zu ändern.
73 Diet

[DL1DTL]

Aus Jahrzehnte langer Praxis in der Contestauswertung (Papier und elektronisch) hat es nie Probleme mit führenden Nullen bei Vergabe einer laufenden Nummer gegeben. Eigentlich gilt die Regel: es muß das geloggt werden, was gesendet wurde.

Wenn es denn einen Veranstalter gibt, der das anders will, muss er damit leben, dass in vielen Logs diese Nullen fehlen und sich darauf einstellen. Solange das Log sauber in Spalten aufgeteilt ist und durch fehlende führende Nullen keine Verschiebungen entstehen, ist eigentlich jeder Auswerter zufrieden.

Ansonsten müßte z.B. in vielen Fällen auf 4-stellig umgestellt werden, da die 1000er QSO-Zahlen im Contest gern überschritten werden.
Bei den Zonennummern wird doch auch des öfteren nur einstellig gesendet und keiner meckert.

@Ben, mit solchen Sonderwünschen keinen Aufwand treiben, es sei denn, der Wunsch kommt von den Spitzen-Contesten aus NA und EU und soll damit generell eingeführt werden.

73 Klaus DL1DTL

[SA2BRN]

Hallo ...

ich finde das Auffüllen sehr Positiv !
Leider hat sich die Anzahl der Stationen, die nur noch die reine Nr. geben, erhöht.
Finde es Hinderlich, wenn die Nummer so gegeben werden !

vy 73 de Bert SE2I

[DL7UCX]

Hallo,

An Bert: Es geht nur um die empfangene Nummer.

Ich denke wie Klaus, daß die empfangene Nummer so zu loggen ist, wie sie gegeben wurde.
Wenn automatisch Nullen aufgefüllt werden, die gar nicht gegeben wurden, könnte ein Veranstalter gerade das als Fehler werten.

Anlaß ist ein kleiner deutscher Contest mit EDI-Format, wo keine Spalten (also auch keine Nullen) zur automatischen Verarbeitung erforderlich sind.
Nun hat 1(!) Teilnehmer erstmals ein paar führende Nullen weggelassen.
Der Contest-Robot wertet nun diese Nummern als falsch, der Veranstalter möchte das tolerieren, bekommt es aber selber nicht automatisch hin und fordert nun von Ucxlog "sich an die Regeln zu halten".

Ich habe nach einigen Mails den Weg des geringsten Widerstands gewählt und dem nachgegeben.
Nun heißt es, ich müßte das bei allen DARC-Contesten "nach Pflichtenheft" so programmieren

73 Ben

[dl3kvr]

Hallo Ben,
wäre es zu aufwendig diesem Veranstalter, bzw. dem, der diese
unvollkommene Software geschrieben hat, mit Rat und Tat zur
Seite zu stehen?
73 Diet

[DL7UCX]

Hallo Klaus,

habe inzwischen mit dem Veranstalter auch telefoniert, wir haben viel aneinander vorbeigeredet.

Eigentlich ist das Problem mit den führenden Nullen gar keins, da die lfd. Nummer dort sowieso nicht über Kreuz geprüft wird, um die Teilnehmer nicht zu vergraulen.
Und die EDI-Definitionen und Contest-Regeln legt (leider) jeder anders aus
Ich habe in 7.43 Beta 21 einen Kompromiß (automatisch führende Nullen und weitere "Toleranz") eingebaut (s. Historie) und die Diskussion damit hoffentlich beendet, sowas kostet mehr Nerven als Änderungsaufwand.

Bei allen anderen Contesten ändert sich nichts.

73 Ben