BPSK Modem für GPS Downlink via Audiokanal

Y

ygramul

Erfahrener Benutzer
#41
#41
Ich kann mich noch an die Zeiten der 300 Baud Akustikkoppler erinnern und staune immer wieder wie über die dünnen 2-Draht Leitungen heute um die 50.000 kBit/s gejagt werden.
Evtl. kann man durch geeignete Modulation doch mehr als die 4k8 aus dem BPSK raus holen? Gut die Fehlerrate wird dadurch auch nicht unbedingt gesenkt.

Die zu übertragenden Daten könnte man ggf. auch einfach "packen" mit gängigen Verfahren und dann übertragen (Vergleichbar gzip gepackten Webseiten). Dann muss man vielleicht nicht mit diesem "Bit Gefrickel" anfangen. ;)
 
der-Frickler

der-Frickler

Fricklomane
#42
#42
Ich denke das Trägersignal sollte schon um einiges höher liegen als die Frequenz der Nutzdaten und da fällt man leicht aus dem Bereich raus den die Sender auf dem Audiokanal übertragen können. Auch das Samplen am PC/IPhone etc... wird bei Frequenzen über 20KHz schwierig bis unmöglich.

P.S: sehe gerade, die Airwave Module übertragen auch nur bis 20kHz Audio.
 
Y

ygramul

Erfahrener Benutzer
#43
#43
der-Frickler hat gesagt.:
Ich denke das Trägersignal sollte schon um einiges höher liegen als die Frequenz der Nutzdaten und da fällt man leicht aus dem Bereich raus den die Sender auf dem Audiokanal übertragen können. Auch das Samplen am PC/IPhone etc... wird bei Frequenzen über 20KHz schwierig bis unmöglich.
Zum Vergrößern anklicken....
Muss leider zugeben, dass ich nicht weiß wie das BPSK Modem die Daten umwandelt. Aber mal so rein theoretisch betrachtet gibt es ja nicht nur Frequenzen, sondern auch Amplituden .. also halt, zur Datenübertragung nicht nur "an/aus" senden, sondern auch die "Lautstärke" mitnehmen. Da kommt's dann drauf an wie viele "Lautstärkestufen" man gut unterscheiden kann.

Wenn, angenommen, aktuell nur "an/aus" gesendet wird und damit die 4K8 realisiert sind, könnte _theoretisch_ bei z.B. 16 "Lautstärkestufen" die Datenrate auf 4*4K8 hochgedrückt werden .. oder lieg ich da jetzt völlig daneben?
 
der-Frickler

der-Frickler

Fricklomane
#44
#44
Ja, Möglich ist das, aber schön ist es nicht, vor allem da du dann durch höhere/geringere Lautstärke andere Daten bekommst....meines Erachtens zu Fehleranfällig und sicher schwerer zu implementieren als das NMEA zu parsen und ein paar Daten rauszusaugen.

das BPSK pulst glaube ich einfach ein fixes Audiosignal (4kHz) mit den 1/0en des seriellen Signales.

Ist Sowieso ein Projekt was frühestens im Winter angegangen wird.....momentan ist noch Flug und Bausaison
 
R

Rangarid

Erfahrener Benutzer
#45
#45
Ahja gut, wenn man das für Google Earth benutzen will dann braucht man GPS, das stimmt schon.

Du hattest irgendwo was gesagt, dass man die Signale von schnelleren GPS aussieben könnte, hört sich meiner Meinung nach ner guten Lösung an, weil man dann viele GPS-Empfänger mit unterschiedlichen Geschwindigkeiten unterstützen könnte.

Was ist denn der Unterschied zwischen meiner Variante mit runterschicken von 2 Zahlen und dem Senden der NMEA Werte? Du sagst meins ist Fehleranfällig, aber das ist das NMEA ja eigentlich auch.

Naja jedenfalls braucht man fürs Google-Tracking auch nicht unbedingt viele Werte, außer man will wirklich auf 5m genau in alle richtungen Tracken. Es Reicht ja auch, wenn ein Trackpunkt alle 10m gesetzt wird bei Google Earth. Also wäre es ja nicht so schlimm, wenn man die Datenrate der NMEA Daten per Modem runtersetzt.

