Forum: HF, Funk und Felder Funkübertragung Audiosignal


von Thomas K. (thomas_k502)


Lesenswert?

Hallo,

für ein kleines Studienprojekt (Elektrotechnik, RF-Designs) bräuchte ich 
eure Hilfe/Empfehlung/Meinung. In ähnlichen Forenbeiträgen bin ich 
leider nicht fündig geworden.

Wir möchten ein Audiosignal über eine kurze Distanz (< 50m) über die 
Luftschnittstelle übertragen. Am liebsten wäre uns eine digitale 
Übertragung. Die Abtastfrequenz soll 48k mit einer Quantisierung von 16 
Bit betragen, insofern das ganze in digitaler Form erfolgt. Die 
Nettodatenrate beträgt somit 768kbit/s. In Frage kämen das 868 - und das 
2400 MHz Band. Das ganze soll natürlich auf der Lolevelebene aufgebaut 
werden, d.h. der Einsatz von Mikrocontrollern, Funkmodulen mit bspw. 
I2S-Schnittstellen zur Anbindung ect.
Funkmodule, die ich im Internet gefunden habe haben oft eine zu geringe 
Datenrate. Könnt ihr mir ein passendes Funkmodul oder einen Händler 
empfehlen?

Danke schonmal,

Thomas

von Arduinoquäler (Gast)


Lesenswert?

Thomas K. schrieb:
> Die Abtastfrequenz soll 48k mit einer Quantisierung von 16
> Bit betragen, insofern das ganze in digitaler Form erfolgt. Die
> Nettodatenrate beträgt somit 768kbit/s.

Soll es denn wirklich HiFi-Qualität haben?
Erst mal checken ob es das wirklich braucht. Man muss sich im
Klaren sein dass es nicht viel hilft die Abtastrate so hoch
zu wählen wenn man die hohen Frequenzen doch nicht hört.

Für weniger Datenrate kann ich den (selbst getesteten) NRF24
empfehlen der wohl etwa 50 kBytes/Sekunde erreichen kann. Mit
2MBit/sec vielleicht auch etwas mehr.

Allerdings wird das Übertragen eines solchen Streams mit einem
"kleinen" Mikrokontroller a la AVR vielleicht etwas schwierig
werden. Aber es gibt ja andere.

von Blubb (Gast)


Lesenswert?

Warum nicht den Datenstrom komprimieren?

von Mike J. (linuxmint_user)


Lesenswert?

nRF24L01P mit oder ohne PA.
Kann bis zu 2Mbit/s und 1Mbit/s, sollte ausreichen.

von HF-Werkler (Gast)


Lesenswert?

Was für ein Delay ist noch ok?

Ist es wirklich nur ein Kanal (Mono)?

Wie Störverseucht ist die Umgebung?
(z.B. 2.4Ghz - WLAN, BT, ...)

Woher kommt die Stromversorgung?

Wie wird die Datensiucherheit gewährleistet?

Sind Unterbrechungen akzeptabel?

Wie sieht die Funkstrecke aus? (Hindernisse, Line of Sight, ...)

Können kann man alles, die Frage ist, ob es zu der Realität passt...

von Arduinoquäler (Gast)


Lesenswert?

Mike J. schrieb:
> Kann bis zu 2Mbit/s und 1Mbit/s, sollte ausreichen.

Du scheinst die Realität nicht zu kennen. Schau dir das
Datenblatt an, 2MBit ist die *Roh*-Datenrate. Entscheidend
ist was hinten 'rauskommt. Netto-Datenrate, Handshake,
Retries .....

Ja ja, einfach mal die Datenrate hinrotzen und schon weiss
man alles, gell?

von Mike J. (linuxmint_user)


Lesenswert?

Arduinoquäler schrieb:
> Handshake,
> Retries .....

Sowas macht man ja auch bei Audioübertragung ... es muss ja unbedingt 
jedes Paket ankommen.

von Arduinoquäler (Gast)


Lesenswert?

Mike J. schrieb:
> Sowas macht man ja auch bei Audioübertragung

... und Audiodaten kann man ja mit dem NRF24 auch roh
übertragen, selbst das kann er ja, gelle?

von Paul H. (powl)


Lesenswert?

