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!
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.
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> WKFalk 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
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?
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
Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.
Wichtige Regeln - erst lesen, dann posten!
Groß- und Kleinschreibung verwenden
Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang