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

[Bernhard S. (bernhard)]

Geschätztes Forum,

ich suche eine analoge RDS-Decoderschaltung zur Rohdatengewinnung, 
möchte bewusst auf diverese IC's verzichten..

Die RDS Daten werden um die 57kHz gesendet, im SCAN-Bild sind 2 
deutliche Pics erkennbar.

So richtig klar ist mir das Modulationsverfahren noch nicht, warum sind 
zwei Pics bei 57 kHz erkennbar?

Würde es genügen, wenn man diese RDS-Frequenzen mit einem einfachen
AM-Demodulator zurückgewinnt?

Danke

Bernhard

[oszi40 (Gast)]

http://de.wikipedia.org/wiki/Radio_Data_System
Ohne ICs wirst Du eine Kiste Transistoren brauchen. Siehe auch DIN EN 
62106

[Wolfgang H. (Firma: AknF) (wolfgang_horn)]

Hi, geschätzter Bernhard,

wenn es Dir nur um die Rohdaten geht, dann kriegst Du die auch mit 
einigen IC wie beispielsweise Mischer, CMOS-Multiplexer als Mischer, 
OpAmps und Exklusiv-Oder Gatter.

Denn RDS ist keine Hexerei, sondern aus dem Stereo-Piloten 19 kHz wird 
die dritte Oberwelle 57kHz entsprechend den Daten in der Phase gekippt 
um 180°.

Ob Du die 19 kHz und deren Phase mit einem MC1310 rekonstruierst oder 
die 57kHz in Real- und Imaginärteil zerlegst, das sei Deiner Phantasie 
überlassen, beides geht.

Sehr plausibel fand ich die Datenblätter SAA... von Philips/NXP, als die 
noch mindestens ein Blockschaltbild hatten.

Ciao
Wolfgang Horn

[Bernhard S. (bernhard)]

@Wolfgang

>Denn RDS ist keine Hexerei, sondern aus dem Stereo-Piloten 19 kHz wird
>die dritte Oberwelle 57kHz entsprechend den Daten in der Phase gekippt
>um 180°.

Ich dachte, die Phase wird nur um 90° gedreht?

Den Hinweis mit der dritten Oberwelle bin ich gleich nachgegangen.

Eine kleine Schaltung filtert den 19kHz Pilotton aus dem Multiplexsignal 
(MPX) heraus (T1+T2). Der T3 verstärkt zusätzlich und verzerrt das 19Khz 
Signal, die 3. Oberwelle, also 57kHz, wird über L3 und C6 
herausgefiltert und steht als Ausgangssignal zur Verfügung (ca. 200mV).

Die Phasenlage des 57kHz Ausgangssignal ändert sich etwas in 
Abhängigkeit der Verstimmung der einzelnen Filter. Hoffentlich wird 
diese Erscheinung nicht später zum Problem.

Theoretisch müsste jetzt das 57KHz-Signal mit dem MPX-Signal im Bereich 
von 57kHz verglichen und ausgewertet werden, oder?



>Ob Du die 19 kHz und deren Phase mit einem MC1310 rekonstruierst oder
>die 57kHz in Real- und Imaginärteil zerlegst, das sei Deiner Phantasie
>überlassen, beides geht.

Vielleicht könnte man das RDS-Signal auch runter mischen und 
anschließend digital abtasten und auswerten?


>Sehr plausibel fand ich die Datenblätter SAA... von Philips/NXP, als die
>noch mindestens ein Blockschaltbild hatten.

Schade, ich fand nirgens ein Datenblatt dazu.


Bernhard

[Michael M. (michaelm)]

Hier sind u.a. ein paar "SAAxxx" -RDS-Decoder:
http://elcodis.com/searchparts/philips_saa.html
EDIT: oder dieser: http://www.nxp.com/documents/data_sheet/SAA6579.pdf

[Bernhard S. (bernhard)]

@alle

Bei diesem Versuchsaufbau wurde das aus dem 19kHz generierte 57kHz 
Signal mit dem MPX-Signal verglichen.

Das MPX-Signal wurde nur durch einen einfachen 57kHz Bandfilter 
aufbereitet.

Es entstanden diese Oszillogramme.

Kann es vielleicht sein, wenn beide Phasen gleich sind, dann entspricht 
das einer "NULL", sind sie ungleich dann ist es eine "EINS".

@Michael M.

Ich danke Dir.


Bernhard

[Wolfgang H. (Firma: AknF) (wolfgang_horn)]

Sehr schön, Bernhard, so fix? Du Fechtmeister mit dem Lötkolben...

> Kann es vielleicht sein, wenn beide Phasen gleich sind, dann entspricht
> das einer "NULL", sind sie ungleich dann ist es eine "EINS".
Daa gibt nicht mal das Blockschaltbild her, das Michael gefunden hat. 
Bloss "Biphase" - was ja auch zu erwarten war wegen seiner Einfachheit - 
wozu mehr entwickeln, als notwendig?
Die Vorschrift informiert bestimmt über die relative Phasenlage zwischen 
Takt und Symbol.

Ich erinnere mich an eine Diplomarbeit - lang, lang ist es her, als GPS 
noch unerschwinglich war für Automotiv - da gab es eine Diplomarbeit 
einer FH im Einzugsbereich von Wolfsburg, ob Kfz navigieren könnten 
durch Vergleich der RDS-Phasen verschiedener UKW-Sender. Ergebnis: Im 
Prinzip ja, praktisch kaum wegen der vielen UKW-Umsetzer. Ich meine, die 
in einer Ausgabe der DGON gelesen zu haben, "Deutsche Gesellschaft für 
Ortung und Navigation".

Zumindest im Einzugsbereich des Fernsehturms München wirst Du wohl 
feststellen können, ob du auf ihn zu, oder von ihm  wegfährst ...

Ciao
Wolfgang Horn

[Martin M. (capiman)]

Interessanter Thread!

Ich habe leider in dieser Richtung noch gar nichts gemacht,
aber mit ist eingefallen, dass es diverse SDR Software gibt,
die RDS dekodieren kann. Ich habe gerade mal nach "SDR RDS" gesucht
und darunter folgende Seite gefunden:

http://www. anothe rurl.c om/library/sdr/sdrrds.htm

(Spaces in der URL entfernen)

Vielleicht hilft dir das Bild mit
"Now that I'm a self-certified DSP GNU Radio Companion expert, I tackle 
the RDS DSP..."
oder
"... that yields the 57kHz subcarrier."

weiter oder der Autor dieser Seite
oder einer der Autoren der anderen SDR-RDS-Software-Lösungen
kann dir weiterhelfen?

[Bernhard S. (bernhard)]

@Martin

Danke für Deinen Link.

Dort fand ich die USA RDS Spezifikation:
ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf

Ich vermute die DIN EN 62106, Spezifikation des Radio-Daten-Systems ist 
ähnlich. Versuch sie gerade bei Beuth zu bestellen

@Wolfgang

>Daa gibt nicht mal das Blockschaltbild her, das Michael gefunden hat.
>Bloss "Biphase" - was ja auch zu erwarten war wegen seiner Einfachheit

Kann sein, dass es wirklich so "einfach" ist.

Als nächstes würde ich gern einen µC zum Einsatz bringen.

Er soll einen Interrupt bei jeder 57kHz-Schwingung auslösen und sofort 
das aufbereitete MPX-Signal abtasten (nur HIGH-LOW Bestimmung).
Und anschließend den BIT-Strom und den Takt generieren.

Die angehängte Schaltung bringt schon PEGEL im TTL-Bereich, ev ist noch 
eine leichte Verstärkung des Eingangssignals erforderlich.


>Die Vorschrift informiert bestimmt über die relative Phasenlage zwischen
>Takt und Symbol.

Kämpfe mich gerade durch die USA-Vorschrift durch:

ftp://ftp.rds.org.uk/pub/acrobat/rbds1998.pdf

Bin aber noch nicht so richtig fündig geworden.

Was mir noch unklar ist, meine momentan einfache Schaltung, generiert 
das 57kHz Signal und bereitet das MPX-Signal im Bereich von 57kHz auf, 
die Qualität der Signale ist relativ gut, die Phasenlage beider Signale 
ist gut erkennbar.

Könnte jetzt schon der Bitstrom und der Takt generiert werden, oder 
müsste zusätzlich noch eine Mischung o.ä. realisiert werden?


Danke



Bernhard

[Jobst M. (jobstens-de)]

Hier mal ein Datenblatt dazu. Leider nur als Hardware vorhanden, deshalb 
abfotografiert ...
Ansonsten steht darin noch die Organisation der Daten - wenn auch daran 
Interesse besteht, bitte hier äussern. Wären dann nochmal 11 Seiten

Edit: Ach Mist, jetzt habe ich das Deckblatt auch hochgeladen ... :-/


Gruß

Jobst

[Martin M. (capiman)]

Was ist der Unterschied zwischen Bild 7 und Bild 8?
Beides im img_9498.gif

Im US-Dokument auf Seite 7 sind ähnliche Kurven,
die vielleicht hilfreich sind.

[Harald W. (wilhelms)]

Jobst M. schrieb:

> Edit: Ach Mist, jetzt habe ich das Deckblatt auch hochgeladen ... :-/

Auweia: Schleichwerbung für die ARD! :-)

[Jobst M. (jobstens-de)]

