Datenweiterleitung zwischen TIdTCPClient und Serial Port

[Blumix]

Hallo Delphianer,

ich habe ein Problem bei der Weiterleitung von Daten zwischen einem TCP Client und einem Seriellen Port.
An dem Seriellen Port ist GPS Empfänger angeschlossen der Korrekturdaten von einem TCP Client(NTRIP Client) erhalten sollen.
Im Grunde ist es nichts weiter als eine Datenweiterleitung an den GPS Empfänger. Der GPS Empfänger verfügt über eine Auswertung
wie viele Pakete empfangen, erfolgreich verarbeitet und fehlerhaft waren.
Es werden zyklisch Daten vom NTRIP Client empfangen und an den Seriellen Port weiter geleitet. In diesen Datenpaketen können
0 Byte Werte vorhanden sein. Um diese Daten auch weiterleiten zu können wird nach dem öffnen des Seriellen Ports das RTS und das DTR Signal
auf "On" gesetzt.

Delphi-Quellcode:

try
  FComPort.Open;
  if (FComPort.Connected) then
  begin  
    FComPort.SetRTS(True);
    FComPort.SetDTR(True);
  end;
except
  // Fehlermeldung ausgeben
end;

Bei der Weiterleitung der Daten meldet der GPS Empfänger immer wieder fehlerhafte Pakete und ich weis nicht warum?

Deswegen habe ich das gleiche in C# nach gebaut und es funktioniert ohne Probleme. Kann mir hier jemand mit diesem Problem weiter helfen?

Verwendete Komponenten und Entwicklungssysteme:
- Delphi XE 6
- ComPort Library 4.11
- Indy Komponente

[jaenicke]

Hast du einmal mit Tools wie Free Serial Analyzer (kostenlos) oder Device Monitoring Studio (nicht kostenlos) verglichen was da an Daten geschickt wird?

Ich vermute ein Zeichenkodierungsproblem.

[Blumix]

Hallo jaenicke,

ich empfange vom TCP Client TIdBytes und sende diese direkt an den Seriellen Port.
Die nachfolgende Funktion läuft in einem Thread.

Delphi-Quellcode:

    if (TCPClient.IOHandler.CheckForDataOnSource(100)) then
    begin
      TCPClient.IOHandler.ReadBytes(ABytes, -1, False);
      if (Length(ABytes) > 0) then
      begin
        ComPort.Write(ABytes[0], Length(ABytes));
      end;
    end;

Ich habe die Datenpakete auch schon mit dem "Free Serial Port Monitor" verglichen und mir sind keine Veränderungen aufgefallen.

[Sherlock]

Von dem ByteArray möchtest Du das erste Byte senden, und gibst die Gesamtlänge des Arrays mit. Was genau bezweckst Du damit?

Zitat von Blumix:

        ComPort.Write(ABytes[0], Length(ABytes));

Ich vermute, daß Du den Pointer auf die erste Speicherstelle des Arrays senden musst.

Sherlock

[Blumix]

@Sherlock
Die Write Funktion sieht wie folgt aus. Um Fehler zu vermeiden gebe ich die Position mit an.
function Write(const Buffer; Count: Integer): Integer;

[Sherlock]

Buffer ist was für ein Datentyp? TByteArray oder PByteArray. Bin selbst oft genug bei der Verwendung solcher C-Übersetzungen auffe Schnauze gefallen, das ich jetzt intensiv darauf achte

Sherlock

[Blumix]

Mit diesem Buffer wird die WinAPI Funktion WriteFile angesprochen. In der MSDN steht dazu das dies ein Pointer ist.
Wenn ich mich recht erinnere wird in Delphi ein Buffer (VOID-TYP) auch so behandelt. Als ein Stück im Speicher mit einem Anfang und einer Länge.

[Blumix]

Ich habe jetzt nochmal die empfangenen Datenpakete mit Wireshark mitgeschnitten und die gesendeten Datenpakete im Serial Port Monitor angeschaut.
Dabei ist mir aufgefallen das ich mehrere kleine Pakete(zwischen 174 und 300 Bytes) im Wireshark sehe und im Serial Port Monitor werden nur Packete mit einer Größe
von 575 Bytes angezeigt. Es scheint mir so als würde ein Datenstau entstehen.

Der Com-Port ist auf eine Baudrate von 115200 eingestellt.

[mjustin]

Delphi-Quellcode:

    if (TCPClient.IOHandler.CheckForDataOnSource(100)) then
    begin
      TCPClient.IOHandler.ReadBytes(ABytes, -1, False);
      if (Length(ABytes) > 0) then
      begin
        ComPort.Write(ABytes[0], Length(ABytes));
      end;
    end;

Wie lang ist das Array ABytes? Wird es durch ReadBytes passend gemacht? Vermutlich nicht, es wird nach dem Aufruf von ReadBytes die Länge haben die es vorher hatte. Was die konstante Größe der Datenpakete erklärt, die an die serielle Schnittstelle gesendet wird.

Zitat:

when AByteCount contains -1, data is read from the data source until it is disconnected or the ReadTimeout value has elapsed.

ReadBytes reads data from the IOHandler data source until the number of bytes in AByteCount has been accumulated in InputBuffer, or CheckForDisconnect interrupts the read request.

Das bedeutet, der Code kann nicht funktionieren, da die Anzahl der gelesenen Bytes unbekannt ist. Sie kann kleiner oder gleich der Pufferlänge sein.

[Blumix]

Hallo Justin,

das ist nicht so. Wenn -1 in der Funktion übergeben wird liest er alles was im Buffer vorhanden ist ohne die Länge anzugeben.
Du kannst dir das gern im Indy Source Code anschauen. Dabei passt ReadBytes die länge des Arrays eigenständig an.
Wie sollte ich sonst überhaupt Daten in dem Array haben, ich habe schließlich nie die länge des Arrays gesetzt.