OT: Soundkartenmodulation

hi,

"Martin Schönegg" dixit:

Der schöne Stern dort oben deutet auf eine Fussnote hin, in der ich mich genau dieser Frage annehme.

Das habe ich ja bereits gemacht (sind jetzt alles reine Text-ASCII Zeichen)

Das ist ja genau mein Problem, wie ich das am schnellsten/unaufwendigsten mache.

Aber wieso finde ich *NICHTS*, nicht einmal annähernd irgendwas, das mir einen `Drucker Emulator' beschreibt bzw sogar fertig programmiert ist? Weil genau so ein Proggie brauche ich ja...

markus

hi,

"Dan Oprisan" dixit:

Ja.

Einfach den Text ausdrucken und das ganze mit OCR machen war meine erste Idee. Nur ist die Seitenanzahl hier wirklich groß...

He, an diese Möglichkeit habe ich noch gar nicht gedacht. Hast du da auch die benötigten Ränder berücksichtigt? Und bist du dir SICHER, dass ein Scanner einen 0,5mm Pixel erkennt?? Ich nämlich überhaupt nicht :-( Da bin ich wieder bei meiner OCR Lösung, das braucht aber viel zu viel Resourcen (vor allem Zeit, Papier und Tinte)

markus.

Markus Bauer schrieb:

Hallo,

es gibt noch mindestens ein drittes Ausgabegerät an Deinem Computer: der Monitor. Du könntest die Daten seriell durch einen schwarz-weiß blinkenden Bereich auf dem Bildschirm (z.B. schwarz = 0, weiß = 1) ausgeben und einen Fototransistor darüberhalten oder auf der Scheibe festkleben. Ich schätze mal, dass das Weiß so hell und das Schwarz so dunkel ist, dass noch nicht einmal ein dem Fototransistor nachgeschalteter Verstärker (Schalttransistor/Schwellschalter) notwendig wird. Mit einem pull-up-Widerstand versehen kann man ihn direkt an einen Eingang des Druckerports anschließen und evtl. noch einen kleinen Kondensator zwischen Masse und Fototransistorausgang vorsehen, um das Monitorflimmern zu glätten (Tiefpass). Mit einem weiteren Fototransistor und einem weiteren separaten Bereich auf dem Monitor könnte man noch zusätzlich das Taktsignal übermitteln und so eine synchrone serielle optische Schnittstelle bauen. Morsen im Computer-Zeitalter...

Markus.

Hallo,

Markus Koechy dixit:

Es tut mir leid, das sagen zu müssen aber ich habe _wirklich_ an _alles_ gedacht. Auch den Monitor. Wirklich alles.

Tja, ganz gleich ist meine Idee nicht, wie deine. Aber bedenke doch bitte die Übertragungsrate. In der größten Theorie würden sich da 60Bit/Sekunde ausgehen. Und das ist mehr als nur utopisch. Selbst wenn ich mehrere Empfänger `basteln' würde - sagen wir 8 für ein Byte, dann wären es immer noch unmöglich.

Was an deiner Idee jedoch interessant klingt, ist, dass das ganze fast ohne Bauelemente zu machen ist. Bist du dir sicher, dass sowas gehen kann? Aber ist ein Taktsignal echt notwendig? Einen Wechsel von HIGH auf LOW kann man ja eh feststellen oder?!

Wenn du mir jedoch echt realistische Chancen für das gibst, probiere ich es echt - scheint mir fast irgendwie am unaufwenigsten - aber auch am unmöglichsten...

markus

Markus Bauer schrieb:

Merkwürdig. BTW - wenn da ne Soundkarte dran ist, hat die einen MIDI Treiber installiert? Das ist nämlich auch ne serielle. Aber ob Du da dann rankommst ...

Ich kann mir halt nicht vorstellen, daß, wenn die Kiste so zu ist, daß Du noch nichtmal an ne serielle rankommst, Du mit VBA oder Perl so hantieren darfst, wie Du dir das vorstellst. Ist denn überhaupt ein Drucker installiert? Wenn der nicht vom Typ TEXT ist, bzw. umgestellt werden kann, kannst Du das eh vergessen. LowLevel kannst Du auf den Druckerport unter diesen Umständen eh nicht zugreifen. Also muss es wenn über ein simples copy nach LPT gehen. Es gibt Centronics -> seriell Umsetzer zu kaufen. Es sollte prinzipiell möglich sein, damit die Daten vom LPT in ein Notebook Terminal zu kriegen.

