Sie sind nicht angemeldet.

Lieber Besucher, herzlich willkommen bei: Forum der DL-QRP-AG für QRP und Selbstbau im Amateurfunk. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

1

Montag, 8. Dezember 2014, 16:56

Konvertierung von WGS84 in Maidenhead

Hallo OMs!

Ich habe eine Frage zur Auswertung eines GPS RX. Konkret geht es darum die WGS84 Angaben in das Maidenhead Locator Grid System umzurechnen und zwar mit 10 Zeichen:

Beispiel:
Longtitude: 16.01388888
Latitude: 47.697743055
--> JN87AQ17QL

Das Problem liegt darin, dass in der Maidenhead-Konferenz nur 6 Stellen (--> JN87AQ) geregelt wurden, aber nicht weitere Stellen. Diese "extended" Stellen finden sich für 8 Stellen noch im Internet. Anscheinden gibt es hier eine stilles Übereinkommen wie das berechnet wird. Ist mir klar. Wie aber werden die 9./10. Stelle berechnet? ?(
Dazu finde ich leider nichts.

Beispiel:
JN87AQ17 ist klar. Für das letzte Paar "QL" fehlt mir leider die Umrechnungsvorschrift.

Wer kann mir da weiterhelfen? ?(

Zur Illustration: http://no.nonsense.ee/qthmap/
Damit kann sehr schön ausgehend von der Karte der Locator mit 10 Zeichen ermittelt werden.

.
73 de Chris, OE3HBW

  • »DH8DAP« ist männlich

Beiträge: 797

Hobbys: QRP, Ausbildung, Jugendarbeit

  • Nachricht senden

2

Montag, 8. Dezember 2014, 17:54

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!
vy 72 de DH8DAP, Frank aus Schwelm nr Wuppertal, JO31PG

Ich bin Westfale von Geburt und Europäer aus Überzeugung!

www.golf19.de

3

Montag, 8. Dezember 2014, 18:40

Hallo Frank!

Naja ich habe tatsächlich einige Quellstudien betrieben. Wie gesagt bis 3 Paare (6 Stellen) ist alles klar beschrieben. Die Rechenvorschrift für das 4. Paar (8 Stellen) kann in diversen Quellcodes rekontruiert werden. Schwieriger wird es aber beim letzten Paar. Ich habe bis dato nichts Eindeutiges gefunden...

Das Grid System ist übrigens kein Quadrat, sondern die Longitude und Latidude hat unterschiedliche Divisionsfaktoren.
Länge 20°/2°/5' usw. bzw. Breite 10°/1°/2.5' usw.

Warum ich das mache?

Nun, heutige GPS RX sind sehr günstig zu bekommen. Sehr empfindlich, genau und einfach auszuwerten (NMEA Format). Warum sollte das Maidenhead Grid System da nicht verfeinert werden? Aber Du hast recht, das ganze ist eine Spielerei und für den AFU nicht wirklich notwendig.

Konkret werte ich den NL-652ETTL mit einem AVR ATmega644 per BASCOM Programmm aus.

Die Berechnung von 8-digit werden z.B. hier recht gut beschrieben: http://home.comcast.net/~lespeters/PROJE…id%20square.pdf

.
73 de Chris, OE3HBW

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »chirt« (8. Dezember 2014, 19:21)


4

Montag, 8. Dezember 2014, 20:54

Erledigt :thumbsup:
Die Berechnung funktioniert nun für 10 Zeichen Maidenhead Locator.
Falls es jemand brauchen kann - Code snipped siehe Beilage

Nachtrag zum Code:
Zum Verständnis wurden die Multiplikationen (Kehrwert des Divisonsfaktors) noch nicht zusammengefasst
tmps2 = Frac(tmps1)
tmps2 = tmps2*1/X --> Ist der Rest von vorherigen Stufe
tmps1 = tmps2*Y --> neues Grid
Kann natürlich zu einem Multiplikations- bzw. Divisonsfaktor zusammengefasst werden.
Damit kommt man dann auf die von Frank oben angesprochenen Abfolge von 10-24-10-24 Faktoren um die jeweils neuen Grids zu erhalten.

.
»chirt« hat folgendes Bild angehängt:
  • QTH.jpg
»chirt« hat folgende Datei angehängt:
  • snipped.txt (1,94 kB - 216 mal heruntergeladen - zuletzt: 8. November 2018, 04:40)
73 de Chris, OE3HBW

Dieser Beitrag wurde bereits 5 mal editiert, zuletzt von »chirt« (9. Dezember 2014, 09:29)


  • »DJ7OO« ist männlich

Beiträge: 88

Hobbys: Selbstbau, Mikrocontroller, Ardiuno, APRS, GPS, Datenübertragung

  • Nachricht senden

5

Donnerstag, 19. Juli 2018, 21:59

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

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »DJ7OO« (21. Juli 2018, 22:58)


6

Freitag, 20. Juli 2018, 14:08

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:

Quellcode

1
2
3
ps2 = ps1-int(ps1);
ps2 = ps2 * 20.0;
ps1 = ps2 * 0.5;
73 de Uwe
DC5PI

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »DC5PI« (21. Juli 2018, 13:29)


7

Freitag, 20. Juli 2018, 15:50

Moin Uwe,

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

73, Tom
DARC I18 |DL-QRP-AG #1186|G-QRP #14624|FISTS #15933|SKCC #13896|LIDS #88 https://twitter.com/DL7BJ

  • »DJ7OO« ist männlich

Beiträge: 88

Hobbys: Selbstbau, Mikrocontroller, Ardiuno, APRS, GPS, Datenübertragung

  • Nachricht senden

8

Samstag, 21. Juli 2018, 23:23

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

9

Sonntag, 22. Juli 2018, 00:38

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

10

Sonntag, 22. Juli 2018, 11:25

Moin Peter,
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 :D

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
DARC I18 |DL-QRP-AG #1186|G-QRP #14624|FISTS #15933|SKCC #13896|LIDS #88 https://twitter.com/DL7BJ

11

Sonntag, 22. Juli 2018, 12:36

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 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

12

Sonntag, 22. Juli 2018, 21:39

Beitrag zu QTH-Locator

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

13

Mittwoch, 25. Juli 2018, 08:26

Hallo werte Bastelfreunde!

Kaum vom Frankreich-Urlaub zurück (im Urlaub gibt es bei mir bewusst kein "Internet") und schon gibt es wieder Arbeit im QRP Forum :D
Da es ja mein (alter) Thread war, muss ich wohl meinen Senf dazugeben:

1. Das angesprochene Problem ist völlig unabhängig von den Maidenhead Berechnungen!

2. Selbstverständlich sollte die Rechengenauigkeit bei Floating Point Operationen bedacht werden

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)

5. Über C/C++ bzw AVR-GCC kann ich nicht sprechen, da ich davon nur minimale Ahnung habe

6. In meinem Originalthread von 2014 (siehe oben) habe ich geschrieben "Zum Verständnis wurden die Multiplikationen (Kehrwert des Divisonsfaktors) noch nicht zusammengefasst...Kann natürlich zu einem Multiplikations- bzw. Divisonsfaktor zusammengefasst werden."

7. Meine uC Programme sind "Hobby-Programme", die letztlich FÜR MEINE Zwecke sehr gut funktionieren

8. In der Praxis verwende ich diesen Code http://www.qth.at/oe3hbw/Projects/GPS/GPS.htm

9. Eine wissenschaftliche Berechnung würde ich damit ohne nähere Analysen nicht durchführen. Für mein Hobby bin ich sehr zufrieden damit.

10. In Frankreich gefällt mir besonders diese "80/20-Kultur", da ist das Leben viel einfacher.

OK, das wars schon und nun auf zu neuen Ufern (Bastelprojekten). Ob in Assembler, BASCOM, C oder LunaAVR - jeder wie er will und wie es die Aufgabe erfordert.

Und wer sich mit Locator-Feldern spielen will, der kann es recht gut hier http://qthlocator.free.fr/index.phpoder hier http://www.k7fry.com/grid/ machen...

.
73 de Chris, OE3HBW

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »chirt« (25. Juli 2018, 14:19)


14

Mittwoch, 25. Juli 2018, 17:54

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.
»DC4LO« hat folgende Bilder angehängt:
  • MeinStandort.jpg
  • NeuerStandort.jpg

15

Samstag, 28. Juli 2018, 22:43

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

Ähnliche Themen

Verwendete Tags

GPS, Maidenhead, NMEA, QTH, WGS84