Martin Maurer schrieb:
> Was ist der Unterschied zwischen Bild 7 und Bild 8?

Steht drunter. Und wenn man sich den Unterschied in der Hüllkurve 
gaaaaanz genau ansieht, dann sieht man es auch ... ;-)


Gruß

Jobst

[Martin M. (capiman)]

@Jobst:
Beschreib doch bitte mal kurz! Sind es die Rundungen und Spitzen?
Oder will es abwechselnd einmal rund und einmal spitz ist,
beim anderen nicht?
Und kann man dies leicht durch Hardware und/oder Software
herausbekommen?

[ArnoR (Gast)]

Bernhard S. schrieb:
> Die angehängte Schaltung bringt schon PEGEL im TTL-Bereich, ev ist noch
> eine leichte Verstärkung des Eingangssignals erforderlich.

Die angehängte Schaltung ist Murks. T2 verstärkt doch nur die 19kHz und 
dämpft die 57kHz. Viel besser wäre es, das Gate von T3 an MP5 
anzuschließen.

[Wolfgang H. (Firma: AknF) (wolfgang_horn)]

Hi, Bernhard,

> Er soll einen Interrupt bei jeder 57kHz-Schwingung auslösen und sofort
> das aufbereitete MPX-Signal abtasten ...

> Könnte jetzt schon der Bitstrom und der Takt generiert werden, oder
> müsste zusätzlich noch eine Mischung o.ä. realisiert werden?

Dene phasensynchrone Abtastung ist bereits die Mischung.

Ciao
Wolfgang Horn

[Jobst M. (jobstens-de)]

Martin Maurer schrieb:
> Sind es die Rundungen und Spitzen?

Genau.
Bild 3 und Bild 7 passen zusammen, Bild 4 und Bild 8 passen zusammen.
Nun dürfte es klar werden.
Was dazwischen stört, ist das Verkehrsfunksignal.
Du musst also eine Quadraturdemodulation machen!
Edit: zumindest eine halbe.


Gruß

Jobst

[DokArkan (Gast)]

Harald Wilhelms schrieb:
> Jobst M. schrieb:
>
>> Edit: Ach Mist, jetzt habe ich das Deckblatt auch hochgeladen ... :-/
>
> Auweia: Schleichwerbung für die ARD! :-)

jetzt müssen alle Extragebühren bezahlen :-P

[Jobst M. (jobstens-de)]

Eigentlich ging es mir um die unnötigen 50kB ...
... und hat auch noch die meisten Downloads ...

Hallo, kann ein MOD mal Bild img_9493.gif entfernen!?

[Jörg W. (dl8dtl) (Moderator)]

Jobst M. schrieb:
> Hallo, kann ein MOD mal Bild img_9493.gif entfernen!?

Nö, lass mal: das finde ich als Quellenangabe ganz sinnvoll so.

[Uwe N. (ulegan)]

Der Verkehrsfunk stört übrigens seit 2007 nicht mehr. Damals wurde das 
ARI-Signal abgeschaltet.

Gruß
Uwe

[Christian B. (casandro)]

Ich würde da auch erstmal das 57kHz "Pilot"-Signal sauber kriegen. Wenn 
das ein sauberer Sinus ist, sollte es reichen das einfach zum sauberen 
RDS-Signal (hast Du ja schon) addieren und die Hüllkurve bilden.
Die sollte dann schon alles enthalten. DC-raus, tiefpassen und mit einen 
Schwellwert detektieren.

Dann musst Du die Biphase-Dekodierung rückgängig machen. Der Takt ist 
übrigens 19kHz/16. Meines Wissens nach erfolgt die weitere Dekodierung 
dadurch, dass Du ein 26-stufiges Schieberegister hast, und an dessen 
parallelen Ausgang einen Dekoder für die Daten. Das is ein linearer 
Code, dessen Details ich jetzt nicht weiß. Anscheinend werden bestimmte 
Syndrome zur Erkennung der Art des Blockes verwendet.

[Bernhard S. (bernhard)]

@ArnoR(GAST)

>Die angehängte Schaltung ist Murks. T2 verstärkt doch nur die 19kHz und
>dämpft die 57kHz. Viel besser wäre es, das Gate von T3 an MP5
>anzuschließen.


T2 soll nur die 19kHz-Pilotton verstärken und nichts anderes. Erst T3 
erzeugt, durch seine Übersteuerung Oberwellen, wovon nur die 2. 
Oberwelle, also die 57kHz genutzt wird. Somit erhält man exakt die 
dreifache Frequenz vom Pilotton.

Beweis: s. Oszillogramme

Und, ist die Schaltung zur Erzeugung des phasengetreuen 57kHz-Signals 
aus dem 19kHz-Pilotton immer noch Murks?

[ArnoR (Gast)]

Bernhard S. schrieb:
> T2 soll nur die 19kHz-Pilotton verstärken...

Nehme alles zurück und behaupte das Gegenteil ;-), ich hatte den Zusatz 
"Verdreifacher" übersehen und gedacht, dass du die 57kHz aus dem 
MPX-Signal (Signal an MP5) verstärken wolltest.

[Bernhard S. (bernhard)]

@alle

ein ganz großes Dankeschön an Euch, sehr viele und sehr interssante 
Hinweise und Tipps wurde hier formuliert.

Einige Aspekte stehen zwar noch offen im Raum, dazu kommen wir später 
noch.

Ich habe hier mal meherere Oszi-Bilder aneinandergehängt.

Man erkennt sehr deutlich die Phasenverschiebung zwischen dem 
57kHz-Signal (aus Pilotton) und dem MPX-Signal.

Die Amltude des MPX-Signals nimmt ab, anschließend ändert sich die 
Phase.
Kann es sein, dass ARI doch noch gesendet wird, denn MPX und 57kHz 
besitzen keine Phasenverschiebung?

In der Phasenverschiebung beider Signale sind die einzelnen RDS-Bits 
versteckt. Doch wie kann man den 1187,5Hz Takt synchronisieren?

Mir ist aufgefallen, bei genauer Frequenzmessung, dass der 19kHz 
Pilotton nicht bei allen Sendern exakt 19.000,0 Hz beträgt. Schade, eine 
Kalbrierung eines Frequenzzählers ist somit kaum möglich.

Bernhard

[Bernhard S. (bernhard)]

Hallo Wolfgang

>Deine phasensynchrone Abtastung ist bereits die Mischung.


Der Sache gehe ich mal nach. Je ein LM311 könnte den Nulldurchgang der 
Signale (57kHz/MPX) registrieren, ein µC misst die Zeitverschiebung 
beider Phasen.

Bernhard

[Jobst M. (jobstens-de)]

Bernhard S. schrieb:
> ZUSAMMENFASSUNG.JPG

Das ist aber trotzdem noch unbrauchbar, was dort ankommt ...

Du sprichst auch immer vom MPX-Signal. Mit MPX ist aber das Gesamtsignal 
aus Mono, 19kHz, Stereodifferenz, ARI/RDS, ... gemeint. Urspünglich 
sogar nur das Signal zur Übertragung des Stereosignals.

Während ich das Signal bei Deinen beiden roten Kreisen und auch den 
Phasenwechsel bei Deinem gelben Pfeil bis etwa Bildmitte als '0' 
erkennen würde, folgt danach irgendwie Quark.

Das Signal sollte wie in Bild 10 (von meinem img_9499.gif) aussehen.
Die vielen Phasenwechsel in Deinem Bild ab etwa Bildmitte bis 2/3 
sollten dort mit und ohne ARI nicht sein.

Mit ARI solltest Du allerdings kontinuierlich mehr Pegel haben. Auch 
muss Deine Phasenbeziehung ja nicht stimmen. Du musst Deine Phase 
abgleichen können. Das ist im Moment allerdings gar nicht Dein Problem. 
Dein Problem ist momentan die Filterung der RDS-Daten. Ich kann Dir 
allerdings nicht sagen, woran das liegt. Evtl. an Deinem Filter?

Ach ja: Radio Hamburg ist der weltweit letzte Sender mit ARI.

Das hier ist mir noch in die Finger gefallen: 
http://www.freepatentsonline.com/6661292.html


Gruß

Jobst

[Ralph T. (programinator)]

Interessanter Thread.
Nur ein kleiner Hinweis. Es besteht keine technische Notwendigkeit, dass 
Piloton und RDS-Träger phasensynchron laufen müssen. Dies war m.W.n. 
eine eher deutsche Forderung der ARD und MediaBroadcast, um den 
Frequenzhub zu optimieren. D.h. mehr MPX-Pegel bei gleichem Frequenzhub. 
Entsprechend findet man noch erstaunlich viele Anstalten, die auf eine 
Synchronisation verzichten. Dies ist insbesondere im Ausland der Fall, 
so dass es für deine Experimente keine große Rolle spielen sollte.
Übrigens: das RDS wird in den meisten IC- und SDR-Lösungen (siehe 
SAA6588, Si47xx, ...) ohne Vorhandensein eines 19kHz dekodiert. Silabs 
musste damals im Si4701 sogar noch nachbessern...

[Jobst M. (jobstens-de)]