Wie stellt man im Empfänger eigentlich sicher, dass die Audiodaten 
wieder zeitrichtig zusammengesetzt werden? Angenommen es gehen Pakete 
zwischendurch verloren, dann fehlen die ja im Buffer. Retransmits 
dürften auch ganz schön zeitaufwendig werden. Wenn man fehlende Pakete 
allerdings ignoriert dann verschieben sich alle Audiosamples ja immer 
wieder ein bisschen nach vorne, d.h. irgendwann gibts nen 
Buffer-Underrun.

von Christian S. (roehrenvorheizer)


Lesenswert?

Rfm73

von Thomas K. (thomas_k502)


Lesenswert?

Also erst einmal danke für die schnellen Antworten.

Wie schon erwähnt reicht die Bruttodatenrate von 2 Mbit/s nicht aus.
Wir bräuchten bei einer Nettodatenrate von 768kbit/s ca. 3Mbit/s 
Bruttodatenrate.

Arduinoquäler schrieb:
> Soll es denn wirklich HiFi-Qualität haben?

Für die Weiterentwicklung des Projekts sollte die Qualität weitestgehend 
erhalten bleiben.

Arduinoquäler schrieb:
> Allerdings wird das Übertragen eines solchen Streams mit einem
> "kleinen" Mikrokontroller a la AVR vielleicht etwas schwierig
> werden. Aber es gibt ja andere.

Wir werden zur Verarbeitung und Anbindung einen STM verwenden.

Blubb schrieb:
> Warum nicht den Datenstrom komprimieren?

Darüber habe ich mir noch keine Gedanken gemacht, da die Qualität 
weitestgehend erhalten bleiben soll. Welche Komprimierungsverfahren 
würden denn in Frage kommen?

HF-Werkler schrieb:
> Ist es wirklich nur ein Kanal (Mono)?
>
> Wie Störverseucht ist die Umgebung?
> (z.B. 2.4Ghz - WLAN, BT, ...)
>
> Woher kommt die Stromversorgung?
>
> Wie wird die Datensiucherheit gewährleistet?
>
> Sind Unterbrechungen akzeptabel?
>
> Wie sieht die Funkstrecke aus? (Hindernisse, Line of Sight, ...)


Die Latenz sollte 3ms nicht überschreiten und vereinfacht soll ein 
Monosignal übertragen werden. Die Umgebung hat maximal ein WLANnetz, 
wobei das System später mit Sicherheit nicht direkt neben einer Fritzbox 
aufgebaut wird. Der Schwerpunkt liegt darin, einfach mal selbst etwas 
funktionsfähiges aufgebaut zu haben. Daher auch keine Hindernisse oder 
ähnliches. Die Stromversorgung wollten wir uns von einem 
Entwicklungsboard abgreifen. Je nachdem, welches Modul verwendet wird, 
hat der Rahemenaufbau doch meistens bereits eine CRC-Prüfsumme oder 
ähnliches oder täusche ich mich da?! Einzelne Unterbrechungen sollten 
den Ton doch nicht übermässig verzerren, da wir nach dem FIFO Prinzip 
arbeiten.

Paul H. schrieb:
> Wie stellt man im Empfänger eigentlich sicher, dass die Audiodaten
> wieder zeitrichtig zusammengesetzt werden?

Wir wollte nach dem FIFO Prinzip arbeiten. Falls vereinzelt Frames 
verloren gehen, sollte das doch nicht auffällig sein oder täusche ich 
mich da?!

von Bernd K. (prof7bit)


Lesenswert?

Paul H. schrieb:
> Wenn man fehlende Pakete
> allerdings ignoriert dann verschieben sich alle Audiosamples ja immer
> wieder ein bisschen nach vorne, d.h. irgendwann gibts nen
> Buffer-Underrun.

Nö, warum? anstelle des fehlenden Pakets muss man an dieser Stelle eben 
eine entsprechend lange Schweige-Millisekunde einlegen oder das letzte 
Paket nochmal abspielen oder beliebig aufwendig interpolieren. Dann hört 
sichs ungefähr so an als ob man mit dem Handy durrrr     Uunkloch 
fährrrr  rrrrt.......krk.....tüt tüt tüt.

: Bearbeitet durch User
von Mike J. (linuxmint_user)


Lesenswert?

Arduinoquäler schrieb:
> ... und Audiodaten kann man ja mit dem NRF24 auch roh
> übertragen, selbst das kann er ja, gelle?

