RDS ENCODER Signalgenerator Testgenerator Testsender Modulator ATmega8 Assembler

[Bernhard S. (bernhard)]

Geschätztes Forum,

eine relativ einfache Hardware-Variante, wie mit einem µC ein RDS-Signal 
generiert werden kann.

Dieser Encoder gibt die RDS-Gruppen am:

- DATA und TAKT Pin aus und
- das "analoge" 57kHz-RDS-Signal,
- sowie ein 19kHz-Signal (Pilotton), welches man bei Bedarf nutzen kann.

Speist man z.B. mit dem analogen RDS-Signal den AFC-Eingang eines 
UKW-Tuners, dann könnten die RDS-Daten in einen benachbartes UKW-Radio 
angezeigt werden.

Die Beispiel RDS-Gruppen mit je 104 Bit 4x(16+10)Bit sind in den 
Tabellen hinterlegt.

Man kann auch nur "NULL"-Bits und und nur "EINS"-Bits senden, oder 
diverse Bitmuster, um die Rohdaten-Decoder zu testen.

Wie funktioniert die Software?

Genutzt werden alle 3 Timer. Timer1 erzeugt die 19kHz (per CTC). Timer2 
die 57kHz (CTC). Timer0 ist nur ein Überwachungstimer, welcher aktiv 
wird (per Interrupt) wenn der Programmcode in der RDS-Routine zu lange 
dauert.

Der Ausgang des Timer2 (57kHz) ist direkt mit INT0 verbunden.

Bei jedem Flankenwechsel (57kHz) wird ein externer Interrupt ausgelöst 
und die RDS-Routine abgearbeitet, welche die Signale für Digital-RDS 
(TAKT/DATA) und Analog-RDS erzeugt.

Die RDS-Routine holt sich jedes einzelene zu sendendes Datenbit aus dem 
SRAM-Puffer und steuert anschließend die einzelnen Pins.

Ist der Puffer geleert, dann können/müssen sofort neue Daten in den 
Puffer geschoben werden, ansonsten reist der Datenstrom ab und die 
RDS-Decoder kommen in's stolpern und müssen sich erst wieder 
synchronisieren.

Die grüne LED blinkt sehr aufgeregt, sie zeigt an, dass neue Daten in 
den Puffer geschrieben werden.

Leuchtet die gelbe, liegt ein zeitliches Problem in der 
Interrupt-Routine vor, und das ist nicht gut.

Das analoge RDS-Signal (Ausgang am LC-Schwingkreis) sieht nicht sehr 
schön aus, ist aber braucbar, ein Conrad RDS-Decoder kam damit sehr gut 
zurecht.

Problematisch ist die Taktfrequenz des µC. Sie muss ein Vielfaches von 
57khZ sein mit nur wenigen Hz Abweichung, sonst arbeiten u.U. die 
Rohdatendecoder nicht korrekt. Im Versuchsaufbau half mir ein externer 
Generator. Eventuel kann man auch einen 16MHz Quarz auf 16.017.000 Hz
"ziehen", dazu fehlt mir aber die Erfahrung.

Einige Hintergrundinformationen haben wir hier zusammengetragen:

Beitrag "RDS DECODER analog Schaltung ohne IC gesucht, für Rohdatengewinnung"

Beitrag "RDS DECODER LCD TWI 2WIRE USART ATmega8 Assembler"

Beitrag "RDS CRC Prüfbit Berechnung"

Beitrag "Si4735 RDS Radio UKW LW MW KW AM FM - TA TP AF GT TMC CT RT Pi PS ATmega8 Assembler"

Für Hinweise und Verbesserungen bin ich sehr dankbar.

Bernhard

[Muffin (Gast)]

Darf ich dazu mal was fragen bitte?

Wer um alles in der Welt will irgendwelche RDS-Daten WOHIN(!!) 
senden??????

Kauf Dir bei ELV das HIER --> 
http://www.elv.de/output/controller.aspx?cid=74&detail=10&detail2=28050 
- damit kanst ne ganze Menge anstellen, wenn das unbedingt willst... Nur 
mein Tip: WER bitte will WAS mit WELCHEN RDS-ROHDATEN anfangen? Nullen / 
Einsen?????????????
sieht ungefähr SOOOOOO HIER --> aus: 00001011100001001000111101000100001

Noch Fragen?...

Kicher nich, das tu ich grad beim Verfassen dieser Nachricht 
hier!(grins) gibt genug zu lachen im Forum...

Bastelfreak Muffin

[Detlef K. (adenin)]

Muffin schrieb:
> Wer um alles in der Welt will irgendwelche RDS-Daten WOHIN(!!)
> senden??????

Solche Leute wie ich.

Muffin, kauf dir 'ne BRAVO und verzieh dich in dein Zimmer.

[Gleichspannungs-Tranformator (Gast)]

Detlef riet:
>Muffin, kauf dir 'ne BRAVO und verzieh dich in dein Zimmer.

Volltreffer! Hirnchen versenkt.

[Bernhard S. (bernhard)]

Muffin schrieb:

>> Wer um alles in der Welt will irgendwelche RDS-Daten WOHIN(!!)
>> senden??????

Detlef Kunz schrieb

>Solche Leute wie ich.


Ich gehöre auch mit zu dieser Spezies.


Es gibt nicht nur NF und HF-Generatoren, sondern auch Generatoren für 
Spezial-Anwendungsfälle, z.B. Bild-, Rausch-, RDS- , Stereo- 
,Bitmuster-Generatoren.


Spielereien sind natürlich auch möglich z.B.:

-Messwerte wie Außentemperatur, Luftruck, Höhe usw. im Autoradio-Display 
anzeigen lassen.

Bernhard

[Bernhard S. (bernhard)]

@alle

eine relativ einfache Beschaltung eines µC, um einen Takt mit einem 
LC-Schwingkreis zu erzeugen.


Beitrag "µC Takt durch LC-Schwingkreis / Oszillator erzeugen ATmega8"

Bernhard

[Bernhard S. (bernhard)]

Detlef Kunz schrieb:

> Du willst aus den 16MHz einen 57kHz Takt für den Schwingkreis machen?
> Ganz einfach:
> Benutz einen Timer: lass ihn 40mal bis 281 und 17mal bis 280 zählen.
> Schön gemischt, so in der Art: 281, 281, 280, 281,281,281,280...
> Das ergibt im Mittel über 57 Werte eine Frequenz von 57kHz mit nur
> gerigem Jitter, der vom LC-Scwinkreis eventuell (je nach Güte) beseitigt
> wird.
> :)

Diese Idee gefällt mir :-) werde die Software mal auf diese Variante 
umstricken, mal schaun, ob die RDS-Decoder mit dem Jitter zurechtkommen.

Danke

Bernhard

[Detlef K. (adenin)]

Bernhard S. schrieb:

> Diese Idee gefällt mir :-) werde die Software mal auf diese Variante
> umstricken, mal schaun, ob die RDS-Decoder mit dem Jitter zurechtkommen.

Ich denke der Jitter sollte irgentwo bei +/-20 ns (0.1%) liegen.

Schau mal hier: http://de.wikipedia.org/wiki/Bresenham-Algorithmus
Das sieht auf den ersten Blick am Thema vorbei aus, behandelt aber genau 
das Problem der Verteilung der einzelnen Intervalle mit kleistmöglichem 
Fehler (Jitter).
Formuliere einfach das Problem um. Du willst eine Linie Zeichnen von den 
Koordinaden (x0=0,y0=0) nach (x1=57,y1=16000). Wie groß ist ist jeder 
einzelne y-Schritt, wenn sich x jeweils um eins ändert.
:)