Irgendwoher benötigt man aber den 57kHz-Träger.
Entweder restauriert man sich den aus dem Signal, was recht aufwändig 
ist und zu Zeiten des ARI sogar problematisch bis unmöglich oder man 
generiert ihn sich aus den 19kHz, welche dazu Phasenverkoppelt sein 
müssen.
Ohne phasenkorrekten Träger ist eine Quadraturdemodulation nicht 
möglich.

Ich kann mir nicht vorstellen, dass das genau so wie von Dir 
beschrieben, in anderen Ländern funktionieren soll.
Die Datenblätter werde ich mir heute Abend mal ansehen.


Gruß

Jobst

[Ralph T. (programinator)]

Ralph T. schrieb:
> Übrigens: das RDS wird in den meisten IC- und SDR-Lösungen (siehe
> SAA6588, Si47xx, ...) ohne Vorhandensein eines 19kHz dekodiert.

Sorry, war falsch formuliert. Gemeint war: Das RDS wird ... auch mit 
fehlender Synchronisation zw. 19kHz und RDS dekodiert. Wir nennen dieses 
immer "laufende Phase", weil auf dem Scope der Pilot und das RDS 
(anschaulicher ist es mit einem reinen ARI-Träger ohne DK und BK) schon 
aneinander vorbei laufen.

[Helmut L. (helmi1)]

Um das RDS Signal (PSK) zu dekodieren wird meistens eine Costas Loop 
verwendet.

http://de.wikipedia.org/wiki/Costas_Loop

[Bernhard S. (bernhard)]

@Jobst

>Ansonsten steht darin noch die Organisation der Daten - wenn auch daran
>Interesse besteht, bitte hier äussern. Wären dann nochmal 11 Seiten

Stell Sie uns mal bitte noch zur Verügung, könnten nützlich sein.


>Du sprichst auch immer vom MPX-Signal. Mit MPX ist aber das Gesamtsignal
>aus Mono, 19kHz, Stereodifferenz, ARI/RDS, ... gemeint.

Da gebe ich Dir Recht, MPX ist das Geamtsignal.

Wird das Gesamtsignal gefiltert, z.B. durch einen Bandpass, dann sollte 
es etwas anders Bezeichnet werden, stiftet sonst nur Verwirrung.


>Während ich das Signal bei Deinen beiden roten Kreisen und auch den
>Phasenwechsel bei Deinem gelben Pfeil bis etwa Bildmitte als '0'
>erkennen würde, folgt danach irgendwie Quark.


Vermutlich ist dieser "Quark" sogar korrekt, denn es handelt sich um 
eine Modulation mit unterdrücktem Träger, d.h. liegt keine Information 
vor, dann wird auch kein Träger gesendet, so würde ich es momentan 
deuten.


Bernhard

[Bernhard S. (bernhard)]

@Ralph

>Nur ein kleiner Hinweis. Es besteht keine technische Notwendigkeit, dass
>Piloton und RDS-Träger phasensynchron laufen müssen.

Das bestätigt meine Vermutung. Hatte die Tage an dieser Schaltung am 
Eingang des SAA6579 nur ein 57KHz-Signal mit "laufender Phase" 
gemessen.

Beitrag "Schaltplan CONRAD RDS Manager gesucht"
(Leider fehlt mir immer noch der Schaltplan)

Ich vermute, die drei vorgeschalteten Filter, filtern die 57-KHz RDS 
Anteile sehr gut aus dem MPX-Signal heraus.

Bernhard

[Jobst M. (jobstens-de)]

Jobst M. schrieb:
> Ich kann mir nicht vorstellen, dass das genau so wie von Dir
> beschrieben, in anderen Ländern funktionieren soll.

Helmut Lenzen schrieb:
> Um das RDS Signal (PSK) zu dekodieren wird meistens eine Costas Loop
> verwendet.

Man lernt nie aus. Die Funktionsweise muss ich jetzt aber erst mal 
nachvollziehen :-)


Ralph T. schrieb:
> Ralph T. schrieb:
>> Übrigens: das RDS wird in den meisten IC- und SDR-Lösungen (siehe
>> SAA6588, Si47xx, ...) ohne Vorhandensein eines 19kHz dekodiert.
>
> Sorry, war falsch formuliert. Gemeint war: Das RDS wird ... auch mit
> fehlender Synchronisation zw. 19kHz und RDS dekodiert. Wir nennen dieses

Nö, war demnach korrekt formuliert. 19kHz ist unwichtig, wenn nicht 
syncron.


Bernhard S. schrieb:
> Stell Sie uns mal bitte noch zur Verügung, könnten nützlich sein.

Da. :-)


Bernhard S. schrieb:
> Vermutlich ist dieser "Quark" sogar korrekt, denn es handelt sich um
> eine Modulation mit unterdrücktem Träger, d.h. liegt keine Information
> vor, dann wird auch kein Träger gesendet, so würde ich es momentan
> deuten.

Nein, eine AM ohne Träger hat gerade bei binärer Modulation immer ein 
Signal. Entweder positive Phase oder negative Phase.
Im Bild AMmT_u_AMoT.png sieht man die Addition der beiden Seitenbänder 
in rot (Zwei Sinuswellen, Träger + Offset und Träger - Offset) und in 
grün den Träger auch mit hinzuaddiert. (Siehe auch Funktion oben rechts 
im Bild)


Gruß

Jobst

[Ralph T. (programinator)]

Google mal nach der en50067. Die Ausgabe von 1998 war bei mir gleich der 
erste Treffer...

[Bernhard S. (bernhard)]

@alle

Einige Messungen am SAA6579.

Eingangspin, Taktausgang und Datenausgang.

Man erkennt sehr deutlich am eingang das 57kHz gefilterte MPX Signal

Bernhard

[Bernhard S. (bernhard)]

...interessant sind auch die RDS Patente:

https://www.google.de/patents/EP1241815A2?cl=de&dq=rds&hl=de&sa=

[Petra (Gast)]

Hier steht sicherlich auch interessantes drinn:
http://www.ko4bb.com/Manuals/Rohde_Schwarz/Rhode_Schwarz_DMC01_OM.pdf

[Bernhard S. (bernhard)]

@alle

Auf diesen Seiten fand ich sehr nützliche Informationen zur 
Ampltudenmodulation mit und ohne unterdrücktem Träger und deren 
Phasenlage.

http://elektroniktutor.de/signalkunde/sinflash.html
http://www.dj4uf.de/lehrg/a12/a12.html

Im OSZI-Bild "Zusammenfassung_Ausschnitt" erkennt man deutlich den 
Phasenwechsel des RDS-Signals, es handelt sich um die positive und 
negative Halbwelle des RDS-Signals, das ist ein typisches 
Biphase-Symbol.

Momentan programmiere ich in Assembler einen Atmega8, der die Phasenlage 
beider Signale (57kHz / gefiltertes MPX-Signal) untersucht und 
decodiert.

Die ersten Gehversuche verliefen sehr vielversprechend.

Den Takt generiere ich aus den 57kHz (57.000Hz:48 = 1.187,5Hz),
damit ist der RDS-Takt unabhängig vom µC-Takt.

Bernhard

[Jobst M. (jobstens-de)]

Soweit korrekt, aber wie erklärst Du Dir, was dahinter kommt?

http://www.mikrocontroller.net/attachment/203229/ZUSAMMENFASSUNG.JPG

Bei ordentlichem Signal dürfte das was dahinter kommt ja gar nicht 
vorkommen.



Gruß

Jobst

[Bernhard S. (bernhard)]

@JOBST


>Bei ordentlichem Signal dürfte das was dahinter kommt ja gar nicht
>vorkommen.

Das ist korrekt, vermutlich hatte ich keinen RDS-würdigen Sender 
oszillographiert.

In der XLS-Datei ist ein aktueller Mitschnitt eines nicht verrauschten 
Senders.

Der µC vergleicht 1000 Perioden des 57kHz Signals mit dem RDS-Signal, 
legt das Ergebnis im SRAM ab, ist der SRAM voll, dann stoppt die 
Prozedur und die Daten werden per USART (RS232) an den PC gesendet.

Ein LIFE-Mittschnitt ist leider bei 56k Baud nicht möglich.

Man erkennt sehr schön, dass ein Biphase-Symbol aus 48 x 57kHz Takten 
besteht, 24 Takte positive Halbwelle, 24 für eine negative.

Die Reihenfolge der Halbwellen ist für die spätere Decodierung wichtig.

Der Phasenwechsel ist interessant, tritt bei jedem Biphase-Symbol auf, 
er kann zur Synchronisation des Taktes verwendet werden. Wenn ich mich 
nicht irre, hat sich jemand diese Eigenschaft sogar patentieren lassen.


Bernhard

[Bernhard S. (bernhard)]

@alle

an den Ausgangspins eines SAA6579 habe ich den Takt und DATA 
abgegriffen, parallel dazu die Phasenlage des RDS-SIGNALS (rote Kurve).

Ist RDS=HIGH (rote Kurve), dann sind die Phasen (57kHz und RDS-Signal) 
nahezu gleich, bei RDS=LOW wurde eine Phasenverschiebung durch einen µC 
ermittelt.

Erkennt jemand von Euch einen Zusammenhang Phasenlage und dem DATA ?

Es gibt sicherlich eine Zeitverschiebung beider Signale, da die 
Phasenlage "ohne" Zeitverzögerung ermittelt wird.


Bernhard

[Jobst M. (jobstens-de)]

