1. Home
  2. Electronics (German)
  3. Einfache digitale Sprachübertragung

Einfache digitale Sprachübertragung

Vielen Dank an alle Antworter. Leider nicht das, was ich mir ursprünglich erhoft hatte - fertige ICs, dafür interessante Ideen.

@ Oliver:

> Gibt es fertige IC's auch für Komprimierung? > Du suchst programmierte Flash DSP's ? ;-)

Was meinst du damit, werden wirklich programmierte DSP verkauft? Du brauchst mir nicht die Begriffe Flash und DSP zu erklären, aber der Zusammenhang mit meiner Frage irritiert mich.

> ... kann man Programme für DSP kaufen? > Für die gängigen DSP's werden in der Tat CODEC's fix- und fertig > angeboten, bei einfacheren auch kostenlos als Applikationsschrift:

Danke für die interessanten Links, die mir im DSP-Fall sicher weiterhelfen werden. Ich habe immer noch die leise Hoffnung um DSP herrum zu kommen. Mir stellt sich dabei die Frage, welche Leistungsklasse von DSP ich bräuchte, wenn ich Sprache kodieren und dekodieren, und seriell transportieren will.

@ Johannes:

> ist es möglich, Sprache auf einfache Weise zu komprimieren > Spontan würde mir da DPCM einfallen. Dann kommst Du locker mit 4 > Bit/Sample hin, macht bei 8kHz Samplingfrequenz 32kBit/s.

Dem Link nach müsste es mindesten ADPCM sein. Sehr interessant, wenn es so einfach ginge. Wie die Prädiktorkoeffizienten errechnet werden, wird in dem Link leider nicht näher eingegangen.

... und auf einfachen Mikrocontrollern leicht zu implementieren.

Wie einfache? Nach meinen bisherigen Erfahrungen mit Assembler auf PIC (nicht Sprache, nur Steuerungen und Datenübertragung) dürften

8-Bit-4-MHz-Mikrokontroller vermutlich etwas schwach dafür sein. In welcher Richtung müsste verbessert werden, Geschwindigkeit (12 oder 20MHz) oder Breite (16Bit)?

@ Falk:

> Die 64kBit/s (ISDN) sind da bei längeren Entfernungen zu viel. > Was heisst denn längere Entfernug und zuviel?

So genau will ich mich beim jetzigen Stand noch nicht festlegen, sondern erstmal ausloten was möglich ist. 3 km würde ich schon gerne anstreben. Wenn es zum Schluss nur 0,5 km werden, muss es auch gehen.

Mit der richtigen > Übertragungstechnik kommt man mit (lausigen) 64 kbit/s verdammt weit > (so ein Infineon SDSL-Chip macht bei 3x64 kbit/s noch ca 5km oder so).

Das es mit Punkt-zu-Punkt-Verbindungen leichter ist, stelle ich immer wieder fest. Hier sollen die Daten jedoch busartig verteilt werden. Es geht um festgelegte Bussysteme (z.B. RS485 oder CAN) für Steuerungen, bei denen man auch noch "ein bisschen" Sprache mit übertragen möchte - wenn es geht. Und gerade bei solchen Bussystemen ist die mögliche Datenrate stark von der Länge abhängig. Ich mache mir zunächst Gedanken welche Möglichkeiten es überhaupt gibt.

@ Rafael:

ISDN komprimiert von 12 Bit auf 8 Bit,

nach meinem Kenntnisstand sogar von 13 Bit auf 8 Bit

Fehlendes Filter schädigt handgestrickte > ADPCM-Lösungen meist mehr als die fehlende > Dynamik.

Ein schlechtes Anti-Aliasing-Filter dürfte bei allen Digitalisierungen zu Störungen führen - sagt zumindest die Theorie.

> wie bei GSM (6,5kBit/s). > Dachte es wären ca. 10kBit/sec.

Als ich mich vor mehr als 10 Jahren mit der GSM-Technik beschäftigte hieß es: Speech Fullrate 13 kbit/s. Die Speech Halfrate wurde mit 6,5 kbit geplant, war damals jedoch noch nicht festgelegt, soll inzwischen benutzt werden.

> Gibt es fertige IC's > Ja, jedes Jahr ein paar neue. Genau so schnell abgekündigt > wie angekündigt.

Schade.

> die Eigenentwicklung jedoch nicht richtig lohnt. > * CVSD ( = ADM ) ist das simpelste Verfahren. > * ADPCM ... 32kBit/sec ist das was DECT verwendet

