Konvertierung von WGS84 in Maidenhead

Hallo Chris,

da du ja offensichtlich schon Quellenstudium gemacht hasst, wird es dir ein Begriff sein, dass die beiden ersten Stellen (mit Buchstaben) die Erde in 24 x 24 "Rechtecke" von jeweils 15° in waagerechter Richtung (parallel zum Äquator) und 7,5° in senkrechter Richtung (zwischen den Polen) einteilt.

Jedes dieser Rechtecke (mit AA bis XX gekennzeichnet) wird in 10 x 10 Rechtecke (von 00 bis 99) aufgeteilt und jedes dieser numerisch bennnaten Rechtecke wieder in 24 x 24 Rechtecke, die wieder mit Buchstaben gekenzeichnet werden (AA bis XX).

Wenn das alles Sinn machen soll, würde ich die weitere Verfeinerung nach dem gleichen Prinzip fortführen, also so, dass die zuletzt mit Buchstaben gekennzeichneten Rechtecke wieder in 10 x 10 nummerisch gekennzeichnete Rechtecke und jedes davon wieder in 24 x 24 mit Buchstaben gekennzeichnete Rechtecke unterteilt wird.

So kann man prinzipiell beliebig fein auflösen.

Jetzt kommt meine Neugierede: Aber wofür braucht man mehr als 6 Stellen??? Die Genuigkeit auf 6 Stellen des Maidenhead-Locators reicht bei unseren Breitengraden für Standortangaben die auf etwa 3 km genau sind.

Ergänzung: so ist es offensichtlich auch bei der von dir angebenen Quelle gemacht: JO31PG99YY geht nicht und JO31PG99XX verweist auf die obere rechte Ecke von JO31PG!

Hallo,
seit dem letzten Posting sind hier zwar inzwischen einige Jahre vergangen. Dennoch möchte ich aber nicht verschweigen, dass mir der BASCOM-Code zur Berechnung des 10-stelligen Maidenhead-Locatorcodes von Chris, OE3HBW entscheidend weitergeholfen hat, um daraus die benötigte ARDUINO-Version bilden zu können.

SourceCode wurde entfernt.

Dank und 73 de Klaus, DJ7OO

Hallo,

es gibt noch Ungereimtheiten in der Interpretation der Rechengenauigkeit, der Datentyp float unter avr gcc wird in 32 Bit gespeichert.
Davon werden
a) Vorzeichen 1 Bit
b) Mantisse 23 Bit
c) Exponent 8 Bit
verwendet.
Man erhält real 6 oder 7 signifikanten Stellen bei der Berechnung.

Der allg. Mann erwartet,. dass die angebenene Zahlen auch so verwendet werden.
16.01388888, 47.697743055 oder 0.083333333

Single float IEEE-754 liefert uns für die Berechnung nun andere Zahlen:
* 16.0138893
* 47.6977425
* 0.0833333

Man sieht es kumulieren sich die Fehler!
Ich würde nie einen code 1:1 übernehmen, ohne die Mathematik vorher zu überprüfen.

Dann zeigt die Umsetzung nach C resp C++ kein Verständnis zu dieser Programmiersprache.
Mir verursachen Rechenoperationen mit nur einem Operator schmerzen.

Gemeint ist diese Syntax basierend auf den bekannten BASCOM Problemen:

ps2 = ps1-int(ps1);
ps2 = ps2 * 20.0;
ps1 = ps2 * 0.5;

Moin Uwe,

bei der Mantisse hast Du einen Tippfehler, es sind 23 Bit, nicht 32 Bit.

73, Tom

Sorry,
die Ergebnisse, die sich bei Verwendung des von mir modifizierten Quellcodes ergaben, hatte ich mehrfach mit denen des Windows-Tools von K7FRY verglichen und kam dabei immer zu identischen Resultaten.
Inzwischen musste ich allerdings leider feststellen, dass dieses offenbar nur auf Positionen zutrifft, die sich im mittleren Teil der Kleinstfelder befinden. Bei Randpositionen kann es dagegen zu Fehlern in den letzten beiden Ergebnisstellen kommen, was ich auf die hierbei bestehenden nur begrenzten mathematischen Möglichkeiten zurückführe.