Bernhard S. schrieb:
> Erkennt jemand von Euch einen Zusammenhang Phasenlage und dem DATA ?

Joa.

Du nun auch?


Gruß

Jobst

[Bernhard S. (bernhard)]

@Jobst

@alle


>> Erkennt jemand von Euch einen Zusammenhang Phasenlage und dem DATA ?
>Du nun auch?

ja, endlich, manche Dinge brauchen etwas Zeit :-)


Fakt 1:

Das RDS-Signal ist so aufgebaut, dass bei jedem Takt 
(57kHz:48=1.187,5Hz)
eine andere Phasenlage entsteht (Manchester Codierung).

Die Phasenlage kennzeichnet bei der Demodulation die positive bzw. 
negative Halbwelle.


Fakt 2:

Entsteht, meistens ziemlich mittig, zwischen den Takt-Phasenwechseln ein 
weiterer Phasenwechsel, dann wurde ein NULL (ROHDATEN-BIT) gesendet 
bzw.empfangen.

Bleibt die Phase während einer Taktperiode gleich, dann ist es eine EINS 
(ROHDATEN-BIT).

Das Bild "img_9497.gif" vereutlicht bestimmt diesen Sachverhalt.
http://www.mikrocontroller.net/attachment/202869/img_9497.gif

Fakt 3:

Ein Takt besteht aus 48 x 57Khz Schwingungen.


Fakt 4:

Die Anzahl aller phasengleichen Schwingungen während einer Taktperiode
ist im Idealfall 0, 24 oder 48.

Wäre eventuell ein Kriterium um die Qualität des RDS-Empfangs zu 
beurteilen.

Anmerkung:

Der Rohdaten-Decoder muss demnach zuerst den Takt generieren, erst dann 
kann das Rohdaten-Bit ermittelt werden.
Ich hänge mal ein Excel-Beispiel mit an.

Im Bild
http://www.mikrocontroller.net/attachment/205331/MESSUNG_SA6579_ZOOM.JPG

sind die Takt-Phasenwechsel durch einen gelben Punkt markiert, die 
Phasenwechsel in einer Taktperiode mit Rot.

Bernhard

[Jobst M. (jobstens-de)]

Bernhard S. schrieb:
> Fakt 1:
> Fakt 2:

Eigentlich gibt es bei einer 0 keinen Phasenwechsel am Bitanfang, bei 1 
aber schon. In Bitmitte bei beiden Zuständen jedoch immer.
Diese Feinheit ist aber zur Demodulation (und zum Verständnis) 
nebensächlich, da es praktisch auf das von Dir beschriebene hinausläuft. 
Man kann dies allerdings auch ganz gut in 
http://www.mikrocontroller.net/attachment/202872/img_9506.gif 
nachvollziehen.

Auch sonst bestätigt es alle Deine Erkenntnisse.


Bernhard S. schrieb:
> Der Rohdaten-Decoder muss demnach zuerst den Takt generieren, erst dann
> kann das Rohdaten-Bit ermittelt werden.

Das ist bei einer AM ohne Träger immer so :-)


Sieht aber schon ganz gut aus - finde ich!
So wie Du an die Sache herangehst, wird es nicht mehr lange dauern bis 
die fertigen Bits aus dem Controller purzeln ...



Gruß

Jobst

[Bernhard S. (bernhard)]

@alle

... die ersten brauchbaren Bits purzeln nun aus dem ATmega8 :-)

Das Programm RDS-SPY konnte die Ausgangsdaten des ATmega8 decodieren.


Jobst, ich danke Dir für Deine lobenden Worte.


Große Probleme hatte ich mit der Synchronisierung des Taktes, der 
Decoder wollte ewig nicht "einrasten", eine LED zeigte mir diesen 
unschönen Zustand an.

Gezielt wird nach einem permanenten Phasenwechsel zu Beginn eines 
BI-Phasen-Symbols gesucht.

Findet er den Phasenwechsel nicht, dann wartet er etwas ab, denn das 
RDS-Eingangssignal könnte kurzzeitig gestört sein und erst dann schiebt 
er den TAKT ganz vorsichtig.

Meine Erfahrung ist die, dass der Fangbereich relativ groß gewählt 
werden sollte, denn das getriggerte Ausgangssignal der Analogschaltung 
jittert etwas.

Was mir momentan noch unklar beim SAA6579 ist, müssen die Ausgangsdaten 
bei steigender oder fallender Flanke des Taktes übernommen werden?


Gruß

Bernhard

[Jobst M. (jobstens-de)]

Na bitte! :-)


Bernhard S. schrieb:
> Was mir momentan noch unklar beim SAA6579 ist, müssen die Ausgangsdaten
> bei steigender oder fallender Flanke des Taktes übernommen werden?

Ich würde die Flanke wählen, die am weitesten von den Flanken auf der 
Datenleitung entfernt ist.



Gruß

Jobst

[Abdul K. (ehydra)]

Wie siehts aus, wenn du das S/N verschlechterst? Wer ist dann besser?

[Bernhard S. (bernhard)]

@alle

ich habe den RDS-Filter (57KHz) etwas aufwändiger gestaltet und 
anschließend einige Messungen vorgenommen.

Mir ist aufgefallen, immer wenn ein "großer Berg", also eine 842µs 
lange (1/57.000Hz x 48) Halbwelle entsteht, egal ob positive oder 
negativ, entspricht es einem Radiodatenbit "1".

Habe diese Erscheining im "img_9506_B.gif" farblich markiert.

Ein Phasenenwechsel ist immer mittig in einem Taktzyklus, deutlich zu 
erkennen am Einbruch der Amplitude des RDS-Signals.

Demnach ist es nicht zwingend erforderlich, den Hifsträger (3x19kHz) zu 
generieren, eine einfache AM-Demodulation würde theoretisch genügen.



@Abdul

>Wie siehts aus, wenn du das S/N verschlechterst? Wer ist dann besser?


Der Hardwareaufwand ist nach meiner momentanen Meinung entscheidend, das 
RDS-Signal muss qualitativ hochwertig herausgefiltert werden, ein stark 
verrauschtes RDS-Signal, oder mit Oberwellen behaftetes Signal aus den 
unteren Frequenzbereichen, macht die Decodierung, mathematisch gesehen, 
unmöglich.

Vielleicht hilft auch ein Korrelationsverfahren bei der Decodierung.

Bernhard

[Abdul K. (ehydra)]

Diese Beulen kommen vermutlich von einem zu schmalen Filter bzw. die 
Gruppenlaufzeit ist eher schlecht. Könnte man auch an der Sprungantwort 
festmachen.

Messe die Bitfehlerrate und wenn die runtergeht wenn du die Filter 
breitbandiger machst, dann ist es genau dieser Effekt.

Wahrscheinlich müßte man die Filter lockerer koppeln. Ich bin aber kein 
Experte für Analogfilter.

[Bernhard S. (bernhard)]

@ Abdul

die Sprungantwort einer Filterschaltung ist ein sehr interessantes 
Thema,
guter Tipp, danke.


Diese Schaltung habe ich mal durchgemessen:

http://www.mikrocontroller.net/attachment/206498/BILD_RDS_FILTER.JPG
http://www.mikrocontroller.net/attachment/206499/SCHALTUNG_57kHz_FILTER.pdf

Der zeitliche Verlauf der einzelnen Kollektorspannungen sind in den 
Bildern dargestellt.


Man erkennt sehr deutlich, was das Rechtecksignal (am Eingang von T1) in 
jeder Filterstufe bewirkt.

Thema RDS-Decodierung:

Natürlich bewirkt eine solche Filterschaltung eine zeitliche 
Verschiebung des RDS-Signals, ist aber nicht tragisch, wenn das 
Bi-Phase-Symbol einige µs später decodiert werden kann.



Bernhard

[Abdul K. (ehydra)]

Du brauchst eine konstante Gruppenlaufzeit(GLZ) innerhalb der 
notwendigen Bandbreite des Signals. Die kann man aus der Sprungantwort 
berechnen oder eben auch anders messen.
Am einfachsten realisierbar über Simulation z.B. in LTspice. Die GLZ 
kannst du dir dort im Phasengang direkt anzeigen lassen.

Ist die Laufzeit nicht für alle Frequenzen innerhalb der 
Durchlaßbandbreite konstant (hier zählen nur die die sich aus den 
gewünschten Übertragungssignal ergeben, nicht Störsignale), dann 
verwischen verschiedene (seriell ankommende) Bits (genauer Symbole) 
miteinander. Damit sinkt unweigerlich das S/N.

Sobald die Filterbandbreite zu gering ist, tritt obiger Effekt 
unweigerlich zumindest bei Analogfiltern auch ein.

[Jobst M. (jobstens-de)]

Bernhard S. schrieb:
> ist aber nicht tragisch, wenn das
> Bi-Phase-Symbol einige µs später decodiert werden kann.

Dann fährt man ja gnadenlos in den Stau rein ... :-D


Gruß

Jobst

[Bernhard S. (bernhard)]

@alle

nun sieht das analoge 57kHz-RDS-Signal schon ganz brauchbar aus

siehe: http://www.mikrocontroller.net/attachment/202871/img_9499.gif

Habe mir erlaubt, die einzelnen Filter etwas zu verstimmen.

