WSPR code generator (gelöst)

    Hallo zusammen,

    als bekennender Milliwatter komme ich natürlich trotz einiger Bedenken nicht um WSPR herum. Da ich ungern fertige Konzepte übernehme, habe ich versucht einem vorhandenen, selbstgebauten QRSS
    Aufbau mit DDS (AD9850) entsprechend zu modifizieren. Um den etwas länglichen Prozess der Codierung der wenigen Bits (Call/Locator/PWR) zu umgehen, habe ich einen WSPR code generator benutzt.
    Die µC-Software (MSP430F2013) für das Senden der 4 FSK-Töne war schnell gemacht. Also Behelfsantenne angeklemmt und auf http://www.wsprnet.org/drupal/wsprnet/map auf Treffer gewartet...
    Nichts, nada. Natürlich habe ich meine Soft- und Hardware verantwortlich gemacht und an allen möglichen Schrauben herumgedreht.

    Es hat mich fast einen vollen Tag gekostet herauszufinden, dass mein Signal fälschlich als F0UPB decodiert wurde. Immer noch überzeugt, dass das an meinem Aufbau liegt, habe ich mal dieses Rufzeichen
    in den besagten code generator eingegeben und siehe da, es führt zu einem identischen Ergebnis, sowohl was die 'message' als auch die 'tones' angeht.

    Da ich nicht dauerhaft unter falscher Flagge segeln möchte, obwohl die Ergebnisse an sich in Ordnung waren, wäre ich dankbar für Hinweise auf eine alternative Möglichkeit, die richtigen Töne zu ermitteln,

    ohne gleich den von G4JNT vorgeschlagenen, etwas mühsamen, manuellen Weg gehen zu müssen.

    Kurz zusammengefasst, welche Töne brauche ich, um korrekt als DL3PB JO31 0dBm identifiziert zu werden?!

    Danke/73

    Peter

    Einmal editiert, zuletzt von DL3PB ()

  • DL3PB

    Hat den Titel des Themas von „WSPR code generator“ zu „WSPR code generator (gelöst)“ geändert.

    Hallo,

    habe extra WSJT heruntergeladen und mich durchs Manual gewühlt, leider scheint es für WSPR, im Gegensatz zu JTx, keine Möglichkeit zu geben die Symbole auszulesen.
    Gefunden habe ich den WSPR-Inspector, ironischerweise aus der gleichen Feder wie der oben erwähnte WSPR code generator. Mit den gleichen Eingabedaten (DL3PB JO31 0dBm)
    ergeben sich gleich ganz andere Töne (Symbole). Schnell in den µC geladen und mal kurz mit ein paar zehn milliwatt die Regenrinne geheizt:



    Jetzt zurück auf 0.5mW, als ich noch F0UPB hieß hat das ja auch noch für einzelne Treffer gelangt 8)


    73


    Peter

    Wie oben beschrieben, habe ich mal kurz ca. 50mW spendiert, da ich keine Lust hatte stundenlang auf eine Rückmeldung zu warten.

    Gestern mit 0.5mW unter falscher Flagge immerhin noch einzelne Treffer in knapp 1000kmEntfernung:



    73

    Peter

    Zitat von DL3PB

    Gefunden habe ich den WSPR-Inspector, ironischerweise aus der gleichen Feder wie der oben erwähnte WSPR code generator. Mit den gleichen Eingabedaten (DL3PB JO31 0dBm)
    ergeben sich gleich ganz andere Töne (Symbole).

    So etwas macht mich natürlich neugierig.


    Eine gute Referenz ist das Programm von G4JNT von 2009: http://www.g4jnt.com/GENWSPR.EXE - mit der Beschreibung hier: http://www.g4jnt.com/WSPR_Coding_Process.pdf

    Oder mit Source code in Python: https://github.com/robertostli…ols/blob/master/encode.py


    Beide Programme liefern für "F0UPB JO31 0" tatsächlich deinen ersten gesendeten Code, den auch der "WSPR code generator" (von Scott/AJ4VD) bei DL3PB produziert.


    Dann fiel mir auf, dass der generierte Code mit 0xF anfing, was aber lt. der Beschreibung des Coding-Prozesses nur passieren kann, wenn es vor dem Rufzeichen "padding" gibt, d.h. das Rufzeichen wird vorne mit Leerzeichen aufgefüllt, damit an der *dritten* Stelle (ist so vorgeschrieben) eine Ziffer steht. Das ist bei F0UPB auch nötig, aber nicht bei DL3PB, da steht die Ziffer schon an der dritten Stelle.


    Wenn man jetzt in obigem "encode.py" die Validierung ausschaltet, und die Message mit dem Rufzeichen " DL3PB" (mit Padding vorne) generiert, kommt genau die F0UPB-Message raus.

    Ergo, das Programm von Scott/AJ4VD macht fehlerhaftes Padding und generiert eine fehlerhafte Message.


    Das brachte mich auf die Idee, es mit einem 6-stelligem Rufzeichen zu testen, und siehe da: Alles funktioniert wie erwartet, jetzt bringt auch der "WSPR code generator" die richtigen Symbole raus, da kein Padding mehr nötig ist.


    Ein schneller Blick in den Code bringt auch die fehlerhafte Zeile schnell zum Vorschein:

    WsprSharp/src/WsprSharp/Encode.cs at main · swharden/WsprSharp
    .NET Standard library for encoding/decoding messages using the WSPR protocol - swharden/WsprSharp
    github.com


    Ich habe Scott über den Fehler informiert, mal schauen, ob er es korrigiert :)

    Respekt, Fabian! Ich hatte auch schon vermutet, dass das mit dem was offenbar 'padding' heißt zu tuen hat. Also dem Problem, dass an zweiter Stelle
    nur Buchstaben zugelassen sind, allerdings erlaubt der online code generator die Eingabe von Leerzeichen nicht.
    Ich hatte Scott auch schon eine mail geschrieben, dass die beiden Rufzeichen ein identisches Ergebnis liefern, aber bislang keine Antwort
    bekommen.
    Mein Problem war, dass ich sehr lange den Fehler an der falschen Stelle gesucht habe, bis ich auf einem Kiwi SDR in der WSPR extension
    zufällig das französische Call mit meinem Locator und meiner PWR entdeckt habe...

    Danke!


    Peter

    Scott war über Nacht aktiv und hat das Problem beseitigt. Die neue Version ist hier online:

    WSPR Code Generator


    Die Version auf seiner Webseite (oben verlinkt) ist noch der alte Stand.


    Zitat von DL3PB

    Mein Problem war, dass ich sehr lange den Fehler an der falschen Stelle gesucht habe, bis ich auf einem Kiwi SDR in der WSPR extension
    zufällig das französische Call mit meinem Locator und meiner PWR entdeckt habe...

    Ja, das kann ich nachvollziehen. Bei einer so professionell gemachten Webseite kommt man nicht auf den Gedanken, dass sie einen Bug haben könnte :)


    73

    Fabian

    Zitat von DJ5CW

    Scott war über Nacht aktiv und hat das Problem beseitigt. Die neue Version ist hier online:

    https://swharden.github.io/WsprSharp/

    Das ist gut, Du hast ihm die Lösung ja quasi auf dem Silbertablett präsentiert. Dennoch gut zu wissen, dass es Sinn macht, solche Bugs offenzulegen.
    Ich vermute, dass die meisten OMs fertige Lösungen z.B. Bausätze inklusive integrierter Software benutzen, sonst wäre der Bug sicher früher schon mal
    aufgefallen.
    Ich habe bei meinem Ausflug in die wundersame Welt der WSPR Kommunikation gelernt, dass WSPR deutlich robuster ist als vermutet, was Timing, Drift etc.
    angeht. Offensichtlich kommt man auch ohne integriertes GPS-Modul zum Ziel.
    73

    Peter

    Zitat von DL3PB

    Offensichtlich kommt man auch ohne integriertes GPS-Modul zum Ziel.

    Das kann ich nur unterstreichen. Im Rahmen eines Schulprojektes wurde im Sommer von den Schülern im Rahmen eines Physik-Projektes eine WSPR Bake aus einzelnen Modulen gebaut. Das Ganze mit einem Billigquarz-Ozillator und Doppelseitenbandmodulator in Freiluftverdrahtung in einer Holzkiste. Die einzelnen Baugruppen wurden auf Schülergruppen aufgeteilt und von der Pieke auf entworfen, berechnet und simuliert. Der WSPR Code kam vom PC. Mit einem 40m Dipol auf dem Schulhof in 3m Höhe wurde nach 24h Betrieb Australien auf dem langen Weg erreicht. Ein Lernelebnis der besonderen Art, die Schüler waren beeindruckt, was mit Amateurfunk möglich ist und was sie geleistet haben. Es geht also auch mit einfachsten Mitteln.


    73.

    Günter

    Klasse-Projekt, Günter! Mir gefällt besonders der pragmatische DSB-Ansatz und die Aufteilung in Baugruppen, die einzeln bearbeitet und getestet werden können.

    Vielleicht wäre auch QRSS was für ein nächstes Schulprojekt. Mit überschaubarem Aufwand könnte man damit u.a. das Logo der Schule in alle Welt senden.
    Vorteil aus meiner Sicht, man sieht dem Ergebnis (entweder auf https://swharden.com/qrss/plus/ oder mit Kiwi SDR plus Argo o.ä.) an, dass es evtl. einen weiten Weg
    hinter sich hat und hat noch ein paar Optionen zur nachtäglichen Bearbeitung, etwa durch 'stacking' oder den Zusammenschnitt von einzelnen Bildern zu einfachen
    animierten Sequenzen. Hier zwei Beispiele (Australien/USA beide <1W)
    .



    73


    Peter