Die Lösung mit der Soundkarte setzt vermutlich voraus, daß Du ein möglichst simples WAV Format schreiben kannst, denn Tools zum Abspielen von RAW Formaten dürften kaum installiert sein. Such Dir also Infos zum Aufbau von WAV Dateien und versuch, sowas mit Perl oder VBA zu erzeugen. Was für ein Coding man da sinnvollerweise nimmt, um einen ggfs. schrägen Audio-Eingang an einem Notebook zu überwältigen weiß ich auch nicht. Am einfachsten dürfte FSK sein, solange Du da unter 5KHz bleibst dürfte das sicher sein. Sonderlich schnell geht es aber nicht. Ne andere Möglichkeit wäre ein 8 Bit quantisiertes Frequenzmapping, also ne Art erweitertes FSK. Du musst Dir halt drüber im Klaren sein, daß das analog transferiert wird und die Ausgänge und Eingänge von PC Audiohardware mit allzu 'digitalen' Signalen gerne kurzen Prozess machen. PWM/PCM oder ähnliche Gags sind zwar schnell gebaut, aber durch eine großzügige RC Kombi auch schnell kaputt. FSK dagegen ist ziemlich robust.

- Carsten

Markus Bauer schrieb:

Wenn Du Zugriff auf ne Digitalkamera hast, würde ich einen Test machen, welche Zeichenauflösung auf dem Schirm noch zuverlässig als ASCII erkannt werden kann. Mal grob überschlagen dürfte es kein Problem sein,

150*60 Zeichen darzustellen und mit ner brauchbaren 3-4MPixel Kamera abzufotografieren. Das sind knapp 10KByte pro Foto. 100 Bilder für ein Megabyte. Kein Problem für eine übliche 256MByte CF Karte. Außerdem 'lesbar' und interaktiv korrigierbar. Keinerlei Elektronik muss gebastelt werden. Setzt allerdings zumindest ein Stativ vor dem Monitor voraus.

- Carsten

Weil der in purer Software gar nicht geht? Und wenn, dann wohl nur unter purem DOS...

Ein Standard-Druckerport hat nunmal nur _fuenf_ EIN-Gänge.

Eine normale Drucker-Schnittstelle erwartet mindestens: - acht Daten-AUS-Gänge - einen Strobe-AUSgang - einen BUSY-EINgang - eventuelle weitere EIN-Gänge: Paper-empty, Select und ACK. - eventuell weitere AUS-Gänge: Feed, Reset und Saelect_IN.

Und vor allem: eine recht schnelle Reaktion auf STROBE -> BUSY.

Ja, das ist Hardware: C'T 6/1988 Seite 168

Es gibt verschiedene Möglichkeiten, die fast alle darauf hinauslaufen, den Output nach seriell zu wandeln und so auf dem zweiten PC wieder einzulesen.

Eine war mit wenigen Bauteilen in einer anderen älteren C'T:

3-4 IC's parallel nach V24; Ausgabe weiss ich nicht aus dem Kopf. Du kannst per BASIC sicherlich eine Einzelbit-Kommunikations- Ausgaberoutine über die LPT-Schnittstelle programmieren; das Gegenstück auf der Empfangsseite mag in verschiedenen Sprachen machbar sein. Wenn das funktioniert kannst Du die Routine wahrscheinlich auf 2 oder gar 4 Bit Übertragung pro Takt aufbohren.

Ene (XMODEM-) Prüfsumme wäre empfehlenswert...

Gruss, Holger

Da fällt mir ja gleich was krankes ein:

Warum nicht das Videosignal auswerten. Durch geeinete Balkenbreiten könnte man direckt ein Serielles Signal erzeugen. Wenn man am Zeilenanfang immer ein Startzeichen sendet könnte das sogar mit beachtlicher geschwindichkeit gehen.

--
MFG Gernot

Hi!

Okay, dann mach ich mal nen konkreten Vorschlag zur Soundkarte:

Ein prima Verfahren hierzu wäre ein biphasencodiertes Signal zu nutzen. Der Vorteil hiervon: Es enthält keinen DC-Anteil (Kondensatoren im Signalweg stören nicht) und der Takt ist auch schon drin. Das ganze kommt in eine 8bit-wav die lediglich zwei Werte kennt,

0 (maximal negative Spannung am Ausgang, im folgenden "L") und 255 (maximal positive Spannung am Ausgang, im folgenden "H"). Die Daten liegen folgenderweise vor:

Ein Bit=1 wird durch Wechel + Wechsel ausgedrückt. Ein Bit=0 wird durch Wechel + kein Wechsel ausgedrückt.

Ich mache mal ein Beispiel. Fixed-pitch-font!

1. Zeile: Datenbits
2. Zeile: Wechsel / kein Wechsel
3. Zeile: 0 (L) oder H (255) in der wav-Datei

. | 0 1 1 0 1 0 1 1 . | . | W K W W W W W K W W W K W W W W . Prä | . L L L L | H H L H L H L L H L H H L H L H

Also immer wenn ein Datenbit 1 ist, wechselst Du zweimal zwischen H (255) und L (0), ist Dein Datenbit 0, wechselst Du nur einmal.

Nun musst Du noch den Anfang eines Byte erkennen. Das geht über eine sogenannte Präambel vor den Daten, links gezeichnet, Du wechselt viermal _nicht_. Viermal nichtwechseln kommt ja in den Daten nicht vor. Ob Du mit H oder L anfängst, ist übrigens egal, es zählt nur Wechsel oder nicht Wechsel. Wenn Du mit H aufhörst, fängt die nächste Präambel also mit vier H an.

Damit ist Dein Byte dann in 20 Einzelwerten codiert. Die Wavedatei aus den H und L spielst Du dann mit 11kHz Samplerate ab und nimmst sie im Laptop mit 44kHz wieder auf. Somit hast Du Deine H/L-Werte vierfach oversampled, das sollte eigentlich für eine ordentliche Decodierung genügen. 11kHz Samplerate / 20 Samples pro Byte macht immerhin 550Byte/s, damit bekommst Du 1MByte in 32 Minuten.

Viel Spaß! Michael.