[Bernhard S. (bernhard)]

@Detlef

> Schön gemischt, so in der Art:....

Hab die Software umgeschrieben, eine Tabelle angelegt, auch gut 
gemischt, 37x140, 20x141, in dieser Form:

TABELLE_TAKTKORREKTUR:
.db 140,141,140,140,141,140,140,141,140,141......

Es funktionierte auf Anhieb. Die RDS-Daten werden fehlerfrei empfangen.

Nur beim Conrad-RDS-Decoder sind nicht mehr alle Balken für 
Signalqualität sichtbar. D.h. das Jittern bereitet dem Decoder Probleme, 
aber er decodiert.

An anderen Decodern werde ich das Verfahren auch noch testen.

Bernhard

[Detlef K. (adenin)]

Wie verwendest Du die Tabelle?
Läuft der Timer 140 bzw. 141 Takte und dann toggelst Du des Pin für die 
57kHz?

[Bernhard S. (bernhard)]

Genau genommen arbeitet der TIMER im CTC Modus mit 139 und 140, 
Tabellenwert Minus 1.

Den Timer wollte ich nicht im Interruptmodus laufen lassen.

Die Ausgangsfrequenz ist 57.000 Hz  +/- 1Hz.




  LPM temp, Z         ; aus Tabelle laden
  dec temp      ; -1 (CTC)
  out OCR2,temp                ; CTC

TABELLE_TAKTKORREKTUR:
.db 
140,141,140,140,141,140,140,141,140,141,140,140,141,140,140,141,140,140, 
141,140,140,141,140,140,141,140,140,141,140,141,140,140,141,140,140,141, 
140,140,141,140,140,141,140,140,141,140,140,141,140,141,140,140,141,140, 
140,141,140,0

[Detlef K. (adenin)]

Hmm, das beantwortet meine Frage nicht ganz.
Du arbeitest mit 16MHz?
Und der Timer toggelt das 57kHz-Pin mit jedem neuen Wert aus deiner 
Tabelle?
Dann ist das so noch nicht korrekt, und Du kannst auf ein viel besseres 
Signal hoffen.

[Bernhard S. (bernhard)]

> Du arbeitest mit 16MHz?

ja

> Und der Timer toggelt das 57kHz-Pin mit jedem neuen Wert aus deiner
> Tabelle?

ja

> Dann ist das so noch nicht korrekt, und Du kannst auf ein viel besseres
> Signal hoffen.

nunja, der RDS-DECODER von Conrad scheint auch etwas sensibel zu sein,

er untersucht die Phasenlage der einzelnen 57kHz Schwingungen.

Ändert sich die Phasenlage, dann muss seine PLL nachjustiert werden.



Hab den Programmcode etwas verbessert.

Der Interrupt wird immer aus einem SLEEP-Modus heraus gestartet.

Wo vielleicht noch Verbesserungsbedarf bestünde wäre hier, bin mir nicht 
ganz sicher, ob diese Routine immer die gleiche Anzahl von Takten 
benötigt, nicht dass hier ein zusätzliches Jittern entsteht:

;----------------------------------------------------------------------- 
--;  ANALOG-AUSGANG (Signal invertieren / nicht invertieren)
  tst RDS_INVERTIERUNG
  breq RDS_GENERATOR_NO_INVERTIERUNG
  sbis (AUSGANG_57kHz_PIN),(AUSGANG_57kHz_PIN_NR)  ; springe, wenn
  rjmp RDS_GENERATOR_PIN_HIGH
  rjmp RDS_GENERATOR_PIN_LOW
RDS_GENERATOR_NO_INVERTIERUNG:
  sbis (AUSGANG_57kHz_PIN),(AUSGANG_57kHz_PIN_NR)  ; springe, wenn
  rjmp RDS_GENERATOR_PIN_LOW
  rjmp RDS_GENERATOR_PIN_HIGH
RDS_GENERATOR_PIN_HIGH:
  sbi (AUSGANG_RDS_ANALOG_PORT),(AUSGANG_RDS_ANALOG_PIN_NR); Analog 
57kHz
  rjmp RDS_GENERATOR_PIN_FERTIG
RDS_GENERATOR_PIN_LOW:
  cbi (AUSGANG_RDS_ANALOG_PORT),(AUSGANG_RDS_ANALOG_PIN_NR); Analog 
57kHz
RDS_GENERATOR_PIN_FERTIG:
;----------------------------------------------------------------------- 
--

[Detlef K. (adenin)]

Ich hab nochmal nachgerechnet, deine Taktzahlen 37*140 und 20*141 
stimmen doch,
Wenn die Verteilung korrekt ist (ich war zu faul das zu prüfen), dann 
lässt sich da doch leider nichts mehr verbessern.
Das ist dann schon der minimalste Jitter, der bei diesem Verfahren 
möglich ist.
Naja, wenigstens geht's. :)

[Bernhard S. (bernhard)]

Vielleicht kannst Du Dir doch mal die Verteilung genauer anschauen.

Ist sie nicht optimal, dann tritt ein unnötiges Jittern auf.

Ich schau mir nochmal das nachgeschaltete Filter genauer an, vielleicht 
ergeben sich dort noch Optimierungsmöglichkeiten.

Kannst Du Dir o.g. Assemblerroutine mal genauer anschauen, hiermit wird 
das Ausgangssignal generiert. Hier sollte kein Jittern entstehen.

Danke

Bernhard

[Detlef K. (adenin)]

OK, ich hab mir erst mal den Code angesehen.
Da ist ein Jitter drin.
Ich hab mal die Takte dahinter geschrieben.
Da kannst Du sehen, dass der Ausgang in RDS_GENERATOR_PIN_HIGH einmal 
nach 6 und dann nach 8 Takten bedient wird.
In RDS_GENERATOR_PIN_LOW wird der Ausgang jedes mal nach 7 Takten 
bedient.

;-------------------------------------------------------------------------
;ANALOG-AUSGANG (Signal invertieren / nicht invertieren)
  tst RDS_INVERTIERUNG                                ;0
  breq RDS_GENERATOR_NO_INVERTIERUNG                  ;1
  sbis (AUSGANG_57kHz_PIN),(AUSGANG_57kHz_PIN_NR)     ;2
  rjmp RDS_GENERATOR_PIN_HIGH                         ;3
  rjmp RDS_GENERATOR_PIN_LOW                          ;4

RDS_GENERATOR_NO_INVERTIERUNG:
  sbis (AUSGANG_57kHz_PIN),(AUSGANG_57kHz_PIN_NR)     ;3
  rjmp RDS_GENERATOR_PIN_LOW                          ;4
  rjmp RDS_GENERATOR_PIN_HIGH                         ;5

RDS_GENERATOR_PIN_HIGH:                               ;5 7
  sbi (AUSGANG_RDS_ANALOG_PORT),(AUSGANG_RDS_ANALOG_PIN_NR); Analog 57kHz        ;6 8
  rjmp RDS_GENERATOR_PIN_FERTIG
RDS_GENERATOR_PIN_LOW:        ;6 6
  cbi (AUSGANG_RDS_ANALOG_PORT),(AUSGANG_RDS_ANALOG_PIN_NR); Analog 57kHz        ;7 7
RDS_GENERATOR_PIN_FERTIG:
;-------------------------------------------------------------------------

