Geschätztes Forum, ich möchte Euch einen RDS-DECODER / Rohdatendecoder vorstellen. Zunächst ein ganz großes Dankeschön an die fleißigen Autoren, die mir sehr wertvolle Hinweise gaben und mich aktiv unterstützten, um Überhaupt dieses Projekt zu realisieren. Denn jede Baugruppe bzw. Schaltung berührt die verschiedenartigsten Problematiken. In diesem RDS-Projekt wollte ich bewusst auf diverse Decoder-IC verzichten (z.B. SAA6579 TDA7330), nur handelsübliche Bauelemente sollten zum Einsatz kommen. ----------------------------------------------------------------------- Alles fing mit einer kleinen Filterschaltung, einem Oszi und einem Spektrumanalyser an. Das es so ausartete hätte ich nie vermutet :-) Leider muss ich auch etwas Wasser in den Wein gießen, denn dieses Projekt ist kein "Anfänger-Projekt". In den folgenden Beiträgen wird das Übertragungsverfahren, diverse Decodiermöglichkeiten und die einzelnen Baugruppen näher beschreiben. Anmerkung: Dieser RDS-DECODER kann selbst leicht verrauschte Sender noch decodieren, dafür ist aber auch der Hardwareaufwand relativ hoch. Das Analoge Einbauinstrument zeigt den Pegel der 19kHz Pilotfrequenz an, ein einfacher Frequenzzähler misst den 19KHz Pilotton mit einem Meßintervall von 1s, 10s, 100s, ist interessant wie unterschiedlich die einzelnen UKW-Sender die Pilotfrequenz ausstrahlen. Gegenwärtig ist das RDS-Gerät mit 3 x ATmega8 bestückt (57kHz-Generator, RDS-Rohdatendecoder und RDS-Decoder) Einige Links, die diese Problematik mit behandeln. Beitrag "RDS DECODER analog Schaltung ohne IC gesucht, für Rohdatengewinnung" Beitrag "RDS ENCODER Signalgenerator Testgenerator Testsender Modulator ATmega8 Assembler" Beitrag "Si4735 RDS Radio UKW LW MW KW AM FM - TA TP AF GT TMC CT RT Pi PS ATmega8 Assembler" Für konstruktive Hinweise und Anregungen bin ich sehr dankbar. Bernhard
@alle Das Übertragungsverfahren : RDS-Daten werden Amplitudenmoduliert mit unterdrücktem Träger und mit einer Datenrate von 1.187,5 Bit/s gesendet. s.Bild: http://www.mikrocontroller.net/attachment/222784/AMPLITUDENMODULATION_mit_und_ohne_Traegerunterdrueckung.JPG Eine 57kHz-Filterschaltung (mit entsprechender Bandbreite) filtert das RDS-Signal aus dem NF-Frequenzgewurschtel (Summensignal, Pilotton, Differenzsignal) heraus. s.Bild: http://www.mikrocontroller.net/attachment/222785/RDS_SIGNAL_ZOOM0.jpg Wenn man den unterdrückten 57kHz Träger wieder zurückgewinnt, ein Möglichkeit wäre die Verdeifachung der 19KHz Pilotfrequenz, dann kann man beide Signale per OSZI miteinander vergleichen. s.Bild http://www.mikrocontroller.net/attachment/222787/RDS_SIGNAL_ZOOM2.JPG In der Praxis erkennt man nach einigen 57kHz-SINUS-Schwingungen deutlich eine 180-grädige Phasenverschiebung der beiden Signale (RDS / 57kHz). Immer dann, wenn die Amplitude zusammenbricht, erfolgt ein Phasenwechsel. Eine 180° Phasenverschiebung kennzeichnet die positive bzw. negative Halbwelle. Anmerkung: Bei der weiteren Rohdatendecodierung ist die absolute Polarität der Halbwellen nicht mehr von Bedeutung. Eigentlich benötigt man nur die Information, dass sich die Polarität der Halbwellen ändert. Bernhard
:
Bearbeitet durch User
@alle Die RDS-Codierung : Ein RDS-Bit also ein Biphasesymbol besteht aus exakt 48 x 57kHz Schwingungen. Eine logische "1" ist eine längere Halbwelle, ohne Phasenwechsel. Eine logische "0" zwei kurze Halbwellen, mit Phasenwechsel. An dieser Stelle wird auch der Bit-Takt generiert, denn der nachfolgende RDS-DECODER möchte gern wissen, ob er eine "0" oder "1" verarbeiten soll. Einfach nur 48 Schwingungen (57kHz) zählen, problematisch ist nur die Taktsynchronisation, den Moment bestimmen, wenn ein Biphasesymbol endet und ein neues beginnt. Bernhard
@alle Eine sehr einfache DECODIER-VARIANTE: Ein "57kHz-Geradeausempfänger" mit einem Amplitudendemodulator :-) Es werden nur die Pegel der einzelnen Halbwellen berücksichtigt und keine Phasenlage. Lange Halbwelle logisch "1", zwei kurze "0". Diese Variante habe ich aber nie getestet, ob sie praxistauglich ist bezweifle ich. Nachteil: Der RDS-Empfang darf nicht verrauscht oder anders gestört sein, sonst wird eine Decodierung sehr schwierig. Bernhard
Das 57kHz RDS-Filter : Aus dem Frequenzgewurschtel am Eingang dieses Filters (Summensignal, Pilotton, Differenzsignal) muss das 57kHz-RDS-Signal herausgefiltert werden. Die Qualität dieser Filterung beeinflusst extrem die spätere Decodierung. Dieses Filter muss 57kHz +/- 1,1875 kHz phasentreu, ohne Laufzeitveränderung filtern. Der Abgleich ist nicht ganz einfach, alle Filter auf 57KHz abstimmen reicht nur für eine Grobeinstellung, da die Laufzeiten (56kHz / 58 kHz) zu stark voneinander abweichen. Alle Filterstufen werden gefühlvoll verstimmt. Gute Qualität: http://www.mikrocontroller.net/attachment/222850/RDS_SIGNAL_optimiert.jpg Schlechte Qualität: http://www.mikrocontroller.net/attachment/222851/RDS_SIGNAL_schlecht.JPG Bei der Optimierung der Sprungantwort jeder Filterstufe und die Wobbelung des Filters lässt der Erfolg nicht lange auf sich warten. Hier wurden zwei Filtereinstellungen miteinander verglichen, (oben) alle Filter auf 57kHz, (unten) Filtereinstellung optimiert. http://www.mikrocontroller.net/attachment/222859/SPRUNGANTWORT_VERGLEICH.JPG Das analoge und gefilterte 57kHz-RDS-Signal kann am Ausgang dieser Fiterschaltung problemlos digitalisiert werden. Die 455kHz (455-1/10) Filterspulen kaufte ich bei: http://www.box73.de/product_info.php?products_id=2417 Bernhard
:
Bearbeitet durch User
Das ist ja alles schön was du Schreiber, es steht aber auch schon gesammelt bei http://de.m.wikipedia.org/wiki/Radio_Data_System#Technische_Grundlagen Das Projekt ist für dich ein großer Schritt, aber für die Menschheit ... ;-)
Hallo, tolles Projekt. Sieht echt alles supper aus. Kann man die Filter nicht auch digital lösen. Bei PICs gibt es da zum Beispiel die DSP Lib. Da sind IIR Biquad Filter drin. Damit müssten sich auf einem 33 PIC die Filter in Echtzeit rechnen lassen. Das würde das System sicher stark vereinfachen. Mfg Klaus
Das 19kHz Filter und der analoge Frequenzverdreifacher : Eine mögliche Variante, um den Hilfsträger zur Decodierung des RDS-Signals zurückzugewinnen. Eine PLL bzw. Costa Loop führt auch zum gewünschten Ergebnis. Nachteil dieser analogen Variante: Bei Ausfall oder Verschlechterung des 19kHz Pilottones entsteht kein 57kHz Ausgangssignal. @Klaus >Kann man die Filter nicht auch digital lösen Bestimmt. Jede Baugruppe bzw. Filter in diesem Projekt lässt sich verbessern und anders gestalten, es ist nur eine mögliche Variante. Diese Projekt ist nicht das "Non plus ultra", es soll nur die RDS-Grundlagen etwas verständlicher machen. >tolles Projekt. Sieht echt alles supper aus. Danke :-) Bernhard
:
Bearbeitet durch User
Der digitale Frequenzverdreifacher : Diese Frequenzverdreifacher- Schaltung mit einem ATmega8 erzeugt 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 Eingang-Störimpuls oder fehlende Eingangsimpulse werden 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
Beispiel Frequenzverdreifacher 19kHz / 57kHz mit einer PLL 4046. Bernhard
DECODIER-VARIANTE mit Multiplikation: Das 57kHz-RDS-Signal kann mit dem 57kHz-Signal (z.B. aus 19kHz Pilotton) multipliziert werden. Hierzu muss aber die Phasenlage beider Signale ziemlich exakt sein, auch bei Temperaturschwankungen, also NULL Grad bzw. 180 Grad, ansonsten wird auch hier die Demodulation schwierig. Auch eine konventionelle Ringmodulator-Variante ist möglich. Bernhard
:
Bearbeitet durch User
Der Rohdatendecoder : Das Prinzip der Decodierung der einzelnen Biphase-Symbole (RDS-Bits) ist in dieser Variante relativ einfach. Das 57kHz-Signal wird benötigt, um das RDS-Signal abzutasten. Bei jeder fallenden Flanke des 57kHz-Signals sampelt der µC. Das Assembleprogramm versucht nun die einzelnen RDS-Bits voneinander zu trennen und den Daten-Takt auf die RDS-Bits zu synchronisieren, indem fleißig nach einem Phasenwechsel gesucht wird. Wir erinnern uns noch, der Datentakt besteht aus exakt 48 x 57kHz Perioden :-) Im Assemblerprogramm wurde auch eine kleine Plausibilitätsprüfung und automatische Korrektur integriert. Verbesserte etwas die Bitfehlerrate bei schächeren Sendern. Ist die Demodulation fehlebehaftet, also keine klare "0" / "1" Trennung möglich, dann wird der Sampling-Zeitpunkt um einige Prozessortakte verschoben, in der Hoffnung, dass sich die Demodulation verbessert. Eine Phasenverschiebung beider Signale (RDS / 57kHz) spielt keine Rolle, sie wird automatisch korrigiert. 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. Am Ausgang OUT(DEMODULATOR) kann man sich das Sampling-Ergebnis anzeigen lassen. http://www.mikrocontroller.net/attachment/222903/OSZI_DEMODULATOR.jpg Ein Quarz ist nicht erforderlich, denn der RDS-DATA-Takt wird aus dem 57kHz-Eingangssignal (z.B. aus Pilotton) gewonnen. Die Schaltung läuft auch beim internen 8MHz RC-Takt problemlos. Bernhard
:
Bearbeitet durch User
Der RDS-DECODER : zunächst kullern die einzelnen RDS-Bits (1.187,5 Bit/s) nacheinander in den Decoder. Bei jeder fallenden Flanke des Takt-Pins übernimmt der Decoder den Pegel des DATA-Pins. Dieser ununterbrochene Datenstrom muss zunächst durch eine Prüfbitmethode synchronisiert werden, also der Anfang der RDS-Gruppe muss gesucht werden. Wurde eine RDS-Gruppe fehlerfrei empfangen, erst dann wird der Inhalt dieser Gruppe (8 Bytes) weiter ausgewertet (z.B. Uhrzeit). Nebenbei erfolgt noch eine Frequenzmessung des 19kHz Signals. Weitere Beispile von RDS-Decodern: Beitrag "RDS DECODER LCD TWI 2WIRE USART ATmega8 Assembler" Die Prüfbitberechnung: Beitrag "RDS CRC Prüfbit Berechnung" Bernhard
:
Bearbeitet durch User
Toll gemacht!! Kleine Korrektur: Eine PLL brauch immer einen zumindest Träggerrest. Ohne Träger, keine PLL!!
Hallo Bernhard, vielen Dank für die ausführlichen Beschreibungen. Auch von mir ein Kompliment zu Deinem Projekt, sehr saubere Arbeit! Grüsse, René
@alle Die Simulation in LTspice IV. Die Resonanzfrequenzen der einzelnen Filter lassen durch die Parameter F1 ... F6 verändern, die Induktivitäten werden automatisch berechnet, die Parallelkapazitäten der Filter sind in diesem Fall fest vorgegeben mit 10nF. So lässt sich relativ einfach das Filter manipulieren und man sieht sofort die Auswirkung auf das gefilterte RDS-Signal. Der Parallelwiderstand der einzelnen Filter ist nicht zu verachten, denn er beeinflusst relativ stark die Filterkurve. Ein kleines Dankeschön an "Abdul", er erstellte die Vorlage für die Simulation. René, ich danke Dir für das Lob. Bernhard
:
Bearbeitet durch User
Die geänderte Simulationsdatei asc des RDS-Filters, hatte versehentlich nicht die Original Symbol-Bibliotheken verwendet, sorry. Bernhard
Hallo @Bernhard S. Ich hätte mal einige kurze Nachfragen: Im Gegensatz zu dem Projekt mit dem 4x20 LCD-Display Beitrag "RDS DECODER LCD TWI 2WIRE USART ATmega8 Assembler" hast Du hier offensichtlich nicht den internen Oszilator sondern den Quarz-Takt mit 16MHz in Verwendung. Hier würde mich mal interessieren (wie nebenan schon erwähnt bin ich noch etwas neu in der Materie) welche Fusen hier gesetzt werden müssen. Bin da auch mit Datenblatt und auch mit Khazama AVR nicht wirklich schlau geworden. Hier hast Du jetzt auch eine zweiten Taste für "Menü-Wert" integriert. Welche Funktion hat Diese neben der "Menü"-Taste? Wozu dient die LED / das Relais am Pin 25? Bei dem Eingang "Frequenzähler" vermute ich mal, dass der nur eine zuätzliche Funktion ist, jedoch für die reine RDS-Funktion nicht zwingend erforderlich ist.
Kleine Korrektur: Eine PLL brauch immer einen zumindest Träggerrest. Ohne Träger, keine PLL!! Stimmt so nicht. Die Costas-Loop kann den Träger aus den Seitenbändern rekonstruieren. Damit kann man ohne den 19kHz Träger auskommen und den Träger aus dem 57kHz Signal gewinnen. Übliche RDS-Decoder ICs machen das so.
Ich wollte mal einen Zwischensstand zu meinem Nachbau geben. Also fertig noch nicht, aber erstmal funktionabel. Ein paar kleine persönliche Anpassungen habe ich auch vorgenommen. Ich hoffe, dass ich die hier so ranhängen darf. Eine kleine zusätzliche Schaltung ist in meinem Rema RX80 Tonica eingebaut worden. Damit koppel ich zum Einem das MPX-Signal sauber aus, zum Anderen wird darüber auch der Decoder mit Spannung versorgt. Den Abgriff vom Rema hänge ich auch mal ran. Da die Schaltungen von vielen RFT-Geräten identisch ist, ist sie u.A. auch auf HMK-T 100, ST3xxx anwendbar. An dieser Stelle auch vielen Dank an Bernhard für die tolle Arbeit am Programm... Nachtrag: Irgendwas ist mit dem Upload von ANhängen schiefgegangen: Erst paar mal "Internel Server-Error" und jetzt erst Fehlendes doch da bzw. doppelt... Wie ich Doppeltes nachträglich wieder löschen kann habe ich nicht gefunden.
:
Bearbeitet durch User
Nette Beschäftigung ... ich denke auch oft darüber nach einige alte Radios/Tuner mit RDS auszustatten. Ich habe dazu aus der Schrotttonne oft Japan Anlagen eingesammelt, wo PDIP RDS Decoder verbaut waren, die ich gerettet habe für eigenen zukünftige Projekte. Einen "diskreten" RDS Decoder (nach-) zu bauen erscheint mir nicht sinnig ... Was mich abhält und frustriert ist die Sache mit der Abschaltung von analog UKW in naher Zukunft ... ! Dann üssen wir uns alle einen kleinen FM Sender bauen und streamen, damit unsere Radios noch benutzt werden können und keine Staubfänger werden. Ich vermisse Sender auf MW und KW in Deutsch!!!
Sicherlich wird UKW auch mal sterben, aber solange noch vorhanden, nutze ich das natürlich. Der RDS-Dekoder ist für mich auch mehr eine nette und (solange UKW noch vorhanden) eine nützliche "Spielerei". @Bernhard Die Seiten 1 und 2 von Radiotext nutzen ja nur 16 Zeichen und nicht die vollen 20 Zeichen vom Display. Nach etwas Suchen bin ich fündig geworden und habe dann den Bereich in der RDSOLCD_LCD_KURZ.asm angepasst: Bisher:
1 | ANZEIGE_RADIOTEXT1_KURZ: |
2 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+0) |
3 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+0) |
4 | ldi temp1,16 |
5 | rcall ANZEIGE_SRAM_Z_TEMP1 |
6 | ret |
7 | ; ############################################################################## |
8 | ANZEIGE_RADIOTEXT2_KURZ: |
9 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+16) |
10 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+16) |
11 | ldi temp1,16 |
12 | rcall ANZEIGE_SRAM_Z_TEMP1 |
13 | ret |
14 | ; ############################################################################## |
15 | ANZEIGE_RADIOTEXT3_KURZ: |
16 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+32) |
17 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+32) |
18 | ldi temp1,16 |
19 | rcall ANZEIGE_SRAM_Z_TEMP1 |
20 | ret |
21 | ; ############################################################################## |
22 | ANZEIGE_RADIOTEXT4_KURZ: |
23 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+48) |
24 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+48) |
25 | ldi temp1,16 |
26 | rcall ANZEIGE_SRAM_Z_TEMP1 |
27 | ret |
28 | ; ############################################################################## |
29 | ANZEIGE_RADIOTEXT5_KURZ: |
30 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+64) |
31 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+64) |
32 | ldi temp1,16 |
33 | rcall ANZEIGE_SRAM_Z_TEMP1 |
34 | ret |
35 | ; ############################################################################## |
36 | ANZEIGE_RADIOTEXT6_KURZ: |
37 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+80) |
38 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+80) |
39 | ldi temp1,16 |
40 | rcall ANZEIGE_SRAM_Z_TEMP1 |
41 | ret |
42 | ; ############################################################################## |
43 | ANZEIGE_RADIOTEXT7_KURZ: |
44 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+96) |
45 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+96) |
46 | ldi temp1,16 |
47 | rcall ANZEIGE_SRAM_Z_TEMP1 |
48 | ret |
49 | ; ############################################################################## |
50 | ANZEIGE_RADIOTEXT8_KURZ: |
51 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+112) |
52 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+112) |
53 | ldi temp1,16 |
54 | rcall ANZEIGE_SRAM_Z_TEMP1 |
55 | ret |
Neu:
1 | ANZEIGE_RADIOTEXT1_KURZ: |
2 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+0) |
3 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+0) |
4 | ldi temp1,20 |
5 | rcall ANZEIGE_SRAM_Z_TEMP1 |
6 | ret |
7 | ; ############################################################################## |
8 | ANZEIGE_RADIOTEXT2_KURZ: |
9 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+20) |
10 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+20) |
11 | ldi temp1,20 |
12 | rcall ANZEIGE_SRAM_Z_TEMP1 |
13 | ret |
14 | ; ############################################################################## |
15 | ANZEIGE_RADIOTEXT3_KURZ: |
16 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+40) |
17 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+40) |
18 | ldi temp1,20 |
19 | rcall ANZEIGE_SRAM_Z_TEMP1 |
20 | ret |
21 | ; ############################################################################## |
22 | ANZEIGE_RADIOTEXT4_KURZ: |
23 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+60) |
24 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+60) |
25 | ldi temp1,4 |
26 | rcall ANZEIGE_SRAM_Z_TEMP1 |
27 | ret |
28 | ; ############################################################################## |
29 | ANZEIGE_RADIOTEXT5_KURZ: |
30 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+64) |
31 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+64) |
32 | ldi temp1,20 |
33 | rcall ANZEIGE_SRAM_Z_TEMP1 |
34 | ret |
35 | ; ############################################################################## |
36 | ANZEIGE_RADIOTEXT6_KURZ: |
37 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+84) |
38 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+84) |
39 | ldi temp1,20 |
40 | rcall ANZEIGE_SRAM_Z_TEMP1 |
41 | ret |
42 | ; ############################################################################## |
43 | ANZEIGE_RADIOTEXT7_KURZ: |
44 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+104) |
45 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+104) |
46 | ldi temp1,20 |
47 | rcall ANZEIGE_SRAM_Z_TEMP1 |
48 | ret |
49 | ; ############################################################################## |
50 | ANZEIGE_RADIOTEXT8_KURZ: |
51 | ldi ZL, LOW (adr_RDS_BEREICH_RADIOTEXT128+124) |
52 | ldi ZH, HIGH(adr_RDS_BEREICH_RADIOTEXT128+124) |
53 | ldi temp1,4 |
54 | rcall ANZEIGE_SRAM_Z_TEMP1 |
55 | ret |
Der jeweils vierten Zeile sind dann nur noch vier Zeichen zugeordnet (fall's mal alle 64 Zeichen ausgenutzt werden). Ich empfinde den Zeilenumbruch am Ende des Displays angenehmer, als wenn da schon nach 16 Zeichen der Zeilenumbruch erfolgt. Nachtrag: "Mecklenburg-Vorpommern" muss man abkürzen in "Meckl.-Vorpommern" (Zeile 624 in RDSOLCD_ini.asm) Sonnst wird in Zeile 2 die ersten beiden Buchstaben "DE" von DEUTSCHLAND überschrieben mit "rn" (die letzten beiden Buchstaben von Vorpommern) "rnUTSCHLAND" sieht in dem Moment etwas komisch aus im Display.
:
Bearbeitet durch User
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.