RDS/TMC-Logs

Ich weiß jetzt nich ob das wirklich LCT sind die hier veröffentlicht werden.
DIe unterliegen Urherberschutz und ürfen hier nicht im Forum sein !!!

Admin bitte löschen damits kein Äreger gibt

Danke

Bill

Die LCTs sind auf legale Weise von den jeweiligen zuständigen Behörden bezogen, der Verwendungszweck wurde im Antrag jeweils klar angegeben.

Ausnahme: Frei über das Internet verfügbare LCT, Beispiel Italien.

Das Format ist nur für das weiter oben gepostete Programm rds2tmc verwendbar. In diesem Sinne sind die LCTs nicht als eigenständige LCL verbreitet, sondern es handelt sich um Module des von mir geschriebenen Programmes rds2tmc.

Das Programm rds2tmc wurde derart gestaltet, daß es die Interessen der Bezahldienste (TMCPro, v-trafic, viamichelin) nicht verletzt.

Von daher sehe ich keinen Grund, diese Dateien zu löschen. Sollten dennoch Bedenken bestehen, bitte ich darum, mir eine PN zu schicken.

Gruß,
m.g

[SIZE=7]edit: Stellungnahme etwas ausführlicher gestaltet[/SIZE]

Update: rds2tmc gibt die Empfangs-Frequenzen mit aus (bei Gopal-Aufzeichnungen)

Hallo m.g,

Entschuldigung, mich plagt mein schlechtes Gewissen schon länger!

Endlich habe ich es geschafft (zeitlich!) nun Dein neuestes Programm kurz zu testen.
1) PE 3.0 funktioniert genauso
2) Deine Auswertung scheint sehr gut und umfänglich zu sein
3) Ein Problem scheint bei den Muli-Messages zu bestehen, denn so ist diese Meldung wohl nicht gemeint, oder:
linker Fahrstreifen gesperrt, bis Jan 00 1901, Brückenarbeiten, 999 km Stau, bis 00:00
(rds-Datei liegt bei)
4) Einige Meldungen (wie diese o.g.) wird in GoPal PE3.0 nicht angezeigt!

Gruß,
Stefan

Hallo Stefan,

Es sei Dir verziehen, möge Dich Dein Gewissen jetzt wieder friedlich schlafen/arbeiten lassen :).

In der Spalte "rep" steht mit drinn, wie oft die Nachricht empfangen wurde. Bei 0 Wiederholungen ist es normal, daß Gopal die Meldung nicht anzeigt: In diesem Fall wurde die Meldung nur einmal empfangen (möglicherweise fehlerhaft).

Die Berechnung / Interpretation der Datumsangaben ist relativ zum Zeitpunkt der empfangenen Meldung: In dieser Datei war keine 4A-Gruppe (Zeitstempel) empfangen, dadurch ergibt sich leider Murks. Auch braucht das Programm in diesem Teil noch Nacharbeit ("Anfang Jan" statt "Jan 00", "Mitte Jan" statt "Jan 15").

Ergänzung: Meldungen mit "Nature" = "S" (silent), im allgemeinen "Meldung aufgehoben", werden auch nicht angezeigt, sondern dienen nur dazu, bestimmte Meldungen aus dem Meldungsspeicher zu entfernen.

Gruß,
m.g

Hallo m.g,

man sieht, dass ich mich schon länger nicht mehr mit TMC beschäftigt hatte, sonst hätte ich das wohl gewusst.
Die Aufzeichnung war in der Tat recht kurz.

Eine Frage zu den Zeitstempeln:
Kommen die regelmäßig und wie oft?

Mir ist da nur so eine Idee bzgl. der TMCPro-Versorgung gekommen:
Wenn man gleichzeitig mit den rds-Dateien auch trk-Dateien aufzeichnet, so könnte man doch im Nachhinein (bei Vorhandensein von Zeitstempeln) feststellen, wo (aus trk) welcher Sender (aus rds) empfangen wurde. Das Ergebnis liese sich in eine Karte eintragen und man könnte so eine TMC(pro)-Empfangskarte aufbauen.

Gruß,
Stefan

Hallo Stefan,

