Rund um das Telemetriemodul: Infos, Nutzen, Hacks...

[Gerold]

Kannst Du mal checken, ob sich an der Scutum UID etwas in den letzten 13 Bytes geändert hat?

[Pfriemler]

UIDS hat sich gar nicht geändert. Noch immer bei mir "NOT_STORED" (als ASCII) und dreimal 00.

[Pfriemler]

Nachdem ich meinen Mo 6/23 aus der Werkstatt (Jahresinspektion + LKL) abgeholt habe, untersuche ich nun, was mir an settings derweil verändert wurde.
edit: Dabei ist mir eine Änderung aufgefallen, die zwischen dem 2.2.23 (Firmwareupdate) und dem 1.3.23 offenbar durch "Fernwartung" unbeauftragt und unbemerkt von mir durchgeführt wurde (der geänderte Wert ist in meinen Logs vom 1.3. und 27.3., vor der Werkstatt, schon drin).
$REPL (report level) ist anders: Anstatt 4294967295=all reports enabled habe ich jetzt 2416181701 = 10010000 00000100 00000001 11000101.

edit: Maske gefunden, hoffentlich alles richtig...

Die REPL-Maske definiert nach meiner Erkenntnis nur, welche Ereignisse einen außerordentlichen Report erzeugen, sagt aber nichts aus darüber, welche Werte im Zusammenhang mit einem sonstigen Report (z.B. timed idle) übertragen werden.
Ich vermute, dass Silence die Änderungen vorgenommen hat, um den Datenverkehr zu reduzieren, vor allem wegen Ereignissen, auf die normalerweise ohnehin nicht reagiert wird. (Den Zündungsstatus unmittelbar zu übermitteln mag für die Überwachung von Leihrollern nützlich sein, aber nicht für den Otto Normalnutzer.) Vor allem aber scheint alles (weiter) wegkonfiguriert, was für die bei SEAT ohnehin nicht verfügbare Alarmfunktion entbehrlich ist.

