Announcement: there is an English version of this forum on Hallo und schönen Sonntag, ich habe aktuell zwei Geräte die über einen CMX868 (Modem IC http://www.cmlmicro.com/wp-content/uploads/2017/12/CMX868_ds.pdf) mittels DPSK (V.22) miteinander über recht lange 2-Draht Leitung (~5km) sprechen. Das funktioniert soweit recht gut, selbst bei der langen Leitung sowie bei gewissen Störeinflüssen. Ich würde allerdings gerne die Modem ICs, da recht schwer beschaffbar durch eine nahezu vollständige Softwareimplementierung ersetzen. Ich dachte daran einen STM32 zu verwenden, falls möglich ohne eingebauter DSP Einheit - falls nicht anders möglich aber auch welche mit eingebauter DSP Einheit. Die Grundsätzliche Frage erstmal, wird es möglich sein ähnliche Empfindlichkeiten und Rauschabstände zu erhalten, wie mittels Modem IC, oder wäre der Aufwand nicht Verhältnismäßig? Soweit ich weiß ließe sich eine FSK demodulation recht "simple" mit dem Görtzel Algorithmus berechnen, sollte dies nicht auch für eine PSK zutreffen? Zur Not würde ich aber auch auf eine FSK umsteigen, sollte das den Aufwand drastisch reduzieren. Ich nehme an, einige Wissende haben das vor einigen Jahren, als FSK und PSK mit niedrigen Baud Raten recht modern war schon gemacht, und können mir eventuell ein paar Hinweise geben? Danke!
Vielleicht käßt sich auch mit HART Modem ICs etwas machen. Hier ist ein Google Beispiel: https://datasheets.maximintegrated.com/en/ds/DS8500.pdf https://www.maximintegrated.com/en/products/interface/current-loop-products-4-20ma/DS8500.html https://www.onsemi.com/pub/Collateral/NCN5192-D.PDF http://www.analog.com/en/products/digital-to-analog-converters/4-20-ma/hart-modem.html Hier noch mögliche DSP Lösungen: https://www.silabs.com/documents/public/data-sheets/Si2494-39.pdf Naja, eine DSP Lösung gibts auch. Hier ein Beispiel: http://www.tij.co.jp/jp/lit/ds/symlink/tms320c54v90.pdf Softmodem: https://bellard.org/linmodem/ https://github.com/geofft/linmodem ftp://ftp.wayne.edu/ldp/en/Modem-HOWTO/Modem-HOWTO.pdf http://www.tij.co.jp/jp/lit/an/spra320/spra320.pdf https://github.com/jgaeddert/liquid-dsp http://ww1.microchip.com/downloads/en/DeviceDoc/70126c.pdf https://www.tapr.org/pdf/DCC1994-LowCostDSP4HF-KC7WW.pdf http://www.ti.com/lit/an/spra080/spra080.pdf http://www.ti.com/lit/an/spra073/spra073.pdf Entwicklungswerkzeuge: https://www.sigview.com/
:
Bearbeitet durch User
Hallo Gerhard, danke für deine ausgesprochen Umfangreichen Links! Es handelt sich dabei hauptsächlich um DSP Integrationen bzw. SoftModems für den PC. Lässt sich daraus schließen, dass es ohne DSP, das heißt nur mit einem ARM µC nicht möglich ist? Hast du selbst schon Erfahrung damit gesammelt? Kannst du eventuell auch zu der Frage, wie es sich im Vergleich zu dedizierten Hardware ICs (CMX868 zb.) verhält etwas sagen? Besten Dank
TI hat hier mir einem Cortex M4F (48 Mhz) mit DSP Erweiterung eine 125kBit BPSK gemacht, das ist ja schon fast DPSK. Ich denke also es sollte möglich sein: http://www.ti.com/lit/an/slaa681a/slaa681a.pdf Der Beispielquellcode dazu ist sehr überschaubar.
Hallo Thomas Thomas schrieb: > [...] > Die Grundsätzliche Frage erstmal, wird es möglich sein ähnliche > Empfindlichkeiten und Rauschabstände zu erhalten, wie mittels Modem IC, > oder wäre der Aufwand nicht Verhältnismäßig? Ja. Die integrierten Chips machen ja nichts anderes als ADC+Signalverarbeitung. Manchmal sogar komplett analog. > Ich nehme an, einige Wissende haben das vor einigen Jahren, als FSK und > PSK mit niedrigen Baud Raten recht modern war schon gemacht, und können > mir eventuell ein paar Hinweise geben? Wie hoch ist denn die Datenrate? Reche doch mal aus wie viele CPU Zyklen Du pro Symbol bzw. Sample brauchst. Ab 100 Zyklen/Sample wird es sicher gut gehen. Unter 30 würde ich es sein lassen. Viele Grüße, Martin Laabs
Andreas M. schrieb: > TI hat hier mir einem Cortex M4F (48 Mhz) mit DSP Erweiterung eine > 125kBit BPSK gemacht, das ist ja schon fast DPSK. Ich denke also es > sollte möglich sein: > > http://www.ti.com/lit/an/slaa681a/slaa681a.pdf > > Der Beispielquellcode dazu ist sehr überschaubar. Danke für den Link zur AN von TI, vorallem da ich ohnehin vorhabe einen Cortex M4F zu verwenden, damit stehen mir auch DSP und FPU Module zur Verfügung. Grundsätzlich würde mir auch eine BPSK reichen. Martin L. schrieb: > Hallo Thomas > Thomas schrieb: >> [...] >> Die Grundsätzliche Frage erstmal, wird es möglich sein ähnliche >> Empfindlichkeiten und Rauschabstände zu erhalten, wie mittels Modem IC, >> oder wäre der Aufwand nicht Verhältnismäßig? > > Ja. Die integrierten Chips machen ja nichts anderes als > ADC+Signalverarbeitung. Manchmal sogar komplett analog. > >> Ich nehme an, einige Wissende haben das vor einigen Jahren, als FSK und >> PSK mit niedrigen Baud Raten recht modern war schon gemacht, und können >> mir eventuell ein paar Hinweise geben? > > Wie hoch ist denn die Datenrate? Reche doch mal aus wie viele CPU Zyklen > Du pro Symbol bzw. Sample brauchst. Ab 100 Zyklen/Sample wird es sicher > gut gehen. Unter 30 würde ich es sein lassen. Mir würde eine Datenrate von 500 - 1000 Baus vollkommen reichen, komme also sicherlich auf über 100 Zyklen / Sample. > Viele Grüße, > Martin Laabs Macht es Sinn wie in der AN von TI den Modulator einfach mittels Timer und 180° Umschaltung zu realisieren, das heißt den Output komplett digital zu haben und dahinter eine reine analoge Filterung einzubauen, oder sollte man eher via DAC einen Sinus ausgeben lassen? Die Ausführung der Demodulation in der AN von TI ist auch recht abstrakt:
1 | if(start demodulation) |
2 | {
|
3 | recover clock from carrier sync bytes; |
4 | stage1 = fir(data); //optional |
5 | //synchronous coherent demodulation |
6 | stage2 = stage1 * clock; |
7 | stage3 = decision(stage2); |
8 | recovered data = stage3; |
9 | end demodulation; |
10 | } |
Das heißt ich muss zuerst den Takt Phasengenau rückgewinnen damit ich dies dann mit den Daten mischen (multiplizieren) kann?
> Macht es Sinn wie in der AN von TI den Modulator einfach mittels Timer > und 180° Umschaltung zu realisieren, das heißt den Output komplett > digital zu haben und dahinter eine reine analoge Filterung einzubauen, > oder sollte man eher via DAC einen Sinus ausgeben lassen? Man könnte (sollte) das Signal ja noch Tiefpassfiltern. Prinzipiell kann man natürlich auch den DAC verwenden, das wird aber recht aufwändig, da Du eine Menge Daten generieren musst. > Die Ausführung der Demodulation in der AN von TI ist auch recht > abstrakt: > >
1 | if(start demodulation) |
2 | > {
|
3 | > recover clock from carrier sync bytes; |
4 | > stage1 = fir(data); //optional |
5 | > //synchronous coherent demodulation |
6 | > stage2 = stage1 * clock; |
7 | > stage3 = decision(stage2); |
8 | > recovered data = stage3; |
9 | > end demodulation; |
10 | > } |
> > Das heißt ich muss zuerst den Takt Phasengenau rückgewinnen damit ich > dies dann mit den Daten mischen (multiplizieren) kann? Ja, um das zu demodulieren brauchst Du ja ein Referenzsignal. Dieses muss man generieren, erzeugt also intern ein "hypothetisches" Signal. Dazu hat man zwei Möglichkeiten: - Entwender man legt sich auf ein Protokoll fest bei dem die ersten Bytes bekannt ist und passt bei jedem Datenpaket sein Referenzsignal so an, das der bekannte Teil übereinstimmt und extrapoliert dann das Referenzsignal in die Zukunft (mit fester Phase). So macht man das z.B. bei DAB - Oder man optimiert das Referenzsignal fortlaufend indem man ein Fenster über die letzen Empfangenen Bits/Daten schiebt und die Signalfrequenz/-Phase so anpasst dass die Differenz immer genau 0 oder 180 Grad ist Denke dran, dass das TI Beispiel nur "simplex" beherscht. Für Duplex müsstest Du zwei verschiedene Frequenzen nehmen, so wie das auch dein IC macht.
Andreas M. schrieb: >> Macht es Sinn wie in der AN von TI den Modulator einfach mittels > Timer >> und 180° Umschaltung zu realisieren, das heißt den Output komplett >> digital zu haben und dahinter eine reine analoge Filterung einzubauen, >> oder sollte man eher via DAC einen Sinus ausgeben lassen? > > Man könnte (sollte) das Signal ja noch Tiefpassfiltern. Prinzipiell kann > man natürlich auch den DAC verwenden, das wird aber recht aufwändig, da > Du > eine Menge Daten generieren musst. Würde es Sinn machen, per DAC / PWM einen Sinus stufenförmig anzunähern, oder würde das die Übertragung weder verbessern noch verschlechtern? Ich würde eine Übertragungsfrequenz im Bereich 2 - 3 kHz verwenden, das heißt selbst mit einer PWM hätte ich vermutlich die Möglichkeit den Sinus anzunähern. >> Das heißt ich muss zuerst den Takt Phasengenau rückgewinnen damit ich >> dies dann mit den Daten mischen (multiplizieren) kann? > > Ja, um das zu demodulieren brauchst Du ja ein Referenzsignal. Dieses > muss man generieren, erzeugt also intern ein "hypothetisches" Signal. > Dazu hat man zwei Möglichkeiten: > - Entwender man legt sich auf ein Protokoll fest bei dem die ersten > Bytes bekannt ist und passt bei jedem Datenpaket sein Referenzsignal so > an, das der bekannte Teil übereinstimmt und extrapoliert dann das > Referenzsignal in die Zukunft (mit fester Phase). So macht man das z.B. > bei DAB > > - Oder man optimiert das Referenzsignal fortlaufend indem man ein > Fenster über die letzen Empfangenen Bits/Daten schiebt und die > Signalfrequenz/-Phase so anpasst dass die Differenz immer genau 0 oder > 180 Grad ist Kannst du mir einen kleinen Anstoß geben, wie man das am Besten implementiert? Ich nehme zb. kontinuierlich via ADC Samples der Leitung, angenommen ich implementiere zb. 100ms 2kHz ohne einen Phasensprung, danach einige Byte Präambel mit definierter Datenabfolge um den Sync herzustellen, wie detektiere ich den ersten Phasensprung, damit ich quasi die Einleitung der Präambel erkennen kann? Weil zu diesem Zeitpunkt habe ich ja noch keinen kohärenten Referenztakt, den muss ich ja daraus erst erzeugen. Oder hättest du ein paar Schlagworte oder Literatur in der ich mir etwas dazu durchlesen könnte? > Denke dran, dass das TI Beispiel nur "simplex" beherscht. Für Duplex > müsstest Du zwei verschiedene Frequenzen nehmen, so wie das auch dein IC > macht. Wenn ich lediglich Halb Duplex benötige, und nur der "Master" die Kommunikation einleitet und der Slave lediglich Antwortet, können Master & Slave doch auf einer Frequenz arbeiten, oder? Besten Dank!
So einen MODEM-IC nachzubauen ist deutlich mehr Aufwand als du denkst. Denn es ist nicht nur die Signalverarbeitung, du braucht auch ein gescheites Analog Front end. Bei 1kBaud über 5km lohnt sich das nicht, das kann ja fast die olle TTY-Schnittstelle mit 20mA. GGf. noch per Optokoppler trennen, fertig.
Falk B. schrieb: > So einen MODEM-IC nachzubauen ist deutlich mehr Aufwand als du > denkst. > Denn es ist nicht nur die Signalverarbeitung, du braucht auch ein > gescheites Analog Front end. Hallo Falk, selbst wenn es am AFE scheitern würde, wäre es sicherlich schonmal für mich eine sehr sehr Lehrreiche Programmierarbeit, soetwas zu bewerkstelligen. Den Transmitterteil ansich sehe ich als schaffbar an. Wie ich allerdings beim Receiver den Takt korrekt rückgewinne ist mir noch ein kleines Rätsel. Möglichkeiten: 1) Per PLL den Takt rückgewinnen, nur wenn ich die PLL in Software löse, muss ich dort als fiktiven Referenztakt intern auch einen Sinus nachbilden, oder reicht es hier mit einem Rechteck zu arbeiten, den ich Phasengenau dem Eingang nachführe? 2) Bei Gleichrichtung des Einganges erhalte ich einen Takt der Phasengenau ist, aber doppelte Frequenz aufweißt - könnte man daraus etwas sinnvolles ableiten? > Bei 1kBaud über 5km lohnt sich das nicht, das kann ja fast die olle > TTY-Schnittstelle mit 20mA. GGf. noch per Optokoppler trennen, fertig. "fast" :D.
Moin, Mal meinen Senf dazu: Ja, ich glaub' schon auch, dass das mit einem STM32 auch ohne DSP-Faxen machbar ist. Sendeseitig wird man noch einiges an Filterung brauchen, ich glaub' das ist in dem TI-Dokument etwas zu kurz gekommen. Entweder man braucht knackige, ggf. umschaltbare Bandfilter nach der WhateverPSK oder man filtert die "digitalDaten" noch vor den I/Q Modulatoren. Das ist ueblicherweise sinnvoller. Da kann man die Filterung und das Upsampling leicht mit je einem Schieberegister und einem ROM machen. Klar sollte dann aus dem Prozessor was rauskommen, was moeglichst ohne oder nur mit wenig Extraaufwand auf die Leitung gehen kann, also am besten eingebauter DAC oder externer R2R; vielleicht auch als SigmaDelta Variante, wenn's Berechnen nicht zuviel CPU kostet. Monsteraufloesung wird man nicht brauchen, hoechstens noch einen Tiefpass gegen die Aliasspektren. Empfangsseitig muss man halt gucken, dass die Pegel und Stoerspannungsfestigkeit irgendwie zum ADC des Prozessors passen/passend gemacht werden. Taktrueckgewinnung wird bei der Signalverarbeitung dann der springende Punkt sein. Bei BPSK kriegt man durch Quadrierung des Eingangssignals einen doppelten Takt, bei QPSK wird das mit 2x quadrieren klappen, nur kriegt man dann den 4fachen Takt und muss sich dann den passenden noch irgendwie raussuchen und weiterverarbeiten vom verrauschten, wackeligen Sinus zu einem Signal was bei ziemlich vielen DSP-Takten low ist und bei genau einem Takt hi, und genau zu diesem Zeitpunkt wird dann der Wert vom empfangenen I und Q festgelegt. Verbindung zum Rest der digitalen Welt ist auch noch ein Thema; der Original-IC hat da ja was SPI-artiges. Bis das in allen relevanten Kommandos laeuft, wirds auch ein paar Zeilen C brauchen... Aber nochmal: Rein performancemaessig glaub' ich dass es geht. Wird aber laenger als ein Wochenend' dauern, die Software dafuer zu stricken. Gruss WK
@Thomas (Gast) >selbst wenn es am AFE scheitern würde, wäre es sicherlich schonmal für >mich eine sehr sehr Lehrreiche Programmierarbeit, soetwas zu >bewerkstelligen. Mag sein, aber deine ursprüngliche Motivation war der Ersatz schwer beschaffbarer ICs. >Den Transmitterteil ansich sehe ich als schaffbar an. Wie ich allerdings >beim Receiver den Takt korrekt rückgewinne ist mir noch ein kleines >Rätsel. Überabtastung + Taktrückgewinnung durch clevere Statemachine. Gerade bei solchen niedrigen Baudraten ist das kein Problem, schon gar nicht mit einem halbwegs modernen uC.
Angehängte Dateien:
-
PSK.PNG
211 KB, 150 Downloads
Dergute W. schrieb: > Moin, > > Mal meinen Senf dazu: > Ja, ich glaub' schon auch, dass das mit einem STM32 auch ohne DSP-Faxen > machbar ist. > Sendeseitig wird man noch einiges an Filterung brauchen, ich glaub' das > ist in dem TI-Dokument etwas zu kurz gekommen. Entweder man braucht > knackige, ggf. umschaltbare Bandfilter nach der WhateverPSK oder man > filtert die "digitalDaten" noch vor den I/Q Modulatoren. Das ist > ueblicherweise sinnvoller. Da kann man die Filterung und das Upsampling > leicht mit je einem Schieberegister und einem ROM machen. > Klar sollte dann aus dem Prozessor was rauskommen, was moeglichst ohne > oder nur mit wenig Extraaufwand auf die Leitung gehen kann, also am > besten eingebauter DAC oder externer R2R; vielleicht auch als SigmaDelta > Variante, wenn's Berechnen nicht zuviel CPU kostet. Monsteraufloesung > wird man nicht brauchen, hoechstens noch einen Tiefpass gegen die > Aliasspektren. Moin, bei einer BPSK ist doch der Q Anteil konstant 0 und nur der I Anteil wechselt zwischen +1 und -1, oder? Das heißt eine richtige "I/Q Modulation" gibt es hierbei ja nicht. Ich dachte daran, eine Halbwelle (oder 1/4) eines Sinus im RAM oder Flash abzulegen, einen Takt zu generieren der mit zb. 100kHz läuft und mir bei jedem Interrupt einen neuen Wert für den Teilsinus lädt, das gebe ich dann an einem DAC aus. Bei jeder fertigen Halbwelle bzw. Vollwelle entscheide ich dann je nach zu übertragenen Daten ob der Sinus ein positives oder negatives Vorzeichen bekommt (180° Phasendrehung). Damit müsste ich doch schon ein gutes Sendesignal einer BPSK erzeugen können, oder nicht? > Empfangsseitig muss man halt gucken, dass die Pegel und > Stoerspannungsfestigkeit irgendwie zum ADC des Prozessors passen/passend > gemacht werden. > Taktrueckgewinnung wird bei der Signalverarbeitung dann der springende > Punkt sein. Bei BPSK kriegt man durch Quadrierung des Eingangssignals > einen doppelten Takt, bei QPSK wird das mit 2x quadrieren klappen, nur > kriegt man dann den 4fachen Takt und muss sich dann den passenden noch > irgendwie raussuchen und weiterverarbeiten vom verrauschten, wackeligen > Sinus zu einem Signal was bei ziemlich vielen DSP-Takten low ist und bei > genau einem Takt hi, und genau zu diesem Zeitpunkt wird dann der Wert > vom empfangenen I und Q festgelegt. Zum Thema Empfang: Ich habe versucht in Mathcad die Signalformen darzustellen. y(x) entspricht meinem BPSK modulierten Signal z(x) entspricht einem Rechtecksignal welches die gleiche Frequenz und gleiche Phase wie der Trägersinus hat. Die dicke grüne Linie entspricht y*z -> demoduliertes Signal welches nurnoch gefiltert werden müsste. Im unteren Diagramm ist y(x)*y(x) zu sehen, also das quadrierte BPSK Signal, gleiche Phasenlage aber doppelte Frequenz. Wie ich sehe ist mit dem so nichts anzufangen. Das heißt ich müsste aus dem y(x)*y(x) zu meinem z(x) kommen, indem ich die Frequenz halbiere. Ich nehme an, dies ist wiederrum am saubersten per PLL möglich, korrekt? > Verbindung zum Rest der digitalen Welt ist auch noch ein Thema; der > Original-IC hat da ja was SPI-artiges. Bis das in allen relevanten > Kommandos laeuft, wirds auch ein paar Zeilen C brauchen... Glücklicherweise muss ich den Modem IC nicht komplett nachempfinden, das heißt ich tausche sowieso Sende + Empfangseinheit aus, und bin damit sehr offen für meinen Datenaustausch. > Aber nochmal: Rein performancemaessig glaub' ich dass es geht. Wird aber > laenger als ein Wochenend' dauern, die Software dafuer zu stricken. Die Zeit spielt erstmal glücklicherweise keine Rolle, soll ja zum lernen auch dienen :). > Gruss > WK Falk B. schrieb: > Überabtastung + Taktrückgewinnung durch clevere Statemachine. Gerade bei > solchen niedrigen Baudraten ist das kein Problem, schon gar nicht mit > einem halbwegs modernen uC. @ Falk: Heißt das du würdest einen komplett anderen Ansatz wählen als ich oben dargestellt habe?
Moin, Thomas schrieb: > Damit müsste ich doch schon ein > gutes Sendesignal einer BPSK erzeugen können, oder nicht? Wenn du das so machst, hat dein Sendesignal doch so komische Knicke im Verlauf. Sowas ist immer ein Zeichen fuer ein sehr breites Spektrum. Das will man eigentlich nicht haben. Deshalb muesstest du entweder das fertig modulierte Signal durch einen entsprechenden Bandpass schicken oder dein Modulationssignal von rechteckfoermig 1 und -1 vor dem Modulator (=Multiplizierer) durch einen Tiefpass, der dir's verschleift. Bei QPSK in z.B. DVB-S oder NICAM und wahrscheinlich diversen anderen Spezifikationen wird da ein root-raised-cosine-Filter genommen, weil das halbwegs gutmuetig in Zeit und Frequenzbereich ist. Und das dazu passende "matched filter" fuer den Empfaenger das selbe RRC ist. OK, nachdem das nix genormtes ist, was du da baust, kanns sein, dass das breite Spektrum dich (und andere?) nicht stoert... Aber dann ist eh' fraglich, ob man da nicht irgendein ganz anderes Verfahren hernehmen kann. Kommt halt auf die Eigenschaften (Daempfung, Bandbreite, Stoerabstand, ...) der Verbindung an. Gruss WK
Angehängte Dateien:
-
PSK2.PNG
78,9 KB, 165 Downloads
Dergute W. schrieb: > Moin, > > Thomas schrieb: >> Damit müsste ich doch schon ein >> gutes Sendesignal einer BPSK erzeugen können, oder nicht? > > Wenn du das so machst, hat dein Sendesignal doch so komische Knicke im > Verlauf. Sowas ist immer ein Zeichen fuer ein sehr breites Spektrum. Das > will man eigentlich nicht haben. Deshalb muesstest du entweder das > fertig modulierte Signal durch einen entsprechenden Bandpass schicken > oder dein Modulationssignal von rechteckfoermig 1 und -1 vor dem > Modulator (=Multiplizierer) durch einen Tiefpass, der dir's verschleift. > Bei QPSK in z.B. DVB-S oder NICAM und wahrscheinlich diversen anderen > Spezifikationen wird da ein root-raised-cosine-Filter genommen, weil das > halbwegs gutmuetig in Zeit und Frequenzbereich ist. Und das dazu > passende "matched filter" fuer den Empfaenger das selbe RRC ist. > OK, nachdem das nix genormtes ist, was du da baust, kanns sein, dass das > breite Spektrum dich (und andere?) nicht stoert... > Aber dann ist eh' fraglich, ob man da nicht irgendein ganz anderes > Verfahren hernehmen kann. Kommt halt auf die Eigenschaften (Daempfung, > Bandbreite, Stoerabstand, ...) der Verbindung an. > > Gruss > WK Hallo WK, meinst du diese Knicke wie im Anhang Rot markiert? Ansonsten müsste der Ausgangs nach einem passiven Filter doch annähernd so aussehen wie in dem dargestellten Verlauf im Anhang. Da man in den meisten Literaturen die DPSK genau so dargstellt sieht, bzw. diese Variante bei Zero Crossing zu schalten als die bessere beschrieben wird, dachte ich das wäre schon das zu übertragende Signal.
Thomas schrieb: > ich habe aktuell zwei Geräte die über einen CMX868 (Modem IC > http://www.cmlmicro.com/wp-content/uploads/2017/12/CMX868_ds.pdf) > mittels DPSK (V.22) miteinander über recht lange 2-Draht Leitung (~5km) > sprechen. Wenn es wirklich nur diese 2 Geräte sind, und nicht absehbar ist, dass da ein 3. Teilnehmenr mit dem gleichen alten Modem Interface hinzukommt, könnte man überlegen auf etwas Moderneres umzusteigen, das auch über 2-Draht geht: RS-485 z.B.
Moin, Thomas schrieb: > meinst du diese Knicke wie im Anhang Rot markiert? Genau die. Ja, man kann schon so arbeiten. Aber dieses Signal ist dann in der Form im Spektrum sehr breit. Guck' dir das Spektrum deines Datenstroms an, also das Spektrum ueber einen Sack voller Rechtecke. Da sind ja ziemlich viele Oberwellen drinnen, weil's ja rechteckig ist. Und genau dieses Spektrum dieser Recktecksignale mit den ganzen Oberwellen wird durch die Modulation nur in der Frequenz (von 0 auf die Sendefrequenz) verschoben. Die Form und Breite des Spektrums bleibt genau gleich. Das macht bei den ueblichen Anwendungen Probleme, weil die Uebertragungskanaele nicht beliebig breit sind; daher die Extrafilterung. Auf'm Satellit darf der DVB-S Transponder nicht einfach in den Nachbartransponder reinquaken; bei NICAM kommen unterhalb die analogen Tontraeger, oberhalb das Restseitenband des Nachbarbildtraegers (Opa erzaehlt vom Krieg). Zum Sendefilter hab' ich in deinem Datenblatt kein Bild gefunden, aber das Empfangsfilter gibts in Fig. 7b auf S. 15. So aehnlich wird das Sendefilter auch aussehen. Und nach solchen Filtern sieht dein Signal nicht mehr so akkurat geknickt aus ;-) Gruss WK
Dergute W. schrieb: > Ja, ich glaub' schon auch, dass das mit einem STM32 > auch ohne DSP-Faxen machbar ist. So ein 56k-Modem aus den 90ern macht die Signalverarbeitung auch in Software (allerdings auf einem DSP). Sollten aktuelle Controller (ohne DSP, dafür mit deutlich höherer Taktfrequenz) dazu nicht fähig sein?
Angehängte Dateien:
-
PSK_Filter.PNG
49,4 KB, 112 Downloads -
PSK_Filter_Demod.PNG
53,4 KB, 149 Downloads
Eric B. schrieb: > Thomas schrieb: >> ich habe aktuell zwei Geräte die über einen CMX868 (Modem IC >> http://www.cmlmicro.com/wp-content/uploads/2017/12...) >> mittels DPSK (V.22) miteinander über recht lange 2-Draht Leitung (~5km) >> sprechen. > > Wenn es wirklich nur diese 2 Geräte sind, und nicht absehbar ist, dass > da ein 3. Teilnehmenr mit dem gleichen alten Modem Interface hinzukommt, > könnte man überlegen auf etwas Moderneres umzusteigen, das auch über > 2-Draht geht: RS-485 z.B. Sollte es gut funktionieren, werden das noch ein paar Geräte mehr werden, die darüber kommunizieren müssen. RS-485 geht soweit ich weiß nur bis zu ~1.5km also zu wenig für mich. Dergute W. schrieb: > Ja, man kann schon so arbeiten. Aber dieses Signal ist dann in der Form > im Spektrum sehr breit. Guck' dir das Spektrum deines Datenstroms an, > also das Spektrum ueber einen Sack voller Rechtecke. Da sind ja ziemlich > viele Oberwellen drinnen, weil's ja rechteckig ist. > > Zum Sendefilter hab' ich in deinem Datenblatt kein Bild gefunden, aber > das Empfangsfilter gibts in Fig. 7b auf S. 15. So aehnlich wird das > Sendefilter auch aussehen. Und nach solchen Filtern sieht dein Signal > nicht mehr so akkurat geknickt aus ;-) > > Gruss > WK Im Anhang nochmal 2 Bilder, mit nachgeschaltenem Filter und mit Filter + Demodulierung (bitte nicht auf die Skalierung achten!). Gut soweit so klar, das heißt ich werde noch versuchen einen Filter in SW vor dem DAC zu schalten, damit ich die Oberwellen wegbekomme. Bleibt für mich jetzt noch die Hauptfrage der Taktrückgewinnung offen. Das heißt quadrieren + PLL oder doch ganz anders? Danke für eure Hilfe!
S. R. schrieb: > So ein 56k-Modem aus den 90ern macht die Signalverarbeitung auch in > Software Damals waren Programmierer aber noch richtige Programmierer! Ohne Matlab! Die wenigen verbliebenen haben heute lange graue Bärte und gehören zum unveräußerlichen Inventar von Firmen wie Google, Apple, Microsoft oder arbeiten als Kernel-Hacker bei RedHat, Canonical, Intel, AMD oder Nvidia oder haben sich zur Ruhe gesetzt und gehen eigenen Interessen nach.
Moin, Thomas schrieb: > Bleibt für mich jetzt noch die Hauptfrage der Taktrückgewinnung offen. > Das heißt quadrieren + PLL oder doch ganz anders? Keine Ahnung, da seh' ich auf Anhieb verschiedene Methoden: https://en.wikipedia.org/wiki/Carrier_recovery und danach eine Symbolrecovery... Musste halt mal experimentieren. Ich wuerd' das halt alles mal auf einem PC ohne Hektik in der Programmlaufzeit durchexerzieren und wenns dort (mit irgendwelchen kuenstlichen Signalen mit kuenstlichen Stoerungen) laeuft, mal gucken, wie lange das dann auf einem STM32 braucht. Wenns zu lange ist, dann halt solange optimieren, bisses passt. S. R. schrieb: > Sollten aktuelle Controller (ohne > DSP, dafür mit deutlich höherer Taktfrequenz) dazu nicht fähig sein? Woher soll ich das wissen? Ich schrub und denke doch, dass sie dazu faehig sind. (Ich denke auch, dass man das auf einem 8bit AVR hinkriegen muesste, aber da wirds wohl etwas tricky Assemblergefiesel und warum soll man sich mit Gewalt das Leben schwerer machen). Gruss WK
Moin, Hmm - grad' bin ich beim Pollin ueber ein Laptop-56k-Modem gestolpert, was der fuer 15 (in Worten: Fuffzehn) cent raushaut... (Best.Nr.:720175) Also dafuer kann man's nicht selbermachen :-)) Gruss WK
Das Problem ist leider, dass es zu denen keine Unterlagen oder technischen daten gibt. Waren die damals nicht ausserdem über die Soundkarte angebunden?
Hallo Thomas, Ich stehe momentan vor dem selben Problem und versuche eine BPSK-Demod. mittels eines STM32 durchzuführen. Gibt es bei dir Neuigkeiten bezüglich der Taktrückgewinnung oder hast du gar eine Lösung gefunden? MfG, Niclas
Danke für die schnelle Antwort, Es geht mir um BPSK31, also 31.25 Hz im 40m Band.
Thread beobachten
Seitenaufteilung abschalten