Hallo Johannes,
du solltest die Ideen von Makus nicht ganz so Ernst nehmen. Du hast eine digitale Signalquelle und willst sie digital weiter verarbeiten, da macht es nur begrenzt Sinn das Signal irgendwie analog zu wandeln und nach der Soundkarte mit viel Arbeit und Glück wieder was Digitales zu machen... Nimm die Idee mit dem Parallelport oder dem USB Joystick. Das ist einfach und funktioniert noch dazu...
Michael
Hi,
Genau. Und als zusätzlichen Tip (Bei Verwendung des Parallelports): Der einfachste Weg, die zeitliche Genauigkeit hinzukriegen ist, das ganze nicht unter Windows zu programmieren sondern unter gutem alten DOS (GW-Basic, Q-Basic - Gut, da ballen sich dem Mathelehrer vielleicht die Fäuste in den Taschen - also besser Turbo-Pascal), es also auf einer von DOS-Diskette gebooteten Kiste laufen zu lassen. Windows macht einfach "nebenher" eine Menge anderer Sachen und das läßt dann Zeitmessungen zu einem Glücksspiel werden. Das _kann_ man zwar auch in den Griff kriegen, aber in der Zeit, die man dazu braucht, ist das DOS-Programm für das Problem viermal geschrieben. Mann kann danach ja dann die Ergebnisse vergleichen zwischen "PC mit DOS-Diskette gebootet" und "Windows-DOS-Box".
Viel Erfolg! Michael Kutscher
-- www.kutschersoft.de
Tschuldigung, mal aus versehen das falsche weggestrichen ^^
Genau das sollen wir verhindern. Es geht ja darum diesen Vorführversuch auf einem Windowsrechner zum Laufen zu bringen, weil unser Lehrer Angst hat, dass ihm der DOS-Rechner mal kaputtgeht und er keinen Ersatz mehr bekommt.
MfG, Johannes Permoser
Hi,
Ähm, weiß Dein Lehrer nicht, daß man auch in einen Top-modernen Super-PC mit Window-Allerneust, eine DOS-Boot-Diskette reinschieben kann? (Ups, ich nehms zurück, wenn da das Diskettenlaufwerk wegmodernisiert worden ist... muß man sich eine DOS-Boot-CD brennen :-)Aber gut, ein besser nachvollziehbarer Grund wäre, daß man das alles mit Windows natürlich sehr viel eleganter darstellen kann, vom Graphik-Zeichnen auf beliebigen Druckern und Bildschirmen bis zur Weiterverarbeitung der Daten in Office.
Der Weg, das zu erreichen, wäre aber wie gesagt (wenn es was taugen soll) wirklich etwas steiniger. _Ich_ würde bei diesen Vorgaben einen ATMEL-AVR AT90S8515 (kleiner dürfte auch reichen) oder AT-Mega nehmen, dem ein Programm für die _komplette_ Messung verpassen und ihn seine Ergebnisse (letztlich eine Zahlenkolonne, braucht wohl nichts anderes als die Zahl der Zeiteinheiten die beim passieren jeweils eines Sensors vergangen sind) über die RS232-Schnittstelle an den PC abliefern lassen. Die dann einlesen und darstellen, geht mit dem "Windows-PC" dann sehr ordentlich :-) Materialaufwand: Der Microcontroller, ein MAX232 für die Schnittstelle, ein paar Kondensatoren, Kabel, Stecker und ähnlicher Kleinkram. Alles zusammen unter 20 Euro. Saubere Lösung, denn die serielle Schnittstelle wird dann genau so verwendet, wie sie gedacht ist. Den AVR in C oder gar Assembler zu programmieren wird (wenn Du damit keine Erfahrung hast) ein bißchen Zeit kosten, aber möglicherweise weniger Zeit, als es kostet, dem Windows-Rechner die "Nebenbeschäftigungen" abzugewöhnen.
Gutes Gelingen Michael Kutscher
-- www.kutschersoft.de
die
hoppla,... natürlich keinen Tiefpass,.. wir wollen ja die Hüllkurve. Also dann z.B. das Maximum über jewils (mindestens) eine Periode bilden...
Andreas.
:> Der einfachste Weg, die zeitliche Genauigkeit hinzukriegen ist, das ganze :> nicht unter Windows zu programmieren sondern unter gutem alten DOS :> (GW-Basic, Q-Basic - Gut, da ballen sich dem Mathelehrer vielleicht die :> Fäuste in den Taschen - also besser Turbo-Pascal), es also auf einer von :> DOS-Diskette gebooteten Kiste laufen zu lassen.
: Genau das sollen wir verhindern. Es geht ja darum diesen Vorführversuch : auf einem Windowsrechner zum Laufen zu bringen, weil unser Lehrer Angst : hat, dass ihm der DOS-Rechner mal kaputtgeht und er keinen Ersatz mehr Es gibt keinen "DOS-Rechner". Jeder derzeit aktuelle Rechner kann mit einem passenden Bootmedium nahezu jedes beliebige OS, also auch DOS nutzen.
??? Bis jetzt booten alle x86 Abkömmlinge klaglos z.B. ein DOS 5.0 von Diskette und ich gehe ganz naiv davon aus, daß das noch eine Weile so bleibt.
Jetzt lese ich gerade in der Beschreibung des Teils: "Nach der Messzeit von ca. 100 ms überträgt das M232 dann den gemessenen Wert an den PC." (Messung für Analogeingang) Das wäre natürlich für meinen Zweck total ungeeignet, da ich Kurzzeitmessungen machen möchte. Mal schaun welche Genauigkeit ich Parallelport und USB-Gamepad hinbekomme, ansonsten werd ich wohl einen Microcontroller basteln müssen (*grml)
MfG, Johannes Permoser
Hallo,
Johannes Permoser schrieb: > Jetzt lese ich gerade in der Beschreibung des Teils:
Da kannte ich die Anforderungen ja auch noch nicht.
Parallelport wäre mein Tip für günstig und schnell, aber wirkliche Erfahrungen habe ich damit leider nicht. Bei USB währe ich vorsichtig, ich kenne da jemanden, der mit einem durchaus professionellen USB-Interface ziemlich schlechte Erfahrungen gemacht hat.
mfg Björn Schrader
Naja, professionell wird's eh nicht werden. Ich hatte da eher an die Gamepad-Variante gedacht. ^^
MfG, Johannes Permoser
Hallo,
Johannes Permoser schrieb:
Meld dich mal hier, wenn du Ergebnisse hast. Das würde mich wirklich interessieren, wie die erreichbaren Werte aussehen.
Ansonsten gibt es unter
mfg Björn Schrader
Oder er nimmt einfach nen USB Joystick. Ich find die Idee wirklich gut. Hab mir letztens gerade einen gekauft und damit könnte man 4 analogwerte einlesen und 16 digitale. Und der ForceFeedback Ausgang kann dann noch die Sensoren wieder wachrütteln... *g* Theoretisch müsste man den auch direkt über den HID Treiber ansprechen können. Oder über irgendwelche Joystickfunktionen, wird sich auch nicht so wild sein. Aber was hast du denn genau für ein Timing, weil hier alle davon reden, dass das so schnell gehen muss?
Michael
Hi,
Naja, der Lehrer möchte wohl zukunftssicher planen und hat sowas wie einen Quantencomputer im Auge... selbstverständlich mit USB :-)
Gruß Michael Kutscher
Johannes Permoser schrub:
Meinst Du etwa Piezo-Sensoren? Die funktionieren aber anders...
Informationsbeschaffung und Recherche ist Voraussetzung jeder guten Arbeit. Die Quellen sind dann aber zu dokumentieren - plumpes Abkupfern ist auf jeden Fall pfui bäh, wenn Du etwa ein gleichartiges "Gesamtkunstwerk" oder wesentliche Teile davon schon fertig finden würdest. Aber Du investierst ja sowieso schon eigenes Hirnschmalz, wie man hier sieht. Auch gestandene Ingenieure tauschen sich hier aus und diskutieren Probleme und ihre Lösungen. Da ist nix Schlimmes dabei.
Genauso ist natürlich die Materialauswahl zu begründen und zu dokumentieren. Noch ein freundlicher Tipp: Je mehr Du schon während der Arbeit möglichst strukturiert mitnotierst (zumindest an wichtigen Stationen!), umso weniger Mühe hast Du später, wenn Du es nur noch zusammenschreiben musst!
Ansgar
-- Mails an die angegebene Adresse erreichen mich - oder auch nicht! Gültige Adresse gibt's bei Bedarf! Mails to the given address may or may not reach me - valid return address will be given when required!
"Axel Berger"
Es gab da mal was dass alles Dos < 6.22 mit einem K6/2 nicht lief. Ist das ein Serienfehler der behoben wurde?
Was bisher im Thread wohl noch nicht genannt wurde: Das Velleman USB-Board. Das hat etliche digitale und analoge Ein- und Ausgangskanaele.
Eine grundsaetzliche Frage scheint hier bisher nicht beantwortet worden zu sein: wie schnell soll der PC denn auf die Daten reagieren? Wie oft sollen diese Daten abgefragt werden?
Eine billige Moeglichkeit fuer USB sind uebrigens wohl auch USB-Gameport-Adapter. Auf der einen Seite 15-polig Sub-D, auf der anderen USB.
Gameport:
Als digitaler Joystick scheint es vier Knoepfe fuer vier Richtungen und vier weitere Knoepfe zu geben. (2.5/0 V)
Als analoger Joystick gibt's anscheinend zwei analoge Signale (0-100 kOhm auf 5 V), zwei Tasten, und das bis zu zwei mal.
Fuer Joysticks gibt's auch unterschiedlichste Software fuer DOS/Win/Linux usw.
Sollte der PC uebrigens einen Gameport direkt anbieten, so kann der genau das gewuenschte: 8 digitale Eingangssignale rasch auslesen.
Schoenen Gruss Martin
Makus Gr0n0tte schrieb:
Das lag daran, daß der K6 zu schnell war. Der Athlon wurde wieder künstlich gedrosselt. Turbo Pascal hatte u.A. ein Problem auf solchen Prozessoren.
Gruß Henning
-- henning paul home: http://www.geocities.com/hennichodernich PM: henningpaul@gmx.de , ICQ: 111044613
IIRC hat TurboPascal seine Zeitschleife kalibriert. Etwa so:
t1=lies_uhrzeit() for (i=1000; i; i--) t2=lies_uhrzeit() speed=komische_konstante/(t2-t1)
Der K6 war so schnell, daß die letzte Zeile ein "Division by 0" gab.
XL
Zeitwerte liegen im Hundertstelsekundenbereich und sollten doch mind. 2 geltende Ziffern haben.
MfG, Johannes Permoser
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.