Mit TT5 "reden", aber ohne SDK

Hmmm... also das Filekommando EnableExternalGPSInput bewirkt offensichtlich schonmal IRGENDWAS.

Wenn ich es dem laufenden Tomtom gebe, erhalte ich als Rückmeldung

0|3865328|\0x00

(wobei die 38... wohl irgendeine Kennnummer ist, weiß noch nicht was die bedeutet).

Das GPS-Rädchen hört sofort auf, sich zu drehen, und ein Antippen von "Konfig." im GPS-Statusscreen öffnet nicht mehr den üblichen Geräteart-Baudrate-Port Screen, sondern ein "Bitte geben Sie an, wie Längen- und Breitengrad angezeigt werden sollen: Grad (G,G°), Minuten (G°M,M'), Sekunden (G°M'S").

Ein DisableExternalGPSInput-Filecommand macht die Sache rückgängig. Ein weiteres Enable... bewirkt die Antwort "0|3790032|\0x00". Die Nummer ist also jedesmal anders. Kann also keine Process-ID sein. AUch keine TCP-Portnummer, die gehen bekanntermaßen nur bis 65535.

Möglicherweise handelt es sich dabei um ein Dateihandle... Die Werte sind bei meinen Tests alle in ähnlichen Zahlbereichen. Ich schätze, Tomtom erwartet, daß ein anderer Prozeß NMEA-Daten in eine Pipe oder vergleichbares mit diesem Handle schreibt. Im SDK gibts auch eine Funktion "GetGPSFeedFile".

Das .NET Compact Framework unterstützt leider keine Angabe von Dateihandles in der FileStream-Klasse. Zu mehr Tests reicht meine Zeit heute leider nicht mehr, jemand anders kann gern mal weiterfrickeln.

Ui, ich sehe gerade daß die Einstellung mit den Grad, Minuten, Sekunden auch über ein Tomtom-Ende hinaus erhalten bleibt! Also zumindest dafür kann man die Funktion schonmal nutzen.

Edit: Kommando zurück, dafür gibts ja eh schon eine Einstellung bei "Einheiten festlegen". Damn!

Wie wäre es, wenn ihr in 2 Wegen weiter geht. Zum einen kann man ja versuchen komplett TMC zu etablieren. Eine erste Hilfe und Alternative wäre es doch, wenn man die Möglichkeit hätte ab Position x in y km eine Sperre von ggf. z km TomTom beizubringen. Das würde im ersten Moment mal helfen.

Gruß
Hannes

Zitat

Original von Loc2262
Im Moment sehe ich nur die Möglichkeit, ein getrenntes Tool zu verwenden, das Staus auf der berechneten Strecke zumindest mal anzeigt. Das wäre ja schonmal was.

Frage bliebe für mich nur noch: wieviel Aufwand ist es / wieviel Bastelwissen braucht man, um so einen RMC-Empfänger selbst zu bauen? Und: wie schließt man ihn an beliebige PDAs an? Ich hätte an meinem z.B. keinen Port dafür. SD-Karten-Slot ist mit Speicherkarte befüllt, und der Syncport steckt im Stromanschluß.

Mit dem getrennten Tool wäre schon mal ein Anfang! Wenn man prüfen kann ob eine Störung auf der Strecke liegt, könnte ein Fenster aufgehen. Dann kann man halt selbst entscheiden ob man umfahren will oder nicht.
Aber gibt es da nicht irgendwelche Probleme, dass TomTom immer im Vordergrund ist?

Allzu aufwändig ist eine TMC-Schaltung nicht. Läuft ja schon alles. Zum Empfang brauchst Du einen Radiotuner, ein RDS-Chip macht die Dekodierung, der Mikrokontroller steuert den Radiotuner und schickt die Daten vom RDS-Chip über die serielle Schnittstelle zum PCC. Löten sollte man allerdings schon können. Das decodieren der TMC-Nachrichten ist nur ein wenig Programmierarbeit und das läuft auch schon.

Entweder wird die Schaltung über den PPC-Stecker und der seriellen Schnittstelle angeschlossen oder über Bluetooth. Solange nicht der GPS-Empfänger hierüber angeschlossen ist, kann man die seriellen Signale mit einbauen.