Filter F1 = 57kHz + 500Hz
Filter F2 = 57kHz - 500Hz
Filter F3 = 57kHz + 500Hz
Filter F4 = 57kHz - 500Hz
Filter F5 = 57kHz + 500Hz
Filter F6 = 57kHz - 500Hz

Die grünen Linien kennzeichnen die 57kHz Einstellung, die blauen die 55 
und 59kHz Einstellung.

Alle Filter auf exakt 57 kHz einzustellen ist bei dieser Filterschaltung 
nicht sehr sinnvoll, da sich das ganze System "aufschaukelt" und ewig 
nachschwingt. Somit werden die RDS-Signale "verwaschen".

Die Sprungantwort dieses Filters an den verschiedenen Messpunkten hefte 
ich mal mit an.



@ Abdul
@ alle

>Am einfachsten realisierbar über Simulation z.B. in LTspice. Die GLZ
>kannst du dir dort im Phasengang direkt anzeigen lassen.

Leider habe ich mit LTspice noch nie gearbeitet, vielleicht kann jemand 
von Euch mal die Filterschaltung simulieren und uns sagen, wie die 
einzelnen Filter optimal einzustellen sind.

@Jobst

>> ist aber nicht tragisch, wenn das
>> Bi-Phase-Symbol einige µs später decodiert werden kann.

>Dann fährt man ja gnadenlos in den Stau rein ... :-D

Sieh's positiv, alle anderen bekommen die Info über den verstauten 
Streckenabschnitt, verlassen und umfahren ihn und dann ist die Strecke 
frei, Freie Fahrt, denn der Stau hat sich aufgelöst :-)

Bernhard

[Abdul K. (ehydra)]

Viel Leute scheint es nicht zu interessieren. Also LTspice spukt mit dem 
was du mir an Daten gabst, dies raus.

Filter 6 sollte man nochmal überdenken, da es ne andere 
Übertragungskennlinie aufgrund anderer Belastung als die anderen 5 
Filter hat.

Vielleicht kannst du noch etwas besser nachmessen was die Bauelemente 
angeht? Ich mußte die 680uH auf 780u erhöhen, um die 57KHz genau zu 
treffen.


So jedenfalls ist dein Filter für RDS viel zu schmalbandig.


Aber erstmal Popcorn machen...

[Abdul K. (ehydra)]

Hier noch die Variante mit +500 und -500Hz abwechselnd. Sieht schon 
besser aus. Im Gegensatz zu der exakt 57KHz Version macht es da auch mal 
Sinn die Gruppenlaufzeit zu plotten.

[Bernhard S. (bernhard)]

@Abdul


ich danke Dir.

Der RDS-Filter muss die 56 und die 58kHz passieren lassen, siehe 
Spektrum.

Hinweis: Bei den Filtern habe ich bei Resonanz einen ohmischen 
Widerstand von ca. 4k ermittelt (Parallelwiederstand zu L + C)

Ich installiere gerade LTspice IV.

Kannst Du uns mal die LTspice-Datei zur Verfügung stellen.

Bernhard

[Abdul K. (ehydra)]

Die Filterbandbreite sollte 3KHz werden.

[Bernhard S. (bernhard)]

@alle

das gefilterte 57kHz-RDS-Signal habe ich mal mit mit dem 57kHz-Signal 
aus dem Pilotton multipliziert.

Das Ergebnis der Multiplikation schaut schon ganz gut aus.

Man erkennt deutlich,wie die positive und negative Halbwelle entsteht.


@Abdul


>Die Filterbandbreite sollte 3KHz werden.

ich schau's mir mal an.

Bernhard

[Abdul K. (ehydra)]

Die 4K Parallelwiderstand habe ich nun reingemacht. Ändert aber nix an 
der fehlerhaften Mittenfrequenz.

Dann hatte ich leider noch einen mächtigen Bug eingebaut, so daß ihr 
leider alle bisher geposteten Plots vernichten könnt. Tut mir leid.

Insgesamt sieht es nun deutlich besser aus.

[Abdul K. (ehydra)]

Wenn die die Verstimmung der Filter auf +/- 1KHz erhöhst, sieht es recht 
gut aus. Mehr geht wohl nur mit echter Filtersynthese.

[Bernhard S. (bernhard)]

>Dann hatte ich leider noch einen mächtigen Bug eingebaut

Welchen? Die Kurve sah doch ganz gut aus.

Ich staune, LTspice lief bei mir sofort, hatte nur mit der Simulation 
Probleme.

Nach der Methode "Versuch und Irrtum" fand ich raus, dass man beim 
simulieren mit der Mouse in die Schaltung, also den Messpunkt, klicken 
muss.

[Abdul K. (ehydra)]

Ja, das war ja das Problem. Such ihn mal :-) Das kommt davon, wenn man 
ne Schaltung so echt simuliert.

Ehrlich gesagt, ich könnte mir Elektronikentwicklung ohne SPICE gar 
nicht mehr vorstellen. Vor 20 Jahren träumte ich von sowas und kann 
deswegen absolut nicht verstehen, wieso viele das nicht als weiteres 
nützliches Tool akzeptieren wollen. Naja, einige Dinge fehlen noch. 
Vielleicht erlebe ich sie noch, z.B. Echtzeit-I/O und Noise-Analysis in 
TRAN.


Probiers mal mit +/-1KHz. Sollte genau 3KHz Bandbreite ergeben.

[Jobst M. (jobstens-de)]

Bernhard S. schrieb:
> RDS_SIGNAL_optimiert.jpg

Dein Filter ist etwas zu schmal. Im Idealfall sollte man bei den langen 
Phasen die beiden Höcker erkennen.

Vermutlich wird das der Dekodierung aber nichts ausmachen.


Gruß

Jobst

[c-hater (Gast)]

Ich lese den Thread sehr interessiert mit und habe eine Idee dazu.

Zum Testen dieser Idee benötige ich allerdings ein MUX-Signal. 
Blöderweise verfüge ich derzeit über kein FM-Radio, um eins zu gewinnen. 
Hat zufällig jemand ein Capture eines solchen Signals (egal ob real 
mitgeschnitten oder generiert, Hauptsache ist erstmal, es enthält ein 
gültiges RDS-Signal und ist lang genug, daß z.B. der Stationsname 
vollständig enthalten ist).

Noch besser wäre natürlich, wenn es gleich auch noch kritische Signale 
enthält, die potentiell die RDS-Decodierung stören können, also z.B. ein 
ARI-DK und/oder ein 9,5kHz Audio-Testton mit maximalem Pegel und leicht 
"wandernder" Phase zum RDS-Signal.

Ideal wäre das ganze als *.wav im PCM-Format, die müßte natürlich 
wenigstens 192kS/s haben und wäre entsprechend fett. Wenn jemand sowas 
fertig vorzuliegen hat oder mit geringem Aufwand erstellen kann, wäre es 
sehr nett, wenn er es irgendwo hochlädt und den Link hier postet. Danke 
im Voraus.

Wenn's kein WAV ist, sondern irgendwas anderes, auch egal. Was es auch 
ist, ich bekomme das schon irgendwie konvertiert.

[Helmut L. (helmi1)]

c-hater schrieb:
> Hat zufällig jemand ein Capture eines solchen Signals (egal ob real
> mitgeschnitten oder generiert, Hauptsache ist erstmal, es enthält ein
> gültiges RDS-Signal und ist lang genug, daß z.B. der Stationsname
> vollständig enthalten ist).

Und welche Soundkarte macht 57kHz mit?

[c-hater (Gast)]

Helmut Lenzen schrieb:

> Und welche Soundkarte macht 57kHz mit?

Viele von denen, die 192kHz Samplerate in ihrem offiziellen 
Windows-Treiber unterstützen.

Leider aber längst nicht alle, so daß diese Unterstützung alleine 
tatsächlich nicht wirklich aussagekräftig ist.

Aber: Das soll nicht dein Problem sein. Wenn das Capture wirklich über 
eine Soundkarte gemacht wurde (was nirgendwo gefordert war) und diese 
dann auch noch zu schmalbandig war, dann sehe ich das schon in der FFT, 
bevor ich ich überhaupt anfange, meine Idee daran umzusetzen, darauf 
kannst du dich verlassen ;o)

[Bernhard S. (bernhard)]

@Jobst
@Abdul

>Dein Filter ist etwas zu schmal. Im Idealfall sollte man bei den langen
>Phasen die beiden Höcker erkennen.

Habe die Filter um ca. 2kHz verstimmt, die Höcker sind nun deutlicher 
ausgeprägt.

Es kann auch sein, dass die Filter unterschiedlich verstimmt werden 
müssen.

Der alte Gauß hätte sicherlich jetzt seine Freude an uns.

Bernhard

[Helmut L. (helmi1)]

@ Bernhard S. (bernhard)

Probier das Filter mal aus. Normal baut man das Filter in einem 
kompletten Block und verstaerkt anschliessend.

Die Spulenguete habe ich mit 50 angenommen.

[Paul B. (paul_baumann)]

Bernhard schrob:
>Der alte Gauß hätte sicherlich jetzt seine Freude an uns.

...und Du hättest jetzt nach langer, angestrengter Messerei sicher
Freude an einem Gaul statt einem Gauß.
;-)

MfG Paul

[Helmut L. (helmi1)]

Hier mal ein Vorschlag um die PSK zu demodulieren.

