🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: de.sci.electronics
Article #1334

Re: Tonerzeugung und Decodierung

#1334
From: Gerd
Date: Sun, 01 Feb 1998 00:00
130 lines
7325 bytes
Hallo Thomas, hallo alle,


> Praktikabel ist ein solches Verfahren nicht, wenn eine nicht-ideale
> �bertragungsstrecke zugrunde liegt.
> 
> Nicht nur der Frequenzgang, auch der Phasengang (Gruppenlaufzeit-
> Verzerrungen) spielt eine Rolle - und f�hrt dazu, da� die Kurvenform
> der Signale mehr oder minder "verzerrt" werden (kein "Klirrfaktor").
> Dies f�hrt nat�rlich dazu, da� die Steigung einer Kurve nicht mehr
> einer bestimmten Frequenz zugeordnet werden kann.

Das ist auch einer der Gr�nde, weswegen es schwieriger ist, �ber 
Funk Daten zu �bertragen, als �ber drahtgebundene Systeme.

> 
> > Hintergrund der Geschichte ist die �bertragung von Daten �ber
> > Funkger�te mit m�glichst einfachen und preiswerten Mitteln.
> Bei Funk�bertragungen (ich gehe mal von FM aus) hat man mit
> noch viel gr��eren Gruppenlaufzeitproblemen zu k�mpfen wie
> bei drahtgebundenen Systemen.
> Der FM-Demodulator tr�gt hierbei den gr��ten Teil bei, besonders
> wenn im Detektor ein keramisches Resonanzelement verwendet wird.
> Dieser Effekt ist auch noch abh�ngig von der Temperatur.

Eben dieses schlie�t die unver�nderte �bernahme von Technologien, wie 
sie zum Bleistift aus dem Netzwerk- oder Telefonsektor bekannt sind,
aus.
Oder, mal dumm formuliert: Wenn es so einfach w�re, so ein Telefonmodem
f�r den Funk zu verwenden, warum qu�len sich dann Millionen von Amateur-
und CB-Funkern mit �berteuerten Ger�ten herum, die zudem noch drastisch
geringere Transferraten bieten, als theoretisch ein 14400-bps-Modem 
f�r 40 DM vom W�hltisch?

> Daher scheiden (bei den angestrebten sehr hohen Datenraten) wohl
> alle �bertragungsarten aus, wo die _Kurvenform_ die Information
> �bertr�gt.

Warum? Es g�be ja noch die (durchaus �bliche) M�glichkeit der 
Kalibrierung: Zu Beginn eines Datenpaketes (oder einer Gruppe von
Paketen) wird eine spezielle (immer gleichbleibende)
Kalibrierungssequenz �bertragen, die der Empf�nger kennt und daher auch
einer aktuellen Kurvenform zuordnen kann. Damit m��te die am Empf�nger
tats�chlich anliegende Kurvenform dem Sender nicht bekannt sein, da der
Empf�nger die Zuordnung Kurvenform - Informationsgehalt selbst trifft.

Au�erdem: Wie anders will man _m�glichst viel_ Information bei einem Ton
unterbringen? Um einen Ton als Tr�ger einer Information verwenden zu
k�nnen, sind prinzipiell folgende Wege denkbar:

- 1. direkte Umtastung (0=kein Ton, 1=Ton vorhanden bzw. Codierungen
     a la NRZI, die Zustands�nderungen zwischen Ton/kein Ton als     
Informationstr�ger nutzen)
- 2. Beeinflussung der Frequenz (Frequenzmodulation)
     - hier ist die Menge an �bertragbaren Informationen pro Zeiteinheit
       wesentlich von der Auswertegeschwindigkeit des Ton-Detektors
       abh�ngig - also der Zeit, die ein Ton mit bestimmter
Frequenz        anliegen mu�, um zweifelsfrei erkannt zu werden.
     - F�r die Auswertung stehen prinzipiell zwei Verfahren zur       
Verf�gung:
       1. Auswertung des zeitlichen Verlaufs, zum Beispiel durch Messung
          des Abstandes zwischen zwei Nulldurchg�ngen der Schwingung
       2. Auswertung des geometrischen Verlaufs (der Kurvenform bzw.
des           Anstiegs der Kurve).
       Letzteres ist zwar wesetlich komplizierter zu realisieren, 
       verspr�che aber eine wesetlich h�here �bertragungsrate, da
von        einer Frequenz nur ein Teilst�ck und nicht mehr eine halbe
oder        gar volle Periode �bertragen werden m��te.  

- 3. Beeinflussung der Amplitude (Lautheit) des Tones          
(Amplitudenmodulation)
- 4. Beeinflussung der Phase des Tones (Phasenmodulation)
- 5. Kombinationen aus diesen, wie die zur Zeit bei den Entwicklern
     des digitalen Stereorundfunks auf Mittel- und Kurzwelle hoch im
