Beiträge von hexagon
-
-
Hallo,
Danke zu euren Tips soweit schonmal.

Ich hatte endlich mal wiede Muße mich dranzusetzen.Aber der Monitor ist ne harte Nuss. Ich hab auch die Schaltung noch nicht hinreichend verstanden. Da ist ja alles mit allem verkoppelt, wie soll man denn da vernünftig Ursache-Wirkung ausmachen können?
IC501 liefert den Rechteck wie am Messpunkt zwischen R509 und R511 beschrieben. Genau so lange bis die Spannung zusammenbricht. (1-2s) Dann bleibt das Rechteck bestehen, die Phase läuft aber durch. Danach wiederholt sich der Zyklus.
Mal ein paar Gedanken zum Aufbau von dem Ding generell:
- Ich wollte den Zeilentrafo ausbauen um die 28V Erzeugung zu testen. Nix. Wieso wird aus dem Trafo eine 12V Schiene ausgekoppelt (über D507) welche die Signalplatine versorgt... hätte man da nicht die Eingangs-12V nehmen können...
- bei ausgebautem Zeilentrafo gibts also keinen Saft an die Signalplatine, daher auch keine Ansteuerung über TP33 ins IC501, und daher auch keine 28V.
- Und der Flyback Konverter für die 28V ist über die H-Frequenz gesteuert... Ich denke der kriegt seine Ansteuerung über die Leitung die über R913 läuft. Damit hängt er über Q502 und Q503 am IC501.
- Was macht genau der Q902 "Error Amp"? - das ist die Spannungsjustierung wenn ichs richtig verstanden habe...
- Testbildgenerator hab ich übrigens keinen.
- nochmal zurück zu dem Punkt was genau passiert: Die 28V sind kurz vorhanden, dann leises Klicken (Magnetostriktion oder Überschlag?), Zusammenbruch auf 12V, IC501 asynchron, Zyklus wiederholt sich (regelmäßige konstante Frequenz, ca. 1-2s).
Daher meine Überlegung:
- Überschlag? - aber so regelmäßig? Ein solcher Fehler müsste zufälliger Durchhauen und auch heftiger sein. Glaub ich nicht.
- Überlast? Aber wo? Vielleicht auch ein platter Elko daß ne Last nicht mehr zu stabilisieren geht.
Schliesslich sieht die Funktion ja vorhanden aus - bricht aber zusammen und startet neu - wenn das Gerät nicht konstant laufen kann wird es nicht warm genug um überhaupt ein Bild aufzubauen (Röhrenheizung) - erst dann wenn die Versorgung steht kann man mal schauen ob das Bild dann noch fehlt (wahrscheinlich nicht)
Momentan fehlen mir echt die Ideen... hab mir gerade 2 Bücher geschossen - "Erfolgreicher Fernsehservice" und "Fernsehtechnik ohne Ballast". Da mal reinschauen ob sich da was findet. Lässt mir keine Ruhe...

Viele Grüße
hexagon -
Hmmm. Definiere Raum Heidelberg... wie weit darfs denn weg sein?
Viele Grüße
hexagon -
Hmm. Das sind ja eher Massnahmen bei kein Bild aber Flyback in Ordnung. Die Heizspannung wird auch dem DST entnommen. Der wird aber eben über die 28V Schiene versorgt. Die Hochspannung wird auch in dem Trafo erzeugt, aber wie gesagt, da haperts schon auf der Primärseite). Dementsprechend denke ich daß ich an den Messpunkten nichts vernünftiges messen kann, ausser vielleicht ob ein sekundärer Schluss eine Überlast verursacht.
Hochspannungstastkopf hab ich leider keinen. Fehlt mir in der Werkzeugsammlung, brauch ich so selten