Das liest sich gut, die beiden werde ich mir mal näher ansehen. Danke für die Stichworte, damit habe ich gleich einen Einstieg zum Suchen. Interessant, dass beide (CVSD + ADPCM) mit Kontrollern realisierbar sein sollen, fragt sich nur wie leistungsfähig sie sein müssen.

@ Martin:

> wie bei GSM (6,5kBit/s). > GSM-FR ist 13kbit - immer noch am üblichsten, HR klingt schlechter.

Ich wußte garnicht, dass man das als Benutzer wählen kann - oder woher kennst du den Unterschied?

> Gibt es fertige IC's auch für Komprimierung? > Such nach AMBE-2000, die können 2kbit/s bis ca. 16kbit und klingen > auch bei 2kbit recht brauchbar. Gibt es als fertiges IC (ROM-DSP) > oder DSP-Code Lizenz.

Danke für das Stichwort, das werde ich mir mal ansehen.

MfG Horst

PS: Leider hat mich Google gestern und heute nicht direkt antworten lassen (unable to re...) deshalb versuche ich es jetzt so.

Reply to
Horst Bartig
Loading thread data ...

Am 10 Jan 2005 08:38:53 -0800 hat Horst Bartig geschrieben:

Bedienungsanleitung meines Telefons, ev. Webseite mit "GSM-Tricks", irgendwelche *# Codes. Ob alle Provider beide Raten (bzw. deren freie Umschaltung) unterstützen, kann ich aber auch nicht sagen.

--
Martin
Reply to
Martin Lenz

"Horst Bartig" schrieb im Newsbeitrag news: snipped-for-privacy@posting.google.com...

Dann sollte man es mal mit 2 DSL Modems versuchen. Hab ich praktisch zwar noch nicht gemacht, ich weiss aber dass zumindest die SDSL Chipsätze variable Bitraten mitmachen. Inwieweit nun die (A)DSL Modems und ihre Software sich dazu verbiegen lassen, keine Ahnung. Wenn man den Aufwand betreiben will/muss kann man auch einen SDSL Chipsatz selber auf ein Board schmieden. Ich kann hier den SOCRATES von Infineon empfehlen, der ist mittlerweile recht ausgereift.

Vielleicht könnte man hier tricksen. Man baut eine Zwischenspeicher für sagen wir mal 5 Sekunden, generiert eine Bitrate von 64kbit/s und überträgt mit der verfügbaren (meist wohl niedrigeren) Bitrate, sagen wir mal 16 kbit/s. Das hat sicher den Nachteil, dass es mit der Echtzeitkommunikation eher schlecht wird, aber ein quasi Halbduplex ala CB-Funk ist dann (mit wenig Aufwand, einfacher PCM Codec) machbar.

Jaja, Vorzeichen.

MfG Falk

Reply to
Falk Brunner

Bei ADSL brauchst Du immer eine CO- und eine CPE-Seite. Mit 2 Modems gegeneinander gibt das nichts. SDSL könnte gehen.

cu Michael

Reply to
Michael Schwingen

Einfach die Stromversorgung trennen. Meine Bausteine werden mit 14-20V~ versorgt, dann geht es auf die Brücke, un d zwei entkoppelte Spannungsregler, einer für den µP... und einer für die Relais und das Servo.

Drehen mit der Hand macht Dir bei kleinen Servos gaaaanz schnell das Getriebe kaputt.

Die Elektronik begrenzt nichts. Manchmal ist zuerst das Poti am Ende, was man durch einen kleinen Sprung der Servostellung bemerkt, wenn der Schleifer ans Ende kommt, manchmal ist man halt am Poller und das Servo brummt.

Gruß, Kurt

--
Kurt Harders
MBTronik - PiN - Präsenz im Netz GITmbH
mailto:news@kurt-harders.de
http://www.mbtronik.de
Reply to
Kurt Harders

Am Mon, 10 Jan 2005 19:25:36 +0100 hat Falk Brunner geschrieben:

Du willst bis zu 5(!) Sekunden Latenzzeit zulassen? Das ist auch Halbduplex unbrauchbar. Störend sind schon 0,2s. Wenn du nur 16kbit hast, dann komprimierst du eben, wenn du nur 2kbit hast, dann komprimierst du eben stärker. Wer garantiert denn denn, das du deine 64kbit im Mittel überhaupt zusammenbrächtest?

Die AMBE Chips haben wir übrigens aus genau diesem Grund (Feldbusbridge, geringe Kanalkapazität, CAN Bus + Sprache) ausgesucht - und wir wollten auch hohe Zuverlässigkeit. Die Modems schicken die Sprache aber nicht über den CAN Bus, der ist nämlich besonders gut fehlergesichert (hohe Redundanz), sondern über einen eigenen logischen Kanal mit besserer Ausnutzung der Kapazität.