Kurs      stehende Quadratur-Amplituden-Modulation (QAM).

Letzlich l�uft es aber IMHO _immer_ auf eine Erkennung der �bertragenen
Kurvenform beim Empf�nger hinaus, will man akzeptable �bertragungsraten
realisieren.

> Warum das Rad nochmals neu erfinden?
> 
> Warum nicht ein Modem-Verfahren, was sich an V32bis / V34 anlehnt?

Du hset die Gr�nde schon weiter oben selbst genannt. Die in �blichen
Telefonmodems verwendeten Schaltkreise sind nicht f�r den Umgang mit 
Laufzeitverschiebungen, Gruppen- und sonstigen Verzerrungen ausgelegt,
wie sie im Funk, aber nicht beim Telefon auftreten. Ein Eingriff bzw.
eine Umprogrammierung der Firmware w�re zwar sicher grunds�tzlich
m�glich, aber leider werden sich die Modemhersteller schwer h�ten,
dar�ber Interna zu ver�ffentlichen. Ohne diese jedoch bekommt das
Telefonmodem den Status einer "Black Box", die ich so ohne weiteres
nicht ver�ndern kann.

> Jedenfalls d�rfte es sehr schwer fallen, ein Verfahren zu
> entwickeln, welches besser (Datendurchsatz, Fehlerkorrektur) ist.
> Die dort verwendete Trelliscodierung ist st�rsicher und bew�hrt, es
> gibt sogar fertige Chips zu kaufen (die allerdings von einem externen
> Controller angesteuert werden m�ssen - f�r erste Versuche tut es
> vielleicht auch ein ausgedientes 14400er-Modem).

Wie schon oben erw�hnt, wenn es so einfach w�re, eben mal ein
ausgedientes 14400er Modem zu verwenden, warum ist denn dann noch keiner
auf die Idee gekommen? Ich selber hatte diese Idee bereits vor zwei
Jahren, habe sie aber nach einem gr�ndlichen Vergleich der
zugrundeliegenden �bertragungsbedingungen erst mal wieder fallen
gelassen.
> Wem diese (DSP-) Chips immer noch zu teuer sind(?!)

Wenn ich mehrere hundert Mark f�r ein Experimentalset (noch nicht mal
ein Fertigger�t -> also noch weitere Entwicklungs- und Materialkosten zu
erwarten) ausgeben mu� und dann noch nicht mal wei�, ob das Ganze denn
auch zu einem Erfolg f�hren kann, w�re ich mit meinem
Studenten-Taschengeld sicher mit einer 9600bps-Fertigl�sung besser
bedient.

>, der hat wenig
> Alternativen - bestenfalls langsamere "dumme" Chips, wie sie ja auch
> bei Packet Radio bis 9600 baud verwendet werden, kommen dann noch
> in Frage.

Ob nun dumm oder nicht dumm, w�re mir egal. Ich bin mir allerdings
sicher, da� das Problem technisch zu meistern ist - wenn auch vielleicht
abseits g�ngiger Mainstream-L�sungen.

Ciao


Gerd
Technical Details
Message-ID: <34D55B49.D6649DC0@studserv.uni-leipzig.de>
Path: arc1-ca.pugleaf.net!unknown!not-for-mail
References: <34D050DE.F9593CF1@studserv.uni-leipzig.de> <6aq0sn$91i$2@news01.btx.dtag.de>

Show Full Headers
Complete Article Headers
X-Google-Language: GERMAN,ASCII
X-Google-Thread: 112e71,505a8fec763c8b36
X-Google-Attributes: gid112e71,public
X-Google-Thread: 105dc7,505a8fec763c8b36
X-Google-Attributes: gid105dc7,public
X-Google-Thread: f637a,505a8fec763c8b36
X-Google-Attributes: gidf637a,public
X-Google-Thread: 115338,505a8fec763c8b36
X-Google-Attributes: gid115338,public
From: Gerd <med91bxf@studserv.uni-leipzig.de>
Subject: Re: Tonerzeugung und Decodierung
Date: 1998/02/01
Message-ID: <34D55B49.D6649DC0@studserv.uni-leipzig.de>
X-Deja-AN: 321158558
Content-Transfer-Encoding: 8bit
References: <34D050DE.F9593CF1@studserv.uni-leipzig.de> <6aq0sn$91i$2@news01.btx.dtag.de>
Mime-Version: 1.0
To: Thomas Rehm <Th.Rehm@t-online.de>, ol1uw@t-online.de, ol1uw@aol.com
Content-Type: text/plain; charset=iso-8859-1
Organization: Uni Leipzig
Newsgroups: de.sci.electronics,maus.elektronik,fido.ger.elektronik,de.comm.misc