mikrocontroller.net

Forum: HF, Funk und Felder Sprachübertragung


Autor: RichieRich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich würde gerne ein Sprachsignal von einem ATMega32 zum anderen 
Übertragen und von diesem aus per RS232 zum PC und sich dieses dort 
anhören.
Die Sprachqualität soll gut bis mäßig sein.

Nun habe folgende Möglichkeit wie man es angehen könnte:
An ATMega einen Mikrophon anschließen, die analogen Signale dann mittels 
AD-Umsetzer in digitale umwandeln und diese anschließend an den anderen 
ATMega mit RFM12 übertragen.

Jedoch kann ich mir vorstellen, das es einen riesen Aufwand darstellt, 
oder irre ich mich?
Kann ich dies mit dem ATMega32 und RFM12 realisieren oder sind diese 
dafür ungeeignet?

Gibt es eine weitere einfachere Möglichkeit das Sprachsignal zu 
übertragen, vielleicht gibt es bereits fertige Funkmodule, die schon das 
Signal ins digitale umwandeln oder ähnliches?

Danke

Autor: Tom (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Vorverstärker zwischen Mikrofon und ATMega muss sein.

Autor: mr.chip (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Mega8 nach Mega8 ist kein Problem. Eng wird es eher bei der Übertragung 
auf den PC. Normalerweise kriegt man max. 115000 Baud, bei 
8-Bit-Auflösung sind das also noch gut 10 kHz Samplingrate und somit 
noch rund 5 kHz echte Bandbreite. Sprache kann man damit verständlich 
übermitteln, aber 'gute' Qualität ist das nicht mehr.

Autor: Sven P. (haku) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab mal so ne Messreihe angelegt. Ab circa 4kHz Sampling wirds 
verständlich, bisserl dumpf (klar, fehlt ja Bandbreite), aber man kanns 
verstehen (siehe...ähhm..höre Anhang, das ist ein Text mit 5kHz).

Dann wärn da natürlich noch allerhand Codecs, die deine Audiodaten 
schrumpfen lassen:
* PCM
* MELP
* Speex
..und wie sie alle heißen.

Speex funktioniert angeblich schon ab 600 Bytes/sec mit recht guter 
Sprachqualität, der AVR dürfte dafür aber etwas knapp sein.

Autor: 6645 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat Atmel nicht eine Appnote zu uLaw & ALaw ?

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
uLaw und ALow sind von der Kompression her aber bescheiden (2:1), ebenso 
ADPCM (bei mehr als 2:1 wird die Qualität sehr schlecht).
Alles was besser als etwa 3:1 komprimiert läuft entweder nicht auf einem 
AVR, oder die Qualität ist unbrauchbar.
Ich hatte auch schon mit dem Gedaknken gespielt, Audio über RFM12 zu 
übertragen, aber es mangels passender Komprimierung dann doch sein 
lassen.
Das einzige was ich gefunden hatte, das ohne größeren Aufwand möglich 
wäre ist ein Speex Codec für einen dsPIC. Der braucht aber >20MIPs und 
eine Menge RAM usw.

Autor: Frank Esselbach (Firma: Q3) (qualidat)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

es gibt auch resourcensparende Modulationsverfahren, die z.B. mit einem 
Bit relativ gut verständliche Übertragungen hinbekommen. Suche mal im 
Web unter dem Stichwort "Delta-Modulation". Dabei wird ein Kurvenverlauf 
in der 1. Ableitung (steigt, bleibt, fällt) abgebildet ...

Frank

Autor: Der Chef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Am einfachsten geht das mit DCPM/ADPCM. Die nutze ich auch für 
Funkübertragung.

Ein paar Links dazu:
http://www.silabs.com/public/documents/tpub_doc/an...
ww1.microchip.com/downloads/en/AppNotes/00643b.pdf
http://www.atmel.com/dyn/resources/prod_documents/...

Autor: Hans (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Könnte man evtl. zwei günstig ersteigerte DECT Telefone mit dem ATMega 
steuern? Die Sprachübertragung würden dann die Telefone übernehmen.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hans wrote:
> Könnte man evtl. zwei günstig ersteigerte DECT Telefone mit dem ATMega
> steuern?

Die Idee hatte ich auch schon, das kann man vergessen (außer man nutzt 
das Telefon komplett und gibt das Audiosignal analog rein). Die 
verbauten ICs stammen fast immer von Siemens/Infineon und sind alles 
proprietärer Mist, zu denen man keine Datenblätter bekommt. Das einzige 
was ich bisher rausgefunden habe ist, dass die PLLs ein paar hundert mal 
pro Sekunde neu programmiert werden, also alleine schon für die 
Datenübertragung der Steuerdaten ein ziemlicher Aufwand notwendig ist.

Autor: Benedikt K. (benedikt) (Moderator)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank Esselbach wrote:
> Hallo,
>
> es gibt auch resourcensparende Modulationsverfahren, die z.B. mit einem
> Bit relativ gut verständliche Übertragungen hinbekommen. Suche mal im
> Web unter dem Stichwort "Delta-Modulation". Dabei wird ein Kurvenverlauf
> in der 1. Ableitung (steigt, bleibt, fällt) abgebildet ...

Allerdings verschwendet die noch mehr Bandbreite, die Samplerate muss 
nämlich sehr viel höher sein, als bei den mit 8 oder 16bit 
digitalisierten Rohdaten. Beispiel: 8bit Wert -> 1bit, bei gleicher 
Bitrate kann die Samplerate also 8x höher liegen. In den 8bit kann man 
aber gerade mal einen Wertebereich von +/-8, also 3bit überwinden.

"Bleibt" gibt es übrigends meistens nicht, sondern man verwendet nur 
steigt/fällt, was ein zusätzliches Rauschen erzeugt.

Autor: Hauke Radtki (lafkaschar) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sinnvoll ist es auch die Bandbreite nach unten hin zu begrenzen, dann 
wird der gesprochene Text noch verständlicher. (Zu tiefe töne stören 
nur)

Autor: Sonnenschein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Es gibt zu ADPCM auch was für den AVR. Ich glaube, ein Cornell Projekt 
und eine AN zum Dekodieren. Man findet im Netz auch Samples, Audacity 
kann einige Kompressionsarten beim Export.

http://www.mikrocontroller.net/search?query=adpcm

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Tom wrote:

> Vorverstärker zwischen Mikrofon und ATMega muss sein.

Sehr glorreicher Beitrag, der 1.) nicht in dieses Forum passt (weil's
hier eher um die übertragungstechnischen Aspekte geht) und 2.) nicht
stimmt.  Der ATmega32 hat einen internen Verstärker am ADC, der die
Sache (für ein gängiges Elektretmikro) durchaus erledigen kann.

Beitrag "Re: uC gesucht; Funktionsumfang; Anfängerfrage"

Autor: Der Chef (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Sonnenschein:
>und eine AN zum Dekodieren


Die hatte ich oben verlinkt...

Autor: Fasti (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi!

Wie wärs mit einem externen Codec für den AVR? Ein VS1053 kann En- und 
Decodieren und das sogar im OggVorbis Format. Damit sollte man dann auch 
eine brauchbare Qualität hinbekommen.32kB/s für ein Monosignal bringen 
schon eine recht gute Qualität in OggVorbis. Ist halt nicht ganz billig.

Grüße

Fasti

Autor: Ulf K. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

wie wäre es mit einem extra Sprachcodec (sowas wie für GSM, Baudraten 
bis 4,8kbps). Zu aufwändig?
Schau mal hier: http://www.dvsinc.com/manuals/AMBE-2000_manual.pdf

Gruß

Autor: Christoph Kessler (db1uq) (christoph_kessler)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja das ist das D-Star-Modem, das von ICOM im Amateurfunk propagiert 
wird, leider ist auf dem Verfahren ein Copyright des Herstellers, sodaß 
man keine Softwarelösung, z.B. mit Soundkarte veröffentlichen darf.
http://de.wikipedia.org/wiki/D-STAR
Digitale Sprachübertragung mit 3600 bits/s (3.6 kbps) inkl. 
Fehlerkorrektur

Im BOS-Funkbereich (Polizei, Hilfsdienste) ist ein anderer Standard 
üblich, der zuverlässiger sein soll
http://de.wikipedia.org/wiki/Bos_funk#Digitaler_BOS-Funk

Autor: RichieRich (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wow soviele Infos, ich hatte mir die Sprachübertragung weniger aufwändig 
vorgestellt. Aber das klingt nach einer MENGE Arbeit!
Jetzt kenne ich aber zumindest den konkretten Wegweiser.

Danke nochmals an alle für die Infos!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RichieRich wrote:

> Wow soviele Infos, ich hatte mir die Sprachübertragung weniger aufwändig
> vorgestellt.

Sie wird weniger aufwändig, wenn du mehr Kanalbandbreite zur Verfügung
hast.  Dann musst du keine irgendwie gearteten Kompressionsalgorithmen
mehr anwenden, und wenn der Kanal zuverlässig ist, dann brauchst du
auch keine Fehlerkorrektur.

Selbst ISDN benutzt aber halt schon µ-law-,,Kompression'', um mit nur
8 bit pro Sample auszukommen, zusammen mit 8 kHz Abtastrate macht das
dann die ISDN-typischen 64 kbit/s.  Zum Vergleich, für CD-Qualität
braucht man 1411200 kbit/s (2 Kanäle je 16 bit, keine Kompression,
44,1 kHz Abtastrate).

Autor: Katherine J. (katherine)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch wrote:
> Zum Vergleich, für CD-Qualität
> braucht man 1411200 kbit/s (2 Kanäle je 16 bit, keine Kompression,
> 44,1 kHz Abtastrate).
1411200 bit/s, Faktor 1000 kleiner aber immer noch eine ganz dicker 
Datenstrom.
Gruß Katherine

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Katherine J. wrote:

> 1411200 bit/s, Faktor 1000 kleiner

Hand-vor-den-Kopf-klatsch klar, danke!

Autor: Günter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,
vielleicht hilft das hier weiter
http://www.romanblack.com/picsound.htm

Gruß
Günter

Autor: Disco Stu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Der Thread ist zwar schon alt, aber anstatt mit Kanonen auf Spatzen zu 
schießen könnte man auch einfach einen sehr einfachen Codec mit Delta 
Modulation verwenden, der sich locker in einem AVR unterbringen lässt 
und schon ab 16 kBit/s brauchbare Ergebnisse liefert (passende analoge 
Filterung des Eingangs und Ausgangssignal wird vorausgesetzt).
Ein AVR mit Harware Multiplizierer ist optimal, ohne geht es aber auch 
(es sind nur 2 (16 Bit) Multiplikationen pro Abtastwert nötig), dazu 
zwei Vergleiche (8 Bit), 1 (ggf. 2) Additionen/Subtraktionen und eine 
Schiebeoperation.
Encoder und Decoder sind identisch, mit dem Unterschied dass der Decoder 
einen Vergleich weniger durchführen muss.
Der Codec ist fehlertolerant, da die Information eines (fehlerhaften) 
Bits über einige ms "abklingt". Wenn man es sich anhört, erhöht sich 
(ähnlich wie bei einer analogen Funkverbindung) das Rauschen im 
Hintergrund.

Weblinks:
http://en.wikipedia.org/wiki/Continuously_variable...
http://www.gamearchive.com/General/Data_Sheets/cvs...

Autor: Pascal O. (raven761)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> wie wäre es mit einem extra Sprachcodec (sowas wie für GSM, Baudraten
> bis 4,8kbps).


GSM "schätzt" nur was jemand sagt, ansich schickt GSM keine 
Sprachinformationen, sondern nur einen Index. Dieser Index ist für eine 
Liste gedacht, in der die menschliche Sprache in 20ms Laute unterteilt 
ist. Der Empfänger sucht sich dann mittels Index diesen Sprachton aus 
seiner Datenbank wieder raus. Damit spart man viel Übertragungsaufwand!

Autor: Disco Stu (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>Damit spart man viel Übertragungsaufwand!
...und tauscht das gegen nur "minimalen" Aufwand für den GSM Codec ein.
Mal im Ernst: Ein AVR ist der falsche Prozessor für hochkomprimierende 
(Sprach)Codecs.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.