Hallo HF-ler,
mit welcher Zeichenfolge kann man den Decoder des TCM3105 am besten
einstellen so das er auch gut ins Rauschen geht?
Gegeben: Decoder direkt am FM-Demodulator, keine Rauschsperre, Zeichen
0..255, 1 Start, 1..2 Stopbit. Die Baudrate beträgt 1200 Baud,
NF-Amplitude bei HF-Signal im Normbereich.
Es handelt sich um die Standardschaltung wie sie bei den alten 1200er
Paket-Radio-Modems verwendet wurde.
Momentan empfange ich zum Einstellen zyklisch in etwa dasda:
"1234567890ABCDEFGHIJKLMN"
Damit stelle ich das Decoderjustierpoti so ein das möglichst viele
Zeichen OK sind.
Kommt in Realo ein Block mit vielen "Nullen" dann ist der gut, kommen
Zeichen die eine "höhere" Zahl haben dann sind falsche dabei.
Mein Eindruck ist das sich das noch verbessern lässt.
Kurt
Abdul K. schrieb:> Da stimmt der Frequenzgang nicht.
Hm, die beiden Kennsignale haben keinen grossen Unterschied in der
Amplitude, es wird auch direkt vom IC zum Modulator und vom Demodulator
zum IC gegangen.
> Mit einem RC-Filter könnte man> da> sicherlich noch was rausholen, ohne groß Aufwand.
Hast du da einen Tipp oder Hinweis?
Das führt doch normalerweise zu Phasenverschiebung.
Kurt
Abdul K. schrieb:> Du benutzt gar kein Funkgerät?
Doch schon, aber ich versuche keine NF-Beeinflussung zu haben.
Darum möglichst gleich zum Modulator und Demodulator.
Kurt
Kurt schrieb:> Decoder direkt am FM-Demodulator, keine Rauschsperre, Zeichen 0..255, 1> Start, 1..2 Stopbit.
Asynchrone UART-Signale sind da völlig ungeeignet. Der TCM3105 versucht,
das Rauschen zu demodulieren, und der empfangende UART nimmt sich die
erstbeste fallende Flanke als (vermeintlichen) Beginn eines Bytes.
AX.25 verwendet stattdessen eine synchrone Uebertragung mit NRZI, und
die Flags (01111110) lassen sich gut von Rauschen unterscheiden.
Kurt schrieb:> Kommt in Realo ein Block mit vielen "Nullen" dann ist der gut
Das liegt daran, dass die 9 (8 + Startbit) aufeinanderfolgenden
Bitzeiten ohne Flanken dem UART helfen, wieder einen sauberen Anfang zu
finden. Mit 0xff sollte es ähnlich aussehen.
>Der TCM3105 versucht, das Rauschen zu demodulieren
Dazu gab es dann eine Squelch-Schaltung mit einem XR2211 PLL-Chip.
Beitrag "Re: Datenverbindung mit XR2206 und XR2211"
Die Links sind tot, man findet mit "packet squelch xr2211" oder auch
"DCD digitale Rauschsperre XR2211" aber noch vieles aus alter Zeit.
Hmmm schrieb:> Kurt schrieb:>> Kommt in Realo ein Block mit vielen "Nullen" dann ist der gut>> Das liegt daran, dass die 9 (8 + Startbit) aufeinanderfolgenden> Bitzeiten ohne Flanken dem UART helfen, wieder einen sauberen Anfang zu> finden. Mit 0xff sollte es ähnlich aussehen.
Eigentlich nicht, die Anzahl empfangener Zeichen ist korrekt, nach den
Nullen wird die Prüfsumme übertragen (zwei Bytes), dann kommt noch ein
Kontrollzeichen.
Die Prüfsumme hat falschen Wert (hohe Zahlen), das Kontrollzeichen
stimmt wieder (ist eine 3).
Also kann es eigentlich nicht am Synchronisieren auf die Startbits
liegen.
Ich werde mal eine komplette Reihe mit vielen Nullen und dazwischen
hohen Zahlen schicken und den Decoder darauf "trimmen".
Wenn der Empfang gut ist fehlt ja eh nichts, es geht halt uns letzte
Eckerl.
(ev. erwarte ich auch zuviel)
Kurt
Christoph db1uq K. schrieb:>>Der TCM3105 versucht, das Rauschen zu demodulieren> Dazu gab es dann eine Squelch-Schaltung mit einem XR2211 PLL-Chip.> Beitrag "Re: Datenverbindung mit XR2206 und XR2211"> Die Links sind tot, man findet mit "packet squelch xr2211" oder auch> "DCD digitale Rauschsperre XR2211" aber noch vieles aus alter Zeit.
Damit hatte ich schon mal rumgespielt, habs aber wieder sein lassen.
Es ist ein "Vorlauf" vorhanden der viel länger ist als eine Zeichendauer
(der Empfänger muss sich ja auch erst einschwingen), in dieser Zeit
werden keine Zeichen übertragen, somit kann sich die UART auf das erste
kommende Zeichen einstellen, es sei denn es kommen schon Rauschpulse
durch den TCM3105 durch die die UART starten. Aber dann geht ja eh schon
nichtsmehr.
Kurt
Kurt schrieb:> es sei denn es kommen schon Rauschpulse> durch den TCM3105 durch die die UART starten. Aber dann geht ja eh schon> nichtsmehr.
Doch, es muss nur gewährleistet sein, dass der UART auch in dem Fall
wieder einen Anfang findet.
Deshalb leitest Du die Daten am besten mit einer Weile High-Pegel ein,
der wird dann irgendwann als Stopbit des im Rauschen begonnenen Bytes
erkannt, und ab dem darauffolgenden Startbit (fallende Flanke) passt
alles wieder.
Ich würde für AFSK übrigens immer den Squelch des Empfängers verwenden.
Hmmm schrieb:> Kurt schrieb:>> es sei denn es kommen schon Rauschpulse>> durch den TCM3105 durch die die UART starten. Aber dann geht ja eh schon>> nichtsmehr.>> Doch, es muss nur gewährleistet sein, dass der UART auch in dem Fall> wieder einen Anfang findet.>> Deshalb leitest Du die Daten am besten mit einer Weile High-Pegel ein,> der wird dann irgendwann als Stopbit des im Rauschen begonnenen Bytes> erkannt, und ab dem darauffolgenden Startbit (fallende Flanke) passt> alles wieder.
Vornedran kommt ja eine Zeit ohne Daten, da gibts auch kein Startbit
(ausser es kommt Rauschen durch) und genügend Zeit für die UART ihr ev.
begonnenes Byte fertig zu machen.
Das erste Zeichen, sein Startbit, startet die Decodierung der Bytes,
gelingt das nicht ists schon vorbei.
Treten zwischendurch falsche Bits auf stimmt die Prüfsumme nicht und das
Telegramm wird verworfen, eine Korrektur hab ich nicht, war mir zu
aufwendig.
>> Ich würde für AFSK übrigens immer den Squelch des Empfängers verwenden.
Hab ich ausgeschaltet, bringt nur Verzögerung und ich muss einen
längeren Sendervorlauf einplanen. Am "Problem" ändert das nichts,
Zeichen durch Rauschen oder "fremde Sender" werden ignoriert und erst
wenn eine eindeutige Kennung angekommen ist wird weitergelesen. Mich
stört es halt das die Nullen so sauber angekommen sind und die hohen
Zahlen nicht. Darum werde ich es mit einer anderer "Einstellsequenz"
versuchen, obs was bringt wird sich zeigen.
Kurt
Kurt schrieb:> Momentan empfange ich zum Einstellen zyklisch in etwa dasda:> "1234567890ABCDEFGHIJKLMN"
Warum so kompliziert?
"55555555..." oder einfach ein Signalgenerator der mit 600Hz zwischen
Mark- und Space-Frequenz umschaltet, ist viel einfacher. Das entspricht
Zeichen mit 1200Bd 8,n,1
Eventuell stimmt der Pegel am RXB-Pin nicht. Ansonsten vielleicht mal
mit einem anderen Chip probieren. Mit dem Stichwort HART findet man
viele. Über die verwendeten Mark/Space-Frequenzen hast du ja nichts
geschrieben.
Da sind SCF drin, damit halbiert sich dann auch deren Takt. Könnte dann
auch Mark/Space-Freqzenzen halbieren. Mußt du das DB genauestens lesen
oder einfach ausprobieren.
http://www.symek.com/pdf/tnc2s.pdf
Das ist die Schaltung (ab S.37), der 4,433MHz Quarztakt ist extern
erzeugt, nicht mit dem internen Oszillator und kann auf die Hälfte
umgeschaltet werden.
Die "Digitale Rauschsperre" mit XR2211 ist auch enthalten.
TCM:
So jetzt wirds schon klarer.
Hier wurde nach den beiden NF-Frequenzen gefragt, um nichts Falsches zu
erzählen habe ich den Frequenzzähler angeworfen, den TCM-Eingang
umlegbar gemacht und noch den Oszi am Frequenzz. dazugeklemmt.
Es zeigte sich zu meinem Erstaunen eine Art Brumm, war aber keiner.
Die Amplitude des Empfängerausgangssignals schwankte in seiner
Amplitude, und zwar unabhängig davon ob ich eine 0 oder eine 1 oder
Daten ausgab.
Um das besser zu erkennen kam noch ein NF-Verstärker mit Lautsprecher
dran.
Da war es deutlich zu hören, es gab eine dritte Signalfrequenz
(Schwebung war hörbar).
Die Suche nach dessen Herkunft endete in den dem Messender
nachgeschalteten Leistungsmesser für die Anzeige der Sendeleistung.
Dieses dritte NF-Signal wird also da drinnen erzeugt, zumindest war es
weg wenn dieser ausgeschaltet wurde. Die Suche nach der Quelle kommt
erst noch.
Jetzt wird auch klar wieso die Decodierung durch den TCM3105 so
"seltsam" ist.
Aufgefallen ist das die Potieinstellung über einen weiten Bereich ohne
erkennbare grössere Auswirkungen auf die "Decodierschärfe" war/ist.
Aus früheren Einstellungen weis ich das es da durchaus eine gewisse
"Schärfe" gibt.
Achja, die beiden NF-Signale:
1200 Hz und 2200 Hz
"Bell 202"
Kurt
