Discussion in 'Bugs' started by jochene, Sep 13, 2009.

Thread Status:
Not open for further replies.
  1. jochene

    jochene New Member

    Hallo,

    habe mal mein Problem mit Openformat erkundet.

    Bei mir sieht es wie folgt aus:

    - mit Wilhelm Krug gebautes Telemetriesystem
    - im LV 2.5 kommt ca. jede Sekunde ein Signal in der Empfangsanzeige an
    - im LV 2.5 werden die ersten 2 angezeigt, die nächsten 3 werden verworfen und die nächsten 2 wieder angezeigt u.s.w.

    Kann das am LV liegen oder ist unsere ini nicht i.O.

    Habe mal alles als Anlage angehängt:
    - Log - LV 2.5
    - Log - Empfangsanzeige
    - Telemetrie.ini

    Danke für Eure Hilfe.

    Gruss
    Jochen

    Attached Files:

  2. jochene

    jochene New Member

    Hallo,

    habe gerade die Mail über die neu 2.5.0.240 bekommen und das update gleich durchgeführt.

    Auch mit der neuen Version besteht das Problem weiterhin.

    Hätte ja sein können.

    Gruss
    Jochen
  3. Holger

    Holger LogView Team

    Hallo Jochen,

    da stimmt vermutlich was mit dem Empfang nicht so richtig.

    Ich habe den Text in "Empfangsanzeige Logview.txt" mal angepasst und dann kann man das sauber über "Gerätedaten importieren" in LV anzeigen lassen. Da wird jede Sekunde mitgenommen, keine Auffälligkeiten.
    Zuvor habe ich die ini ins passende User-Verzeichnis kopiert (bei mir: C:\Dokumente und Einstellungen\Holger\Anwendungsdaten\LogView\Geraete\OpenFormat) und das Gerät ausgewählt.
    Kannst Du das so weit bei Dir nachvollziehen? Klappt der Import?

    Gruß, Holger

    Attached Files:

  4. jochene

    jochene New Member

    Hallo Holger,

    wenn ich die "SeriellInput.txt" importiere, werden mir auch alle Werte (sekündlich) angezeigt - es fehlen keine Daten.

    Meine "Telemetrie.ini" liegt ebenfalls im entsprechenden Userverzeichnis.

    Wenn ich den Datenempfang im OpenFormatEditor simuliere sieht ebenfalls alles OK aus.

    Was könnte ich noch Testen?

    Gruss
    jochen
  5. Holger

    Holger LogView Team

    Hallo Jochen,

    dann musst Du das Debug-Logging aktivieren und ansehen.
    Dazu gab es vor kurzem bereits ein oder zwei threads. Auch auf der website ist im OF-Bereich und Debugging einiges zu finden.

    Mehr kann ich im Moment leider nicht so auf die Schnelle dazu sagen, müsste die passenden Stellen auch erst heraussuchen.

    Gruß, Holger
  6. jochene

    jochene New Member

    Hallo Holger,

    werde mal heute abend mit dem Debug-Logging loggen und hier posten.

    Gruss
    Jochen
  7. Dominik

    Dominik Administrator Staff Member

  8. jochene

    jochene New Member

    Moin,

    wenn ich das anhängende Log richtig werte, liegt das Problem wohl nicht beim LogView sondern auf meiner Seite.

    Habt Ihr vielleicht eine Idee, woran es liegen kann?

    Danke für Eure Hilfe.

    Gruss
    Jochen

    Attached Files:

  9. Holger

    Holger LogView Team

    Hallo Jochen,

    da kommt z.B. eine Zeile im Logging vor, die folgendes zeigt:

    Daten als ASCII = '$3;1;7;541;543;0;0;0;0;0;0;0;0;28<CR>$3;1;8;541;543;0;0;0;0;0;0;0;0;27<CR>$3;1;9;541;543;0;0;0;0;0;0;0;0;26<CR><LF>'

    Die ohne <LF> empfangenen Strings werden aber zuvor gar nicht im Logging aufgeführt, merkwürdig.

    Irgend etwas bringt da die Zerlegung der im Eingangspuffer stehenden Zeichen in einzelne Datentelegramme durcheinander.
    Werden die Daten denn zeitlich sehr ungleichmäßig oder mit irgendwelchen anderen Besonderheiten gesendet?

    Wir werden auch versuchen, die Zerlegungsroutine bei OF-Empfang mit einem besseren Resync zu versehen, damit einzelne Störungen den Empfangspuffer nicht mehr so durcheinander bringen.

    Versuche doch bitte alternativ auch mal, Clustersize in der ini von jetzt -90 z.B. auf -20 zu setzen. Bei einigen anderen hat das in ähnlichen Fällen beim OF-Empfang geholfen.

    Gruß, Holger
  10. jochene

    jochene New Member

    Hallo Holger,

    danke.

    Clustersize werde ich heute abend mal probieren.

    Zum Sendeprotokoll wird Dir Wilhelm etwas sagen können.

    Ich schicke Wilhelm mal einen Mail.

    Gruss
    jochen
  11. wkrug

    wkrug New Member

    Seltsam ist, das das LF nicht in jedem Telegramm enthalten ist.
    Das kann eigentlich so nicht sein.
    Vom Telegramm her ist es so, das jede Sekunde ein Telegramm erzeugt wird.
    Diese Telegramme werden bereits im Telemetrie-Sender erzeugt und per Funk an den Empfänger, der beim Rechner steht übertragen.
    Das passiert 1*pro Sekunde.
    Sobald der Empfänger ein <LF> im Signal findet, berechnet er die EXOR- Checksumme und schickt dann den kompletten String über die serielle Schnittstelle mit 38400,8,N,1 raus.
    Es können also durchaus Pakete verloren gehen, da bei der Funkübertragung ja Fehler auftreten können.
    Das kann man daran erkennen, das Zeitstempel in den Telegrammen fehlen.
    Die Checksummenberechnung findet natürlich nur bis zum letzten Byte vor der Checksumme statt.
    Empfangene Strings werden beim Empfang eines $ Zeichens komplett gelöscht, um im Puffer immer nur gültige Daten zu haben.
    Da Logview ja keine Probleme macht, wenn man die Daten mit einem Terminalprogramm loggt und die Datei dann importiert, sollten die Telegramme eigentlich in Ordnung sein.
    Ob da wirklich <LF> nicht gesendet werden, werd ich versuchen mal nachzuvollziehen.

    Ich habe mir mal die Datei "SeriellInput.txt" mit einem HEX Editor angeschaut.
    Die <LF> sind bei jedem Datensatz vorhanden.
    Ein möglicher Fehler wär jetzt noch, das u.U. die Checksummenberechnung nicht stimmen würde.
    Aber auch das müsste sich bei .txt Import auswirken.

    @Holger
    Wenn Du meinst es bringt was, könnte ich die Baudrate niedriger einstellen.
  12. jochene

    jochene New Member

    Hallo Holger,

    habe mal ein wenig mit der "Clustersize" gespielt.

    Bei einem Wert zwischen -20 und -35 funktioniert das gut.

    Es kommen ganz lustige Sachen heraus, wenn man sich außerhalb dieser Werte befindet.

    In den älteren LV-Versionen hatten wir mit einer ClusteSize von -90 keine Probleme.

    Wie wird denn eigentlich die korrekte Clustersize für unsere Datensätze berechnet?

    Danke für die Hilfe.

    Gruss
    Jochen
  13. Dominik

    Dominik Administrator Staff Member

    Moin !

    Mal ne Frage zwischendurch ... Könntet ihr uns nicht mal einen Logger zur Verfügung stellen - auch leihweise würde ja reichen.

    Nur mal so als Idee :)
  14. jochene

    jochene New Member

    Hallo Domink,

    klar können wir Euch einen Logger testweise zur Verfügung stellen - baue gerade einen neuen Heli auf und der Telemetriesender ist im Moment somit nicht im Einsatz.

    Den einfachen Empfänger habe ich auch noch hier. Das große LipoVoltMeter ist im Moment leider stark im Einsatz, das Empfangsteil hat aber die selben Funktionen.

    Teile mir doch bitte Deine Anschrift per Mail/PM mit.

    Gruss
    Jochen
  15. Dominik

    Dominik Administrator Staff Member

    Moin !

    Ich bin im Moment etwas dicht was Geräte angeht - zumal haben wir übers WE Taufe von Junior.

    Schreib doch bitte Holger mal eine Mail -> holger ÄTTT logview DOTTTER info
  16. Holger

    Holger LogView Team

    OK, Kontakt ist aufgenommen, es geht in die nächste Runde. :)

    Gruß, Holger
  17. michaelw

    michaelw New Member

    Ich beobachte ein ähnliches Problem 2.5.0.240 mit OpenFormat das allerdings auch in der Vorversion schon auftrat.

    Ich habe das Ganze eingegrenzt auf folgendes:
    Zwei Nachrichten folgender Art werden direkt aufeinander gesendet.
    Danach gibt es eine längere Pause.
    $1;1;;280;275;-5;0<CR><LF>
    $2;1;;281;200;20;0<CR><LF>

    Die Nachrichten werden beim Lesen von der Schnittstelle in mehrere Blöcke geteilt (zu sehen unter serielle Daten).
    Beispiel:
    $1;1;;280;275;-5
    ;0<CR><LF>$2;1;;28
    1;200;20
    ;0<CR><LF>

    Nachdem die erste Nachricht erkannt wurde verschwindet vom Reststück das letzte Byte reproduzierbar (also jedes einzelne mal) im Nirvana.
    Im Buffer steht nun nurnoch:
    $2;1;;2

    Später wird dann für den Kanal 2 folgendes verarbeitet:
    $2;1;;21;200;20;0<CR><LF>

    Je nachdem welches Byte verschwindet ist die Nachricht entweder nur verstümmelt (da kein CRC) oder ungültig.

    Im Betrieb mit mehreren Kanälen tritt nach einiger Zeit dann eine vollständige Blockade ein; der Buffer füllt sich kilobyteweise mit Daten die nicht mehr verarbeitet werden können.

    Ich habe deswegen nun alle Datensätze in einem einzelnen Kanal, zwar
    verschwinden dort auch Daten in dieser Art, allerdings findet keine Blockade statt.

    Ich kann bei Bedarf noch Logs anfertigen.
  18. wkrug

    wkrug New Member

    Ja, so wird das bei uns ( Telemetriesender ) auch gemacht.
    Allerdings können da 1 oder 3 Datensätze ( Kanäle ) direkt hintereinander gesendet werden, mit einer Pause von ca. 1 sek. dazwischen.
  19. Holger

    Holger LogView Team

    Hallo,

    die Teile sind bei mir angekommen, Danke!
    Werde die Telemetrie dann so bald wie möglich in Funktion setzen und den LV-Empfang testen.

    Fehler der beschriebenen Art dürfen nicht auftreten. Ich habe auch schon eine Vermutung, wie es LV-intern dazu kommt.

    Gruß, Holger
  20. Holger

    Holger LogView Team

    So, hatte nun endlich etwas Zeit...

    Telemetrie läuft, feine Sache! Respekt!

    Empfang und Anzeige in LV funktionieren ohne Probleme, wenn ich Clustersize auf -30 stelle.
    Bei Clustersize = -90 tritt das beschriebene Verschlucken von Bytes auf. Werde ich nun mal untersuchen.

    Gruß, Holger
Thread Status:
Not open for further replies.

Share This Page