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
Da stimmt der Frequenzgang nicht. Mit einem RC-Filter könnte man da sicherlich noch was rausholen, ohne groß Aufwand.
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.
Außer dem Datenblatt gab es noch Applikationstexte: http://bitsavers.org/components/ti/_dataBooks/1986_TI_Telecommunication_Circuits_Data_Book.pdf ab PDF-Seite 250 Für 300 Baud auf Kurzwelle gab es eine Trickschaltung, ich meine der Takt wurde einfach durch 2 geteilt, und die Einstellung für 600 Baud verwendet.
:
Bearbeitet durch User
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.