Hallo, habe ein Problem mit der Auswertung meines FSK - Signals. Habe mir nach folgendem Prinzip einen Demodulator realisiert: * 2 Bandpässe (durch SCF Filter realisiert) filtern beide Frequenzen * Gleichrichtung mit 2 Hüllkurvengleichrichter * Vergleich mittels Komparator * Komparatorausgang an den RS232 Eingang meines uCS Das ganze funktioniert auch ganz gut, jedoch mit folgenden Nachteilen: * 2 Zustände am Ausgang (0,1) entsprechen 3 möglichen Zuständen (FREQ_0, FREQ_1, Keine Frequenz) * Während keine Daten übertragen werden muss die ganze Zeit die FREQ_1 ausgegeben werden, damit der Komperatorausgang auf High geht. Nur so kann das Startbit (Fallende Flanke) vom Uart des uCs detektiert werden! Gibt es für die Demodulation auch noch eine elegantere Möglichkeit als den Komparator? Das Prinzip der Demodulation mit den 2 Bandpässen und die anschließende Gleichrichtung möchte ich beibehalten. Vielen Dank im Voraus, mfg Mathias Habe mit Hilfe eines SCF Filters 2 Bandpässe realisiert und die 2 Frequenzen herausgefiltert. Anschließend habe ich beide Signale gleichgerichtet und mit einem Komperator verglichen. Den A
Dass kein Signal anliegt, siehst Du ja an der Eingangsamplitude, welche gleichgerichtet und kompariert werden kann. Du kannst Das ja so aufbauen, dass keine Frequenz und Frequ1 beide 1 ausgeben, oder andersherum: nur wenn Freq0 erkannt wird, ist der Ausgang 0. Kennst Du den 567 (ich glaube NE567) oder andere FSK-Demodulator-ICs? Was machst Du damit?
hallo profi thx für deine antwort.. genau so habe ich es ja inzwischen realisiert! von dem pll prinzip wollte ich eigentlich wegkommen, habe zuerst den xr2211 verwendet. habe nicht gerade die besten erfahrungen damit gemacht. (pll reißt ab wenn ich nicht dauerhaft daten ausgebe) außerdem benötige ich mit den scf filtern keine externen bauteile( außer 3 widerstände). somit muss ich nicht mit den toleranzen von kondensatoren leben. die 2 quarze die den 50 fachen takt der zu filternden Frequenzen liefern, spare ich mir, indem ich die beiden Frequenzen per uC ausgebe! (Pin Toggle on Timer Overflow mit Auto Reload Funktion) bis jetzt habe ich zum vergleich der beiden freq. einen externen comperator verwendet! spricht eigentlich etwas dagegen den uC internen comperator zu verwenden und das ergebnis über einen pin auf den uart eingang auszugeben? danke, Mathias
Hallo Mathias, die von Dir angesprochenen Probleme sind quasi hausgemacht, da Du den FSK-Modulator direkt aus dem asynchronen Signal einer UART speißt. Der funktionierende Ansatz lautet: Verwende ein Bitcodierung, die sich auch zuverlässig demodulieren läßt. D.h. beispielsweise, dass zu Beginn einer Übertragung eine eindeutige Kennung übertragen wird, die z.B. aus einem ständigen Wechsel aus 0 und 1 bestehen kann. Sowas läßt sich auch prima in Software eines Mikrocontrollers giessen. Natürlich kannst Du auch die UART-Version zum funktionieren bringen, indem z.B. der Komparator etwas empfindlicher auf den Kanal des Ruhezustands reagiert und somit auch dann in diesem Zustand bleibt, wenn kein Signal anliegt bzw. maximales Rauschen. In diesem Fall kannst Du aber auf die FSK verzichten und eine 100% AM mit einem Bandpass einsetzen. Das bleibt aber im Vergleich zu Deiner FSK eine minderwertige Lösung. Grüsse Christian
hmm irgendwie wäre es doch auch möglich den uart zu deaktivieren wenn keine der beiden frequenzen anliegt oder? so hätte ich meine drei zustände wieder: high, low, und empfang aus! theoretisch könnte ich doch auf den comperator verzichten und beide signale direkt in zwei Inputs meines uC's schicken. beide inputs würde ich dann so verknüfen: FREQ_0 0 1 0 1 FREQ_1 1 0 0 1 RS232_ON 1 1 0 0 OUTPUT 1 0 0 0 OUTPUT würde direkt mit Rxd verbunden werden. Um mit dem Uart einen Startimpuls detektieren zu können, müsste ich vor jedem Byte ein High Bit ausgeben! Das Ausschalten der RS232 müsste natürlich mit einer gewissen Verzögerung verbunden sein. Dürfte aber weniger ein Problem sein, da ich nur mit 300 Baud sende. Das einzige Problem was ich hierbei sehe ist, dass eine anliegende Freq. mindestens einen Pegel von 0,8V (TTL) haben müsste, um als ein detektiert werden zu können. Mfg, Mathias
Jetzt hat's irgendie den Server zerbröselt... nochmal: Du versuchst Dich da irgendwie um die Tatsache herum zu mogeln, dass Deine FSK in dieser Form einfach nur zwei Zustände übertragen kann. Stelle Dir nur vor, was passiert, wenn das Rauschen im Kanal groß genug wird (bei ausgeschaltetem Sender) Wenn die RX-UART damit nicht umgehen kann, war's das. Wenn Du aber sagst, ist kein Problem, weil Rauschen viel niedriger, kannst Du gleich wieder nur einen Ton tasten und auf eine Schwelle horchen -> fertig. Du kannst die Ausgänge der beiden Demodulatoren ggf. auch auf zwei ADC-Eingänge geben und Dir dann Schwellen wahlfrei überlegen. TTL ist sehr undefiniert, was das Verhalten "zwischen" den Pegeln angeht. Tun wird sich aber trotzdem was. Besser wäre aber schon die Nutzung von Schmitt-Trigger-Eingängen. Grüße Christian
@ christian: mit dem comperatorprinzip habe ich dann doch einen undef. zustand am ausgang wenn ich keine daten sende oder? dadurch könnte ja der uart eventuell ein byte empfangen wenn gar keines anliegt bzw. einen falschen startimpuls detektieren. als alternative könnte ich im ruhezustand dauernt freq. 1 übertragen. nur was macht es dann für einen unterschied wenn ich überhaupt nur eine freq. übertrage?? mfg, Mathias
Eben! Meine Meinung: Entweder FSK mit anderer Bitcodierung per "Software-UART" oder einzelnen Träger tasten mit der existierenden UART. Wenn der Empfänger der PC ist, muß halt für die FSK noch ein Controller vorgeschaltet werden, aber da kenne ich Deine Aufgabenstellung zu wenig. Grüße Christian
Noch eine Idee: Falls Du die Bitcodierung am Sender selber beeinflussen kannst, der Empfänger ein PC ohne zus. Controller sein soll, könntest Du als RX Pin nicht RXD verwenden, sondern eine der Handshake-Leitungen, z.B. CTS. Dann machst Du die Bitdecodierung in einem eigenen Thread, der per Performancecounter und Event-On-Pin-Change arbeitet. Bei 300 Baud sollte das kein Problem sein und wird auch konkret so gemacht, z.B. zur Decodierung von IR-Empfängern. Grüße Christian
hallo christian.. als empfänger verwende ich auch einen uC der jedoch ziehmlich an seinen leistungsgrenzen ist (software pwm) ... aus diesem grund habe ich das empfangen mittels uart gewählt! kann leider auch als kostengründen keinen zweiten uC verwenden der sich um die dem. kümmert! es bringt aber doch einen unterschied wenn ich 2 statt nur einer Freq übertrage, zumindest wenn ich das ganze per comperator vergleiche.
Wir drehen uns im Kreis... FSK ist besser wie Tontastung. Mangels vernünftiger Bitcodierung, kannst Du die nur einsetzen, wenn Du der FSK eine Schwelle, bzw. Vorzugslage verpaßt, die sicher über dem Rauschen liegt, was meiner Meinung nach nicht mehr besser wie eine Tastung eines Tones ist. Meine letzte Idee: Wenn Deine UART in der Lage ist, eine Break-Condition zu detektieren, könnte das eine prima Synchronisation für Deine Übertragung sein. Break-Error detektieren und ein paar Sync-Zeichen vor das Telegramm. Dann braucht's auch keine Vorzugslage mehr für die FSK. Grüße Christian
Die Aussage, man bräuchte eine vernünftige Bitcodierung, also einen Manchestercode ist nicht ganz richtig. Es gibt z.B. einige Langwellensender die senden ebenfalls FSK Daten, die man mit einem normalen UART empfangen kann, vorausgesetzt des FSK Dekoder funktioniert. Da gibt es auch keine Manchestercodierung o.ä.
Und? Wie machen die's? Es geht ja darum, auf den Start einer Sendung zu synchronisieren. Sprich, den Übergang von Bitrauschen zu sinnvollen Daten zu finden. Evtl. genügt es ja schon, den Sender im Zustand der Ruhelage einzuschalten, zu warten, z.B. 4 Bytezeiten und dann erst mit der Übertragung zu starten. Der Empfänger muß dann sämtliche Fehlerbits seiner UART abfragen und ständig zurücksetzen und auf eine Syncsequenz warten. Ja, das könnte gehen! Grüße Christian
Bitte 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.