Du willst mit dem Modul ein analoges, nicht digitalisiertes Signal 
übertragen?
Dazu musst du dir schon ein anderes Modul suchen.

Wenn er 768000 bit/s übertragen möchte, dann ist da doch noch einiges an 
Luft nach oben.

Ich würde einfach den Puffer füllen und es weg schicken.
Die Adressen werden eh bei der Initialisierung des Moduls vergeben, also 
weiß der Empfänger auch von welches Modul er Daten zu erwarten hat.

CRC war doch auch schon implementiert wenn ich mich nicht irre.

Auto-Ack würde ich abschalten und die Pakete verwerfen wenn sie nicht 
übertragen worden sind.
Wenn man da mal kurz außer Reichweite befindet würde der Puffer ja voll 
laufen und der Controller versuchen das Paket von vor 5 Minuten zu 
versenden. Ist aber schon eine veraltete Information und damit sinnlos.


Paul H. schrieb:
> Wie stellt man im Empfänger eigentlich sicher, dass die Audiodaten
> wieder zeitrichtig zusammengesetzt werden?

Ist eigentlich nicht notwendig.
Man schickt ja die Pakete nacheinander weg und setzt sie auch sofort der 
Reihe nach wieder zusammen.
Wenn ein Paket nicht angekommen ist kann man den fehlenden Teil mit 
irǵend welchen Daten auffüllen oder einfach weglassen.

Man könnte aber zum Beispiel zwei Module nutzen und die Pakete 
zeitversetzt übertragen, dazu benötigt man dann noch eine Paketnummer, 
ein richtiger Zeitstempel ist nicht notwendig.

Also Das Modul_1 sendet Paket_12 und Modul_2 sendet Paket_13 zu den 
Empfängern, jeweils auf einer anderen Frequenz.
Man steigert die Datenrate so auf 4Mbit/s, belegt aber zwei Frequenzen.
Es sollte auch kein Problem darstellen die Pakete wieder richtig 
zusammen zu setzen.

von Thomas K. (thomas_k502)


Lesenswert?

Hallo,

Mike J. schrieb:
> Die Adressen werden eh bei der Initialisierung des Moduls vergeben, also
> weiß der Empfänger auch von welches Modul er Daten zu erwarten hat.
>
> CRC war doch auch schon implementiert wenn ich mich nicht irre.

Der Rahmenaufbau vom NRF24 hat doch standardmäßig den volgenden Aufbau:

1 Byte Preamble --- 3-5 Byte Adresse --- 9 Bit Control field --- Payload 
und 1-2 Byte CRC

Meinst du ich kann das Adressfeld nach der Initialisierung einfach 
wegschalten und bei der reinen Audioübertragung weglassen? Dann würde 
ich automatische eine höhere Datenrate hinbekommen. 2 
Empfänger-/Sender-Module zu verwenden müsste ich erst noch absprechen.

Was haltet ihr von dem RN171 Modul?

http://ww1.microchip.com/downloads/en/DeviceDoc/70005171A.pdf

von Route_66 H. (route_66)


Lesenswert?

Hallo!
Wie wäre es mit der Kodierung die bei CD oder DVD benutzt wird. Dafür 
hat die Industrie Chips, die kleinere Fehler korrigieren kann

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Route 6. schrieb:
> Hallo!
> Wie wäre es mit der Kodierung die bei CD oder DVD benutzt wird. Dafür
> hat die Industrie Chips, die kleinere Fehler korrigieren kann

Die Idee, extra Daten, die eine Fehlerkorrektur ermoeglichen, 
mitzuschicken, ist schon OK. aber keine Industrie hat Chips, die "kleine 
Fehler" korrigieren koennen. Da gibts hoechstens Chips, die eine 
komplette Signalverarbeitung, Motorsteuerung, Display, Fernbedienung, 
etc. fuer einen DVD-la haben. Und diese Chips gibts nicht einzeln, und 
Datenblaetter dazu gibts schon mal ueberhaupt garnicht.

