Schaltungsvariante
für den Sparrow
von Ralf Beesner
Ich
habe bei der LM358-Version für sauberere Verhältnisse zu sorgen
versucht, indem ich die Eingänge auf etwa halbe Betriebsspannung gelegt
habe; das hat 3 Widerstände gekostet. Die intervierenden Eingänge
hängen etwas tiefer, damit aus den Komparatoren in Ruhelage ein "High"
rauskommt.
Das NF-Signal ist ja im wesentlichen ein Gemisch
aus Grundwelle und der 3-fachen Grundfrequenz, so dass sich gegenüber
einem Sinus etwas steilere Flanken und eine Einsattelung (um das
Maximum herum) ergeben. Geht man da mit einem Komparator ran. der ja
nicht genau im Nulldurchgang der Schwingung schaltet, sondern irgendwo
auf der Flanke, schaltet er nicht 50% der Zeit durch, sondern kürzer.
Da der Komparator das Signal dreht, ist das Tastverhältnis am Ausgang
also stets grösser als 50%, bei großen NF-Amplituden ist es nahe an
50%, bei kleineren schaltet der Komparator immer kürzer durch und das
Tastverhältnis wird immer größer. Irgendwann verschieben sich dann die
Signalflanken zwischen Takt und Datensignal so sehr, dass, wenn der
Mikrocontroller das Datensignal übernehmen soll, das Datensignal zu dem
Zeitpunkt immer auf "High" hängt. In der beigefügten Schaltung hatte
ich später dem festen Spannungsteiler aus den zwei 1 MOhm-Widerständen
ein Poti parallelgeschaltet. Da konnte man noch schöner sehen, wie sich
das Tastverhältnis ändert, wenn man mit dem Schaltzeitpunkt auf der
Flanke "rauf und runter rutscht".
An der Stelle kommen nun die
antiparallelen Dioden aus deiner letzten Schaltungsvariante ins Spiel.
Die verhindern nicht nur den von dir geschilderten Inversbetrieb der
OpAmp-Eingangstransistoren, sondern begrenzen das Eingangssignal und
versteilern die Flanken. Ersteres vermindert die Abhängigkeit des
Tastverhältnisses vom NF-Pegel, zweiteres nähert das Tastverhältnis
weiter an 50% heran. Die Signalformung mit den antiparallelen
Dioden ist zwar etwas brachial, aber sicherlich die simpelste Lösung
und anscheinend gut genug. Muss ich also mal nachbauen.
Bei
meinem Problem-Notebook hatte ich auch erste Erfolge: es klappt nur mit
den invertierten Wav-Dateien und in einem sehr engen Pegelbereich. Mit
dem Wissen funktionierte es sogar mit der 3-Transistor-Schaltung, aber
nur mit "handverlesenem" Pegel und dem Oszilloskop im Blick.
Komparatorschaltung
mit LM339
Die letzte LM339-Variante ,
allerdings mit 4 Schottkydioden und ohne die 100k-Widerstände, läuft
hier auf meinem Problem-Notebook Lenovo L530 endlich recht zuverlässig
unter Windows7, ohne die Atinies zu verfusen.
Ich
musste allerdings den 27 kOhm-Widerstand auf die Hälfte verkleinern, um
die Reset-Schwelle herabzusetzen, und muss den Soundregler etwas unter
100 Prozent einstellen.
Allerdings läuft diese Schaltung nun
gar nicht mehr unter meinem Lieblings-Linux. Auch nicht unter Debian7 -
jedoch unter Kubuntu 14.04, wenn ich aplay oder mplayer zum Abspielen
nehme (mit dem "Komfortplayer" Kaffeine geht's nicht).
Auf dem
Oszilloskop sehen die Signale sehr schön aus - keine Trapeze mehr,
sondern Rechtecke; das Tastverhältnis ist zwar etwas grösser als 50
Prozent, aber nicht mehr lautstärkeabhängig. Die Hardware dürfte also
kaum noch zu verbessern sein.
Dass es trotzdem
unter Linux Glückssache ist, scheint wohl an irgendwelchen Eigenheiten
der Soundkartentreiber zu liegen. Wer weiß, ob es die nur mit meiner
Sound-Hardware und nur unter Linux gibt. Der Android-Unterbau basiert
ja auf Linux; möglicherweise schlummern da auch einige
Inkompatibilitäten - ich habe allerdings keine Ahnung von Android
(nicht mal mehr ein Handy).
Signale aus der Soundkarte
So, ich habe mir mal angeguckt, ob sich die NF auf meinem
Problem-Notebook
zwischen Windows7 und Linux unterscheidet. Alles mit 330 Ohm Last am
jeweiligen
Soundausgang gemessen.
Unter Windows sind auf dem rechten Kanal sofort Schwingungen mit zu
Anfang 1,4
V Spitze zu Null, dann setzt in den Tiefen von Windoof oder in meinem
Player
irgend eine Pegelregelung ein, die das Signal gleitend auf 0,8
V
Spitze-Null abregelt. Auf dem linken Kanal kommen erst mal ein paar
Hüpfer mit
voller Amplitude, während die regelmäßigen Schwingungen bei etwa 1,2 V
einsetzen. Pegeleinstellung jeweils auf 98%, der Wert, bei dem das
Programmieren gerade noch klappt.
An der Stelle beginne ich mich bereits am Kopf zu kratzen - die Hüpfer
zu
Anfang hätte ich auf dem rechten Kanal erwartet, denn das ist doch der
Datenkanal? Stattdessen finde ich die auf dem linken. Der Hüpfer-Kanal
ist auch
der mit dem stabileren Oszillogramm - das sieht mir mehr nach Takt als
nach
Daten aus. Wenn das nicht zu abwegig wäre, würde ich sagen, die
Reset-Hüpfer
sind auf dem falschen Kanal.
Unter Kubuntu sind es 1,4V, auf beiden Kanälen; sowohl beim
Kommandozeilen-Player aplay als auch bei dem "Komfortplayer" Kaffeine
(mit dem es nicht funktionierte). Unter meinem Lieblingslinux
(Slackware)
sehen die Oszillogramme verwaschener aus (die übereinander liegenden
Amplitudenlinien streuen um ca. 10% und der Hüpfer fehlt völlig (wtf?)!
Da
scheinen die Soundtreiber des verwendeten Kernels oder die
Alsa-(Sound-)Utils
eine Macke zu haben.
Hinweis zum Aufbau des
Signals von B.Kainka
Der Datenkanal (rechts) beginnt mit einem Vorspann, der nur den
Reset-Zustand
einschalten soll. Geleichzeitig beginnt links ein Dauerpegel, der SCK
auf Null
zieht. Erst mit einer Verzögerung setzen die Impulsserien an SCK ein.
Die Idee
ist, am Datenkanal darf man beliebige rumklappern, solange SCK still
steht. Die
Vollaussteuerung mit einem DC-Pegel dauert etwas 20 ms und dann noch
einmal 20
ms mit entgegengesetztem Pegel. Hochohmig belastet sieht man
diese
andauernden DC-Pegel einigermaßen glatt, aber mit 330 Ohm und dem
Soundkarten
Ausgangs-Elko hat man bereits einen Hochpass, der wohl die
beobachteten
Hüpfer bewirkt.
Das Oszillogramm von Thomas Baum
zeigt übrigens schon die kleine
Impuls-Lücke für die Reset-Unterbrechung, hier am Beispiel der sehr
kurzen
Datenübertragung beim Fuse-Editor. Man sieht deutlich, dass der
Vorspann
wesentlich länger ist als die eigentliche Datenübertragung. Die vielen
hellen
Punkte im Signal sind Artefakte des Zweikanal-Choppers im Hameg HM203.
Alle möglichen Signalprozessoren, automatische Ohrschutz-Pegelwächter
und
sonstige Gemeinheiten rund um die Soundkarte sollen nach Möglichkeit
abgeschaltet
werden, was aber je nach Betriebssystem schwierig sein kann. Die
Hoffnung ist
aber auch, dass eine optimale Schaltung mit genügend Toleranz gegen
viele
dieser Softwarefilter immun sein sollte.