Ohne Bluetooth und belegtem PPC-Stecker gibt es derzeit noch keine Möglichkeit. Alles andere, über SDIO- oder CF-Slot dürfte zu kompliziert werden.

Zitat

Original von Loc2262
Hier könnten noch wertvolle Informationen zum Dekodieren der TMC-Nachrichten stecken.

Danke, die Quelle kannte ich noch nicht. Muss mal sehen, was ich noch verwenden kann.

Zitat

Original von Loc2262
Bei einem Autobahnstau möchte ich ja möglichst VOR der letzten Abfahrt vor dem Stau wissen, daß was abgeht, um noch von der Autobahn runter zu können. Wenn ich sehe "in 10 km gibts nen schönen Stau", bin aber gerade an der letzten Abfahrt vorbei und lande eh im Stau, bringt mir das nüscht.
Und die Tomtom-Streckensperr-Funktionen sind nicht für "Sperre x km in y km ab hier" gedacht, sondern die sperren wirklich nur "x km ab aktueller Position". Zumindest die "Straßensperre vermeiden" Funktionen.

Ob man Tomtom irgendwie "gefakte" TTT-Daten unterjubeln kann wäre noch die nächste Frage. Da müßte mal jemand Tests machen, der das abonniert hat. Mal nen Ethereal zwischen Tomtom und Internet hängen. Vielleicht stellen die sich ja "ganz blöd" an und verwenden das gleiche Datenformat wie TMC.

Das ist klar. Aber über die LCL kann man die Abfahrt VOR der Abfahrt ermitteln, ab wo die Störung besteht. Wenn man dann sagen könnte, die nächsten 15 km umfahren, müsste TT uns genau an der richtigen Ausfahrt umleiten.
Beispiel: zwischen A4 Köln-Olpe 20 km Stau ab Ausfahrt 15. Wir ermitteln über die LCL die Koordinaten der Ausfahrt 14, und wenn wir da vorbei sind, sagen wir dem TomTom, bitte die kommenden 20+5 km umfahren.

Ich weiß aber nicht, ob der Aufruf dieser Funktion irgendwie möglich ist.

Was das Faken von TTT-Daten angeht, kann uns doch bestimmt bill_gehts helfen? Die Location haben wir ja innerhalb der traffic.inc schon gefunden. Der Rest sollte auch kein Problem sein, wenn wir die dazugehörigen Meldungen im Klartext kennen.

Zitat

Original von Loc2262
Könnte man nicht einen von diesen im Handel befindlichen "Standalone-TMC-Empfängern" zweckentfremden? Display braucht man ja nicht unbedingt wenn das Anklemmen an den PDA funktioniert, und die müßte doch alle benötigten Teile, vom Radioempfänger bis zur seriellen Schnittstelle, an Bord haben? Oder sind die Dinger ähnlich teuer?

Ich glaube nicht, dass dies funktioniert. Die TMC-Empfänger dürften ähnlich teuer sein, und es ist fraglich ob diese eine serielle Schnittstelle besitzen und wie die Daten aufgebaut sind.
Das Display (~ 30 EUR) kannst Du natürlich weglassen. Vielleicht finde noch ein anderes Radiomodul (muss aber über I2C ansteuerbar sein). Ich bastle aber auch an ein einer Standalone-Funktion.
Also wenn Du nicht navigieren willst, aber auf der Autobahn unterwegs bist, stellst Du an meiner Schaltung z.B. A4 und die Richtung ein, und schon informiert sie Dich nur noch über Meldungen auf Deiner Strecke.

Zitat

Original von Hannes123
Wie wäre es, wenn ihr in 2 Wegen weiter geht. Zum einen kann man ja versuchen komplett TMC zu etablieren. Eine erste Hilfe und Alternative wäre es doch, wenn man die Möglichkeit hätte ab Position x in y km eine Sperre von ggf. z km TomTom beizubringen. Das würde im ersten Moment mal helfen.

Ich denke, wenn man die Funktion "ab jetzt x km umfahren" von extern aufrufen kann, funktioniert die Sache. Oder gibt es eine Befehl "Autobahnen vermeiden und re-routing?"
Dann noch eine Meldung auf dem Bildschirm und die Sache sind geritzt!

Mal sehen was Loc2262 dazu meint??

Viele Grüße
Frank