Natuerlich ist es etwas unclever, unkomprimiertes und ungeschuetztes 
Audio ueber einen Funkkanal zu uebertragen. Sowas kriegt man eigentlich 
im Studium beigebracht.
Welche Kompressionsverfahren fuer's Audio und welche 
Fehlerschutzverfahren fuer die Uebertragung man dann nimmt, ist halt 
Ermessenssache und haengt von den Randbedingungen wie Kanalkapazitaet, 
Bitfehlerrate und -verteilung, max. zulaessige Verzoegerung, usw. ab.
Kleine Beispiele:
DVB-S2/HDTV Uebertragung: Da nimmt man AAC fuer die Audiokompression und 
fuer den Fehlerschutz einen BCH-Code und danach noch einen LDPC-Code.

Bei DVB-S/SDTV ist's halt eher MPEG1Layer2 bzw. Reed-Solomon und 
Viterbi.
Aber das Prinzip ist immer gleich.

Gruss
WK

von B.A. (Gast)


Lesenswert?

Dergute W. schrieb:
> Natuerlich ist es etwas unclever, unkomprimiertes und ungeschuetztes
> Audio ueber einen Funkkanal zu uebertragen.

Er will doch nur dass es funktioniert, mehr hat er nicht angegeben.
Wenn er die Daten kompremieren und verschlüsseln will, dann benötigt es 
einen genügend schnellen ARM-Prozessor.

Der TO kann ja mal sagen was er sich genau vorstellt.

von B.A. (Gast)


Lesenswert?

Thomas K. schrieb:
> Meinst du ich kann das Adressfeld nach der Initialisierung einfach
> wegschalten und bei der reinen Audioübertragung weglassen?

Nein, denn der Empfänger schaut ja dort rein ob er angesprochen wird 
oder ein anderes nRF24L01P angesprochen soll welches auf der selben 
Frequenz arbeitet.

von Georg A. (georga)


Lesenswert?

Von Sennheiser gibts das AVX-System, das überträgt digital. An dessen 
Preis merkst du, dass dein Vorhaben nicht ganz so trivial ist...

von Paul H. (powl)


Lesenswert?

Was ist mit WLAN?

von Thomas K. (thomas_k502)


Lesenswert?

Dergute W. schrieb:
> Natuerlich ist es etwas unclever, unkomprimiertes und ungeschuetztes
> Audio ueber einen Funkkanal zu uebertragen. Sowas kriegt man eigentlich
> im Studium beigebracht.

Das bei einer Funkübertragung im Normalfall Verschlüsselungs- und 
Komprimierungstechniken eingesetzt werden ist mir schon bewusst, 
allerdings geht es hier in erster Linie darum, etwas lauffähiges 
aufzubauen.

Das Projekt kommt ja nicht auf den Markt, sondern dient nur dazu, den 
Lernprozess anzuregen. Dazu zählt die richtige Hardware auszusuchen, im 
Team zu arbeiten, Probleme zu erkennen, Lösungen zu entwickeln und das 
ganze aufzubauen. An Standards müssen wir uns, soweit ich weiß, nur an 
die Richtlinien der Bundesnetzagentur halten und die gibt keine 
Kodierungs- oder Verschlüsselungsrichtlinien vor.
Um jedoch das richtige RF-Modul zu finden, entscheiden wir uns 
wahrscheinlich, das ganze zu komrimieren. Produkte von bspw. mouser oder 
NXP haben einfach eine zu hohe Lieferzeit.

von Dergute W. (derguteweka)


Lesenswert?

Moin,

Aeh - da wurd' ich wohl etwas missverstanden: mit ungeschuetzt meinte 
ich: nicht gegen Uebertragungsfehler geschuetzt - also ohne Forward 
Error Correction. Nix mit Verschluesselung. Die brauchts wirklich nicht. 
Aber ohne FEC - das waere arg gewagt.

Thomas K. schrieb:
> Das Projekt kommt ja nicht auf den Markt, sondern dient nur dazu, den
> Lernprozess anzuregen.

Aber grad' beim Lernprozess sollt' man den Leuten keinen Mumpitz 
beibringen. Wenn man sich mal die Datenrate anschaut: 768kBit/sec fuer 
ein unkomprimiertes, nicht gegen Fehler geschuetztes Mono Audiosignal. 
Das uebertraegt keiner so. Wenn da ein hoeherwertiges Bit kippt, dann 
fliegt dem Lautsprecher die Membran raus.
Sogar mit dem ollen MPEG1 Audiocodec kannste sowas eindampfen auf z.B. 
192kBit/sec. Also auf 1/4. Und wenns nicht audiophil sein muss, dann 
noch tuechtig mehr. Damit haettest du dann noch fuer die 3 fache Menge 
Fehlerkorrektur Platz. Oder du kannst die Bitrate, die du uebertragen 
musst, massiv reduzieren...