Zuerst wird das Signal in der Frequenz verdoppelt damit die 
Phasenspruenge wegfallen und dann wieder durch 2 geteilt. Mit dem Signal 
wird das Ursprungliche Signal abgetastet. Je nach Phasenlage ergeben 
sich dann Positive oder negative Impulse an der Sample und Hold Stufe. 
Dort kann man die Information die in der Phasenlage steckt abnehmen.

Ausgangsignal = gruen = in der Mitte der Phasensprung.
Signal an der S+H Stufe = blau = man erkennt das sich der Pulse 
veraendert hat.

[Bernhard S. (bernhard)]

@Helmut

>Probier das Filter mal aus...

Danke für den Vorschlag, wäre auch eine Alternative.

Könntest Du uns bitte Deine "asc" Dateien mit zur Verfügung stellen?

Das MONO-Stereo-Frequenzspekrum (s.Amlage) zeigt, dass das Seitenband 
des Stereo-Differnzsignals bis ca. 54kHz reicht.

Die Filterschaltung sollte demnach so dimmensioniert sein, dass das 
57kHz RDS Signal (56/58kHz) davon nicht beeinflußt wird.

Ansonsten könnte es passieren, dass bei hohen Stereofrequenzen die RDS 
Bitfehlerrate ansteigt.

Diese Erscheinung viel mir bei vorhergehenden Versuchen auf.

Momentan favorisiere ich die mehrstufige Filterschaltung 
(Geradeausempfänger), ist aber Geschmacksache. Jede Stufe lässt sich 
separat trimmen, ohne die anderen direkt zu beeinflussen.



>Hier mal ein Vorschlag um die PSK zu demodulieren

Hab momentan ein Verständnisproblem. Das 57kHz-RDS-Signal soll 
verdoppelt werden.

Vom Prinzip her kein Problem, aber das RDS-Signal bricht bei den 
Nulldurchgängen (Hüllkurve) kurzzeitig für ca. 50µs "zusammen".

Diese relativ lange Zeit, muss der Frequenzverdoppler, bzw. der 
Demodulator, verkraften können.


Gegenwärtig arbeite ich noch mit einem Frequenzverdreifacher (19kHz x 
3),
die Hardware ist zwar etwas aufwändiger, hat aber nicht nur Nachteile.

Die Takgenerierung kann daraus erfolgen (57kHz : 8), man benötigt keine 
Spetial-Quarze, bei der weiteren Bi-Phase-Decodierung ist der µC-Takt 
nicht ganz so von Bedeutung.

Die Multiplikation beider Signale (57kHz-RDS mit 57kHz aus 
Pilotfrequenz) ist relativ unkompliziert.

siehe: 
http://www.mikrocontroller.net/attachment/207059/RDS_FILTER_2kHz_verstimmt.jpg



Leider habe ich noch keine richtige Idee, wie man aus dem 
Multiplizierten Signal eine Hüllkurve gewinnt. Eine einfach 
Diodenschaltung reicht sicherlich nicht?



@Paul

Schön Dich zu lesen.

>>Der alte Gauß hätte sicherlich jetzt seine Freude an uns.

>...und Du hättest jetzt nach langer, angestrengter Messerei sicher
>Freude an einem Gaul statt einem Gauß. ;-)

Ach, sag das nicht, die Arbeit mit einem "Gaul" ist manchmal auch sehr 
anstrengend. Da fallen schnell mal die Worte "Du kommst in die Wust"

Bernhard

[Helmut L. (helmi1)]

Bernhard S. schrieb:
> Hab momentan ein Verständnisproblem. Das 57kHz-RDS-Signal soll
> verdoppelt werden.
>
> Vom Prinzip her kein Problem, aber das RDS-Signal bricht bei den
> Nulldurchgängen (Hüllkurve) kurzzeitig für ca. 50µs "zusammen".
>
> Diese relativ lange Zeit, muss der Frequenzverdoppler, bzw. der
> Demodulator, verkraften können.

Ich habe da nur das Prinzip der PSK Demodulation damit verdeutlichen 
wollen.
Um den Einbruechen zu begegnen kann man hinter dem Verdoppler eine PLL 
schalten (4046),die buegelt die Aussetzer dann wieder raus 
(Schwungradprinzip). Hatte nur keine Lust gestern mehr da eine PLL 
einzubauen.

Im Anhang Filter u. Demodulator.

Bernhard S. schrieb:
> Hab momentan ein Verständnisproblem. Das 57kHz-RDS-Signal soll
> verdoppelt werden.

Ja, damit werden die Phasenspruenge eleminiert. Nach der Teilung durch 2 
gibt es da keine Phasenspruenge mehr drin. Mal dir da Signal mal 
zeitlich auf dann siehst du wie der Trick funktioniert.

Bernhard S. schrieb:
> Leider habe ich noch keine richtige Idee, wie man aus dem
> Multiplizierten Signal eine Hüllkurve gewinnt.

Wenn du dieses Signal jetzt mit dem Eingangssignal multiplizierst und 
dann Filters (Tiefpass) dann bleibt dein urspruengliches Signal ueberig.

Tipp zur Rechnung:  x = Eingangsignal mit Phasenspruenge also sin(x) u. 
cos(x)

y = das aus dem Teiler kommende Signal und von Phasenspruenge bereinigt.

sin(x) * sin(y) = -1/2 * (cos(y+x) - cos(y-x))
cos(x) * sin(y) =  1/2 * (sin(y+x) - sin(y-x))

davon wird das Summensignal durch einen Tiefpass unterdrueckt dann 
bleibt:
den Faktor 1/2 lassen wir einfach weg.

cos(y-x) und -sin(y-x)

Da y und x ja gleich sind wird das Argument = 0 also ergibt:
cos(y-x) = cos(0) = 1 und -sin(y-x) = - sin(0) = 0

Heraus kommt dann nach dem Multiplizierer und Tiefpass 0 oder 1 je nach 
Phasenlage des Eingangssignales.

Kleines Problem hat die Sache doch: Die Anfangsphaselage ist nicht 
vorraussehbar weil das Flipflop irgendwo steht. Loesung es wird nur die 
Differenz zur vorigen Phasenlage uebertragen. Also DBPSK gemacht.
Dann klappts auch mit dem Nachbar eh Phasenlage.

[Abdul K. (ehydra)]

Wie hast du dieses Filter erzeugt? Programm und Vorschrift? Danke!

[Abdul K. (ehydra)]

Das hier gibt die Verhältnisse besser wieder.

[Helmut L. (helmi1)]

Abdul K. schrieb:
> Wie hast du dieses Filter erzeugt? Programm und Vorschrift? Danke!

Mit dem Program:

http://www.aade.com/filter.htm

Butterworth Filter design. Einmal mit Hochpunktkopplung einmal mit 
Fusspunktkopplung.

Bei Hochpunktkopplung ist die untere Filterflanke steiler und bei 
Fusspunktkopplung die obere.

[Abdul K. (ehydra)]

Aha. Der Phasenverlauf ist erstaunlich geradlinig, womit die GLZ günstig 
wird.

[Helmut L. (helmi1)]

Hast du es mal getested?

[Bernhard S. (bernhard)]

@alle

Ein Foto der Wobbelkurve, derzeitige Filtereinstellung, lege ich mal mit 
bei. Mich wunderte die Breitbandigkeit des Filters, aber derzeit läuft 
die Demodulation damit ganz vernünftig.

Gewobbelt wurde mit diesm Projekt:
Beitrag "Spektrumanalysator Frequenzspektrumanalysator Frequenzspektrometer Speki Wobbelgenerator TFT Atmega8"

Die anderen Bilder zeigen das Multiplizierte Ergebnis bei einem starken 
und etwas verrauschten Sender.

Und ein Mitschnitt eines starken und etwas verrauschten Senders.

Bei dem verrauschten Sender erkennt man deutlich die Phasenverschiebung 
des RDS-Signals nach wenigen 57kHz Schwingungen.


Große Bitte.

Könnte jemand von Euch eine 57kHz PLL mit dem 74HCT4046 entwerfen, ich 
würde sie auch nachbauen.

Die Frequenzverdreifacherschaltung generiert ca. 100mV Sinus bei 57kHz, 
sie soll die PLL ansteuern.

Ziel soll es sein, bei verrauschten Sendern, die 57kHz (3x19kHz) 
phasentreu bereitzustellen.

Bernhard

[Helmut L. (helmi1)]

Bernhard S. schrieb:
> Könnte jemand von Euch eine 57kHz PLL mit dem 74HCT4046 entwerfen, ich
> würde sie auch nachbauen.

Du willst von den 19 kHz ausgehen mit der PLL?

Mal sehen wenn ich im laufe des Tages Zeit bekomme.

[Abdul K. (ehydra)]

Hier das gewünschte Samplefile mit 192KHz und RDS. Und ein Testfile für 
LTspice zum Einlesen und bespicen.

[c-hater (Gast)]

Abdul K. schrieb:

> Hier das gewünschte Samplefile mit 192KHz und RDS.

Danke, das sieht nach einem ersten kurzen Blick da rein schonmal 
ungefähr nach dem aus, was ich brauche.

Allerdings scheinen die Pegelverhältnisse nicht zu stimmen, in einem 
realen Mux müßte RDS doch um vieles "leiser" erscheinen, oder nicht?. 
Wenn meine Soundhardware besser wäre und ich Ultraschall hören könnte, 
würde die Stimme der netten Tussi ja glatt in dem Gezischele untergehen.

Aber egal, schlechter machen kann ich es immer noch selber, wenn die 
Funktion meiner Idee erstmal nachgewiesen ist. Leider ist das WE gerade 
vorbei, die Sache muß also erstmal liegen bleiben. Aber das nächste 
kommt ja schon in nur vier Tagen :o)

[Abdul K. (ehydra)]

Ich weiß nicht mehr unter welchen Umständen dieses File entstand. Ist 
wohl auf dem defekten Laptop konfiguriert worden und da müßte ich für 
weitere Nachforschungen die Festplatte ausbauen.

Hab noch einen angehangen. Da müßten die Pegel stimmen. Hat 1KHz -10dB 
Sinus Stereo und 19KHz -24dB Pilotton sowie RDS -65dB drin. Hier sieht 
man dann auch schön die Filterwirkung wenn RDS_wave_1.zip angewendet 
wird.


Für die richtige RDS-Text Dekodierung gibts 2x ne virtuelle Tüte 
Gummibärchen.

[Helmut L. (helmi1)]

Hier wie versprochen die PLL die aus 19kHz die 57kHz erzeugt.
In Teiler3 sieht man die vervielfachung der 19kHz.
Um das Einschwingverhalten des PLL Filters zu demonstrieren sieht man 
die Messung am VCO Eingang (Optimal und Unterdaempft).
Es wurde die Engangsfrequenz der PLL von 19KHz auf 19.5kHz periodisch 
umgeschaltet. Einmal mit Optimal Daempfung und einmal Unterdaempft 
(11KOhm Widerstand im Filter auf 0 Ohm gesetzt). Man sieht das das 
klingeln beim Einschwingen.

[Bernhard S. (bernhard)]

@Helmut

ich danke Dir.

> ...und einmal Unterdaempft (11KOhm Widerstand im Filter auf 0 Ohm
> gesetzt). Man sieht das das klingeln beim Einschwingen.


Ich hätte die Maßnahme 11kOhm auf Null als Überdämpfung bezeichnet,

denn würde die 11kOhm auf unendlich gesetzt werden, wäre keine Dämfung

mehr zu verzeichnen, also eine Unterdämpfung.

Oder habe ich einen Denkfehler?


@alle

Thema PLL, hier sind ein paar grundlegende Probleme ganz gut 
beschrieben:

http://www.elektronik-kompendium.de/public/schaerer/pll4046.htm


Bernhard

[Helmut L. (helmi1)]

Wenn es anfängt zu schwingen ist eher die Dämpfung zu klein, also 
Unterdämpft.

[Bernhard S. (bernhard)]

@alle

Einige PLL Beispiele:

Beitrag "4046  74HC4046  74HCT4046 / PLL Beispiele"

Helmut, danke für die Zuarbeit.

Bernhard

[Abdul K. (ehydra)]

Abdul K. schrieb:
> Hier das gewünschte Samplefile mit 192KHz und RDS. Und ein Testfile für
> LTspice zum Einlesen und bespicen.

Und, hat nun jemand seine tollen Ideen daran ausprobiert? Wurde ja 
gewünscht.

[Bernhard S. (bernhard)]

@alle

ich habe den Ausgang des Rohdatendecoders SAA6579 nochmal genauer 
untersucht.

Bei steigender Flanke des Taktausgangs wird der Datenpin entsprechend 
geschaltet, bei fallender Flanke kann dann am nachfolgendem Decoder die 
Datenübernahme erfolgen.

Bernhard

[Abdul K. (ehydra)]

In manchen Blaupunkt-Radios haben sie hintendran noch ein D-FF. 
Vermutlich um dem nachfolgenden Prozessor mehr Zeit zu verschaffen.

[Bernhard S. (bernhard)]

@alle

>Würde es genügen, wenn man diese RDS-Frequenzen mit einem einfachen
>AM-Demodulator zurückgewinnt?

ja, mit einem einfachen Dioden-Hüllkurven-Demodulator kann man auch die 
Datenbits und den Takt zurückgewinnen.

Bei guten Empfangsbedingungen ist es kein Problem.

@Abdul
>In manchen Blaupunkt-Radios haben sie hintendran noch ein D-FF.
>Vermutlich um dem nachfolgenden Prozessor mehr Zeit zu verschaffen.

So richtig nachvollziehen kann ich es nicht, ist das FF in der Daten 
oder Taktleitung eingebunden?

Bernhard

[Abdul K. (ehydra)]

Na der Takt geht an C, und D and D. Was sonst.

[Bernhard S. (bernhard)]

@alle

Assembler Version-2 des Rohdatendecoders.

Das Problem der RDS-Taktsyncronisation habe ich in dieser Version etwas 
einfacher gelöst.

Bei Senderwechsel benötigt der Decoder einige Zeit, um den Takt zu 
syncronisieren, bei gutem Senderempfang rastet er relativ schnell ein,
bei verrauschten Sendern kann es passieren, dass er aus dem *Suchmodus 
nicht rauskommt.

Aber auch in dieser Zeit werden decodierte Daten zur Verfügung gestellt, 
in der Hoffnung, dass brauchbare RDS-Bits dabei sind.

Im Bild "V2_2.jpg" kann das Ausganssignal des Demodulators sichtbar 
gemacht werden.

Im Bild "V2_1.jpg" habe ich die Signale mit einem SAAxxx verglichen, sie 
laufen syncron zueinander.

Ein Quarz ist nicht erforderlich, denn der RDS-DATA-Takt wird aus dem 
57kHz-Eingangssignal (aus Pilotton) gewonnen.

Die Schaltung läuft auch beim internen 8MHz RC-Takt problemlos.

Bernhard

[Abdul K. (ehydra)]

Und was ist mit dem Thread-Titel?

[Bernhard S. (bernhard)]

@alle

Helft mir bitte, ich komme mit der CRC / Prüfbitberechnung nicht 
zurecht,
hab dazu mal einen extra Thread geöffnet:

Beitrag "RDS CRC Prüfbit Berechnung"


@Abdul

>Und was ist mit dem Thread-Titel?

Hätte man vielleicht doch anders formulieren können:

z.B. RDS DECODER analog Schaltung ohne spezial IC gesucht, für 
Rohdatengewinnung

Bitte um Verzeihung.

Bernhard

[Bernhard S. (bernhard)]

@alle

ein kleiner Decoder, der die aufbereiteten Rohdaten anzeigen kann:

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

Bernhard

[Abdul K. (ehydra)]

Bernhard, ich finde das Querverlinken etwas doof. Mach doch einen 
Artikel und verlinke dort alle Artikel, die dir sinnvoll erscheinen. 
Danke.

[Bernhard S. (bernhard)]

Dieser Thread ermöglichte mir dieses kleine Projekt:

Beitrag "RDS ENCODER Signalgenerator Testgenerator Testsender Modulator ATmega8 Assembler"


@Abdul
>Bernhard, ich finde das Querverlinken etwas doof

Warum findest Du es doof ?

Érspart kostbare Zeit beim Suchen, finde ich.

Zumal die Problematik sehr komplex ist und die die einzelenen Beiträge 
der vielen Autoren zu wertvoll sind, dass sie in Vergessenheit geraten.

Bernhard

[Abdul K. (ehydra)]

Zu einem Thema schaut man doch erst mal obs bereits einen Artikel dazu 
gibt. Und wenn nicht dann sucht man Einzelthreads.

Ist darum viel effizienter.

Ehrlich gesagt, über dein RDS-Projekt habe ich bereits die Übersicht 
verloren. Überall postest du quer rein.

Dabei finde ich das Projekt ansich toll.

[Muffin (Gast)]

Bernhard S. schrieb:
> @alle
>
> Assembler Version-2 des Rohdatendecoders.
>
> Das Problem der RDS-Taktsyncronisation habe ich in dieser Version etwas
> einfacher gelöst.
>
> Bei Senderwechsel benötigt der Decoder einige Zeit, um den Takt zu
> syncronisieren, bei gutem Senderempfang rastet er relativ schnell ein,
> bei verrauschten Sendern kann es passieren, dass er aus dem *Suchmodus
> nicht rauskommt.
>
> Aber auch in dieser Zeit werden decodierte Daten zur Verfügung gestellt,
> in der Hoffnung, dass brauchbare RDS-Bits dabei sind.
>
> Im Bild "V2_2.jpg" kann das Ausganssignal des Demodulators sichtbar
> gemacht werden.
>
> Im Bild "V2_1.jpg" habe ich die Signale mit einem SAAxxx verglichen, sie
> laufen syncron zueinander.
>
> Ein Quarz ist nicht erforderlich, denn der RDS-DATA-Takt wird aus dem
> 57kHz-Eingangssignal (aus Pilotton) gewonnen.
>
> Die Schaltung läuft auch beim internen 8MHz RC-Takt problemlos.
>
> Bernhard
______________________________________________________________________ 
_-

Hallo Bernhard,

