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
http://de.wikipedia.org/wiki/Radio_Data_System Ohne ICs wirst Du eine Kiste Transistoren brauchen. Siehe auch DIN EN 62106
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
@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
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
:
Bearbeitet durch User
@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
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
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?
:
Bearbeitet durch User
@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
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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Jobst M. schrieb: > Edit: Ach Mist, jetzt habe ich das Deckblatt auch hochgeladen ... :-/ Auweia: Schleichwerbung für die ARD! :-)
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
@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?
:
Bearbeitet durch User
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.
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
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
:
Bearbeitet durch User
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
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!?
:
Bearbeitet durch User
Jobst M. schrieb: > Hallo, kann ein MOD mal Bild img_9493.gif entfernen!? Nö, lass mal: das finde ich als Quellenangabe ganz sinnvoll so.
Der Verkehrsfunk stört übrigens seit 2007 nicht mehr. Damals wurde das ARI-Signal abgeschaltet. Gruß Uwe
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.
@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?
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.
@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
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
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
:
Bearbeitet durch User
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...
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. 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.
Um das RDS Signal (PSK) zu dekodieren wird meistens eine Costas Loop verwendet. http://de.wikipedia.org/wiki/Costas_Loop
@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
@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
:
Bearbeitet durch User
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
Google mal nach der en50067. Die Ausgabe von 1998 war bei mir gleich der erste Treffer...
@alle Einige Messungen am SAA6579. Eingangspin, Taktausgang und Datenausgang. Man erkennt sehr deutlich am eingang das 57kHz gefilterte MPX Signal Bernhard
...interessant sind auch die RDS Patente: https://www.google.de/patents/EP1241815A2?cl=de&dq=rds&hl=de&sa=
Hier steht sicherlich auch interessantes drinn: http://www.ko4bb.com/Manuals/Rohde_Schwarz/Rhode_Schwarz_DMC01_OM.pdf
@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
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
@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
@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
Bernhard S. schrieb: > Erkennt jemand von Euch einen Zusammenhang Phasenlage und dem DATA ? Joa. Du nun auch? Gruß Jobst
@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
:
Bearbeitet durch User
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
@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
:
Bearbeitet durch User
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
Wie siehts aus, wenn du das S/N verschlechterst? Wer ist dann besser?
@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
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.
@ 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
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.
:
Bearbeitet durch User
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
@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
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...
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.
@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
:
Bearbeitet durch User
Die Filterbandbreite sollte 3KHz werden.
@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
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.
Wenn die die Verstimmung der Filter auf +/- 1KHz erhöhst, sieht es recht gut aus. Mehr geht wohl nur mit echter Filtersynthese.
>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.
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.
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
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.
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?
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)
@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
@ 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.
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
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.
@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
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
Wie hast du dieses Filter erzeugt? Programm und Vorschrift? Danke!
Das hier gibt die Verhältnisse besser wieder.
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.
Aha. Der Phasenverlauf ist erstaunlich geradlinig, womit die GLZ günstig wird.
@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
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.
Hier das gewünschte Samplefile mit 192KHz und RDS. Und ein Testfile für LTspice zum Einlesen und bespicen.
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)
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.
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.
@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
Wenn es anfängt zu schwingen ist eher die Dämpfung zu klein, also Unterdämpft.
@alle Einige PLL Beispiele: Beitrag "4046 74HC4046 74HCT4046 / PLL Beispiele" Helmut, danke für die Zuarbeit. Bernhard
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.
@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
In manchen Blaupunkt-Radios haben sie hintendran noch ein D-FF. Vermutlich um dem nachfolgenden Prozessor mehr Zeit zu verschaffen.
@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
Na der Takt geht an C, und D and D. Was sonst.
@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
:
Bearbeitet durch User
Und was ist mit dem Thread-Titel?
@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
@alle ein kleiner Decoder, der die aufbereiteten Rohdaten anzeigen kann: Beitrag "RDS DECODER LCD TWI 2WIRE USART ATmega8 Assembler" Bernhard
Bernhard, ich finde das Querverlinken etwas doof. Mach doch einen Artikel und verlinke dort alle Artikel, die dir sinnvoll erscheinen. Danke.
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
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.
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
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...
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. ;)
:
Bearbeitet durch User
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.
@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
@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
Interessant. Versuch mal die 57KHz runterzuteilen auf den Datentakt und mit diesem das Eingangssignal zu samplen.
>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
@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
:
Bearbeitet durch User
@alle Fertiges Projekt RDS-DECODER: Beitrag "RDS DECODER selber bauen / Rohdatendecoder Eigenbau" Bernhard
Beitrag #5596448 wurde von einem Moderator gelöscht.
Beitrag #5596468 wurde von einem Moderator gelöscht.
Beitrag #5596948 wurde von einem Moderator gelöscht.
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.