Ich hab das ein klein wenig geändert.
Die Ausgänge sollten nun immer nach 7 Takten bedient werden.

;-------------------------------------------------------------------------
;ANALOG-AUSGANG (Signal invertieren / nicht invertieren)
  tst RDS_INVERTIERUNG                                   ;0
  breq RDS_GENERATOR_NO_INVERTIERUNG                     ;1
  sbis (AUSGANG_57kHz_PIN),(AUSGANG_57kHz_PIN_NR)        ;2
  rjmp RDS_GENERATOR_PIN_HIGH                            ;3
  rjmp RDS_GENERATOR_PIN_LOW                             ;4

RDS_GENERATOR_NO_INVERTIERUNG:
  sbis (AUSGANG_57kHz_PIN),(AUSGANG_57kHz_PIN_NR)        ;3
  rjmp RDS_GENERATOR_PIN_LOW                             ;4

RDS_GENERATOR_PIN_HIGH:        ;5 5
  nop                                          ;6 6
  sbi (AUSGANG_RDS_ANALOG_PORT),(AUSGANG_RDS_ANALOG_PIN_NR); Analog 57kHz        ;7 7
  rjmp RDS_GENERATOR_PIN_FERTIG
RDS_GENERATOR_PIN_LOW:        ;6 6
  cbi (AUSGANG_RDS_ANALOG_PORT),(AUSGANG_RDS_ANALOG_PIN_NR); Analog 57kHz        ;7 7
RDS_GENERATOR_PIN_FERTIG:
;-------------------------------------------------------------------------

[Bernhard S. (bernhard)]

@Detlef


>Ich hab das ein klein wenig geändert.
>Die Ausgänge sollten nun immer nach 7 Takten bedient werden.

Ein ganz großes Dankeschön.

Hab's getestet, scheint etwas besser zu funktionieren, da jetzt manchmal 
einige Balken für die Signalqaultät leuchten.

Ich werd's so belassen.

Bei Bedarf kann ja der µC mit einem anderen Takt (Vielfaches von 57kHz) 
betrieben werden, dann tritt kein Jittern auf, vorausgesetzt man 
deaktiviert die zuvor Taktkorrektur.

Bernhard

[Abdul K. (ehydra)]

Hast du den Empfang mal mit einem normalen RDS-Dekoder ausprobiert? 
Eventuell liegt es nur an dem Conrad-Dingens - wo ich den Schaltplan 
leider nicht kenne.

[Bernhard S. (bernhard)]

@Abdul

>Eventuell liegt es nur an dem Conrad-Dingens

An anderen Decodern konnte ich's diesen Signalgenerator noch nicht 
testen, hatte noch keine Zeit einen kleinen UKW-Sender (z.B UKW-Tuner 
und AFC-Eingang) entsprechend umzubauen.... kommt aber noch.


@alle

hatte einen Bug in der neuen Programmversion gefunden, die 
Interruptroutine dauerte zu lange, der Überwachugstimer schlug Alarm, 
welchen ich Anfangs ignorierte.

Eine Verbesserung des Ausgangsfilters brachte leider nichts.


Bernhard

[Abdul K. (ehydra)]

Hm. Eventuell liegts an der Phasenlage und dem Algorithmus wie der 
Conrad-Dekoder arbeitet. Bei RDS ist die Phasenmodulation ich glaube 
+/-90° und normale BPSK hat +/-180°. Dementsprechend unterscheiden sich 
die analogen Filter übrigens auch leicht.

Was man auch noch machen könnte als Versuch: einen deiner 
Controller-Dekoder phasenstarr an den gleichen Quarz koppeln.

Vielleicht bricht dein Taktquarz auch abundzu mal aus und macht Sprünge. 
Kommt vor bei schlechter Entkopplung der Versorgungsspannung oder wenn 
man zuweit getrimmt hat (Dann bricht Q drastisch ein).

Die Filter kann man komplett weglassen. Du hast ja ausreichend 
Störabstand und nur dafür sind sie da: nämlich Störsignale im Verhältnis 
zum Nutzsignal zu dämpfen.

[Bernhard S. (bernhard)]

> Hm. Eventuell liegts an der Phasenlage und dem Algorithmus wie der
> Conrad-Dekoder arbeitet. Bei RDS ist die Phasenmodulation ich glaube
> +/-90° und normale BPSK hat +/-180°. Dementsprechend unterscheiden sich
> die analogen Filter übrigens auch leicht.

Die Phasenlage kann man getrost in diesem Fall ignorieren, es wird ja 
auch nur ein 57kHz RDS-Signal beim Conrad-RDS-Manager benötigt. 19kHz 
(Pilotton) braucht er nicht.

Die positive und negative Halbwelle des RDS-Signal ist durch nur durch 
eine 180° Phasenverschiebung gekennzeichnet.


> Was man auch noch machen könnte als Versuch: einen deiner
> Controller-Dekoder phasenstarr an den gleichen Quarz koppeln.

Das bringt nichts, denn der Rohdatendecoder muss erst vernünftig 
Decodieren.


> Vielleicht bricht dein Taktquarz auch abundzu mal aus und macht Sprünge.
> Kommt vor bei schlechter Entkopplung der Versorgungsspannung oder wenn
> man zuweit getrimmt hat (Dann bricht Q drastisch ein).

Der Takt ist wichtig, da hast Du Recht, denn die 57KHz müssen relativ 
genau generiert werden, Abweichungen größer 11 Hz dankt der 
Rohdatendecoder mit falschen Rohdaten.

> Die Filter kann man komplett weglassen. Du hast ja ausreichend
> Störabstand und nur dafür sind sie da: nämlich Störsignale im Verhältnis
> zum Nutzsignal zu dämpfen.

In diesem Fall wollte ich etwas sinusähnliches dem Decoder anbieten. 
Aber Du hast schon Recht, es ginge auch ohne, denn das Conrad Teil 
besitzt schon 3 Filter-Stufen, welche das 57kHz Signal filtern.

[Abdul K. (ehydra)]

Bernhard S. schrieb:
> Die positive und negative Halbwelle des RDS-Signal ist durch nur durch
> eine 180° Phasenverschiebung gekennzeichnet.
>

Falsch. Schau dir den Modulator in der Norm an.
Wenn es so wäre wie du denkst, könnte man den ARI-Träger nicht mehr 
unterbringen! Die haben schon genau gewußt was sie taten.


> Der Takt ist wichtig, da hast Du Recht, denn die 57KHz müssen relativ
> genau generiert werden, Abweichungen größer 11 Hz dankt der
> Rohdatendecoder mit falschen Rohdaten.
>

Das Problem haben übrigens viele Chips. Da nützt es auch wenig, wenn der 
Ansatz ein Quarz bei 4,332MHz ist. Übrigens auch mit Absicht, denn 
normale Quarze sind zwischen 4 und 5MHz am temperaturstabilsten.


>> Die Filter kann man komplett weglassen. Du hast ja ausreichend
>> Störabstand und nur dafür sind sie da: nämlich Störsignale im Verhältnis
>> zum Nutzsignal zu dämpfen.
>
> In diesem Fall wollte ich etwas sinusähnliches dem Decoder anbieten.
> Aber Du hast schon Recht, es ginge auch ohne, denn das Conrad Teil
> besitzt schon 3 Filter-Stufen, welche das 57kHz Signal filtern.

Auch falsch. Du brauchst wirklich keine Filter!!!

[Bernhard S. (bernhard)]