Gruss
WK

von Thomas K. (thomas_k502)


Lesenswert?

Ja ich verstehe...
Wir haben uns jetzt entschieden das ganze zu komprimieren. Aber nicht 
über ein Standart-Komprimierungsverfahren sondern über einfache IIR 
Filter. Etwas komplexeren gibt der STM vermutlich nicht her und die 
Laufzeit wäre zu hoch. Das müsste man testen. Da eine Gitarre zum 
größten Teil den Frequenzbereich von 15 - 11500 Hz nutzt, werden wir das 
Signal zuerst mit der besagten Datenrate einlesen, downsamplen 
(tiefpassfilterung und Abtastrate auf 32kHz oder 24 kHz reduzieren) und 
evt die Quantisierung ebenfalls auf 12 Bit setzen, übertragen und wieder 
upsamplen. Im Worst Case hätten wir dann eine Rate von 512 kbps. Das 
wäre ja schonmal ein guter Ansatz. Vermutlich gehen wir aber mit der 
Frequenz auf 24 kHz. Bevor wir die Hardware bestellen, werden wir das 
ganze in Matlab simulieren, um sicher zu gehen das die Qualität noch 
ausreichend ist. Mit diesem Konzept könnten wir das nrf-modul nehmen.

von HF-Werkler (Gast)


Lesenswert?

Noch ein kleiner Tip:
Erstmal ohne Funk testen, das ganze rein "digital" aufbauen und testen.

Dann in einem möglichen zweiten Schritt einfach mal Aussetzer/Fehler im 
Datenstrom einbauen und sehen, was passiert.

In einer separaten Schiene das Funkmodul mit der Ansteuerung austesten 
und feste Pakete übertragen.

Wenn das dann separat läuft, kann das System leichter zusammengebaut 
werden.

Ob mit dem Aufbau aber wirklich <3ms Delay sicher zu realisieren ist?
Das Paket kann ja erst abgesendet werden, wenn das letzte Byte drinnen 
ist. Und der Empfang des Pakets braucht dann solange, wie noch Bytes "in 
der Luft" sind.
--> Erstmal ausrechnen, was die reine Übertragungszeit ist, und dann 
noch die Zeit für die Komprimierung und De-Komprimierung draufrechnen.

Nur mal so als Gedanke: Bei Bluetooth gibt es ähnliche Ansätze (A2DP), 
und die Nettobandbreite ist auch ziemlich in der Nähe (zumindest bei 
EDR). Ich glaube mich zu erinnern, dass die Latency wohl deutlich höher 
war (so im Bereich >100ms).

von Thomas K. (thomas_k502)


Lesenswert?

HF-Werkler schrieb:
> Wenn das dann separat läuft, kann das System leichter zusammengebaut
> werden.

Danke für die Info. Das wollten wir selbstverständlich so machen.

HF-Werkler schrieb:
> Ob mit dem Aufbau aber wirklich <3ms Delay sicher zu realisieren ist?

Ich habe herausgefunden, das die Wahrnehmungsschwelle nicht bei 3ms, 
sondern bei 11 ms liegt. Das passt uns sehr gut ins Projekt. Außerdem 
sind die Bluetooth-Module von Grund auf viel langsamer als die 
WLAN-Module. Der nrf24 sollte schnell genug sein.

von Willi (Gast)


Lesenswert?

Abend,

ob NRF24 oder RFM73 (jetzt eher RFM75) nimmt sich erst einmal nichts.
Man kann dort 32 Byte in einem Rutsch übertragen. On Air sieht das dann 
so aus wie oben schon erwähnt. Der Empfänger kann die Daten automatisch 
prüfen (an Hand der CRC) und bei Fehler ein Retransmit anstoßen. Von 
daher kann man auch den Verlust eines Paketes ausgleichen. Was einem 
bewusst sein muss, das man keine kontinuierliche Datenübertragung hat. 
Man bekommt also immer maximal 32 Byte und muss dann auf das nächste 
Paket warten. Die Wiedergabe muss man also irgend wie wieder mit den 48 
kHz synchronisieren. Eventuell arbeitet man mit einem kleinen 
Datenpuffer.