@bill_gehts
@alle TTT-User

Wer kann Inhalte der traffic.inc und die entsprechenden Traffic-Meldungen im Klartext posten???

Wer kann dazu vielleicht sogar noch eine Ethereal-Protokoll posten???

Wer weiß, welche Datei vom TT-Server für TTT geladen wird. Das sieht man normalerweise auch in Ethereal???

Danke und Gruß
Frank

Ein Hallo in die Runde ...

...oje da hab ich ja was angestellt ...

@Frank
"Ein Blick in die Location Code Table verrät: 12449 =
A72 von Zwickau nach Chemnitz
Kreuz Chemnitz Nr. 17 (Autobahnkreuz) am Übergang zur A4
in Deutschland-->Sachsen-->Chemnitz-->Röhrsdorf"

Ja wenn ich die hätte ...
Hast Du sie?

@Loc2262
Mal eine Erklärung warum (fast) alle Funktionen 3 mal vorkommen.

zBsp.
GetRouteCoordinates()
GetRouteCoordinatesAsync(int)
GetRouteCoordinatesAsyncRetrieve()

Das die erste Fkt sendet das Kommando und kehrt solange nicht zurück bis das Ergebnis zurückgeliefert wurde (oder Timeout)

Die anderen 2 Funktionen arbeiten asynchron. Mit der ersten wird das Kommando abgesetzt, aber nicht auf ein Ergebnis gewartet. Später (evtl. bekommt man ein Event vom SDK) kann man über die 3. Fkt das Ergebnis abfragen. Vorteil dabei: im eigenen Programm geht's bis zum ergebnis weiter.

Noch was zur ext. GPSeinspeisung ... Im TTSDK3 ist da was beschrieben ...
da muß man in der Regestry unter tomtom/gps entsp. Werte setzen ...
in TT5 sind Registry Zugriffsnamen im File drin die auch in diese Richtung gehen...

Zeit müßte man haben ...

Grüße Bill

ah, nochwas

Anfragen gehen an
"http://t.tt1.nl/proxy/de.php" (für deutsches TMC)
übergeben werden noch Parameter : Kundenemail + verschl. Passwort +
irgendwelche anderen Daten

zurück kommt :

>gelöscht ...

Grüße

Das könnte für euch vll. interessant sein:

http://www.ertico.com/download…05/Blaupunkt-Pfeiffer.pdf

Edit: Das auch noch:

http://www.google.de/url?sa=t&ct=res&cd=2&url=http%3A//www.escope.info/%3Ffile%3D286&ei=L8UBQ8KUH4uOiALylvUl

Achja wenn ich störe sagts einfach^^

Zitat

Original von bill_gehts?
Mal eine Erklärung warum (fast) alle Funktionen 3 mal vorkommen.

Jo das ist mir schon klar, ich bin nur zu faul die beim Pasten rauszuschnippeln.

Zitat

Noch was zur ext. GPSeinspeisung ... Im TTSDK3 ist da was beschrieben ...

Ich denke nicht, daß das was da bei TT3 beschrieben ist noch zutrifft, denn der Krims bezieht sich auf das alte getrennte GPS-Modul.

Aber wenn Du magst, spiel doch mal mit den Dateikommandos rum und mit der Theorie, daß der Rückgabewert von EnableExternalGPSInput ein Filehandle ist. Ich bin im Moment mit Uni zu sehr beschäftigt dafür.

Zitat

Original von bill_gehts?
Anfragen gehen an
"http://t.tt1.nl/proxy/de.php" (für deutsches TMC)
übergeben werden noch Parameter : Kundenemail + verschl. Passwort +
irgendwelche anderen Daten
zurück kommt :

Das sieht sehr nach komprimierten Daten aus. Bei unkomprimierten hat man fast immer mehr oder weniger viele Nullbytes dazwischen, nämlich bei Langworten mit Wert<16777216 oder <65536. Würde auch Sinn machen: Internettraffic sparen.

Schritt eins wäre also: Kompressionsverfahren rausfinden.

Wir bräuchten hier mal jemanden mit Erfahrung im Umgang mit Disassemblern, der sich die Navigator.exe gründlich vornimmt! Meine Assemblerprogrammierzeit (C64+Amiga) ist schon zu lange her für sowas.

