RDS/TMC-Logs


    Danke für diese Information!


    Event 82: Da war doch tatsächlich ein Fehler in der Eventliste, hing einfach eine 0 am Quantifier dran.
    Q-Label 8,9,11: Bei der Ausgabe nicht die berechnete Fließkommazahl ausgegeben....
    Q-Label 12: hatte ich glattweg nicht drin - ist nachgeholt (aber nur für ITU Region 1 und 3 gültig, sprich weltweit, außer Amerika)


    Habe den alten Download durch die korrigierte Version ersetzt.


    Gruß,
    m.g


    PS: bei mir hatte die BAST "blitzschnell" reagiert, ja, per email

    Apropo GNS Protokoll : Hat das jemand ? Hab schon überall im Netz gesucht, aber das GNS 2.0/3.0 ist nirgends zu finden.

    GNS scheint da ein grosses Geheimnis draus zu machen, ich poste aber gerne mal das, was ich bisher rausgefunden habe, wenn Bedarf besteht...

    Hi Volker,


    wäre echt prima, wenn Du das mal posten könntest.


    Gruss
    JT

    @M.G.: An info@bast.de? Ich habe noch immer keine Antwort, werde wohl eine weitere E-Mail schicken oder sogar mal anrufen.


    @Joe: Ich habe eine erste Zusammenfassung meiner Erkenntnisse hier online gestellt.

    @Volker
    Das sieht ja schon recht spannend aus. Ich werde die Tage mal was experientieren.
    Ich hab schon eine NMEA Implementierung in C# angefangen und werde das RDS/TMC-Zeuch mal einbauen.
    Zur Info : Ich hab' 'ne NAVILOCK BT-453TE (GNS 3.0). Ich hatte bei NaviLock wegen dem Protokoll angefragt.
    Die hatten geantwortet, das man genau angeben muß, für welches Produkt (!) man das Protokoll braucht und man muß eine Vertraulichkeitserklärung abgeben.
    Für Nicht-Kommerzielle Projekte würde das Protokoll auf keinen Fall freigegeben. Wassn Schwachsinn !!!!


    Zu Deinem Artikel : Auch bei GNS 3.0 werden standardmäßig keine TMC-Daten gesendet.


    Gruss
    JT

    Ich habe meine ersten Erkenntnisse ueber das GNS-Protokoll erlangt indem ich meinen Laptop als "Repeater" zwischen GPS und Smartphone benutzt habe. Auf dem Smartphone laeuft Destinator SP (GNS-tauglich). So konnte ich bytegenau beide Richtungen mitloggen.


    Bei RDS und TMC war m.g. eine grosse Hilfe, die erforderlichen Normen habe ich ueber die Firma bestellt.


    GNS kann uns das Leben zwar schwer machen, aber aufhalten koennen sie uns nicht! *fanfarespiel* *siegessichereposeeinnehm*


    Unterschiede zwischen GNS 2.0 und GNS 3.0 wuerden mich natuerlich interessieren. Log mal was das Zeug haelt und lass mich an neuen Erkenntnissen teilhaben.


    Wenn Du mit dem .NET Framework arbeitest, musst Du bei den Schnittstellen noch auf das Encoding achten! Die laufen standardmaessig auf ASCII und wandeln alle Bytes > 0x7F in 0x3F. System.Text.Encoding.Default muss extra eingestellt werden. Dann kannst Du ueber die Eigenschaft ReadExisting problemlos in einen String oder CharArray einlesen. Das ist wesentlich CPU-schonender als die Bytes einzeln aus dem Puffer zu lesen.


    So far...


    Volker

    So.....1. Test......allerdings ohne Antenne an der Maus. Geht im Mom aus "logistischen" Gründen nicht. Kann ich erst morgen testen.


    Bekomme zurück : 3F 0 0 0 45 72 72 0 0 3F


    Volker, statt wie bei Dir 2 Nullen, kommen hier 3, außerdem statt 0x46 kommt 0x45.

    @Volker
    Kannst Du mal genauer beschreiben, wie Du das mit dem Loggen gemacht hast ?! Mit welcher Soft ?

    Die Position der 45 wuerde bei GNS 2.0 ja die Frequenz zurueckgeben. Welcher der Werte steigt denn an wenn du auf eine hoehere Frequenz schaltest? Und mit welcher Frequenz hast Du getestet?


    Den "Logger" habe ich mir schnell in VB .NET zusammengeschustert. Einfach zwei Serialport-Controls (nicht vergessen Encoding zu setzen) und in den OnReceive-Events auf den jeweils anderen Port weitergeleitet. Dann noch einen Streamwriter geoeffnet (auch hier Encoding setzen!) und abgespeichert. Um unterscheiden zu koennen, noch je nach Port "DES:" oder "GPS:" davorgesetzt und das ganze anschliessend mit einem Hex-Editor analysiert.


    Per Bluetooth auf dem Laptop dann den GPS-Receiver auf einen vituellen COM-Port gelegt, auf dem Smartphone einen eingehenden Port angelegt und ebenfalls per BT mit dem Laptop verbunden. Navi Software gestartet.


    Fertig! ;)

    Mein kleines Programm zum repeaten und loggen der seriellen Ports haengt an. Benoetigt eine aktuelle Version des Microsoft .NET Frameworks.


    GPS und Navigationssoftware unter Benutzung des SerialPort-Dienstes per Bluetooth mit dem Rechner verbinden - Programm starten - Dateiname fuer Ausgabe waehlen (nicht existierende Datei, sonst wird ueberschrieben!) - Portnummern eintragen und auf den Button klicken.


    Die Ausgabe im Textfenster ist Unicode codiert, die Ausgabedatei enthaelt die Binaerdaten.


    Die Ausgabedatei kann dann auch mit m.g.'s splitlog und rds2tmc weiterverarbeitet werden. Die Ausgabe der NMEA-Daten ist aber ungueltig, da die Talker GPS und APP benutzt werden, um anzuzeigen woher die Daten stammten.


    Mit einem HexEditor laesst sich feststellen, welche Bytes in welche Richtung uebertragen wurden.

    An der Stelle mal der Hinweis auf das neue OSM-Forum,
    speziell den Thhread "TMC-Unterstützung für OSM" sowie "NaviPOWM"
    um eine funtionsfähige, vollständige OpenSource-Navi auf den Weg zu bringen...




    Garry

    ich verfolge das thema schon einige zeit und habe auch selber bereits eine implementierung eines rds-decoders in java fertig.
    um die tmc nachrichten richtig darstellen zu können bräuchte ich nun die Event Liste und die Location Tabelle.
    Kann mir jemand das Format der Dateien geben, die mit rds2tmc ausgeliefert werden?
    Wenn nicht, wo kann ich mir die Tabellen besorgen?
    Für jede Hilfe wäre ich dankbar.

    Siehe Link von weiter oben: Klick Hier


    Ich habe bis dato allerdings keinen Erfolg gehabt, die Listen zu bekommen. Um erstmal Listen zu generieren, mit denen ich arbeiten kann, habe ich einen TMC-Simulator geschrieben und RDS2TMC mit diesen Daten gefuettert. Also z.b. eine Meldung fuer jedes Event zwischen 0 und 2048 ausgebeben. Danach habe ich den CSV-Output von RDS2TMC geparst um eine Eventliste zu erstellen. Gleiches auch mit den Locations.


    Wenn Du genauere Informationen ueber die Listen benoetigst, bitte PN an mich. Solange das fuer ein privates Projekt ist, habe ich keine Probleme damit, einige ISO-Informationen weiterzugeben.


    Volker

    wow. habe gerade einen blick auf openstreetmap geworfen.
    das sieht ja richtig beeindruckend aus.
    jetzt wäre es vielleicht cool die TMC Daten da rein einzublenden.
    am besten mit zeitlichem verlauf, so dass man die entwicklung von verkehrsbehinderungen beobachten kann.