Die RFM7x gibt es als RFM7xP Variante(mit Verstärker), nur die würde ich 
auf der Sendeseite nehmen. Mit den normalen Modulen bekommt man maximal 
5-6 m Reichweite, das "P" sollte die 50 m aber schaffen.

WLAN stört nach meinen Erfahrungen die RFM Datenübertragung eher nicht.

LG Willi

von HF-Werkler (Gast)


Lesenswert?

Thomas K. schrieb:
> Außerdem sind die Bluetooth-Module von Grund auf viel
>langsamer als die WLAN-Module. Der nrf24 sollte schnell genug sein.

Naja, WLAN kann auch langsam, wenn der Übertragungskanal gestört oder 
schlecht ist (z.B. viel Multipath oder zuwenig Pegel). Dann landet man 
auch mal bei der Funkdatenrate bei 1MBit/s (WLAN).

Der nrf24 kann afaik auch nur max. 1 oder 2MBit/s auf der 
Luftschnittstelle, das kann Bluetooth ebenfalls (BR/EDR).

Du wirst für einen ausreichenden Puffer sorgen müssen, um die ev. 
schwankenden Übertragungszeiten ausgleichen zu können. Alles in allem 
denke ich, dass selbst "nur" 11ms ev. schwer zu erfüllen sein könnten.

von Thomas K. (thomas_k502)


Lesenswert?

Hallo zusammen,

ich wollte mich mal zurückmelden und ein Statement zu dem Projekt 
abgeben. In dem vorgegebenen Zeitraum haben wir das Projekt leider nicht 
komplett umsetzen können. Außerdem gab es einige Komplikationen. Es 
liegt nun an der Hochschule, das Projekt evt. mit anderen Studierenden 
weiterzuführen. Vielleicht kommt es ja dazu, es würde mich sehr freuen. 
Wir haben die Aufgabenstellung bei der Planung überschätzt.

Eine Audiofunkübertragung haben wir hinbekommen, allerdings nicht wie 
geplant, mit dem STM32F7 Discovery, sondern dem F4er. Wir hatten absolut 
keine Erfahrung mit den HAL-Libs und sind deswegen umgestiegen, da der 
Schwerpunkt auf dem RF-Teil lag. Leider hat die Rechenleistung des 
Boards nicht ausgereicht, um die Daten in Echtzeit zu verarbeiten. Wir 
haben eine sehr hohe Latenz. Durch den 48kHz Interrupt verliert das 
Board zuviel Zeit zum Verarbeiten. Auch bezüglich Programmierung des 
Boards hat es wohl an Erfahrung gemangelt. Ich denke, das ein erfahrener 
Embedded-Programmierer das Ganze hinbekommt. Zu der Fehlerrate: Bei 
15000 empfangenen Packeten haben wir 63 fehlerhafte in einem 
nebenläufigen WLAN-Netz gemessen. Die CRC des RFM75P hat das sehr gut 
selbst geregelt. Trotzdem haben wir von 32 Byte (Payload) nur 24 Byte 
für die Nutzdaten verwendet, um einen kleinen Platz für andere Daten zu 
lassen. Bei dem RFM75P messten mir weiterhin eine maximale 
Brutto-Übertragungsrate von nur 1,5 Mbit/s. Für die Audioübertragung hat 
das also ausgereicht, obwohl im Datenblatt 2 Mbit/s angegeben sind. Zu 
den bereitgestellten Audiodaten: Wir haben dafür im RAM einfach 1ms 
Audiodaten abgelegt, wiederholt übertragen und dann ausgegeben. Bei der 
Ausgabe über den CS43L22 kam es zu einem unangenehmen Knacken, da der 
Controller nicht schnell genug arbeitet. Der Buffer besteht aus 
400*48*16 Bit Audiodaten. Wir haben das Ganze ohne ACK gemacht. Mit 
einer maximalen Leistungsabgabe haben wir eine Entfernung von ca. 140 m 
ohne höhrbaren Verbindungseinbruch erreicht. Zusammenfassend sind wir 
eig sehr zufrieden. Es hat zwar nicht so geklappt, wie wir es uns am 
Anfang vorgestellt haben, aber es kann ja noch weiter fortgeführt 
werden.

Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.