Mit TT5 "reden", aber ohne SDK


    Shit, warst schneller. Hab das auch gerade durch Rumprobiererei rausgefunden. :) Gut, dann kann ich mir das Posting ja sparen.


    Cool, dann können wir jetzt sogar den Zeitpunkt der letzten Aktualisierung in das File eintragen. ;)


    Zitat

    GEIL
    das bei TT der Monat und der Tag mit dem 0.0. anfangen,
    IRRE :rofl :rofl


    Hat mich auch gerade etwas verwirrt. ;) Da ich im Moment keine Möglichkeit habe, selbst "offizielle" traffic.incs durch Abruf zu erstellen, mußte ich etwas mehr rumfrickeln.

    Einmal editiert, zuletzt von Loc2262 ()


    Kaum schaut man ein paar Stunden nicht ins Forum, schon überschlagen die Erkentnisse. Ich bin platt!!! :)



    Jein,


    eine RDS-Gruppe ist nur mit reinen Nutzdaten 8 Byte groß.


    104 Bit = 4 Blöcke mit je (16 Bit Nutzdaten + 10 Bit Prüfsumme)


    TMC wird in Gruppe 8A gesendet. In Block 2 Bit 4 und 3 muss 0 und 1 stehen, damit es eine Single Group Message ist. Generell kann eine TMC-Nachricht auch in mehreren 8A-Gruppen übertragen werden.


    Schauen wir uns mal Deine Daten an:
    Block 1: A2 03 --> PI-Code: A203 = Hitradio Ö3
    Block 2: 05 4A --> Gruppe: 0A, Programmkennung: POP Musik
    Block 3: 04 7C --> Alternativfrequenz: 87,9 MHz und 99,9 MHz
    Block 4: 20 33 --> 5. und 6. Buchstabe Radiotext: "<space>3"


    So, wenn ich alles richtig gemacht habe, hast Du eine 0A-Gruppe gepostest des ORF-Senders Ö3.
    Der Anteil von 0A-/0B-Gruppen zu der gesamten RDS-Übertragung liegt bei ca. 40%.
    Alle Gruppen fangen immer mit dem PI-Code an.


    Die RDS-Nachricht ist plausibel aber keine TMC-Meldung.
    Ö3 sendet POP-Musik u.a. auf den Frequenzen 87,9 und 99,9 MHz und im Radiotext steht auch eine 3.



    Woher hast Du diese Bytefolge???
    Ist Österreich plausibel???



    Ich habe mir gerade auch nochmal Deinen Ethereal-Snapshot angeschaut, kann aber leider immer noch keine Struktur erkennen. Loc2622 hatte gestern die Idee, dass dies vielleicht reine TMC-Nutzdaten sein könnten. Ich werde mal weiter sehen.


    Gruß
    Frank

    Zitat

    Original von bill_gehts?
    also ich habe erstmal mit dem offiziellen Daten herumpropiert...
    TT ignoriert die bei dem routing, der routet über Baustellen,Staus selbst
    Straßensperren einfach drüber ... ??? Hä?


    Also Loc2262 hat gestern festgestellt, dass TT bei einer Straßensperre automatisch umleitet.


    Wichtig wäre halt noch, zu erkennen, ob in der traffic.inc irgendwo ein Flag gesetzt werden kann, welches dann Umfahrung bedeutet.


    Gruß
    Frank

    Zitat

    Original von Frank
    Ich habe mir gerade auch nochmal Deinen Ethereal-Snapshot angeschaut, kann aber leider immer noch keine Struktur erkennen. Loc2622 hatte gestern die Idee, dass dies vielleicht reine TMC-Nutzdaten sein könnten. Ich werde mal weiter sehen.


    Das hab ich nicht gesagt... ich habe gesagt, daß es möglicherweise komprimierte TMC-Daten sind. :)


    Oder aber Daten im Format der traffic.inc, oder des internen Tomtom-Trafficmessage-Datenaufbaus. Aber mit ziemlicher Sicherheit komprimiert.

    Zitat

    Original von Frank
    Wichtig wäre halt noch, zu erkennen, ob in der traffic.inc irgendwo ein Flag gesetzt werden kann, welches dann Umfahrung bedeutet.


    Da sind jetzt die experimentierwütigen Spielkinder gefragt, die gern jedes Bit einzeln rumdrehen und schauen, was passiert. :D

    Zitat

    Original von Loc2262


    Das hab ich nicht gesagt... ich habe gesagt, daß es möglicherweise komprimierte TMC-Daten sind. :)


    Oder aber Daten im Format der traffic.inc, oder des internen Tomtom-Trafficmessage-Datenaufbaus. Aber mit ziemlicher Sicherheit komprimiert.


    Sorry! ;)


    Aber bei Sperre hat er Dich umgeleitet, oder?


    Gruß
    Frank

    HI


    woher ich das habe ?


    http://www.pocketnavigation.net/board/tid21547-sid.htm


    Loc2262 hat mich mit seinem Link auf diesen RDS Empfänger drauf gebracht ...


    Ich hatte irgendwie nach dem lesen der Postings das Gefühl das das
    plain RDS ist.
    Darum hab ich Dir (Frank) das mal als Knobelaufgabe gestellt ...
    Wenn du das Posting durchlist wirst du fesstellen das der Poster dieses Teils
    aus Wien kommt ;)


    Ich glaube Loc2262 kann sich über "seine" TMC Anbindung
    hermachen ....


    Oder?


    Grüße
    Bill

    besonders ist der 66'link interresant der liefert:


    1124453809
    TMC 1 6005 6005 1502 18 25 19.08.05 14:16:49 - in the area of Bodenseeraum , sports event, delays expected,
    TMC 1 390 390 1 1 25 19.08.05 14:16:49 - in the area of Dresden , traffic problem, major event
    TMC 1 349 349 201 3 25 19.08.05 14:16:49 - in the area of Böblingen , accident
    TMC 1 4121 4121 919 12 25 19.08.05 14:16:49 - in the area of Choren , burst water main, closed,
    TMC 1 10141 10138 108 1 25 19.08.05 14:16:49 A1 Bremen - Lübeck between Hamburg-Stillhorn[37] and Hamburg-Südost[35] , queuing traffic 3 km
    TMC 1 10073 10070 101 1 25 19.08.05 14:16:49 A1 Leverkusen - Dortmund between Gevelsberg[90] and Hagen-Nord[87] , stationary traffic
    TMC 1 10078 10076 63 12 25 19.08.05 14:16:49 A1 Leverkusen - Münster between Schwerte[85] and Dortmund/Unna[84] , object on the road. Danger
    TMC 1 10068 10065 701 11 25 19.08.05 14:16:49 A1 Leverkusen - Dortmund between Wuppertal-Ronsdorf[94] and Wuppertal-Langerfeld[93] , roadworks 2 km, stationary traffic
    TMC 1 10148 10150 898 12 100 19.08.05 14:16:49 A1 Lübeck - Hamburg between Bargteheide[27] and Ahrensburg[28] , obstruction warning withdrawn
    TMC 1 10112 10113 701 11 25 19.08.05 14:16:49 A1 Bremen - Osnabrück between Bremen/Brinkum[57] and Delmenhorst-Ost[58] , roadworks
    TMC 1 10117 10116 101 1 25 19.08.05 14:16:49 A1 Bremen - Hamburg between Uphusen/Bremen-Mahndorf[54] and Bremer Kreuz[53] , stationary traffic 2 km
    TMC 1 10112 10111 701 11 25 19.08.05 14:16:49 A1 Osnabrück - Bremen between Delmenhorst-Süd / Groß Ippener[59] and Delmenhorst-Ost[58] , roadworks
    TMC 1 10081 10080 101 1 25 19.08.05 14:16:49 A1 Dortmund - Münster between Kamen-Zentrum[83] and Kamener Kreuz[82] , stationary traffic
    TMC 1 10064 10062 101 1 25 19.08.05 14:16:49 A1 Leverkusen - Dortmund between Wermelskirchen[96] and Remscheid[95] , stationary traffic 2 km
    TMC 1 10076 10068 201 3 25 19.08.05 14:16:49 A1 Leverkusen - Dortmund between Wuppertal-Langerfeld[93] and Schwerte[85] , accident 6 km, stationary traffic
    TMC 1 10183 10184 211 4 25 19.08.05 14:16:49 A10 AD Schwanebeck - AD Havelland (Nördlicher Berliner Ring) between Mühlenbeck[34] and Birkenwerder[33] , broken down vehicle, hard shoulder blocked



    usw...


    das ist doch erstmal ne TMC Quelle ohne Geräte ...

    Ich möchte einfach mal noch ein paar weitere Beobachtungen hier einstreuen, vielleicht bringen die Euch ja noch auf Frickelideen:


    -------------------


    Interessant noch: die Bytes 6 und 7 jedes Eintrages. In allen meinen Beispielen steht dort 01 64 drin. Das wäre 1 100 in dezimal, oder 25601 als 16-Bit Zahl. Hm.


    Im Naviscreen wird eine Verkehrsstörung mit einem andersfarbigen vertikalen Balken dahinter auf dem "Fortschrittsbalken" rechts am Rand dargestellt. Bei 01 64 ist der Balken schwarz, bei 00 00 ist er rot, bei 55 55 ist er orange. Was mag das bedeuten...


    ---------------------


    Die Bytes 9-15... da stehen lauter Nullen. Schreibe ich da z.B. lauter 22 rein, wird aus dem "Baustellen"-Störungssymbol ein "Achtung"-Ausrufezeichen. Beim Speichern werden die ersten beiden 22 wieder durch 00 ersetzt.


    ---------------------


    Schreibe ich in die Bytes 18 und 19 (Original: Nullen) 22 22 rein, wird das Baustellenzeichen zum !. Beim Speichern werden die 22 22 in die Bytes 9 und 10 kopiert!


    ------------------------


    Im Byte 20 steht eine 01. Schreibe ich da zum Test 05 rein, hängt sich Tomtom beim Laden der Karte auf.


    -------------------------


    Eine Änderung an den Bytes 12 und 13, die laut bill_gehts die Länge der Störung sein sollen, ändert nichts an der Länge des farbigen Balkens auf dem senkrechten Fortschrittsbalken.


    ----------------------


    Der Locationcode scheint in einem Langwort abgelegt zu sein. Ändere ich das A1 30 00 00 auf A1 30 55 55, wird an der vorigen Stelle keine Baustelle mehr angezeigt.


    ----------------------


    Ersetze ich die Bytes 27-31 (Nullen) durch 55, wird das Baustellenzeichen durch einen Schlangenlinien-Pfeil ersetzt. Beim Speichern wird aus 55 55 55 55 55 eine 00 00 00 51 55.


    Schreibe ich 00 00 00 22 22 da rein, wird ein Teil der Strecke um die Störung herum in ROSA (statt vorher das Routen-rot) dargestellt. Ob da ein Längenbyte drinsteckt? Oder Typcode "Bereich vermeiden"? Länge dann vielleicht woanders? Der rosa Bereich geht genau von einem Kreuzungsabschnitt bis zum nächsten.


    --------------------------


    Man sieht: die vielen Nullbytes haben auch eine Bedeutung. Die möchte ich am liebsten noch wissen! :)


    das ist alles Das Typ feld
    8,9,10
    und
    17,18,19


    alles was TT nicht als Typ hat tut er per default als ! darstellen,
    das hintere Feld ist für TT das primäre, ist das vordere anders
    fixt er es beim nächsten schreiben

    Anmerkung zum rosa markierten Straßenstück durch Eintragen von 22 22:


    Tomtom plant die Route um solche Straßenstücke herum. Da scheint also ein "Streckenstück vermeiden!" Flag drin zu sein.


    Mal genauer checken...:


    Okay, da haben wir unser "Stück vermeiden"-Flag. Im Byte 30 stehts. Tomtom ersetzt die dortige 00 durch eine 03, wenn man "Vermeiden" in den Störungsdetails anwählt!

    Byte 6 scheint eine Art "temporär/permanent"-Flag zu enthalten. Bei Inhalt 01 wird die Störung in der traffic.inc abgelegt, bei 00 wird sie beim Kartenwechsel verworfen.


    Leider ist es mir bisher nicht gelungen, Tomtom zum Anzeigen einer Staulänge zu bewegen, oder einen Parameter zu finden, der die Streckenberechnung beeinflußt. Abgesehen von der "Stück vermeiden" Funktion routet Tomtom gnadenlos durch jeden Stau durch.

    Einmal editiert, zuletzt von Loc2262 ()


    Du Schlingel! ;)


    Dann stimmt auch meine RDS-Dekodierung! :D
    Ich werde mir das mal genauer anschauen!!!


    Das heißt, dass die Maus Plain-RDS im Datenstrom mit sendet und der ganze Rest in der Software gemacht wird.


    Somit könnten wir auf bestehende TMC-Empfänger zurückgreifen! Aber was ist dann mit meiner tollen Schaltung? :-D)



    Jetzt gibt es aber auch ein neues Problem:


    Der TomTom versteht nur reine GPS-Daten. Mit dem GPS-RDS-TMC-Mix kann TT nichts anfangen. Darum gibt es ja auch ein Tool, um RDS-TMC in der Maus zu deaktivieren.


    Ich glaube, es gibt auch für den PPC virtuelle COM-Schnittstellen. Denn unsere Software müsste aus dem GPS-RDS-TMC-Mix GPS und RDS-TMC trennen. RDS-TMC werten wir weiter aus, GPS leiten wir unverändert an die virtuelle COM-Schnittstelle weiter, wo TT die GPS-Daten abrufen kann.


    Wir müssten noch prüfen, ob der RDS-TMC-Empfänger den Loc2262 meint, die RDS-Daten auch Plain an den PPC weiterleitet. Davon gehe ich aber fast mal aus.


    Daher stellen sich für den o.g. RDS-TMC-Empfang folgende Fragen:
    - Gibt es wirklich eine Software mit virtuellen COM-Ports für den PPC?
    - Oder haben wir eine andere Lösung, um die Daten zu trennen und an TT weiterzuleiten.
    - Wie arbeitet der RDS-TMC-Empfänger, den Loc2262 meint
    - Was ist mit meiner tollen Schaltung ;D


    Unabhängig davon, stehen, so glaube ich, noch einige Forschungsarbeiten bzgl. TT an.


    Gleich kommen die Ergebnisse von meinem Koordinatenabgleich.


    Gruß
    Frank

    Einmal editiert, zuletzt von Frank ()

    Zitat

    Original von Loc2262
    Interessant noch: die Bytes 6 und 7 jedes Eintrages. In allen meinen Beispielen steht dort 01 64 drin. Das wäre 1 100 in dezimal, oder 25601 als 16-Bit Zahl. Hm.


    Im Naviscreen wird eine Verkehrsstörung mit einem andersfarbigen vertikalen Balken dahinter auf dem "Fortschrittsbalken" rechts am Rand dargestellt. Bei 01 64 ist der Balken schwarz, bei 00 00 ist er rot, bei 55 55 ist er orange. Was mag das bedeuten...


    also bei mir macht er das nicht ...
    ganzt du mal ein bilddavon machen ...


    und la0 bitte die 01 (0164) drin, ansonsten ist der Eintrag beim nächsten TT beenden weg
    (evtl Löschflag ?)


    0x64 -> 100 (evtl km/h)
    ist vieleicht die zu erwartende Speed für diese Stelle
    je kleiner desto ... daher "röter"


    Vermutung ...

    laut Hersteller Homepage soll das Teil
    diese "spezifische Protokoll" bringen ...


    Ist ja NUR TMC ...
    damit bräuchte Loc2262 auch keine virtuelle Com oder so


    bei seinem PPC nimmt er COM 1 für TMC
    und GPS läuft auf COM 4 oder so ...


    die andere Seite ist folgende ...


    der der keinen TMC Empfänger kauft, kann
    ja sich ja am PC die 66'er Daten ziehen und
    eine Momentaufnahme Traffic.inc erstellen...