mir ist zwar das ganze Frequez und Phasen-Gefasel hier unverständlich, 
aber wenn meinen ganz oben benannten Tip zur 
"Vorfilter-Eingagsproblematik" gelesen hast, versteh ich diese das hier 
wegen "...bei verrauschten Sendern bleibt die PLL hängen... usw." nicht 
wirklich.. denn: Wen interessiert denn, WIE das IC "arbeitet" - 
Hauptsache es funktioniert, und bei mir gehts prima! OHNE irgedwelcher 
Selektiv-Vorfilter-Zusätze ect... Das Gefasel um den 57 khz-Vorfilter 
ect - ist doch Unsinn: Solange der Radioempfänger ein einigermaßen gutes 
MPX-Signal in auseichender Feldstärke hat, wird die Eingangsstufe des 
Decoder-ICs damit "fertig", und die damit verbundene PLL auch "sauber 
einrasten" können... Der von Euch hier beschriebene "Aufwand" ist meines 
Erachtens völlig am Thema vorbei, denn Du hast eh keinen Einfluß drauf, 
wenn ein Radio-Sender "verrauscht" ist - schalte auf Mono um - soll ja 
helfen... Nunja, Ihr fachsimpelt hier wirres Zeugs von 
Verdoppler/Verdreifacher etc des MPX-Eingangssignales... Wenns denn was 
bringt.... (sorry, dazu muss ich nur schmunzeln, war ja auch nicht böse 
gemeint, ok?)

Bastelfreak Muffin

[Muffin (Gast)]

Wolfgang Horn schrieb:
> Hi, geschätzter Bernhard,
>
> wenn es Dir nur um die Rohdaten geht, dann kriegst Du die auch mit
> einigen IC wie beispielsweise Mischer, CMOS-Multiplexer als Mischer,
> OpAmps und Exklusiv-Oder Gatter.
>
> Denn RDS ist keine Hexerei, sondern aus dem Stereo-Piloten 19 kHz wird
> die dritte Oberwelle 57kHz entsprechend den Daten in der Phase gekippt
> um 180°.
>
> Ob Du die 19 kHz und deren Phase mit einem MC1310 rekonstruierst oder
> die 57kHz in Real- und Imaginärteil zerlegst, das sei Deiner Phantasie
> überlassen, beides geht.
>
> Sehr plausibel fand ich die Datenblätter SAA... von Philips/NXP, als die
> noch mindestens ein Blockschaltbild hatten.
>
> Ciao
> Wolfgang Horn

______________________________________________________________________ 
__

...aja Wolfgang, Hallo erst mal...Grins

Wen die NULEN ud EINSEN verstanden hast, kannst Dich ja mal wieder hier 
"wichtig tun" ... nee, war Scherz letzteres.. sorry..

Also worum gehts hier überhaupt? WOZU will WER den 19-khz-Pilotton, und 
die andren Frequenzen "zerlegen"???? WOZU soll das dienen? Sich ins 
Weltall zu beamen, etwa?...." grins

Leute, machts Euch einfacher, beschränkt Euch aufs Wesentliche bitte. Im 
Internet, im Fachbuchhadel etc gibts Millionen Einträge zu ALLEM, was 
man nicht verstehen MUSS, aber scheinbar UNFREIWILLIG erzwingen will...

WEM nützt ein zerlegtes 38khz-Sendesignal, ein 19khz-Pilot usw???? Also 
ich glaub, irgendwie reichts doch, wenn ein UKW-Sender in STEREO / RDS 
empfangen wird, oder? alles andre ist Wichtigtuerei und Schmalz für all 
jene, die mit ihrem Hirnextrakt irgendwie in die Mülltonne gelangt 
haben....

Na egal, Leute, wollte nicht ausfällig werden, nehmts mit Humor, ich les 
einige Eurer Beiträge ja auch (noch....)....

...in diesem Sinne...

Bastelfreak Muffin...

Nehmts euch nicht zu Herzen, war grad mal in "Stimmung"...Danks jedem... 
der das hier gelesen hat bis hierher... kicher...

[Detlef K. (adenin)]

Hi, Muffin(Gast)

Muffin(Gast) schrieb:
> aber wenn meinen ganz oben benannten Tip zur
> "Vorfilter-Eingagsproblematik" gelesen hast,

Ich hab hier alle 3 (drei) Links, die Du zu diesem Thema abgelassen 
hast, aufgeliste.
Beitrag "Re: RDS DECODER analog Schaltung ohne IC gesucht, für Rohdatengewinnung"
Beitrag "Re: RDS ENCODER Signalgenerator Testgenerator Testsender Modulator ATmega8 Assembler"
Beitrag "Re: RDS DECODER analog Schaltung ohne IC gesucht, für Rohdatengewinnung"

Wo hast Du irgendwas sinnvolles zum Thema oder speziell zur 
"Vorfilter-Eingagsproblematik" gepostet?


OK, hab deinen Beitrag woanders gefunden:
Beitrag "Re: Schaltplan CONRAD RDS Manager gesucht"
Überraschenderweise tatsächlich brauchbar.
Vielleicht solltest Du nach 2:30 Uhr nichts mehr schreiben. ;)

[Abdul K. (ehydra)]

Das SAF7579 hatte noch kein Filter onboard. Daher wird man ein passendes 
Filter im DB finden. Q sollte ca. 9 sein bzw. die Bandbreite 3,5KHz.

[Bernhard S. (bernhard)]

@Helmut

ich werde die Problematik Rohdatendecodierung mit dem 
Frequenzverdopplungsverfahren (2x57=114kHz) nochmal aufgreifen.

Erspart die 19KHz Filterstrecke, verringert den Hardwareaufwand.

Detlef gab mir wertvolle Tipps, wie man bei einem 16MHz Quarz 
hinreichend genau 57KHz generieren kann.



@Detlef

>OK, hab deinen Beitrag woanders gefunden:
>Beitrag "Re: Schaltplan CONRAD RDS Manager gesucht"
>Überraschenderweise tatsächlich brauchbar.
>Vielleicht solltest Du nach 2:30 Uhr nichts mehr schreiben. ;)

Der Beitrag von "Muffin (Gast)" ist technisch falsch, nicht 
nachvollziehbar und unbegründet.

Vermutlich liegt hier eine Verwechselung vor, oder jemand möchte uns 
hier in die Irre treiben.

Bernhard

[Bernhard S. (bernhard)]

@alle

Helmut hatte eine gute Idee, die benötigten 57kHz zur Decodierung kann 
aus dem 57kHz-MPX-Signal generiert werden.

Der µC arbeitet im CTC-Modus, als "freilaufender Oszillator", wird aber 
durch das 57kHz Eingangssignal, welches aber ständig die Phase 
wechselt, synchronisiert.

Bei jedem Flankenwechsel erfolgt bei Bedarf eine leichte 
Synchronisation des Oszillators indem der CTC-Wert des Timer2 geändert 
wird.

Problem: Während eines Phasenwechsels (siehe ZOOM) erhält man keine oder 
sogar falsche Impulse für die Synchronisation des Oszillators.

Der µC erkennt eine extreme Abweichung oder fehlende Synchronisation und 
ignoriert die störenden oder fehlenden Impulse und arbeitet im 
Freilauf weiter.

Anmerkung: Die 57kHz am Ausgang werden durch eine Timermanipulation und 
einer hinterlegten Tabelle generiert

Bernhard

[Abdul K. (ehydra)]

Interessant. Versuch mal die 57KHz runterzuteilen auf den Datentakt und 
mit diesem das Eingangssignal zu samplen.

[Bernhard S. (bernhard)]

>Interessant. Versuch mal die 57KHz runterzuteilen auf den Datentakt und
>mit diesem das Eingangssignal zu samplen.

Die 57KHz brauchen nur durch 48 geteilt zu werden und schon können wir 
uns am Datentakt erfreuen (57kHz:48= 1.187,5kHz).

Aber, der Daten-Takt läuft dann noch nicht synchron zu den RDS-Daten.

Im Bild habe ich ein Biphasesymbol "1" und "0" und den 57kHz Takt 
dargestellt.

Ein Biphasesymbol besteht immer aus 48 x 57kHz Perioden.


Ein Rohdatendecoder muss durch seine eingebaute Logik die Bihasesymbole 
voneinander trennen können, um den Daten-Takt entsprechend zu 
synchronisieren.

Das Sampeln ist unkompliziert, kann nach jedem 57kHz Takt erfogen oder 
auch zu anderen Zeitpunkten.

Bernhard

[Bernhard S. (bernhard)]

@alle

diese Frequenzverdreifacher- Schaltung erzeugt phasengenau das 57kHz 
Signal aus der 19kHz Pilotfrequenz des Senders.

Der Programmcode für den ATmega8 wurde in Assembler erstellt.

Bei jede fallenden Flanke des 19kHz Eingangssignal erfolgt ein 
Interruptaufruf.

Im Interrupt wird berechnet, ob eine leichte Taktkorrektur des 
CTC-Timers (Timer2) erfolgen soll.

Ein Störimpuls wird weitestgehend unterdrückt und der 57kHz Oszillator 
arbeitet mit seiner Quarzgenauigkeit im Freilauf weiter.

LED:

- GRÜN: Eingangssignal liegt an
- GELB: leichte Korrektur des 57kHz Ausgangssignals
- ROT: 19kHz Eingangssignal ist unbrauchbar (starkes Phasenrauschen)

Bernhard

[Bernhard S. (bernhard)]

@alle

Fertiges Projekt RDS-DECODER:


Beitrag "RDS DECODER selber bauen / Rohdatendecoder Eigenbau"

Bernhard