OT: Soundkartenmodulation

[Markus Bauer]

hi,

tomtailor@freesurf.fr (chris) dixit:

OK, ich weiss, dass dieser Beitrag möglicherweise stümperhaft wirkt,
aber es geht "ratz faz" und man muss nichts programmieren.

Wenn es Tatsächlich um Sourcen (=Text sprich druckbare Zeichen) geht,
druck das ganze aus, und lies es mit einem OCR Programm wieder ein.
Heutzutage krigt man wirklich gute OCR's zum 10 Tage testen gratis im
Internet und ein Pagescanner welcher die Blätter durchzieht ist auch
nicht mehr so rar. Hatte mal ein ähnliches Problem und hat prima
funktioniert, allerdings war die Datei ein nur paar KB gross.

Natürlich war dies auch meine erste Idee. ASCII-only ist ja kein Problem,
hab schon ein kurzes Proggie geschrieben, welches mein Zip File in nen
ASCII-Hex Stream konvertiert.
Nur beinahe 100 Seiten sind mir doch etwas too much..wenns auch
besser/schneller geht

markus

 

[Markus Bauer]

hi,

"Martin Schönegg"
<martin.schoenegg#und_hier_ist_klar_was_hinkommt#@arcor.de> dixit:

| Also ich hab einen PC der ist komplett eingeschränkt, praktisch
keine
| Geräte drinnen, NT4, keine Rechte unsw. Davon will ich mir jetzt
eine
| Datei kopieren*.

auch wenn sich das ganze nicht so besonders legal anhört, weil sonst
würde man mal kurz zum Admin gehen und den bitten...

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

ECP sollte IMHO abwärtskompatibel sein. Ich sehe kein Problem darin.
Zur Not bereitest Du Deine Datei so auf, dass alles in den unteren 4
bits liegt und druckst diese einfach aus. Auf der Gegenseite

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

übernimmst Du die Daten auf einem 1:1 kabel an den Datenleitungen und
schreibst alles in ein File.

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

Nun filterst Du alles mit gesetzten Bit 4-7 heraus und setzt Deine
Nibbles wieder zu Bytes zusammen.
So ähnlich, nur mit dem Umweg über die Statusleitungen lief das bei
Laplink. Da Du aber kaum ein solches installieren darfst hilft Dir
Laplink & Co auch nicht weiter, sondern musst mit dem Druckerport
hantieren. Je nach Druckertreiber (zumindest die alten halten sich
dran) werden die Steuerzeichen alle im ASCII Bereich 127+ verwendet,
also mit gesetztem Bit 7. Also Nibbles machen, dann kannst Du
Steuerzeichen und Daten einfach trennen.
Due eigentliche Datenübertragung dürfte dann auch recht schnell vorbei
sein und das Aufbereiten ist dann doch wohl nicht mehr zeitkritisch,
oder?

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

 

[Markus Bauer]

hi,

"Dan Oprisan" <dandy1313@yahoo.com> dixit:

"Markus Bauer" <mc_@gmx.net> schrieb:

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach
dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

Hast du einen Drucker? Dann könnte man die Daten auf Papier drucken,

Ja.

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

eine 0 als Schwarzer Pixel eine 1 als weisser. Wenn deine Pixel 0.5 x
0.5 mm betragen kann man auf einer A4 Seite um die 28kB speichern. Die
Kodier-Software ist einfach geschrieben, das Einscannen/Dekodieren ist
ein bischen aufwändiger.

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 Koechy]

Markus Bauer schrieb:

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

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.

 

[Markus Bauer]

Hallo,

Markus Koechy <markus.koechy@web.de> dixit:

Markus Bauer schrieb:
Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach
dem Ausdrucken auf Papier).
- Parallelport
- Soundkarte

es gibt noch mindestens ein drittes Ausgabegerät an Deinem Computer:
der Monitor. Du könntest die Daten seriell durch einen schwarz-weiß

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

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...

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

 

[Carsten Kurz]

Markus Bauer schrieb:

Habe ich geschrieben - nein.

Du kannst im DOS Fenster problemlos jede Datei per Umleitung an den
Drucker oder eine serielle schicken und dort abgreifen. Dafür musst Du
noch nichtmal Software installieren.