--
Martin
Reply to
Martin Lenz

Sollte man sich über die Randbedingungen klarwerden Es gäbe:

  • unidirektional. Da macht ein Controller nur senden, der andere nur empfangen.
  • bidirektional, "push to talk" jemand drückt eine Taste wenn er sprechen will. Da macht der Controller entweder senden oder empfangen. Offene Sprechstelle möglich.
  • bidirektional mit Headset oder Handapparat. Da muß der Controller beide Richtungen gleichzeitig machen.
  • bidirektional mit offener Sprechstelle Da ist Freisprecheinrichtung fällig die im simpelsten Fall empfangen/idle/senden schaltet. Das ist zwar halbduplex Controller muß aber die Richtungsumschaltung auch noch machen. Soweit man kein Telefon-Codec und Handset verwendet wird in allen Fällen wird auf Mikrofon-Seite eine ALC für saubere Aussteuerung benötigt. Z.B. kann Controller Pegel per Fet ( CD4007 ) via PWM nachregeln.

Für DPCM ( "differential PCM" ) denkbar einfach: wenn für 8 Bit PCM-Daten das letzte Sample den Wert 80h hatte und das neue Sample den Wert 84h hat, dann ist die Differenz der 4 Bit Wert +4h. Natürlich paßt die Differenz nicht immer direkt in 4 Bit, dem kann man bei ADPCM "Adaptive..." im simpelsten Fall mit einer nichtlinearen Tabelle abhelfen die eine maximal 8 Bit Differenz auf 3 Bit + sign staucht. DPCM kann lossless Compression sein, ADPCM ist es nicht.

Bezüglich ADPCM/CVSD: 8 Bit reicht aber mehr Takt ist nötig ( AVR, 20 MHz PIC, 68HC908 mit 8 MHz Busfrequenz ... ). Eventuell Mehrchip-System wo Schrumpfcontroller in DIP8 nur Encoder bzw. nur Decoder macht.

Ein CVSD braucht kein Aliasingfilter. Sein Frequenzgang ist ( je nach Bitrate ) bis 800Hz eben und fällt danach langsam ab. Das paßt gut zu natürlicher Sprache ( ohne preemphase =

1pol Hochpaß bei 800Hz ).

MfG JRD

Reply to
Rafael Deliano

"Michael Schwingen" schrieb im Newsbeitrag news: snipped-for-privacy@individual.net...

AFAIK können (einige??) Chipsätzte aber beides. Ob die Software es unterstützt, ist ne andere Frage.

MfG Falk

Reply to
Falk Brunner

Horst Bartig schrieb:

Ok, dann also mehr Infos:

formatting link
(unteres Drittel) Leider habe ich mein Multimedia-Kommunikation - Script nicht hier... Aber Du kannst ja erstmal mit nur einem Prädiktorkoeffizienten arbeiten und den gleich eins setzen. Zum Prinzip der DPCM: Der Empfänger arbeitet simpel: Er nimmt zuerst einen Startwert entgegen und addiert die folgenden Differenzwerte (die sind positiv oder negativ). Der Sender überträgt als erstes einen Startwert,z.B. 0, und dann nur noch Differenzwerte. Das übertragene Differenzsignal quantisiert er, z.B. auf 4Bit pro Wert. Im Sender ist der Empfänger auch nochmal enthalten und bezieht seinen Eingang vom Ausgang des Senders. Da man nun weiß, was beim Empfänger herauskommt, kann man die Differenz zum Eingangswert bilden und erhält den Fehler. Dieser ist durch die Quantisierung entstanden. Diesen Fehler addiert man auf den nächsten zu übertragenen Wert, so daß er scih nicht fortpflanzt.

Ich denke schon, daß das mit einem solchen Controller 8Bit, 4MHz, z.B. Atmel AVR) problemlos möglich sein dürfte. Der Rechenaufwand hält sich ja in engen Grenzen...

Viele Grüße

Johannes

Reply to
Johannes Raschke

Martin Lenz schrieb in der newsgroup de.sci.electronics:

Die Idee als solche ist nicht schlecht, wenn die Anwendung das zuließe - bei mir sind 5 s nicht möglich.

Und außerdem 40 KByte RAM-Speicher, der vorhanden und verwaltet sein will - dann ist ein DSP mit Komprimierung auch nicht viel mehr aufwendiger.

Das dürfte der beste Weg sein, oder ...

MfG Horst

--
Immer auf dem aktuellen Stand mit den Newsgroups von freenet.de:
http://newsgroups.freenet.de
Reply to
Horst Bartig

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.