Meinen Quellcode habe ich deshalb auch erst einmal wieder vom Netz genommen. Vielleicht gibt es hier aber professionelle C-Programmierer, die für das Problem dennoch eine Lösung haben.

73 de Klaus, DJ7OO

Es macht bei Floating point keinen Sinn, mit short real zu arbeiten, d.h. 32bit Speicherung, Bereits die ersten Intel PC Coprocs arbeiteten intern mit 63 bit Mantisse. BASIC konnte bereits ab der zweiten Version long real und damit 15 oder 16 wertdarstellende Ziffern. EXCEL und Lotus123 rechnen nur mit long real = double oder wie immer definiert.

Als Grundregel muß man beachten, daß man ausgenommen Integer bei Float durchgängig nur mit gleicher precision rechnet (double fast schon zwingend). Bei jedem Wechsel riskiert man einen Konversion-Aufruf in Bibliotheksroutinen und Genauigkeitsverluste. Selbst IEE754 wird unterschiedlich implementiert.

Ich habe in den 70ern beim IBM techn. Außendienst Compilerkurse gegeben (internals für den Service, ALGOL, FORTRAN, PL/1 und Cobol) und kenne die Arie rauf und runter zwischen den diversen Implementierungen (Intel, IBM, IEE754 und auch unterschiedliche Auflösungen zwischen den Compilern). Es gibt einige Uni-PDFs, die den Wirrwarr der Implementierung noch bis heute beschreiben.

Bei C muß ich leider passen, das tue ich mir nicht an, dann schon lieber gleich Assembler . Ich programmiere noch selber - auf dem PC Fortran, APL und Basic, teilweise noch PL/1 und ein paar Script-Sprachen, aber C ist mir einfach zu mühselig.

Zur Trigonometrie/Mathe des QTH-Kenners zu meinem uralten DOS-Programm http://www.db6zh-9.bn-paf.de/qthzz/qthxx03.htm , Beschreibungen. Die SIN/COS Funktion wird sehr kritisch, wenn man in den Bereich 0.9999... kommt. Da geht es einfach nicht mehr vernünftig mit 6-7 Ziffern. Im übrigen: bei der Umrechnung Locator --> Geo-Pos. sollte man grundsätzlich die Feldmitte berechnen und nicht die Ecke. Das halbiert den Fehler auf eine halbe Diagonale anstelle einer ganzen -- wenn schon, denn schon. (im übrigen: im Absatz "(programmierte) Genauigkeit" habe ich etwas zu den erforderlichen Ziffern geschrieben.)

Ich muß mein Pgm gelegentlich auf 32 bit (BASIC) umstellen, auf XP läuft es noch, aber darüber ---- Vielleicht erweitere ich dann auch den Locator noch, aber garantiert nicht mit C .:-)

73 Peter

Moin Peter,

Zitat von DB6ZH

Es macht bei Floating point keinen Sinn, mit short real zu arbeiten, d.h. 32bit Speicherung, Bereits die ersten Intel PC Coprocs arbeiteten intern mit 63 bit Mantisse. BASIC konnte bereits ab der zweiten Version long real und damit 15 oder 16 wertdarstellende Ziffern. EXCEL und Lotus123 rechnen nur mit long real = double oder wie immer definiert.

Das ist zwar richtig, aber es geht hier um 8-Bit Microcontroller aus der ATMEGA Serie von Atmel. Zum einen mit dem BASCOM Compiler fuer Basic und den AVC-GCC C-Compiler. Der AVR-GCC fuer die 8 Bit Controller hat von Haus aus keine 64 Bit Mathematik. Aber es gibt Bibliotheken und Codebeispiele, z.B. hier:
https://www.mikrocontroller.net/topic/85256