Ich weiss, ein `Permission denied' hilft mir aber auch nicht weiter. Und
bei einer Umleitung über den LTP (der ja auch stink normal einen Drucker
ansteuert) kann ich gleich den vernünfigen Druckertreiber verwenden.

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

 

[Carsten Kurz]

Markus Bauer schrieb:

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...
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

 

[Holger Petersen]

Markus Bauer <mc_@gmx.net> writes:

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.

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

Weil
genau so ein Proggie brauche ich ja...

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

 

[Gernot Fink]

In article <cbu2m3$43t$05$1@news.t-online.com>,
Stefan Heinzmann <stefan_heinzmann@yahoo.com> writes:

Dan Oprisan schrieb:

"Dan Oprisan" <dandy1313@yahoo.com> schrieb im Newsbeitrag
news:cbu231$mv6$1@rzsun03.rrz.uni-hamburg.de...

"Markus Bauer" <mc_@gmx.net> schrieb:


Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten

(nach

dem

Ausdrucken auf Papier).
- Parallelport
- Soundkarte

Hast du einen Drucker? Dann könnte man die Daten auf Papier drucken,
eine 0 als Schwarzer Pixel eine 1 als weisser. Wenn deine Pixel 0.5

x

0.5 mm betragen kann man auf einer A4 Seite um die 28kB speichern.

Die

Kodier-Software ist einfach geschrieben, das Einscannen/Dekodieren

ist

ein bischen aufwändiger.


1MB wären 35 Seiten. Wenn du Papier sparen willst, kannst du ja das
Bild als Bitmap auf dem Monitor anzeigen und mit einer Web-Cam
einlesen. Das heisst natürlich weniger Pixel/Bild (vielleicht 10.000)
aber dafür mehr Bilder/sek

Aha, ich sehe jetzt fangen die ernsthaften Vorschläge an

Da hätte ich auch noch einen:
Man könnte die Daten auf dem Bildschirm anzeigen und einen Empfänger
bauen, der die vom Monitor abgestrahlten Signale auswertet.

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

 

[Michael Eggert]

Markus Bauer <mc_@gmx.net> wrote:

Hi!

Es wäre genial wenn es irgendwie möglich wäre, simple Daten (im Moment
hab ich sie als ASCII-HEX-Stream) in eine WAV Datei zu konvertieren,
sodass im Prinzip (so stelle ich mir das halt vor) ein HIGH einen hohen
Ton bedeutet und ein LOW einen tiefen.

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.

 

[Martin Schönegg]

| >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

 

[Martin Schönegg]

| 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

 

[Carsten Kurz]

"Martin Schönegg" schrieb:

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.

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 Gronotte]

"Markus Bauer"

Die zweite Möglichkeit wäre das ganze über die Soundkarte regeln zu
können.
Geschwindigkeit ist nicht sooo wichtig, Datenvolumen ca 1MB.
Es wäre genial wenn es irgendwie möglich wäre, simple Daten (im Moment
hab ich sie als ASCII-HEX-Stream) in eine WAV Datei zu konvertieren,
sodass im Prinzip (so stelle ich mir das halt vor) ein HIGH einen hohen
Ton bedeutet und ein LOW einen tiefen.
VBA hätte ich dafür zu Verfügung.

Diese WAV Datei könnte ich dann abspielen und direkt mit Line-IN vom
Notebook wieder aufnehmen und danach wieder irgendwie `demodulieren'.

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 => http://gronoworx.dyndns.org/haiflai/haiflai-help.html

 

[Martin Schönegg]

|
| 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

 

[Manuel Lausch]

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...

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
http://www.manuellausch.de/ng/viel_murks.zip runterladen. (Achtung: 4 MB)

Manuel

 

[Alex Wenger]

Hi,

Die zweite Möglichkeit wäre das ganze über die Soundkarte regeln zu
können.
Geschwindigkeit ist nicht sooo wichtig, Datenvolumen ca 1MB.
Es wäre genial wenn es irgendwie möglich wäre, simple Daten (im Moment
hab ich sie als ASCII-HEX-Stream) in eine WAV Datei zu konvertieren,
sodass im Prinzip (so stelle ich mir das halt vor) ein HIGH einen
hohen Ton bedeutet und ein LOW einen tiefen.
VBA hätte ich dafür zu Verfügung.

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.

 

[Martin Lenz]

Am Wed, 30 Jun 2004 18:26:27 +0200 hat Carsten Kurz
<audiovisual@t-online.de> geschrieben:

Markus Bauer schrieb:

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...
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.
Da ist Drucker/Scanner aber besser - deutlich mehr Auflösung.

--
Martin

 

[Carsten Kurz]

Martin Lenz schrieb:

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

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

- Carsten

 

[Wolfgang Horejsi]

"Markus Bauer" <mc_@gmx.net> schrieb im Newsbeitrag
news:Xns9517CC1162825markusbauergmxnet@213.229.60.102...

Unterm Strich bleiben einfach nur 2 realistische Möglichkeiten (nach dem
Ausdrucken auf Papier).
- Parallelport
- Soundkarte

Ausdrucken und mit OCR-Spftware wieder einlesen.

Quellcode gehört eh auf Papier.

--
Wolfgang Horejsi