Fürs Antennentracking sollte das so auch reichen denke ich. Naja ihr macht das schon ;), wenns fertig ist *habenwill*.
 
der-Frickler

der-Frickler

Fricklomane
#46
#46
nee, mit fehleranfällig meinte ich die Idee noch verschiedene Lautstärken zu senden.

Runtersetzten sollte mit nem Atmel relativ einfach machbar sein denke ich, aber wenn dann Winterprojekt....Du darfst dann mal versuchen das Audio-Signal in Java zu dekodieren und die Daten wieder als NMEA bereitzustellen oder GoogleEarth zu füttern ;_)

Jetzt muss erst mal Horst fliegen.....
 
K

klausklaus

Benutzer
#47
#47
Hallo,
ein Hauptproblem ist doch, dass wir von der BPSK-Übertragungsanordnung nur die Hex-Codes haben, nichts ändern können und letzendlich auch garnicht wissen, wie die BPSK-Signalübertragung im Einzelnen realisiert wurde. Nachdem die ursprüngliche Seite inzwischen auch vom Netz genommen wurde, hat es zumindest den Anschein, als würde sich der ( dänische ) Autor inzwischen auch nicht länger mit der Sache beschäftigen wollen. Also bleibt nur, mit den Schnittstellen, so wie sie bestehen irgendwie zu leben oder etwas ganz Neues zu "erfinden". Nachdem Letzteres nicht ganz einfach sein dürfte, halte ich es für das Beste, grundsätzlich die vorhandene Lösung zu verwenden und sie nur durch Zwischenschaltung eines Prozessors auf der Senderseite den eigenen Vorstellungen anzupassen. Dabei dürfte es zuerst einmal nicht erforderlich sein, ALLE von den GPS-Empfängern bereitgestellten NMEA-Protokolltypen auch wirklich zu verwenden. So könnte die Übertragung jeder Menge nicht benötigter oder redundanter Daten vermieden werden. Das Beste dürfte m.E. sein, sich auf EINEN neuen, auf die spezielle Anwendung abgestimmten gemeinsamen offenen Protokolltyp zu einigen und hier nur die wirklich benötigten Daten hineinzupacken. Nach meiner Meinung sollten das neben GPS-Positions-, Höhen- und Geschwindigkeitsdaten aber auch einige vom Modell stammende Messwerte sein. Wird dazu ein an NMEA angelehnter Protokolltyp geschaffen, so ist es dann immer auch noch möglich, die Übertragung einzelner Werte bei Bedarf auch wegzulassen.

Eine Winkelberechnung auf der Senderseite halte ich NICHT für sehr praktikabel, weil der Bezugsstandort für die Empfangsstelle dann nur entweder ein vorabgespeicherter Fixpunkt sein könnte oder man ständig Positionsdaten von der Empfangsstelle in Richtung Modell senden müsste.

Klaus
 
der-Frickler

der-Frickler

Fricklomane
#48
#48
Wenn ich das richtig verstehe generiert das BPSK Modem einfach ein 4kHz Signal und schaltet dieses mit dem Pegel vom seriellen Signal an und aus. Einfaches binäres AM. Das lässt sich einfacher selbst implementieren als noch einenen µProz dazwischen zu schalten.
 
R

Rangarid

Erfahrener Benutzer
#49
#49
http://garydion.com/projects/whereavr/

habe gerade das hier gefunden, hört sich sehr interessant an.
Ist für unsere Zwecke vielleicht besser geeignet.

Source Code ist vorhanden, Komponenten sind beschrieben, printed board ist auch da.

Gruß Samuel
 
K

klausklaus

Benutzer
#50
#50
Rangarid hat gesagt.:
http://garydion.com/projects/whereavr/

habe gerade das hier gefunden, hört sich sehr interessant an.
Ist für unsere Zwecke vielleicht besser geeignet.

Source Code ist vorhanden, Komponenten sind beschrieben, printed board ist auch da.

