RFM12 und Audiosignale?

Audiosignal mit 8Bit und 8kHz Samplerate / knapp 4kHz Bandbreite: ja. 
Alles darüber: nein. Bei zu großer Distanz oder Störungen wird das 
Audiosignal ebenfalls abreißen / gestört sein.

Einen DSP braucht man nicht. Das kann bei der angegebenen Datenrate auch 
ein AVR.

Hört sich gut an... Das Audiosignal soll auch nicht umbedingt hifi 
entsprechen, ich denke dass kann man für 5.95 € nicht umbedingt 
erwarten... ;)

Dass ich einen µC brauche ist mir bewusst... Schema soll sein im groben:


Audio --> ADC von µC --> SPI --> RFM12 (Sender) --> RFM12 (Empfänger) 
--> SPI -- > µC --> DAC --> Verstärker --> Lautsprecher

Was Du in Deiner Signalkette vergessen hast, sind ein steiles fsample/2 
Anti-Alias-Filter vor dem ADC und einen entsprechenden Glättungs-Tiefpaß 
nach dem DAC. Der DAC kann auch ein HighSpeed-PWM sein.

hans wrote:
> Bei einer Samplerrate von 8 KHz und 8 Bit Auflösung würde ich
> als Empfänger einen Tiny mit PLL nehmen (z.B. Tiny25) und die
> Ausgabe mit PWM machen.
>
> gruß hans

du meinst den internen clock nehmen? ist denke ich mal nicht unbedingt 
nötig, weil das RFM12 einen 10MHZ Takt ausgibt, mit dem ich den µC 
ansteuere... PWM macht sinn, hab ich aber noch nie programmiert, werde 
mich aber da mal reinarbeiten...

Zum testen benutze ich gerade nen Mega8, wollte dann aber irgendwann auf 
Mega48 oder einen von der tiny serie umsteigen...

Travel Rec. wrote:
> Was Du in Deiner Signalkette vergessen hast, sind ein steiles fsample/2
> Anti-Alias-Filter vor dem ADC und einen entsprechenden Glättungs-Tiefpaß
> nach dem DAC. Der DAC kann auch ein HighSpeed-PWM sein.


"ein steiles fsample/2 Anti-Alias-Filter" Was meinst du damit? Alles 
über 4 Khz filtern? Wie könnte sowas aussehen? steiler Hochpass bei 4 
khz?

Hier nurmal ein paar Dinge die man beachten sollte:
- Irgendwie muss man die Daten in Pakete packen, damit sich der 
Empfänger neu synchronisieren kann, wenn man ein Bit übersprungen wird 
und so die Bytes durcheinander kommen.
- Um dieses Problem zu vermeiden, darf man nie länger als 1-2 Byte den 
Wert 0 oder 255 senden, ansonsten funktioniert die 
Baudratensynchronisation nicht. Mit anderen Worten: Die Audiodaten 
dürfen nicht übersteuert sein.
- Was passiert wenn Daten fehlerhaft bzw. mit Lücken ankommen? Hier 
könnte man versuchen die Lücken irgendwie zu füllen, so dass es 
möglichst wenig auffällt.
- Wenn man die Daten in Pakete packt, wie schafft man es dann, die Lücke 
zwischen Paketende und Packetstart zu überbrücken.

Was ganz gut geht (aber wenig Sinn macht): Einen Videosender mit UART 
Daten füttern. Durch die hohe Bandbreite kann man problemlos 1MBaud 
übertragen und die Signale am Empfänger sind noch schöne Rechtecke (wenn 
der Empfang gut ist). Das ermöglicht 25kHz, 16bit, Stereo.

Hi,
zu bedenken wäre auch noch, das man nur pro Minute um die 6 Sekunden 
senden darf, soweit ich mich erinnere. Also kurz gesagt es ist illegal 
auf dem 433Mhz Band Audio zu übertragen.


P.S. : zumindest nicht mit der Sendeleistung

Gruß

Fabian Ostner wrote:
> zu bedenken wäre auch noch, das man nur pro Minute um die 6 Sekunden
> senden darf, soweit ich mich erinnere.

Nein, nicht bei 433MHz. Bei 868MHz gibts die Einschränkungen auf 1% bzw. 
0,1%. 433MHz ist komplett uneingeschränkt.
http://www.bundesnetzagentur.de/media/archive/6709.pdf
Aber mal davon abgesehen ist der ISM Bereich eigentlich nicht für 
Audioanwendungen gedacht.

Der Bereich 863 - 868MHz ist dagegen für Audioanwendungen reserviert. 
Mit der 868MHz Version dürfte es daher keine Probleme geben.
http://www.bundesnetzagentur.de/media/archive/5005.pdf

> P.S. : zumindest nicht mit der Sendeleistung

Erlaubt sind 10mW, die RFM12 liefern gerade mal etwa die Hälfte.

Mahl ganz eine andere frage zu dem Team:

Wie sieht es mit der Reichweite aus?

Freie Sicht, keine Störung: Mit etwas Glück 400m.
Mit einer Yagiantenne: 1km.
Im bebautem Gelände: 20-200m je nachdem was so alles den Empfang stört.