> Hm. Eventuell liegts an der Phasenlage und dem Algorithmus wie der
> Conrad-Dekoder arbeitet. Bei RDS ist die Phasenmodulation ich glaube
> +/-90° und normale BPSK hat +/-180°. Dementsprechend unterscheiden sich
> die analogen Filter übrigens auch leicht.

>> Die positive und negative Halbwelle des RDS-Signal ist durch nur durch
>> eine 180° Phasenverschiebung gekennzeichnet.

>>>Falsch. Schau dir den Modulator in der Norm an.
>>>Wenn es so wäre wie du denkst, könnte man den ARI-Träger nicht mehr
>>>unterbringen! Die haben schon genau gewußt was sie taten.

Dein "Falsch" ist falsch und unbegründet.

Beweis:

1. ARI ist abgeschaltet, nicht mehr vorhanden, wird nicht gesendet,
   bis auf wenige Sender, die ARI noch senden.

   Siehe "SCAN_100kHz.jpg", der NF-SCAN meines Ortssenders,
   Pilotton und RDS ist erkennbar, ARI fehlt.

2. Durch eine einfache Schaltung konnte ich den 19kHz-Pilotton isolieren
   und anschließend verdreiachen.
   Siehe "SCHALTUNG.jpg"

  Im Bild "•OSZI.jpg" ist das Verdreifachte 19kHz (3x19=57kHz) und das
  isolierte RDS Signal erkennbar und die Phasenlage beider Signale.
  Man erkennt sehr schön den Phasenunterschied, welcher die positive
  und negative Halbwelle kennzeichnet.
  Das ist der typische Fall Amplitudenmodulation mit unterdrücktem 
Träger.

   Bild "•THEORIE_MODULATION.jpg" einfache grafische Darstellung
   Amplitudenmodulation mit unterdrücktem Träger.

3. Dem  SAA6579 reicht das einfache RDS-Signal aus, um die Rohdaten zu
   demodulieren siehe "•EINGANSSIGNAL__SAA6579.jpg"

4. Deine angesprochene "Phasenlage" ist gegenstandslos, denn ARI
   existiert nicht und Pilotton (19kHz) wird bei diesem Decoder nicht
   benötigt.

[Bernhard S. (bernhard)]

>>> Die Filter kann man komplett weglassen. Du hast ja ausreichend
>>> Störabstand und nur dafür sind sie da: nämlich Störsignale im
>>> Verhältnis zum Nutzsignal zu dämpfen.
>
>> In diesem Fall wollte ich etwas sinusähnliches dem Decoder anbieten.
>> Aber Du hast schon Recht, es ginge auch ohne, denn das Conrad* Teil
>> besitzt schon 3 Filter-Stufen, welche das 57kHz Signal filtern.

>Auch falsch. Du brauchst wirklich keine Filter!!!


Dein "Auch falsch" ist wieder falsch und unbegründet.

Es kommt auf den konkreten Anwendungsfall drauf an, er ist eine Option, 
man kann, man muss aber nicht.


Dieses Filter kann bei Bedarf verwendet werden, wenn dieser 
RDS-Generator z.B. den analogen Ausgang eines FM-Demodulator darstellen 
soll.

Mir ist kein FM-Demodulator in der kommerziellen Radiotechnik bekannt, 
der so steile Flanken zur Verfügung stellen könnte wie der µC-Pin des 
RDS-Generators, ich lasse mich aber gern eines beseren belehren.

Es ist gleichzeitig auch ein Formungsfilter, etwas primitiv, scheint 
aber auszureichen.

Siehe Bilder, Vergleich eines gesendeten Biphasesymols vom Sender und 
vom  Generator.

Man sollte auch ein Filter verwenden, kann auch RC-Kombination sein, 
bevor der RDS-Generator einen HF-Sender ansteuert. Die Bandbreite des 
Senders wäre ansonsten extrem hoch.

In diesem Beitrag wurden in mühevoller und monatelanger Kleinarbeit die 
Erkenntnisse von vielen zusammengetragen, schau ruhig mal rein:

Beitrag "RDS DECODER analog Schaltung ohne IC gesucht, für Rohdatengewinnung"

[Abdul K. (ehydra)]

Schon unter deinem 1. widersprichst du dir ja selber. ARI abgeschaltet 
und dann bis auf ganz wenige Sender doch da. ???
Dieser aggressive Ton noch dazu als Fragender paßt mir übrigens auch 
überhaupt nicht. Du fährst da eindeutig zu schnell für deine 
Verhältnisse.


Warum erzeugt der Modulator in der Norm Nadelimpulse? Würde doch ein 
einfacher Invertierer reichen.

Es stimmt, die gängigen Dekoderchips können auch +/-180 BPSK dekodieren. 
Hatte ich das Gegenteil behauptet? Eine Betrachtung über das S/N würde 
diese Sachen übrigens relativieren.

Ist folgendes einsichtig:
1. RDS wurde entwickelt um zu ARI kompatibel zu sein. Es spielt also 
keine Bohne wenn ARI mittlerweile nicht mehr existiert oder nur noch 
vereinzelt benutzt wird. System RDS kann sich dadurch nicht mehr ändern.
2. Für die Übertragung von Daten reicht ein einzelner ständig 
anstehender Träger nicht aus. Es muß Modulation stattfinden, die aber zu 
einer größeren Bandbreite als die des gegen Null Bandbreite gehenden 
Trägers führt und zwar unweigerlich !
3. Ein BPSK-Signal mit +/180° Modulation hat genau in der Mitte auf der 
Frequenz des virtuellen Trägers eine gegen Null gehende Lücke. Dort paßt 
nach 2. keine Information außer einem <hier nutzlosen> Träger rein!
4. ARI moduliert seinen Träger zur Informationsübermittlung 
(Bereichskennung A-F). Der reine Träger ohne Modulation ist SK. SK wird 
heutzutage weiterhin gesendet (typischer Duddelfunk mit 
Verkehrsdurchsagen), ist aber bei vielen Sendern auch aus (z.B. 
Klassik-Programme)!
5. Folglich muß das BPSK Signal vom Frequenzpunkt des eigenen Trägers 
entfernt werden. Das genau macht man durch orthogonale Modulation mit 
starren Phasenkopplungen.
6. Orthogonale Modulation bedingt eine Änderung des Phasenhubs. Hub ist 
hier wohl einfach ein besserer Begriff als Phasenlage. Meine 
"Phasenlage" hat nichts direkt mit 19KHz zu tun! Sie bezieht sich auf 
den virtuellen 57KHz-Träger resp. die Phasenlage des vorherigen Symbols 
im Datenstrom.
7. Beachte auch, das ein Restträger wie bei anderen üblichen 
Modulationsverfahren eben nicht enstehen darf! Der wäre exakt auf 57KHz 
und da ist eben ARI (genauer der SK-Träger) bzw. war ARI schon lange vor 
RDS. Daher nennt man es orthogonal und die wird eben durch die 
phasenstarre und definiertem Phasenversatz -Modulation erzeugt - 
ausgehend von 19KHz. Das ist der einzige Punkt wo RDS von 19KHz abhängig 
ist. (Hintergrund: Die 19KHz waren früher beim Bayerischen Rundfunk 
sozusagen atomuhrgenau und eine der Entwicklerfirmen von RDS saß mit dem 
Designteam in Bayern. Vermute das ist auch der Grund warum RDS zu genaue 
Vorgaben beim Quarz hat. Es gibt aber viele Sender, die die 19KHz weit 
ungenauer erzeugen und dann gibts Probleme mit den Dekoderchips wenn das 
Quarz doch nicht so genau ist)