Diese Ereignisse triggern demnach keinen extra Report (an Silence) mehr:
- distance travelled exceeded
- geofence event (für Alarmauslösung erforderlich)
- panic switch (haben wir das?)
- external I/O (?)
- low battery (welche? Astramodul?)
- external power change (battery change) - spannend: Die Entfernung der Rollerbatterie wird dann also nur noch im Rahmen eines normalen IDLE-Reports gemeldet, nicht aber unmittelbar nach dem Entfernen der Batterie. In der Tat sind diese Meldungen neuerdings bei mir verzögert, müsste theoretisch bis zu 10 Minuten dauern (s.u.)
- idling start/stop/ongoing (Zündungsstatus)
- power ON or RESTART?
- Speed overthreshold - die war ohnehin so hoch gesetzt, dass das nur auf Rollen bei Bergabfahrt passiert wäre
- towing event (Fzg wird bewegt bei ausgeschalteter Zündung - tatsächlich haben diese Ereignisse früher bei mir eine Datenflut ausgelöst. Ohne Alarmfunktion sinnlos.)
- unauthorised driver alarm (Zündung an, unerlaubter Fahrer = Leihrollerfunktion, wir haben keine Fahrer-ID-Hardware im Roller)
- accel/decel threshold X (Überschreitung von Beschleunigungs-/Bremswerten in X-Achse - ohnehin nie wichtig, weil unser Modul nach wie vor in der falschen Montage-Orientierung konfiguriert ist (das Event hätte es also nur gegeben wenn uns jemand von der Seite reinfährt)
- cornering threshold maximum event (zu schnelle Drehung)
- GPS re-aquired (?)
- CANBus event (hm, was war da nochmal...)
- CARRIER event (?)
- TAMPER alarm (Alarmanlage)
- Towing Event end (Alarmanlage)
- Gritter (??? DeepL sagt: "Streufahrzeug", lol)
- Bike fall / vehicle roll-over (Überschlag?)

Diese Ereignisse bleiben übrig und erzeugen weiterhin einen Report:
- timed interval (spätestens alle x Sekunden wenn keine anderen Events)
- position on demand (Standortabfrage)
- Journey START und STOP
- heading change (Fahrtrichtungswechsel)
- collision alarm (Unfall/Umfallen)
- bit31 RESERVED
und natürlich ein gewöhnlicher Statusbereucht (SCUTUM) - bei mir aktuell 15 Sekunden bei Betrieb ($JSEC) und 10 min im Stand ($STIM)

[Gerold]

.....
Ich vermute, dass Silence die Änderungen vorgenommen hat, um den Datenverkehr zu reduzieren, vor allem wegen Ereignissen, auf die normalerweise ohnehin nicht reagiert wird. ....

Von den Events, die durch den geänderten $REPL Wert nicht mehr ausgelöst werden, sind in meine Datenbank nur die Events "accel threshold" und "cornering threshold" auf. Die werksseitig falsche Montageorientierung habe ich mittlerweile korrigiert.

Auf die Datenmenge haben diese Events aber nur einen geringen Einfluss. Der weit aus größte Anteil der Daten werden durch die Time Intervall Events erzeugt. Dabei überwiegen die Daten, die während der Standzeit alle 10 min gesendet werden. Hier wurde aber mittlerweile der Datenverkehr seitens Silence stark reduziert. In meinem Modul war werksseitig $STIM auf 1 min eingestellt, während der Standzeit wurde beim ausgeschaltetem Roller noch jede Minute ein Datensatz gesendet.

Ich habe $JSEC auf 5 Sekunden und $STIM auf 5 Minuten eingestellt. Durch den kürzeren $JSEC Parameter werden während der Fahrt die Daten öfter gesendet, Änderungen in den Daten werden damit besser aufgelöst. $STIM steht auf 5 Minuten, da ich einen Teil der Daten des Moduls an meine Smarthome Anwendung (FHEM) weiterleite, die mit den Daten den Ladevorgang des Akkus steuert. Da beim Laden innerhalb von 5 Minuten sich der SOC um etwa 1% und die Akkuspannung sich gleichzeitig um etwa 0,1V erhöht, ist das 5 Minutenintervall für mich optimal.

[patba]

Welche Qualität haben bei Euch eigentlich die in der App abrufbaren tracks der zurückgelegten Fahrstrecke?
Bei mir ist es schon immer so, dass öfters eine Fahrt als mehrere Teilfahrten angezeigt wird, also die Aufzeichnung quasi unterbricht und mit neuem Start beginnt.
Zufälligerweise (?) genau seit dem letzten Service vor gut 1 Monat hat das nun aber extrem zugenommen. Meine Fahrt zur Arbeit z.B. (13 km einfach) wird nie mehr am Stück angezeigt. Teilweise wird sie in 5 oder mehr Teile zerstückelt, können auch mal 10 sein.
Beim Service wurde eigentlich nichts softwaremäßig geändert.
Habt Ihr, die Ihr an den Telemetriedaten lauscht, eine Idee, was zu diesen Unterbrechungen führt? Sind es GPS-Empfangsaussetzer, oder ein anderweitiger Wackelkontakt irgendwo im System? Ich finde noch keine rechte Systematik in dem, was da passiert.

Patrick

[blackblade]

Bei mir ist es so unspektakulär, wie es nur sein kann. Eine Fahrt ist eine Fahrt ohne Unterbrechung.

[Pfriemler]

Welche Qualität haben bei Euch eigentlich die in der App abrufbaren tracks der zurückgelegten Fahrstrecke?

Ich kann ja nicht mitreden, nur partiell, wenn ich mit dem Handy während der Fahrt einen Mitschnitt an der Telemetrie laufen lasse und meine selbstgestrickte Software daraus ein GPX-File erstellt. Das sah zuletzt erstaunlich gut aus, gerade die cornering-Events sorgen dafür, dass die Wegpunkte nicht irgendwo in der Botanik landen, sondern dem Straßenverlauf folgen.

Gründe für Löcher gäbe es viele. Ich denke, wenn die Pausen zwischen den Events zu groß werden. Verloren gehen sollte nichts, denn die mehrfach in der Minute gesendeten Standorte in den Berichten werden bei Übertragungsfehlern zwischengespeichert und nachgeholt. Das GPS-Modul ist nicht das fitteste, aber ingesamt erstaunlich gut.

Du hast nicht zufällig $SHOW-Reports von vor und nach dem Werkstattaufenthalt? Da könnte man gut sehen, was verändert wurde. Ansonsten gibt es ja gut funktionierende Konfigs hier zuhauf. Wer schon mal mit der Kommandozeile irgendwo gearbeitet hat, setzt die paar Befehle ja leicht ab.

jm2c.

[Gerold]

Die Analyse des Problems von @patba wird durch die unterschiedlichen Softwareversionen auf den Modulen erschwert. Meine alte 7,0,39.35 Version ist zudem fehlerhaft. So werden bei der werkseitigen Einstellung von $IGNM=4 (Start/Stop Erkennung über CAN Daten) bei mir die Start und Stop Events in Modul nicht ausgelöst, stattdessen werden Towing Events (vehicule moving with IGN off) generiert. Trotzdem hat die App die Fahrten korrekt angezeigt. Mir ist deshalb nicht klar, nach welchen Kriterien die App Fahrtanfang und -ende festlegt.

[DimoM]

Mein S01+ macht das auf meinem Arbeitsweg (23km einfach) auch gelegentlich. Interessanterweise eigentlich nur morgens. Ich hab’s bisher auf GPS oder Mobilfunkaussetzer in Tunneln geschoben aber so ganz logisch ist es irgendwie nicht. Vielleicht auch irgend ein Wackler oder Ähnliches am Telemetriemodul.
Prinzipiell ist es mir aber nicht wirklich wichtig, dass ich da Aufwand reingesteckt häte.

[patba]

Danke für die bisherigen Rückmeldungen.

Ich habe leider keine Reports vom Modul. Mit dem "Reden" mit dem Modul habe ich mich bisher aus Zeitgründen und fehlendem akuten Interesse nicht beschäftigt.

Meine Befürchtung ist, dass ein Problem außerhalb des Telemetriemoduls ursächlich sein könnte. Bei der Wartung waren ein paar "unerklärliche" Einträge im Fehlerspeicher. Ich kann sie nicht genau wiederholen, aber es waren solche Dinge wie "Spannung zu hoch", "Spannung zu nieder" etc. Laut Werkstatt sagt das Service-manual dazu "ignorieren, wenn sonst alles funktioniert".
Konkret wurde an anderer Stelle hier schon von schlechtem Kontakt im Zündschloss berichtet. Eine meiner Ideen war, dass evtl. Erschütterungen da kurze Unterbrechungen auslösen, was aber noch nicht zu einem "Ausgehen" des Rollers führt. Ich habe aber inzwischen getestet: wenn ich den Roller per app anschalte, treten die Unterbrechungen in der Aufzeichnung auch auf.

Schlechter Mobilfunk-Empfang? Einerseits treten die Aussetzer durchaus gehäuft immer in bestimmten Bereichen meiner Strecke auf. Andererseits aber folgende Beobachtung: Wenn ich z.B. in eine Tiefgarage fahre, und dort den Roller ausschalte, ist das letzte Fahrstück (seit der letzten Unterbrechung) nicht in der App sichtbar. Es wird aber sichtbar, wenn man später wieder aus der TG herausfährt. Und der Ort der Unterbrechungen ist in keinster Weise mit der Lokalisation der TG gekoppelt. Also auch kein direkter Zusammenhang...

Das bleibt irgendwie vage, und so lange sonst alles funktioniert...

Patrick