Das zusammenklappen der 28V geschieht mit einer Periode von ca 2s. Und man hört ein leises Klicken auf dem Bereich des Flyback. Könnte normales Geräusch vom Kern sein wegen Spannungssprung, vielleicht aber auch Isolationschaden. Ich würd fast dazu tendieren den Trafo zu tauschen. Kriegt man den Typ noch?
Viele Grüße (und ich finds gut daß sich da noch jemand über den Fehler Gedanken macht - Danke)
hexagon -
Ich war zwischenzeitlich schon mal dran, aber jetzt habe ich die Kiste mal wieder rausgekramt. Hat jemand schonmal Service an dem Monitor gemacht?
Was ich bis jetzt sehe: Die 12V Versorgung steht, aber im Monitor klappt die 28V Schiene zyklisch zusammen (messbar z.B. an TP91). Dabei wird die 12V Schiene (kommt von SX-64 Hauptnetzteil) jedoch nicht überlastet, die Sicherung F03 im Monitor (2A) bleibt drin.
Für das Fehlerbild kommen meiner Meinung nach leider ne ganze Reihe Ursachen in Frage. Zuerst mal die Frage liegt es an der 28V Erzeugung selbst (über Q907 und Ansteuerung), oder wird die 28V Schiene überlastet? Da hängt alles wesentliche dran, Q503 (Horizontalendstufe), DST, etc. In RöhrenTVs gibts ja normalerweise ne Brücke um das Netzteil von der Last zu trennen und mit einer Ersatzlast erst mal die Grundfunktion sicherzustellen, das scheint hier aber nicht vorgesehen zu sein. Müsste man notfalls die Leiterbahn unterbrechen und sowas dranbauen. Das wäre so mein nächster Schritt, dann wüsste ich obs um die Q9xx geht oder eher im Bereich Q5xx Probleme sind...
Irgentwelche Ideen? Fernsehtechniker hier? Für Ideen, Hilfe, Brainstorming wäre ich dankbar.
Viele Grüße
hexagon -
News:
Ich habe die neue, auf v-usb basierende Software jetzt mal zusammengestellt und auf eine Website gepackt.
Bitte melde dich an, um diesen Link zu sehen.
Dies war für die v-usb Freeware Lizenz erforderlich. Es wird nach wie vor der ATtiny2313 eingesetzt, der Einsatz eines ATtiny4313 ist jedoch auch möglich und wird für zukünftige Softwareerweiterungen wahrscheinlich zwingend notwendig.
Changes:
- Software mit gcc 4.5.2 übersetzt
- USB Treiber von avrusb auf aktuelle v-usb Version umgestellt
- PID/VID auf für v-usb Projekte vorgesehene Werte geändert
- USB Header Daten korrekt ausgefüllt
- Beide Joysticks heissen nun "Joystick" in der Spielsteuerung. (Und das selbst beim ATtiny2313 mit 2 KB Flash)
- Die Software kann auch für den ATtiny4313 übersetzt werden, der Chip ist pinkompatibel und hat mehr PlatzHinweis:
- Zukünftige Erweiterungen werden wahrscheinlich den 4313 brauchen. Es hat mich jetzt schon gewundert daß das zusätzliche Zeugs trotzdem noch in den 2313 gegangen ist. Ich denke der v-usb Treiber effizienter ist.ToDo:
- Linux Problem mit nur einem js0 Device checken
- unterscheidbare Joystick Namen, sowas wie "Joystick - 1", "Joystick - 2"Viele Grüße
hexagonEdit: Beitrag in eigenen Thread verlagert
-
Mal ein Zwischenstand. Ganz so trivial ist die Sache nicht.
Der Programmcode basiert auf dem v-usb ATMEL AVR USB Softwarecode. Im Code ist 1 Endpoint definiert, der USB HID-Descriptor hat für jeden Joystick eine Report-ID (also 2).
1.) Linux Thema
Hier habe ich noch nicht mit Linux getestet, aber gelesen daß Linux Schwierigkeiten hat 2 Geräte anzulegen wenn in einen USB HID Descriptor 2 Report-IDs drin sind. Hierbei gab es keine Aussagen ob das ein Problem von v-usb oder sogar von Linux selbst ist. Wäre auch möglich. Windows ist ok.2.) Anzeige der Namen in der Spielsteuerung
Zwei gleiche Namen sind kein Problem "Joystick". Zwei unterschiedliche wohl schon (Also "Joystick 1" und "Joystick 2"). Ich hab im Internet noch nichts gefunden was das kann. Hätte gerne ein Beispiel. Hier weiss ich noch nicht wie man zu den Report-IDs die Namen splitten kann.Eine mögliche, aber komplexe Lösung (möchte ich vermeiden): v-usb kann 2 Endpunkte handhaben. Das würde bedeuten daß sich der ATMEL nicht als 1 Gerät mit 2 Funktionen, sondern als 2 getrennte USB Geräte mit jeweils einer Funktion (also jeder Joystick für sich) anmeldet. Ok - das würde beide Probleme erschlagen, denn damit hätte auch Linux kein Problem und man könnte den beiden USB Geräten wahrscheinlich frei Namen vergeben. Will ich aber vermeiden, da ich dafür an für sich nicht tief genug in der Materie drinstecke um das umzubauen. Generell hätte ich nix dagegen wenn jemand hilfreich was weiss, aber ich denke die Problematik ist so spezifisch daß ich das mal in den entsprechenden v-usb / USB-Treiber Foren ansprechen werde.
Viele Grüße
hexagon -
Hallo wensa,
freut mich daß Dir mein Modul gefällt. So ganz hab ich aus Deiner Schilderung aber die Frage nicht rauslesen können. So wie ich es verstehe ist es so daß Deine Schaltung nicht ganz richtig funktioniert.
Vom Prinzip her gibts 2 Blöcke - zum einen die normale Anbindung des Eproms an den Bus und zum anderen die im Schaltbild dargestellte Zusatzlogik welche im 7400 untergebracht ist. Damit werden nach dem Einschalten die Eproms als $8000 Game Rom und als $a000 Basic Rom eingeblendet. Durch den Zugriff auf IO1 wird dann das Modul abgeschaltet und kann erst durch den Reset wieder aktiviert werden. Ich denke mal von der Logik wirst Du nicht abweichen können, das muss man schon so in der Art umsetzen. Die IO2 - IO1 Brücke Deiner Schilderung verstehe ich nicht. Wie kann ich Dir weiterhelfen?
Viele Grüße
hexagon -
Zitat
Was war denn der Grund warum es erst nicht lief mit dem neuen Tiny?
Meines Erachtens startete die fehlerfrei übersetzte Software im 4313, hatte aber USB-Timingprobleme. Daher wurde der Adapter nicht erkannt. Das avrusb / v-sub Paket macht die USB-Kommunikation softwaremässig mit Assemblerroutinen. Diese sind extrem zeitkritisch. Im v-usb Paket hat es deutliche Weiterentwicklung gegeben, da sind DEFINES vorgesehen um das auf sehr vielen ATtiny/ATmega Chips mit korrektem Timing zum Laufen zu kriegen.
**
Das Verhalten unter Linux schaue ich mir an.
Viele Grüße
hexagon -
Thread direkt nach "Programmieren" verschoben. Mal sehen, vielleicht ists auch unter "Laberecke" besser aufgehoben.
P.S.: Ich programmiere gerade an einer Firmware für den USB-Joystickadapter mit ATtiny4313 anstatt ATtiny2313. Da ist mehr Platz und deshalb können da ein paar Sachen besser gelöst werden.
-
Thema -> Assembler verschoben
-
Die alte Firmware hatte ein Platzproblem, da der ATtiny2313 nur 2 KB Flash hat. Daher waren alle Descriptor-Einträge ausgenullt, was unter anderem zu den seltsamen Zeichen bei den Einträgen in der Spielsteuerung führte. Die Firmware ging auch nur mit der 3.x.x avr-gcc Serie zu übersetzen, da 4.x.x etwas mehr overhead produziert und das schon nicht mehr reinpasste.
Die neue Firmware für den ATtiny4313 hat genug Platz für korrekt ausgefüllte Descriptoren. Das ist Vorraussetzung um z.B. auch das von Dir genannte Problem zu lösen, wenn es sogar nicht schon automatisch damit behoben ist.
Viele Grüße
hexagonP.S.: Wie kann ich das Problem unter Linux nachvollziehen? Ich habe eine ubuntu 10.04 Testkiste, aber wo muss ich da nachsehen wenn der Adapter angeschlossen ist und wie kann ich die beiden Ports unter Linux prüfen?
-
-
Ich habe nun aus dem letzten Stand des v-usb Pakets mal das Mouse-Demo auf dem USB-Joystickadapter mit ATtiny4313 zum Laufen gebracht. Ich werde die bisherige Software (diese verwendete einen alten Stand, damals noch avr-usb) dorthin portieren. Insofern bin ich zuversichtlich daß der Einsatz des 4313 möglich ist und durch den vergrösserten Speicher auch sinnvolle Descriptor-Daten hinterlegt werden können.
Viele Grüße
hexagon -
Zitat
Wo liegt das Problem?
Ich weiss es noch nicht. Von der Theorie würde es reichen das makefile anzupassen (also einfach den 4313 als target auszuwählen) und dann neu zu übersetzen. Läuft aber nicht. Ich verwende den 20100110 Release von WinAVR. Der erzeugt aber auch für den 2313 ein anderes hex-File (Grösse anders). Vielleicht gibts da schon ein Problem, ich werde zum einen mal sehen ob der Code für den 2313 so erzeugt wirklich läuft. Zum Anderen könnte es auch sein daß es in der Codeerzeugung für den 4313 ein avr-gcc Problem gibt (ist der mitgelieferte 4.3.3 von WinAVR), oder die Unterschiede (hauptsächlich Registererweiterungen) zwischen 2313 und 4313 doch was ausmachen.
Viele Grüße
hexagon -
-
-
Cool. Das wird heute abend gleich mal angetestet.

Viele Grüße
hexagon -
An einer flashbasierten Speicherkartenlösung für den Apple II bin ich prinzipiell auch interessiert. Allerdings ist meinApple II noch nicht ganz einsatzbereit, der zickt immer noch mit dem Floppycontroller rum.
Viele Grüße
hexagon -
Zitat
Dazu müsste der C64 aber I2C können ...

Eben nicht. Schau Dir die Datenblätter an. Der PCA9564 ist eine 8 Bit i2c Buscontroller zum Anschluss an Microcontroller/computer. Über eine 8 Bit breite Datenschnittstelle und ein paar Steuerleitungen nimmt er Kommandos byteweise entgegen und setzt diese auf den i2c - Bus um. Vom eigentlichen Timing/Protokoll am i2c ist die C64 Seite dann vollkommen abgetrennt.
Viele Grüße
hexagon