Oder man weicht aus, z.B. auf den IAR Compiler, der allerdings in der Region eines Mittelklasse-Transceivers liegt, waehrend der GCC, ausgeschrieben GNU C-Compiler Open Source und kostenlos ist. Der GCC ist der Compiler mit dem fast alles fuer Linux/BSD usw. erstellt wird, d.h. der kann sehr viele Zielsysteme bedienen.
Allerdings sollte man sich etwas mit der Mathematik und vor allem dem C-Compiler beschaeftigen. Denn wie Uwe bereits erwaehnt hatte, sind solche Konstrukte wie

a = a * 20
b = a * 0.5

in C voellig unnoetig. Bei der Verwendung mit Microcontrollern, insbesondere von 8-Bit mit 32/64 Bit Mathematik sollte man auch bedenken, dass unnoetige Rechenoperationen entfernt werden, denn die kosten Zeit. Hier haette es ein b = a * 10 auch getan. Frueher haben wir die noetigen Taktzyklen fuer jede Operation manuell berechnet, heute gibt es da Tools fuer und man kann sich auch den vom C-Compiler erzeugten Code anschauen und optimieren (was meist ueberfluessig ist, denn die Compiler sind heute sehr gut). Nur Speicher und Performance ist auf Microcontrollern immer noch begrenzt.