Hoffe nix vergessen zu haben. Ja ich weiß, es ist ganz schön 
kompliziert.

[Abdul K. (ehydra)]

zu Beitrag "Re: RDS ENCODER Signalgenerator Testgenerator Testsender Modulator ATmega8 Assembler"

Ich kenne alle deine RDS-Threads und lese sie gern genüßlich. Schöne 
Arbeit!
Trotzdem weißt du was RDS-Verfahren angeht, einfach viel weniger als 
ich.


Auch beim Filter bleibe ich bei meiner Meinung. Nicht das ich damit 
sage, du würdest nur Blödsinn schreiben. Teils stimmt es richtig.


Hier noch was für die Theorie. Aber wie gesagt, das ist normale BPSK und 
RDS ist einen deutlichen Zacken extravaganter:
http://www.amsat.org/amsat/articles/g3ruh/108.html


Simulier einfach mal deine Modulation und schau dir das Spektrum an. Ein 
Referenzspektrum ist in der Norm.


Cool einfach down! Du wirst bald erkennen, wie recht ich hatte.


Ach noch ein Punkt:
8. Durch die Manchestermodulation wird die Null auf der Höhe des Trägers 
erzeugt. Sonst wäre bei BPSK dort der Punkt der höchsten Energiedichte.

[Bernhard S. (bernhard)]

>Schon unter deinem 1. widersprichst du dir ja selber. ARI abgeschaltet
>und dann bis auf ganz wenige Sender doch da. ???

Der Sender Hamburg sendet noch ARI, vielleicht gibt es doch noch einen 
oder anderen. Das sind doch relativ wenige.

Aus diesem Grund möchte ich auch nicht weiter auf ARI eingehen.


>Warum erzeugt der Modulator in der Norm Nadelimpulse? Würde doch ein
>einfacher Invertierer reichen.

Du meinst vermutlich die Darstellung im "img_9506.gif", diese Nadeln am 
Messpunkt "4" sind aber an den nachfolgenden Messpunkten bedeutungslos.


>Simulier einfach mal deine Modulation und schau dir das Spektrum an. Ein
>Referenzspektrum ist in der Norm.

So sieht das gemessene Frequenzspektrum aus, gemessen an einem 
2-stufigen LC-Filter.

Mit dieser einfachen Schaltung, Kostenpunkt ca. 5 Euro, wird natürlich 
nicht die Norm erfüllt, aber ein paar Filter mehr und das Spektrum kommt 
der Norm schon ziemlich nahe.


Ich sehe momentan keinen grundlegenden Fehler in diesem RDS-Generator 
Konzept. Es ist ein 57-kHz Generator, der eine 180-grädigen Phasensprung 
für die RDS-Biphasesymbole generiert.

Für konstruktive Hinweise bin ich sehr dankbar.

Bernhard

[Abdul K. (ehydra)]

ARI hin und her. Es muß für diese Modulation noch Platz vorhanden sein, 
auch wenn sie dann nicht mehr genutzt wird.
Mag sein, daß es mittlerweile sogar bei den Sendern Klone gibt, die da 
kein ARI mehr vorhanden, einfachere Schaltungen verwenden als +/- 90° 
Modulation. Zu Postzeiten gabs sowas natürlich nicht. Aber wir kennen ja 
alle den Verfall...
SK wird auf jeden Fall noch gesendet und der Dekoder muß mit beiden 
Optionen klar kommen:
1. SK nicht vorhanden, 57KHz ist leer
2. SK vorhanden, bei 57KHz ist ein einzelner Träger ohne Modulation


Ich meine die Darstellung in der offiziellen Norm. Moment...
Fig. 1 page 7 EN50067
NRZ to polar pulse converter mit der Waveform 3


Ohne weitere Kenntnis des Conrad-Dekoders ist das aber einfach das 
falsche Pferd.


Das korrekteste Filter würde die beste Bitfehlerrate haben.
Dein Spekrum ist einfach zu verschmirrt. Ist halt real aufgenommen und 
die Integrationszeit viel zu kurz.


Fixier dich nicht auf den Conrad-Dekoder. Wie du ja vor kurzem 
darstelltest, hast du doch einen SAA6579. Was sagt der denn zu deinem 
Signal? Der hat doch einen Quality-Ausgang.
Nach meinen Forschungen ist da ne Schaltung drin, die die immer 
entgegengesetzte Polarität des Manchester-Signals auswertet. Ein Bit 
wird ja in zwei Teilbits übertragen und die müssen integriert genau Null 
ergeben. Das Ding zählt dazu mit einem höheren Takt die Pegelzustände 
aus. Und aktualisiert periodisch dann den Schaltausgang. Beim TDA7330 
jeweils nach 16 Bits. Mit irgendeinem sinnvollen Schwellwert verglichen 
- den ich nicht kenne.


Ich hoffe der Beitrag war ein konstruktiver Hinweis lol

[Bernhard S. (bernhard)]

@alle

Version-2 des RDS-Signal-Generators.

Er kommt mit einem 16MHz Quarz zurecht, Detlef ich danke Dir nochmals 
für die tolle Idee.

Der 57KHz Generator läuft im CTC-Modus, bekommt aber bei jedem Durchlauf 
einen neuen End-Wert, welcher in einer Tabelle hinterlegt ist.

Das analoge RDS-Ausgangssignal jittert etwas bei 16MHz Takt, aber aus 
meiner Sicht vertretbar, denn ein Conrad-RDS-Decoder kommt problemlos 
damit zurecht, stellenweise sind auch alle Balken für die 
RDS-Signalqualität sichtbar.

Ideal wäre ein Takt mit einem Vielfachen von 57kHz, dann müsste nur die 
Taktkorrektur im Programmcode deaktiviert werden.

Die Interruptroutine zur Generierung des RDS-Signals wird immer aus dem 
SLEEP-Modus heraus gestartet, um ein zusätzliches Jittern durch den 
Interruptaufruf zu unterbinden.

An anderen Decodern konnte ich die Schaltung noch nicht testen. Es kann 
sein, dass andere Decoder noch das 19kHz-Signal (Pilotton) benötigen.

In der Datentabelle sind die Gruppen für Stationsname, Radiotext und 
Uhrzeit hinterlegt, die fortlaufend gesendet werden.

@Abdul

>Fixier dich nicht auf den Conrad-Dekoder.

Da stimme ich Dir zu, hab nur gegenwärtig keine andere 
Decodiermöglichkeit. Mir ist aufgefallen, dass der Conrad-RDS-Manager 
ziemlich pingelig ist, selbst wenn der Empfangssender nur leicht 
verstimmt ist, werden die Balken für die Empfangsqualität sofort 
weniger.

Werde aber bei Gelegenheit einen kleinen UKW-Sender damit ansteuern und 
diverse Radios damit speisen.

Bernhard

[Bastler (Gast)]

Bernhard S. schrieb:
> Die Ausgangsfrequenz ist 57.000 Hz  +/- 1Hz.

Ist dein Quarz überhaupt so genau abgeglichen?
Die üblichen 30ppm ergeben schon eine Abweichung von fast 2 Hz.

[Bernhard S. (bernhard)]

> Ist dein Quarz überhaupt so genau abgeglichen?

ja, muss er aber nicht

> Die üblichen 30ppm ergeben schon eine Abweichung von fast 2 Hz.

bei 57.000kHz +/- 11 Hz kann der Conrad-RDS-Manager noch decodieren