Gruß Samuel
Zum Vergrößern anklicken....
Das ist ein Baustein für ein 1200bps-AFSK-Datenübertragungssystem, so wie sie zigtausendfach für APRS im Amateurfunk verwendet werden. Der Vorteil dabei ist, dass die Übertragung über "ganz normale" Sprechfunkanäle ( 300-3000Hz ) erfolgen kann und das Ganze durch das AX25-Protokoll auch noch abgesichert ist. Das bedeutet, dass ein Decoder nur einwandfrei übertragene Daten liefert und die fehlerhaft ankommenden unterschlägt.
Wenn die gesetzlichen Bestimmungen nicht dagegen stehen würden, könnte man solche Signale z.B. mit PMR446-Geräten übertragen.

Klaus
 
K

klausklaus

Benutzer
#52
#52
Rangarid hat gesagt.:
Also kann man den nicht mit unserem Audiokanal benutzen?
Zum Vergrößern anklicken....
Doch, doch, aber ein auf den Frequenzbereich der menschlichen Stimme ( also etwa 300-3000Hz ) begrenzter Übertragungsbereich ( wie bei Sprechfunkgeräten üblicherweise verwendet ) würde auch genügen.
Im vorliegenden Falle erfolgt die Datenübertragung durch Umtastung von Tönen mit 1200Hz- und 2200 Hz. Man nennt die Modulationsart "AFSK", was für "audio frequency shift keying" steht ( wenn ich mich nicht irre ).

Klaus
 
K

klausklaus

Benutzer
#54
#54
electracks hat gesagt.:
Die gesetzliche Bestimmung ist doch nur Listen before Talk. Das lässt sich doch leicht implementieren.
Zum Vergrößern anklicken....
Auf den PMR446-Kanälen ist nur Sprach- und keine Datenübertragung zulässig.
Das "Listen before Talk" kenne ich nur aus dem 868MHz-Bereich, wo bei das auch dort nur für einzelne Frequenzsegmente gilt und in vielen Fällen auch unberücksichtigt bleiben kann, wenn die Frequenznutzung unter einem bestimmten prozentualen Wert pro Zeiteinheit bleibt.

Klaus
 
R

Rangarid

Erfahrener Benutzer
#55
#55
Aber wir können doch mit unserem Audiokanal, der zum Video gehört mehr oder weniger machen was wir wollen, deshalb versteh ich grad den Zusammenhang irgendwie nicht.

Außerdem sind die Quellen offen, also kann man die Art der Übertragung ja jederzeit ändern auf eine, die besser mit unserem sender funktioniert. Oder seh ich da was falsch?

Wäre denn im allgemeinen dieses AVR-"Modem" gut geeignet wenn man die Übertragung etwas anpasst? Weil dann würde uns das ja mehr bringen, als weiter mit dem BPSK Model rumzuprobieren.
 
E

electracks

Erfahrener Benutzer
#56
#56
Im Grunde wäre ein Downlink auch über den Audiokanal einfach zu realisieren. Der NMEA String müsste nur in einen Amplitudencode konvertiert werden, der von einem Gegenstück am Boden wieder entziffert und dargestellt wird.

Einen GPS Logger hab ich schon gebaut. Jetzt müsste ich nur noch den Arduino die NMEA Daten als Amplitudencode ausgeben lassen und an den Audiokanal stecken. Das Gegenstück dann am Audioausgang des Empfängers.

Wenn man nur die Positionsdaten haben will ist das wirklich kein Problem. Das errechnen von Geschwindigkeit, Richtung etc kann ja in der Einheit am Boden erfolgen.

Der GPS Logger gibt den NMEA String einfach als Piepcode (einfachste Methode) oder Tonfolge aus.
 
K

klausklaus

Benutzer
#57
#57
Rangarid hat gesagt.:
Aber wir können doch mit unserem Audiokanal, der zum Video gehört mehr oder weniger machen was wir wollen, deshalb versteh ich grad den Zusammenhang irgendwie nicht.
Zum Vergrößern anklicken....
Im Vergleich zur schmalbandigen z.B. AFSK-Übertragung ist eine Datenübertragung in einem Audio-Subkanal doch deutlich störanfälliger. Wer kennt nicht die im Bild sichtbaren und gleichzeitig auch hörbaren Signaleinbrüche? Besonders der 2.4 GHZ-Bereich mit seiner Vielzahl Nutzer unterschiedlichster Art ist hier sehr anfällig.