| >Aber wieso finde ich *NICHTS*, nicht einmal annähernd irgendwas, das mir | >einen `Drucker Emulator' beschreibt bzw sogar fertig programmiert ist? | | Weil der in purer Software gar nicht geht? Und wenn, dann wohl nur unter | purem DOS... | | Ein Standard-Druckerport hat nunmal nur _fuenf_ EIN-Gänge.

Warum denn, er sagt doch, dass er einen ECP hat, der kann an allen Datenleitungen Ein und Ausgang sein. Unidirektional gabs bei XTs spätestens alles neuer als 386 kann bidirektional am Parallelport.

| Eine normale Drucker-Schnittstelle erwartet mindestens: | - acht Daten-AUS-Gänge | - einen Strobe-AUSgang | - einen BUSY-EINgang | - eventuelle weitere EIN-Gänge: Paper-empty, Select und ACK. | - eventuell weitere AUS-Gänge: Feed, Reset und Saelect_IN. | | Und vor allem: eine recht schnelle Reaktion auf STROBE -> BUSY.

Das darf schnell sein, muss aber nicht unbedingt. Wenn Du auf der Busy Leitung eine 1 liegen hast, dann wartet der Computer brav mit dem nächsten Wort. Wie das im einzelnen mit ACK und Co war müßte ich selbst noch einmal nachschauen, aber das waren IMHO alles Minimalzeiten, nicht maximal. In so eniem 0815 Drucker musste das ein

8051 Derivat erledigen, der war auch nicht sooo schnell. Das bekommst Du mit gängigen Rechnern schon gebacken. Am besten direkte Registerzugriffe und Byte schieben.

| >genau so ein Proggie brauche ich ja...

Und das wird der OP ja wohl selber schreiben müssen, weil alle anderen gehen zum Admin und bitten den um den kleinen gefallen, wenns doch nix illegales ist, warum solls dann so umständlich und geheim ausfallen... | | Es gibt verschiedene Möglichkeiten, die fast alle darauf | hinauslaufen, den Output nach seriell zu wandeln und so | auf dem zweiten PC wieder einzulesen.

Was ohne entsprechende Rechte unter NT schwierig werden wird.

| Du kannst per BASIC sicherlich eine Einzelbit-Kommunikations- | Ausgaberoutine über die LPT-Schnittstelle programmieren; das | Gegenstück auf der Empfangsseite mag in verschiedenen Sprachen | machbar sein. Wenn das funktioniert kannst Du die Routine | wahrscheinlich auf 2 oder gar 4 Bit Übertragung pro Takt | aufbohren.

Das dürfte ohne Zugriff auf eine HardwareDLL schlecht gehen

MArtin

| Und bist du dir SICHER, dass ein | Scanner einen 0,5mm Pixel erkennt?? Ich nämlich überhaupt nicht :-(

300 dpi sind ca 0,1 mm Auflösung, das reicht üppig. Da kannst Du noch ein Karo dazudrucken. MArtin

"Martin Schönegg" schrieb:

Das ist doch alles irrelevant. An den Druckerport kommt er unter so einem System doch garnicht ran, außer über einen konventionellen Druckbefehl - und dem ist egal obs ECP oder SPP ist.

- Carsten

"Markus Bauer"

Moin,

Ich habe mal ein Programm geschrieben, mit dem man Audio in Bilddaten und umgekehrt umwandeln kann. Zu deinem Problem: Ich habe gerade folgende Lösung gefunden:

1.) Du lädst eine Datei als Rohdatei in Paint oder sonstwo und speicherst diese als BMP. (Nur rauschen). 2.) Dieses BMP wandelst du mit Haiflai in eine Audiodatei um. 3.) Diese Wav-Datei kannst du dann auf einem Rechner abspielen und mit einem anderen aufnehmen. 4.) Wenn es sich um Rohe BMP-Dateien gehandelt hat, sind die Bilder hinterher noch brauchbar. Alle anderen Dateien sind danach Schrott, wegen den Eingangsfiltern und ungenauigkeiten von Soundkarten.

Gruß,

Markus Haiflai =>

| | Das ist doch alles irrelevant. An den Druckerport kommt er unter so | einem System doch garnicht ran, außer über einen konventionellen | Druckbefehl - und dem ist egal obs ECP oder SPP ist.

Hab ich doch weiter oben schon beschrieben, wie das geht...

MArtin

Mir war mal danach und hab das glatt mal ausprobiert. Das ergebnis bei mir war irgendwie ernüchternd. Nachdem ich erstmal mit bastlerischem Geschick das Umgebungslicht von den beiden Phototransistoren (Takt und Daten) abgeschirmt hab hatte ich nur mittels OP ein brauchbares Signal erhalten. Nur mit recht langsamer Taktung hab ich auch Daten fehlerfrei übertragen bekommen (etwa 4 - 5 sek/byte). Mit etwas Optimierung wäre da bestimmt noch etwas mehr rauszuhohlen, aber alles in allem ist es doch ne recht interessante Art Daten zu übertragen, wenns auch dem Markus net wirklich weiter hilft.

Wer sich viel Murks anschauen will kann sich ja mal die

runterladen. (Achtung: 4 MB)

Manuel

Hi,

warum denn überhaupt modulieren? Du gibst einfach für eine 0 einen Ton aund für 1 keinen Ton aus, wenn du das jetzt mit Start und Stop Bit und mit z.b 9k6 Baud machst, kannst du das Signal am Lineausgang einfach mit einem Gleichrichter gleichrichten und über einen Komperator auf deine Serielle geben. Fertig.

Am Wed, 30 Jun 2004 18:26:27 +0200 hat Carsten Kurz geschrieben:

Da ist Drucker/Scanner aber besser - deutlich mehr Auflösung.

--
Martin

Martin Lenz schrieb:

Wenn er da einen Drucker und Druckertreiber zu Verfügung hat, sicherlich.

- Carsten

"Markus Bauer" schrieb im Newsbeitrag news:Xns9517CC1162825markusbauergmxnet@213.229.60.102...

Ausdrucken und mit OCR-Spftware wieder einlesen.

Quellcode gehört eh auf Papier.

--
Wolfgang Horejsi