[Abdul K. (ehydra)]

Bernhard S. schrieb:
> Da stimme ich Dir zu, hab nur gegenwärtig keine andere
> Decodiermöglichkeit. Mir ist aufgefallen, dass der Conrad-RDS-Manager
> ziemlich pingelig ist, selbst wenn der Empfangssender nur leicht
> verstimmt ist, werden die Balken für die Empfangsqualität sofort
> weniger.
>

Das ist seltsam, denn eine Frequenzverstimmung ändert bei FM nichts an 
der Lage der Unterträger (also hier RDS). Was sich verändert, ist 
eigentlich nur die Amplitude. Weiter weg überlagert es sich dann mit dem 
nächsten Nachbarsender und das S/N bricht zusammen.
Vielleicht ist der FM-Demodulator in deinem Empfänger recht 
asymmetrisch. (Ganz früher gabs mal den Trick, daß das Empfangssignal 
absichtlich nichtlinear verzerrt wurde und dann mit dem normalen damals 
eh vorhandenen Amplitudendemodulator für den AM-Bereich dekodiert wurde. 
Das würde sich dann so äußern)


> Werde aber bei Gelegenheit einen kleinen UKW-Sender damit ansteuern und
> diverse Radios damit speisen.
>

Wäre sinnvoll. Du kannst dir auch mal einen Dekoder mit ARI-Ausgang äh 
eigentlich SK-Ausgang besorgen und schauen, ob das Signal dauerhaft 
ordentlich aus ist. Wenn im Sender irgendwas mit der Modulation nicht 
stimmt, blinkt dieser Ausgang beim TDA7330 abundzu. Beim SAA6579 wurde 
diese Funktion bereits wegoptimiert.

[Bernhard S. (bernhard)]

@alle

mit wenigen Handgriffen konnte ich einern DDR-Tuner davon überzeugen, 
die RDS-Daten zu senden.

Der Gehäusedeckel musste nur geöffnet (bleiben) und die Kapazitätsdiode 
/ Varicap ausfindig gemacht werden.

Mit einem 10k Widerstand speiste ich das RDS-Signal (ca. 20mV) auf die 
Varicap.

Die Radios erkannten und decodierten sofort das RDS-Signal.

Es gibt mehrere Varianten diesen RDS-Signalgenerator zu nutzen,
ich stell mal 3 Varianten zur Verfügung.

DiePilottonübertragung habe ich mal weggelassen, kann sein, dass sie in 
der Praxis bei RDS nicht mehr erforderlich ist.


@Abdul

>Das ist seltsam, denn eine Frequenzverstimmung ändert bei FM nichts an
>der Lage der Unterträger (also hier RDS).

Mein Exemplar eines Onrad-RDS-Decoders mit einem SAA6579 ist an dieser 
Stelle etwas pingelig, ev. Phasenrauschen mag er nicht.

Bernhard

[Paul B. (paul_baumann)]

@Bernhard

Du mußt aber auch noch die Information mitsenden, welches Lied Du gerade
vor Freude über das Gelingen pfeifst.

Flücht
;-)
MfG Paul

[Bernhard S. (bernhard)]

Paul, leider gibt es PTY "in höchster Extase" nicht... :-)

Bernhard

[Detlef K. (adenin)]

http://www.youtube.com/watch?v=SaV-6qerkqI
;)

[Bernhard S. (bernhard)]

@alle

Die Version-3 berechnet die Rohdaten aus den zu sendenden Gruppen,
incl. CRC-Berechnung und bekam noch einen 19kHz-Ausgang spendiert.


Die zu sendenden Gruppen sind in der Tabelle in folgender Form 
hinterlegt:

.dw 0xD4F6,0x4400,0x0000,0xE684  ; ZEIT

Momentan ist noch eine weitere Version in Arbeit, per RS232 sollen bei 
Bedarf die Gruppen in den Signalgenerator geschoben werden.

Bernhard

[BM (Gast)]

Hallo Bernhard,
spannende Sache deine RDS Entwicklungen.
Lese deine RDS Beiträge ganz gespannt mit weil mich das Thema schon 
immer
interessiert hatte aber nie die Zeit fand mich tiefer damit zu 
beschäftigen.
Weiter so.


Markus

[Abdul K. (ehydra)]

Glückwunsch!
Sehe ich das richtig, der AVR demoduliert gleichzeitig den selbst 
gesendeten Datenstrom.
Was sendet er an Daten nun genau? Da steht im Display 'nur' BERNHARD.

[Bernhard S. (bernhard)]

@Markus

>Lese deine RDS Beiträge ganz gespannt

ich danke Dir für die Lobesworte :-)

>hatte aber nie die Zeit.....

Dieses RDS-Projekt liegt auch nun auch schon seit vielen Monaten bei mir 
auf dem Schreibtisch, hätte nie gedacht, dass es so ausartet.

Nachdem ein Problem gelöst war, tauschten plötzlich zwei neue Probleme 
auf z.B. Filterschaltungen, PLL, Frequenzerzeugungen


@Abdul

>Glückwunsch!

Danke :-)

>Sehe ich das richtig, der AVR demoduliert gleichzeitig den selbst
>gesendeten Datenstrom.

Ich würde es anders formulieren, er codiert. Es ist ein Codierer.

Jede RDS-Gruppe z.B. 4A (Zeit) besteht aus 64 Bit, also 8 Bytes 
(AH+AL+BH....DL).

Diese 8 Bytes werden aber vor der Übertragung codiert, jeder Block 
(2Bytes)mit 10 Prüfbits angereichert, Stichwort "Masterword" und 
Polynom, es entstehen die sogenannten Rohdaten.

Somit besteht jede gesendete Rohdaten-Gruppe aus 104 Bits 4*(16+10).

Dieses Bit-Gewurschtel wird später wieder decodiert, so dass die 
ursprünglichen 64 Bit wieder zur Verfügung stehen.

Der AVR erzeugt in diesem Thread die Rohdaten zur weiteren Verwendung.


>Was sendet er an Daten nun genau? Da steht im Display 'nur' BERNHARD.

Ein paar Gruppen-Beispieldaten habe ich in der Programmtabelle 
hinterlegt.

"BERNHARD" ist in diesem Fall der Stationsname bzw. Sendername 
Gruppentyp "0A".

Eine Uhrzeit wird auch gesendet GT "4A" und ein Text, aber den verrate 
ich nicht, wer es herausfindet, der bekommt von mir eine virtuelle Tüte 
Gummibärchen geschenkt :-)

Bernhard

[Abdul K. (ehydra)]

Danke für die Erkklärung! Damit sollte man durch den Assemblercode 
durchkommen.

[Bernhard S. (bernhard)]

@alle

Abdul gab mir für diese Version wertvolle Hinweise und Anregungen, ich 
danke Dir :-)

Theoretisch wäre ein Codierer und ein Decodierer in einem µC möglich, 
vermute aber, dass 16MHz Takt dafür nicht ausreichen, zu viele 
Rechenoperationen bei zu wenig Takten.

Die Version-4 kann ein sehr hilfreiches und interessantes Tool sein, sie 
kann folgendes:

- RDS-Daten werden aus der der internen Tabelle geladen und am analogen 
und digitalen RDS-Ausgang zur Verfügung gestellt.

- RDS-Daten können bei Bedarf per RS232 dem Codierer zugesendet werden, 
er schaltet automatsch von Daten-Tabelle auf USART um. Für diesen 
Gruppenpuffer stehen 256 Bytes zur Verfügung (32 Gruppen zu je 8 Bytes).
Leider jittert bei der RS232-Datenübertragung etwas das 
RDS-Ausgangssignal.

