Hilfe zu TNC2multi

[DF2WKR]

Hallo,
ich habe ein Problem mit einem TNC2multi. Es stammt aus einem Nachlass.

Problem: Das Gerät reicht empfangene Pakete nicht zum Rechner durch.

Einstellungen:
- Baudrate zwischen TNC und Rechner = 9600
- Schalter am TNC auf 1k2*
- Stromversorgung über das Funkgerät (Alan77)
- unterer Speicherbereich mit Nord><Link eingestellt (Hostmode)
- keine Initialisierungsparameter in Paxon eingetragen

Folgende Tests wurden durchgeführt:

1. Zugriff mit Terminalprogramm über die serielle Schnittstelle geht
   Beim Anschalten des TNC werden im Terminal die Firmwareversion 2.7b und weiteres ausgegeben.
   "ESC i barney" wird angenommen und bei "ESC i" wird korrekt "* BARNEY *" zurückgegeben
   
2.  in Paxon schaltet das Gerät nach Einstellung des Com-Ports und der Baudrate auf Bereit
   
3. Mit Paxon kann eine Aussendung gemacht werden (Connect-Versuch auf eine andere Station)
   Die andere Station antwortet auch, kann das Paket also empfangen und verarbeiten.
   Alle Datenpakete kann ich auf einem anderen Rechner empfangen und bekomme den Text decodiert (mit SDR# und Soundmodem / mit Malahite-Clone als Receiver und Soundmodem)
   
   

Am TNC2Multi werden die eingehenden Datenpakete mit DCD und DCD1k2 signalisiert, aber es kommen keine Daten in Paxon an.

Kann mir jemand einen Tip geben, ob hier ein Defekt am TNC oder eine Fehlkonfiguration in Paxon vorliegt?

Gruß Rainer

Moinsen

ich habe genau das selbe Porblem mit einem TNC2Multi :-( Habe recherchiert wie ein Weltmeister und habe folgendes herausbekommen. Hoffe, das es weiterhilft !

"Wenn dein TNC2multi Signale von anderen Stationen korrekt dekodiert, aber ausgerechnet die eines zweiten TNC2multi nicht, deutet dies auf subtile Unterschiede in der Signalverarbeitung oder den Protokolleinstellungen hin.

Hier sind die wahrscheinlichsten Gründe und Lösungsansätze:

1. Inkompatible AX.25-Protokoll-Implementierungen

Obwohl beide Geräte TNC2 heißen, können sie unterschiedliche Firmware-Versionen mit leicht abweichenden AX.25-Implementierungen nutzen.

• Lösung: Vergleiche die genaue Firmware-Version beider Geräte (
  DISPLAY
  oder
  VERS
  Befehl). Stelle sicher, dass beide die gleiche Version verwenden, idealerweise die weit verbreitete TF2.7b. Manchmal sind ältere TNCs wählerisch bei neueren Protokoll-Headern.
  

2. Unterschiedliche Serialisierungs-Modi (KISS vs. Host/Terminal)
Dein WinGT-Programm erwartet möglicherweise Daten im KISS-Modus (ein rohes Datenformat, bei dem der PC die Protokollverarbeitung übernimmt), während das zweite TNC im Standard-Host-Modus sendet.

• Symptome: Das TNC leuchtet zwar, weil es das Signal erkennt, aber es reicht die Daten nicht in dem Format an den PC weiter, das WinGT erwartet, oder WinGT verwirft sie, weil sie nicht als saubere KISS-Frames ankommen.
  
• Lösung: Stelle sicher, dass beide Geräte im selben Modus arbeiten. Wenn WinGT den KISS-Modus erfordert, muss auf beiden TNCs der KISS-Modus aktiviert sein (oft mit dem Befehl
  @K
  oder
  KISS
  ON
  , gefolgt von
  STORE
  ). 
  

3. Abweichende Digipeater-Pfade oder Adressierung
Vielleicht ist das Problem nicht die Dekodierung der physischen Schicht (was die LEDs anzeigen), sondern die logische Schicht. Dein TNC dekodiert das Signal physisch, entscheidet aber, dass die Pakete nicht für es bestimmt sind oder auf einem falschen Digipeater-Pfad ( VIA ) ankommen, und zeigt sie daher im Terminal nicht an.

• Lösung: Überprüfe die
  MYCALL
  -Einstellungen und die Connect-Befehle (
  C [ZIEL-CALL] VIA [PFAD]
  ). Stelle sicher, dass die Rufzeichen korrekt eingetragen sind und die Pfade (z.B. nur direkte Verbindung ohne
  VIA
  ) identisch konfiguriert sind. 
  

4. Hardware- oder Jumper-Fehlkonfiguration (9600 Bd vs. 1200 Bd)
Die LEDs zeigen an, dass irgendein Träger oder Datenstrom empfangen wird, aber nicht unbedingt, dass er lesbar ist.

• Symptome: Wenn ein TNC auf 1200 Baud AFSK eingestellt ist, das andere aber intern auf 9600 Baud FSK (anderer Jumper-Satz), wirst du LEDs sehen, aber keine Dekodierung im Terminal. Die Signale sind für das menschliche Ohr oder Oszilloskop "gut", aber für den Modemchip des anderen TNC unlesbar. 
  
  
• Lösung: Vergleiche die Jumper-Einstellungen in beiden Geräten akribisch. Der TNC2multi hat unterschiedliche Jumper-Sets für AFSK (Audio) und FSK (Direct Frequency Shift Keying).
  
  

Empfohlener Test:

Tausche die Rollen der Geräte: Kann das "problematische" TNC die Signale des ursprünglich "funktionierenden" TNC dekodieren? Wenn nein, liegt das Problem definitiv an der Konfiguration des einen Gerätes.
Das Handbuch für das TNC2multi von IfD liefert detaillierte Informationen zu allen Jumper-Einstellungen und Befehlen, was bei der Fehlersuche sehr nützlich sein kann."

73 de DF2WKR