Im Prinzip sollte das wohl möglich sein. In der csv-Datei wird pro Eintrag der Zeitstempel (falls vorhanden) mit angegeben. Wenn die Meldungen nur 1x gelistet werden, betrifft der Zeitstempel die erste Meldung, beziehungsweise ist es der erste erhaltene Zeitstempel betreffend einer Meldung.

Normalerweise soll ein Sender genau zu Beginn jeder Minute eine 4A Meldung senden.

Gruß,
m.g

Zitat

Original von bab
Zuerst einmal meinen riesen dank für dein wirken hier im Forum!

Danke, freut mich das zu lesen

Für diese Art Vergleich den 2. Parameter in der batch-Datei auf "1" setzen, damit die Meldungen nicht zusammengefaßt werden.

Die Test-Strecke sollte nicht allzu kurz sein, dann kommen bestimmt auch ein paar Zeitstempel mit in die Auswertung. Am besten einfach mal ausprobieren.

Gruß,
m.g

Die Aufzeichnungen sollten mit identischer Software durchgeführt werden, ansonsten kann zum Beispiel ein unglücklicher Sender-Such-Algorithmus der "besseren" Antennenlösung zum Verhängnis werden. Feste Empfangsfrequenz ist vermutlich die bessere Alternative.

Beim Spielen mit Deiner Software (Version, die Du mir per PN hast zukommen lassen) habe ich noch folgende Bugs gefunden:

-Bei Event 82 ist der Quantifier um 10 zu hoch (320 Baustellen; mit regem Verkehr ist zu rechnen; statt 32 Baustellen).

-Bei den Events 901 und 902 aendert sich der Text, es wird aber kein Quantifier eingefuegt.

-Bei Q-Label 8 wird immer "0.0 t" angezeigt, egal wie hoch der Quantifier ist.

-Bei Q-Label 9 wird immer "0.0 m" angezeigt, egal wie hoch der Quantifier ist.

-Bei Q-Label 11 wird immer "0.0 MHz" angezeigt, egal wie hoch der Quantifier ist.

-Bei Label 12 wird immer "0 KHz" angezeigt, egal wie hoch der Quantifier ist.

Noch eine Frage: Hast Du in Deinem Table jeweils einen deutschen Text mit und ohne Quantifier stehen? Ich habe nur den Table in CEN-Englisch und da gibt's keine Schwierigkeiten mit Mehrzahl durch Umlaute, oder aehnlichem.

Ansonsten funktioniert in meiner Anwendung schon alles recht gut. Den LT habe ich von der Bast allerdings noch nicht erhalten.

Um die Qualitaet von Position und TMC-Sendern zu testen, habe ich uebrigens eine Option eingebaut, die den aktuellen Standort mit der Anzahl und Entfernung (von aktueller Position) der bestaetigten TMC-Nachrichten verknuepft. Ist auch sehr aufschlussreich!

Hallo Volker,

Danke für das Feed-Back! Könntest Du bitte noch eine Aufzeichnung dazu posten? Ist Deine Anwendung für den PC?

Gruß,
m.g

Wenn Du mir dann auch noch meine Frage beantwortest... Geplittetes Log haengt an!

Meine Anwendung ist in C# und VB.NET geschrieben, sollte spaeter auch auf meinem Windows Mobile Smartphone laufen.

Bisher habe ich:

-Ein Control zur Kommunikation mit dem GNS-Receiver:
-Kann RDS-Uebertragung ein- und ausschalten.
-Kann auf eine bestimmte Frequenz schalten.
-Splittet NMEA und RDS in Echtzeit und gibt beides getrennt aus.

-Ein Control zur Verarbeitung von RDS:
-Liest und wertet Gruppen 0A, 0B, 1A, 2A, 2B, 4A vollstaendig aus.
-Gibt Gruppe 8A an TMC-Control weiter.

-Ein Control zur Verarbeitung von TMC:
-Liest und wertet Gruppe 8A aus.
-Verwaltet alle TMC-Nachrichten.
-Bringt TMC in End-User Format.

An letzterem arbeite ich noch fleissig (und werde natuerlich erst fertig sein, wenn ich einen LT von der BAST erhalten habe).

Um mir vorlaeufig zu behelfen, habe ich noch einen Emulator gebaut, dessen Output ich deinem Programm zu fressen gegeben habe. Die CSV habe ich dann wiederum geparst und in ein Datenbankformat gebracht. So habe ich schonmal einen LT, wenn auch ohne Directions, Negative- und Positive-End usw...

Zum Thema TMC-Qualitaet: Ich habe in einer Anwendung die oben genannten Module benutzt um in einer Datenbank die folgenden Daten abzulegen:

-Sendername / -frequenz
-Derzeitiger Standort (vom GPS)
-Anzahl bestaetigter TMC-Nachrichten im Umkreis 0-20km
-Anzahl bestaetigter TMC-Nachrichten im Umkreis 20-100km
-Anzahl bestaetigter TMC-Nachrichten im Umkreis >100km

Hatte Dir ja schon erzaehlt dass ich mich zur Zeit in Deutschland (Berlin) aufhalte. Hier habe ich z.B. herausgefunden dass DKULTUR die meisten TMC-Nachrichten sendet, ganz dicht gefolgt von 88.8. 88.8 konzentriert sich aber viel mehr auf die lokalen Meldungen, was sicherlich von Vorteil sein kann.

Spaeter soll das Modul selbstaendig herausfinden, welcher TMC-Sender gerade der geeignetste ist und diesen dann benutzen.

Nebenbei bin ich noch dabei, nach einem OEM-FM-Receiver (USB oder andere Schnittstelle) zu suchen, der Self-Development unterstuetzt und nach Moeglichkeit auch Full-RDS ausgibt. In den USA gibt's ja nicht wirklich TMC und ich kann mich daran erinnern, dass mein A6-Navi dieses Manko ausgebuegelt hat, indem es immer einen Radiosender ueberwacht hat und die Verkehrsnachrichten (TA+TP) digital aufgezeichnet hat, so dass man sie vor Fahrtantritt anhoeren konnte.

Achja, es gibt ja noch soooo viel, was ich erledigen moechte!

Zitat

Original von VolkerSchulz
Wenn Du mir dann auch noch meine Frage beantwortest...

Ouups, das hab ich glatt überlesen... ja - ich habe die ECL (von der BAST) verwendet und mir dann entsprechend angepaßt.

Gruß,
m.g

bab: Das Programm muss nicht unbedingt das Ziel wissen (was aber durchaus moeglich waere, durch Schnittstelle zum Navi).

Ein Beispiel: Die Software hat sich "gemerkt" dass 88.8 ueberdurschnittlich viele Infos fuer Umkreis <20km verbreitet, nutzt also diesen. Ausserdem weiss sie dass DKULTUR oder DLF gleichverteilt Medungen 0 bis > 100km Umkreis rausgibt. Die Software wuerde dann, sobald ich den Umkreis 20km verlasse, auf DKULTUR oder DLF switchen.

Dass GNS RDS unterstuetzt war mir schon klar, sonst haette ich wohl die TMC-Nachrichten nicht auslesen koennen. Bei Alternativfrequenzen und Suchlauf liegst Du aber falsch: Das GNS-Protokoll uebermittelt volle RDS-Bloecke (ohne Checkwords), also auch 0A und 8A, in denen die Alternativfrequenzen codiert sind. Diese kann ich Problemlos auslesen und auch benutzen. Dies benuzte ich derzeit um festzustellen ob ich evtl. 0.1 MHz neben der eigentlichen Frequenz liege und einen besseren Empfang haben koennte. Einen "Suchlauf" habe ich im GNS-Protokoll noch nicht entdecken koennen, nur den Befehl "Wechsel zu Freqenz X.X MHz", mit dem sich ja einfach ein softwaregesteuerte Suchlauf realisieren laesst (habe ich auch bereits erledigt).

Der GNS-Receiver gibt natuerlich kein Audio aus, weswegen ich nach dem FM-Receiver suche.

@M.G.: Hast Du bei der BAST per E-Mail angefragt? Wie lange musstest Du auf Antwort warten?