nach EnableExternalGPSInputV01
wird ein neue Fenster (versteckt) erzeugt.
Der Rückgabewert von EnableExternalGPSInputV01 ist der WindowHandle.

Das Window hat den Titel "TTNNmeaReceiver" ...

jo das wartet nun bestimmt auf Botschaften ...

Grüße
Bill

PS
"Jo das ist mir schon klar, ich bin nur zu faul die beim Pasten rauszuschnippeln. Smile"

->>Zschuldigung

@bill_gehts?: Erstmal vielen Dank für Deine Postings.

Hallo,

wichtig wäre mal Folgendes:

1. TT-Traffic syncen und mit Ethereal protokollieren
2. die entsprechende traffic.inc posten, sowie
3. die entsprechenden Klartextmeldungen zur Störung

Somit habe ich die Möglichkeit innerhalb der 45 Byte neben der Location, die Richtung, Länge und Eventcode zu ermitteln.

Der einzelne Eintrag aus der traffic.inc hilft uns da leider nicht mehr viel weiter.

Gibt es vielleicht in den SDKs (damit meine ich auch das Microsoft PPC SDK) Routinen, die bestimmte Komprimierungsformate unterstützen?

Vielleicht ist es auch einfach eine CAB-Datei, die die traffic.inc beinhaltet?

Danke und Gruß
Frank

@Frank

DANKE

Hallo,

danke, aber ohne weitere Infos hilft mir die traffic.inc nicht weiter. Wir kennen die Position der Location. Aber um die Bedeutung der anderen 43 Bytes zu erkennen benötige ich den Klartext dazu.
Also Länge des Staus usw.

Und wieso sind da nur Baustellen drin? Wie macht das TT bei Staus? Kann man die Datei im laufenden Betrieb ändern?
Ersetzt TTT dir Navigator.exe oder läuft es als zweites Programm parallel?

Und gibt es folgende Funktionen die man beim TT aufrufen kann:
- Aktuelle Position
- Strecke ab aktueller Position für x km sperren?
- Kann man Tastendrücke simulieren und an den TomTom schicken?

Ich denke nun an folgendes:
Falls wir keine weiteren Infos zur traffic.inc bekommen, die übertragenen Daten nicht analysieren können und auch sonst nicht wirklich weiter kommen, hier meine zwei konkreten Vorschläge:

1. Wir können dem TT irgendwie sagen, ab jetzt, x km sperren:
Dann brauchen wir ein Programm welches bei einem Stau, eine Abfahrt vorher die Strecke sperrt.

2. Wir bekommen lediglich über den TomTom die aktuelle Position:
Dann muss ein Fenster aufgehen, was uns dazu auffordert, den Stau zu umfahren.

Wer könnte das programmieren?
Gib es evtl. andere Tools, die uns helfen könnten?

Danke und Gruß
Frank

Zitat

Original von Frank
Ersetzt TTT dir Navigator.exe oder läuft es als zweites Programm parallel?

Das war bei TT3 mal so, die 5er hat TTT wohl integriert.

Zitat

Und gibt es folgende Funktionen die man beim TT aufrufen kann:
- Aktuelle Position

Yep, kann man abrufen.

Zitat

- Strecke ab aktueller Position für x km sperren?
- Kann man Tastendrücke simulieren und an den TomTom schicken?

Hier ist bisher nichts bekannt.

Zitat

2. Wir bekommen lediglich über den TomTom die aktuelle Position:
Dann muss ein Fenster aufgehen, was uns dazu auffordert, den Stau zu umfahren.

Das ist für meine Begriffe im Moment die am ehesten zu implementierende Lösung.

Allerdings genügt die aktuelle Position nicht: wir möchten ja wissen, auf welcher Autobahn Tomtom uns langführen will! Nur mit den Koordinaten kannst Du schwerlich etwas auswerten, es sei denn Du möchtest selbst auf Tomtoms Katendaten zugreifen und feststellen, zu welcher Autobahn welche Koordinaten gehören. Viel Spaß dabei.

Wer Lust hat, kann sich ja mal die Filecommands GetRouteInfo oder so (hatte ich vor kurzem mal gepostet) anschauen, was die alles ausspucken. Und hoffen daß da brauchbare/auswertbare Straßenbezeichnungen dabei sind.