Das Übertragungsprotokoll ist relativ einfach (9 BYTES):
"*", AH, AL, BH...DL

Der interne Puffer wird geleert durch (9 BYTES):
"*",0,0,0,0,0,0,0,0

- Bei Betätigung der Tasten sendet der Codierer sofort NULLEN, EINSEN 
oder ein Bitmuster (als Rohdaten), somit kann die Übertragungsqualität, 
oder die Ursache falscher Rohdaten besser untersucht werden.

- Die Rohdaten liegen am analogen und digitalen RDS-Ausgang an.

- Die Rohdaten werden zusätzlich am TAKT und Data-Pin zur Verfügung 
gestellt.

Die grüne LED zeigt die rechenzeit an (Prüfbits usw,), die gelbe den 
USART-Modus und die rote LED Zeitüberschreitung in der Interruproutine.



Bernhard

[Philipp K. (philipp_k59)]

Ich finde das ist ein echt Klasse Projekt!

Ich möchte dieses nun nachbauen um eine Aussentemperatur im Radio 
anzuzeigen vielleicht via DS18B20, Diverse Kenntnisse sind schon 
vorhanden.. Asm leuchtet nur ein wenig ein.

Die Bauteile vom Schaltplan sind alle vorhanden.. Ich werde mich noch 
einige male durchlesen aber was ich mich jetzt gefragt habe, ist der 
Eingang 57khz noch nötig oder wird das über diese Tabellen vom Timer 
erledigt?

Bei Conrad kostet das RDS-Temperatur-Modul 70€ ...

Gruß, Philipp

[Abdul K. (ehydra)]

Die 57KHz erzeugt der AVR wie auch alles andere selber. Für 
Stereo-Übertragung fehlt aber wohl noch die Ankopplung an die 19KHz des 
Stereo-Encoders - wenn ich das richtig sehe. Geht also nur mit einem 
Kanal in Mono.

[Philipp K. (philipp_k59)]

Also brauche ich wenn ich das richtig verstehe einen FM-Transmitter der 
mir bei 57khz nicht hochraucht.. dachte da an z.B. eine Chinaplatine 
verkauft als Mikrofon-Transmitter für 5€.

[Abdul K. (ehydra)]

So weit ich das überblicke, genau.
Für Stereo müßte synchronisiert werden. Entweder der RDS-Encoder hängt 
sich an die 19KHz des Stereoencoders oder andersherum. Vielleicht gehts 
sogar ohne Beachtung der Norm dann unsynchronisiert. Empfang dann 
vielleicht nicht mit jedem Empfänger. Mit viel Pech könnte ich mir sogar 
ein ständiges Ein- und Ausrasten vorstellen.

Vielleicht sagt Bernhard noch was zu seinem Experiment mit dem 
DDR-Tuner.

[Paul Baumann (Gast)]

Abdul schrub:
>Mit viel Pech könnte ich mir sogar
>ein ständiges Ein- und Ausrasten vorstellen.

Von wem? Von der PLL oder von dem, der die Schaltung aufbaut?
;-)

MfG Paul

[Blödian (Gast)]

Paul Baumann schrieb:
> Abdul schrub:
>>Mit viel Pech könnte ich mir sogar
>>ein ständiges Ein- und Ausrasten vorstellen.
>
> Von wem? Von der PLL oder von dem, der die Schaltung aufbaut?
> ;-)
>
> MfG Paul

Mensch Paul, das ist ja der Reißer der Woche.

[Bernhard S. (bernhard)]

@alle

Thema RDS-Übertragung:

Es gibt 2 Prinzipielle-Übertragungsmöglichkeiten.

1. Die 57kHz-RDS-Daten werden ohne 19KHz-Pilotton übertragen

2. Die 57kHz-RDS-Daten werden mit 19KHz-Pilotton übertragen


Wichtig ist, ein RDS-Decoder muss "exakt" 57 kHz aus dem Eingangssignal 
zurückgewinnen können.

Manche nostalgische Decoder-Modelle brauchen die 19kHz noch, eine 
Frequenzverdreifacherschaltung erzeugt dann die 57Khz.

Der DECODER z.B. SAA6579 benötigt dazu nur das
57kHz-RDS-Daten-Rohdaten-Signal,
seine komplizierte PLL synchronisiert dann intern auf 57KHz.


>Vielleicht sagt Bernhard noch was zu seinem Experiment mit dem
>DDR-Tuner.

Ich modulierte den HF-Sender (ca. 100MHz) nur mit dem 
57kHz-RDS-Daten-Rohdaten-Signal und alle mir zur Verfügung stehenden 
RDS-Radios decodierten sofort.

Die Kapazitätsdiode der AFC modulierte das HF-Signal.

Monoübertragung mit RDS :-)

Sollten andere RDS-Decoder nicht decodieren, dann kann es sein, das der 
19kHz Pilotton erforderlich ist.

Einfach mit draufmodulieren, ev. ist die Phasenlage beider Signale zu 
beachten.


>Also brauche ich wenn ich das richtig verstehe einen FM-Transmitter der
>mir bei 57khz nicht hochraucht.. dachte da an z.B. eine Chinaplatine
>verkauft als Mikrofon-Transmitter für 5€.

Der FM-Transmitter darf in seiner Bandbreite nicht zu stark begrenzt 
sein, denn 57kHz muss er NF-seitig übertragen können.


>ist der Eingang 57khz noch nötig

nein, bei 16MHz Takt wird hinreichend genau das 57kHz Signal, durch die 
Tabellenwerte, generiert.


Bernhard

[Abdul K. (ehydra)]

Es ging ja um Stereo, wo die 19KHz gebraucht werden. Gibt sich ein 
junger Mensch überhaupt noch mit Mono zufrieden? Mein Nachwuchs sieht 
grundsätzlich keinen Film der in s/w ist. Egal was der Inhalt ist.

[Abdul K. (ehydra)]

Vielleicht könnte man das Projekt mit diesem Stereo-Encoder AVR 
verheiraten?
http://cappels.org/dproj/FM_MPX_STEREO/SIMPLE%20FM%20STEREO%20MULTIPLEX%20ENOCDER%20CIRCUIT.html

Ist natürlich nix für Apple-Hasser ;-))

[Bernhard S. (bernhard)]

@Abdul


>Vielleicht könnte man das Projekt mit diesem Stereo-Encoder AVR
>verheiraten?


Theoretisch prinzipiell möglich, denn 19 bzw. 38kHz kann der 
RDS-Signalgenerator problemlos nebenbei mit zur Verfügung stellen.

Es muss ja nur das Summensignal beider Kanäle und die Differenzsignale
(L-R und R-L) mit entsprechender 38kHz-Umschaltung zugemischt werden.

Bei der µC-Variante bezweifle ich die HIFI-Qualität, da die Samplingrate 
nicht sehr hoch sein wird.

Abdul, bist Du nicht auch der Meinung, dass Du Dich mit dieser Materie 
etwas tiefgründiger beschäftigen möchtest? ;-)

Wir würden uns sehr über eine analoge und / oder digitale Lösung 
erfreuen.

Bernhard

[Abdul K. (ehydra)]

Meine Frau ist da ganz anderer Meinung ;-)

Naja, vom AVR versteh ich nix ohne mich tief einzuarbeiten. Bliebe nur 
eine angestöpselte diskrete Lösung. Aber eigentlich gibts das ganze ja 
auch fertig z.B. von Silabs.