Außerdem sind die Quellen offen, also kann man die Art der Übertragung ja jederzeit ändern auf eine, die besser mit unserem sender funktioniert. Oder seh ich da was falsch?
Zum Vergrößern anklicken....
Im bis über 10 KHz reichenden Audio-Subkanal hat man schon weitgehend freie Hand.

Wäre denn im allgemeinen dieses AVR-"Modem" gut geeignet wenn man die Übertragung etwas anpasst? Weil dann würde uns das ja mehr bringen, als weiter mit dem BPSK Model rumzuprobieren.
Zum Vergrößern anklicken....
Die Tonsignale des AVR-Modems kann man grundsätzlich auch über den Audio-Subkanal "jagen", nur gilt immer das oben Gesagte und es gibt halt effektivere Übertragungswege. Solange die Empfangssignale aber dick genug sind und nicht von außen gestört werden, mag das auch so gehen!

Klaus
 
Y

ygramul

Erfahrener Benutzer
#58
#58
klausklaus hat gesagt.:
Im Vergleich zur schmalbandigen z.B. AFSK-Übertragung ist eine Datenübertragung in einem Audio-Subkanal doch deutlich störanfälliger. Wer kennt nicht die im Bild sichtbaren und gleichzeitig auch hörbaren Signaleinbrüche? Besonders der 2.4 GHZ-Bereich mit seiner Vielzahl Nutzer unterschiedlichster Art ist hier sehr anfällig.
Zum Vergrößern anklicken....
Wenn die Datenübertragung grundsätzlich funktioniert, kann man durch das Protokoll maches "ausbügeln". Möglichst kleine Datenhäppchen inklusive ner Checksumme übertragen. Sehr übliches vorgehen z.B. bei einigen Quadrocoptersystemen (OSP, NG, ..), wenn dort auch häufiger wi232 oder blauzahn zum Einsatz kommt.

Wenn mal ein Datenpäckchen ausfällt wegen Störung macht das ja bei Telemetriedaten nicht so viel aus .. dann aktualisiert sich die Sache beim nächsten Datenpäckchen. Bei höherer Übertragungsrate würde die nächste "Packetsendung" schneller kommen .. ob das dann eine höhere Störanfälligkeit "wett" macht, müsste man mal probieren.
 
R

Rangarid

Erfahrener Benutzer
#59
#59
Das hier wäre vielleicht auch interessant:
http://www.rcgroups.com/forums/showthread.php?t=1238316

Es handelt sich hier um ein Modem, das zwischen OSD und GPS gesteckt wird. Die Datenübertragung scheint soweit inklusive Google Earth zu funktionieren. Der Entwickler beschäftigt sich nach dem Modementwickeln nun mit dem Tracking.
 
K

klausklaus

Benutzer
#60
#60
Hallo,
das Projekt aus Polen sieht auf jeden Fall interessant aus. Allerdings scheint der Autor einen Schleier des Geheimnisses um technische Details zu legen. Ein Schaltbild u.ä. habe ich jedenfalls bisher noch nicht gefunden. Unabhängig davon werde ich demnächst aber einmal mit den folgenden Bausteinen experimentieren:
http://www.lechner-cctv.de/datenfunk/dtrx2412-digitales-2-4ghz-uart-datenfunkmodul-rs232-.192.407.de.html?mwdSID=hbn5f2a2t227unr4qk3mmvu597
Es handelt sich dabei um sehr einfach einsetzbare 2.4GHz-Transceiver mit 100mW-Sendeleistung, die als Ersatz für eine drahtgebundene serielle Datenverbindung mit 1200 bis 9600 bps angesehen werden können und somit auch problemlos die Ausgangssignale handelsüblicher GPS-Bausteine übertragen können sollten.
Was es noch herauszufinden gilt ist, in wie weit sich das etwa 2 MHz belegende Frequenz-Hopping-Signal mit im gleichen Band arbeitenden Fernsteueranlagen verträgt.

Klaus
 
Um antworten zu können musst du eingeloggt sein.
FPV1

Banggood

Oben Unten