Wenn man mit 8-Bit Prozessoren wie auf dem Apple ][ oder C64 begonnen hat, kennt man die Problematik und irgendwie sitzt das drin, auch auf Microcontrollern den Code immer optimieren zu wollen

Zitat

Bei C muß ich leider passen, das tue ich mir nicht an, dann schon lieber gleich Assembler . Ich programmiere noch selber - auf dem PC Fortran, APL und Basic, teilweise noch PL/1 und ein paar Script-Sprachen, aber C ist mir einfach zu mühselig.

Man nimmt immer die Programmiersprache, die fuer eine Aufgabe am besten geeignet ist. Fuer Microcontroller ist das immer noch C und Assembler. Trotz guter Macroassembler ist es aber muehselig groessere Anwendungen in Assembler zu programmieren, das geht einfacher und schneller mit C.

Bei Arduino handelt es sich um ein Quasi-C, man hat viele Standardroutinen in Bibliotheken verfrachtet und massiv vereinfacht. Ich mag diese Umgebung ueberhaupt nicht, denn so schwer ist es nicht, z.B. einen Timer in C zu programmieren. Aber Arduino hat viele Leute zur Beschaeftigung mit Microcontrollern gebracht, das ist natuerlich positiv und man kann spaeter ja immer noch tiefer einsteigen.

Etwas Beschaeftigung mit dem Compiler und den oben genannten Funktionen wuerde dann zu einem kurzen Code fuehren, der auch hinreichend genau ist.

73, Tom

Hallo Tom,
angekommen, an die Micros habe ich nicht gedacht. Ich habe in den 60ern mit Mainframe H/W angefangen und damals gehörte µCode und Maschinensprache zur Grundausbildung. Später hat man es an zentralen Support ausgelagert. Lange Jahre war ASM usus, später bei den Kaufleuten Cobol, PL1, in der Technik Fortran und Algol. Die meisten "Alten" haben noch mit ASM angefangen, und dann programmiert man automatisch sparsamer.

Die ersten Locatorrechnungen habe ich mit Basic per ASM-Unterprogramm für den 3087 geschrieben, wurde dann überflüssig. Man hat mit der Zeit halt einen Stamm von Grundprogrammen in Source, die man immer wieder verwendet. Da müßte ich mit C bei Null anfangen und dazu bin ich zu faul. Ich habe ein paar Java und C Routinen geschrieben und es dann aber wieder bleiben lassen. Rein vom Coding kein Problem, aber ich müßte zu viel vom Grundstock portieren. Für die ersten TNCs habe ich noch Assembler und Disassembler irgendwo rumliegen --

Mir kam es in erster Linie darauf an, daß man beim Gleitkomma Coding Daten-Typ Wechsel vermeidet, wie der Teufel das Weihwasser. Außer man weiß 100pro, wie der Compiler es umsetzt, d.h. in den Maschine-Code bzw. ASM Liste (bieten manche Compiler an) nachsehen. Dazu natürlich die Formeln so umbauen, daß wenig Code produziert wird.

BTW ich bin eigentlich wegen Floating Point eingestiegen, weil ich erst vor kurzen für einen OM eine Nachberechnung von Tabellen gemacht habe. Dort wurde in einigen Varianten mit FP einiges an Differenzen produziert. Zu der Problematik gibt es einen guten PDF http://www.eng.utah.edu/~cs6830/Slides/FP5830x2.pdf , der recht gut von den Anfängen bis heute das Durcheinander beschreibt.

Ist etwas OT geworden ............... 73 Peter

Hallo Funkfreunde,

hier findet Ihr Beschreibungen, wie der QTH-Lovator zusammengesetzt wird:
QST JAN. 1989 P.29
CQ-DL 8/1984 S. 386.

Aus den GPS -Daten soll mittels ARDUINO der QTH-Locator berechnet werden. Dazu
habe ich eine C++ Library für Arduino geschrieben.

Bei Interesse hier nachlesen:
http://dk2jk.darc.de/arduino/qth_locator/

73
Heribert

Hallo zusammen,
mit dem Programm von http://qthlocator.free.fr/index.php ist man mit Sicherheit sehr gut bedient, denn es kann auch Karten und Google Earth.

2 Beispiele sind im Anhang aufgeführt, und man hat nicht Berechnungsfehler der schon beschrieben wurde.

72

Gerhard

Nachtrag: mit einem Laptop im Netz ist alles möglich. Es können dann zu einem anderen Locator die Antennenrichtung und die Entfernung bestimmt werden.

Zitat: ......

3. BASCOM hat das Problem, dass in einem Schritt immer nur eine Rechenoperation ausgeführt werden kann (zumindest sieht es im Text danach aus). Allerdings ist mir nicht bekannt was der Compiler daraus dann für einen Code macht. Dadurch kumulieren möglicherweise Rechenungenauigkeiten sehr rasch.

4. Das sagt BASCOM zur Floating Point Operationen https://avrhelp.mcselec.com/language_fundamentals.htm (runterscrollen zu Floating-Point Complications und weitere Punkte)
---------------------
Ich müßte erst in BASCOM einsteigen, aber.... es ist ein allgemeines Problem aller Programmiersprachen und in der URL (...fundamentals) auch beschrieben. Wenn man zwischen double und single wechselt, muß gerundet werden. Je nach Zahlenwert kann das erheblich verfälschen. Man sollte Floatimgpoint Variable explizit definieren, um den Compiler zum Beibehalten von Double zwingen. Bei Basic teilweise per Declare, Defdbl oder bei Konstanten/Variablennamen mit dem # als Suffix (1# ist z.B. 1.0 mit double precision). Wie der Compiler das umsetzt, kann man erst mal außen vor lassen. Läßt man den Compiler "frei laufen", kann der je nach Gusto des Herstellers single oder double hin und her benutzen.

Ob und wie die H/W (Chip) dazu paßt, muß der Compiler selber lösen, evtl per Library. Wenn der Chip nicht richtig supported wird --- Herstellerproblem. Es ist wirklich wichtig, alle FP Variablen und Constanten durchgängig als double zu kennzeichnen und dem Compiler keine Wahl zu lassen. Mehr kann der Programmierer/Anwender nicht machen, aber das sollte er aber auch wirklich tun.

Sorry, aber weiter zu erklären, geht in's eingemachte und hilft einem Anwender wenig. Zudem .... wurde ja auch erklärt, daß der Chip nur 8-bit macht. Dann muß man es via Bibliotheken lösen, bzw. BASCOM oder wer auch immer muß es. Dauert eben länger ..... oder man verzichtet eben auf Genauigkeit.

73 Peter