[Philipp K. (philipp_k59)]

Danke für die Tips, bin jetzt beim mmr-70, damit sollte mein Vorhaben 
klappen.

[Bernhard S. (bernhard)]

@alle

in der Version 5 ist die Drahtbrücke zwischen zwei Pins eliminiert 
worden, spart wertvolle Ressourcen :-)


- RDS-Daten werden aus der der internen Tabelle geladen und am analogen
und digitalen RDS-Ausgang zur Verfügung gestellt.

- RDS-Daten können bei Bedarf per RS232 dem Codierer zugesendet werden,
er schaltet automatsch von Daten-Tabelle auf USART um. Für diesen
Gruppenpuffer stehen 256 Bytes zur Verfügung (32 Gruppen zu je 8 Bytes).
Leider jittert bei der RS232-Datenübertragung etwas das
RDS-Ausgangssignal.

Das Übertragungsprotokoll ist relativ einfach (9 BYTES):
"*", AH, AL, BH...DL

Der interne Puffer wird geleert durch (9 BYTES):
"*",0,0,0,0,0,0,0,0

- Bei Betätigung der Tasten sendet der Codierer sofort NULLEN, EINSEN
oder ein Bitmuster (als Rohdaten), somit kann die Übertragungsqualität,
oder die Ursache falscher Rohdaten besser untersucht werden.

- Die Rohdaten liegen am analogen und digitalen RDS-Ausgang an.

- Die Rohdaten werden zusätzlich am TAKT und Data-Pin zur Verfügung
gestellt.

Die grüne LED zeigt die Rechenzeit an (Prüfbits usw,), die gelbe den
USART-Modus und die rote LED Zeitüberschreitung in der Interruproutine.



Bernhard

[Abdul K. (ehydra)]

Nur die Drahtbrücke, oder hab ich was überlesen?

Was macht eigentlich der Schalter "ein Bitmuster (als Rohdaten)" genau? 
Kannst du das bitte mal erläutern? Danke!

[Bernhard S. (bernhard)]

Nur die Drahtbrücke, somit entfällt der "störanfällige" externe 
Interrupt im Assemblerprogramm.

Der Timer erzeugt einen eigenen Interrupt im CTC-Modus bei jedem 
Flankenwechsel.

Bitmuster: NULL und EINS im Wechsel.

[Bernhard S. (bernhard)]

@alle

Version-6 und die fertige Platine.

Mit der Taste-C lässt sich die Betriebsart umschalten, RDS on/off,
19kHz on/off.

Ausgangswiderstand ca. 1k,
Pegel RDS ca. 20mV (Spitze), einstrellbar.
Pegel Pilotton ca. 40mV (Spitze), einstrellbar

Der Abgleich der 57kHz Filter ist nicht ganz einfach, den ersten Filter 
auf ca. 56kHz abgleichen, den zweiten auf ca. 58kHz, ein Oszi könnte 
sehr hilfreich sein.

Siehe Bescheibung Version-5.

Bernhard

[Abdul K. (ehydra)]

38KHz wäre vielleicht sinnvoller für die die selbst Stereo encodieren 
wollen.


Ich habe mal nachgeforscht wieso mein obiger Bericht vor einiger Zeit 
die Durchsagekennung als vorhanden beschrieb, aber offensichtlich die 
Erkenntnis ist das es kein ARI mehr gibt. Meine lokalen Sender hier 
haben auch alle kein ARI mehr drin. Habe mir deren Spektren angesehen 
mittlerweile angesehen. Sind allerdings nur so ca. 5 Stück sauber 
empfangbar. Wohne halt am Ende von DE wo man es nicht mehr für nötig 
empfindet die Bevölkerung mit Radio jenseits dreier 
Grundversorgungssender zu erheitern.
Also die Erklärung ist kurios einfach: Dieses 'Economy'-Radio (ein 
CAR200 von Grundig) hat zwar keine RDS-Anzeige und auch keine 
Funktionalität die man von RDS kennt, aber es hat ein RDS-Dekoder drin 
und das scheint ausschließlich dazu verwendet zu werden, das 
Vorhandensein der Infofelder im Datenstrom "Verkehrsfunk" und 
"Durchsagekennung" zu dekodieren. Das konnte ich natürlich nicht wissen 
oder erwarten. Das Licht ging auf beim Durchsehen dessen Schaltplans.

[Bernhard S. (bernhard)]

>38KHz wäre vielleicht sinnvoller für die die selbst Stereo encodieren
>wollen.

Damit würde ev. das 57kHz Signal zusehr jittern (+/-1µs),
man müsste mit Taktkorrekturen und zusätzlichen Interrupts arbeiten,
der µC mit seinen 16 Mhz ist etwas zu langsam dafür.

Lösung: Frequenzverdoppler, denn das 19kHz Signal ist relativ jitterfrei

[Bernhard S. (bernhard)]

@alle

Fertiges Projekt RDS-DECODER:


Beitrag "RDS DECODER selber bauen / Rohdatendecoder Eigenbau"

Bernhard

[Bernhard S. (bernhard)]

@alle

die Simulation in LTspice IV.

Die entsprechende Induktivität für die Schwingkreise wird automatisch 
berechnet.

Die Parallelkapazität Cp und die Resonanzfrequenz kann problemlos 
geändert werden.

Die erforderlichen Signale (19kHz  57kHz  RDS / Bitmuster) werden u.a. 
durch das Bauteil bv - Arbitrary Behavioral Voltage generiert.

Bernhard

[Flo (Gast)]

Hallo,

Vorab: Ja, ich weiß - der Thread ist schon etwas älter. Dennoch hoffe 
ich, dass ich eine sinnvolle Antwort bekomme.. :-)

Frage:
Ich habe hier einen (fertigen) Stereo-Encoder, der mir ebenfalls den 
19kHz-Pilotton bereitstellt. Weiterhin hat der Stereo-Encoder einen 
Eingang für die RDS-Signale. Kann (darf) ich nun diesen RDS-Encoder an 
den RDS-Eingang vom Stereo-Encoder anschließen, obwohl der Pilotton 
nicht synchonisiert ist?

Ich vermute mal, dass es hier zu Problemen kommen kann. Gibt es dafür 
eine (einfache) Lösung?

PS: Ich brauche nur das fertige MPX-Signal (Stereo + RDS) - und keinen 
All-In-One-FM-Transmitter vom Chinamann. :-)

[Nerd 8. (nerd81)]

Interessantes Projekt. :-)
Was ist das genau für eine Induktivität? Typ? Wert? Hersteller?

[Bernhard S. (bernhard)]

>Ich habe hier einen (fertigen) Stereo-Encoder, der mir ebenfalls den
>19kHz-Pilotton bereitstellt. Weiterhin hat der Stereo-Encoder einen
>Eingang für die RDS-Signale. Kann (darf) ich nun diesen RDS-Encoder an
>den RDS-Eingang vom Stereo-Encoder anschließen, obwohl der Pilotton
>nicht synchonisiert ist?

Ganz einfach. RDS ist auf 57KHz aufmoduliert.

siehe https://www.mikrocontroller.net/attachment/217046/SCAN_100kHz.jpg

19kHz dienen nur zur Synchronisierung und Bereitstellung
der 57kHz (3x19kHz).

Schau mal hier, so als Prinzip:

Beitrag "RDS ENCODER Signalgenerator Testgenerator Testsender Modulator ATmega8 Assembler"