Beiträge von SHF

Zitat

Meint ihr das macht so Sinn oder reicht der Sempron 2200+ auch für ne bulk DVB-S Karte?

Ich hatte VDR-Xine mal auf einem 1000er Thunderbird am laufen, der Sempron sollte eingentlich reichen (ob VDR-Xine oder softdevice macht da keinen unterschied, glaube ich). Nur Installation war die Installation ein elendes gefrickel, immer Versionsprobleme oder andere Abhängigkeiten. Das ganze ist inzwischen aber an die 2 Jahre her, da hat sich hoffentlich was getan.

Zitat

Jetzt hatte ich gedacht nehm ich ne FF DVB-S Karte und kann dann demnächst zB mit ner bulk DVB-T Karte nachrüsten wenn nötig.

Ne Karte ohne Signal ist, glaube ich, problematisch. Da gab es hier im Board schon längere Diskussionen.

Vielleich solltest du dir da mal die DXR3-Karten als Ausgabegerät ansehen. Die sollen inzwischen gut funktionieren, sind billig und haben auch einen VGA-Ausgang (ob der aber ein brauchbares Signal liefert weiss ich nicht).

Zitat

Hab im wiki einiges gelesen über unterstütze Karten, nur waren die Bezeichnungen in den Listen oft nicht mit denen im Shop übereintimmend, was mich etwas verunsichert hat.

Es gibt andauernd neue Typen und viele Karten werden dazu noch mit unterschiedlichen Bezeichnungen gehandelt, das macht die Sache reichlich unübersichtlich.
Viele der Budget-karten werden aber unterstützt, nach der genauen Bezeichnung hilft meistens.

Zitat

[...] geht das auch ohne son Modul?

Ja, aber nicht mit allen Mainboards. (Stichworte: NVRAM ACPI-WAKEUP)

Zitat

Ich schließe nicht aus mir irgendwann ma n Flachbildfernseher zuzulegen.

Wenn du Glück hast kannst du auch irgendwo an der Uni (z.B. HRZ) eine 21er Röhren-Monitor für lau abstauben.

Der Cypress Chip ist wirklich nur ein USB-Controller und scheidet daher als Fehlerquelle aus. Es muss also entweder an der Empfängerstufe oder an der Fernbedienung liegen.

Die Beiträge von Dyl0n und rell legen den Schluss nahe, dass irgendein Bauteil den Geist aufgegeben oder seinen Wert geändert hat. Wenn das im Empfänger der Fall war könnte mit der Abgleichschraube noch was herauszuholen sein.

Den "433 MC" Aufkleber deute ich so, dass es ein 433MHz Empfänger. Eine Reichweite von 2m währe dann aber ein miserabeles Ergebnis. Mein Fernbedienungsverlängerer (auch 433MHz) schafft 10m plus eine Betondecke.

BTW: Ich hoffe ihr habt anständige Alkaline-Batterien in der Fernbedienung verwendet, nicht dass es an ausgelutschten Batterien hängt.

Zitat

Meine Frage ist nun was dort Hardwaremäßig anders ist, evtl. kann man ja was umbauen ?
Den Empfänger kann man ja leicht zerlegen.

Wenn das Öffnen so einfach ist mach doch mal ein Foto vom geöffneten Empfänger. Vielleicht kann dann einer der Hardwarespezis dazu einen Tipp geben.

Zitat

gilt hierfür der der FUTABA eintrag in der serialvfd.hwto?

Der sollte passen.
Aber Achtung, ingendwie ist da die 7 verschwunden:
1 /STROBE -------------- /WR 17

Zitat

was ist hier besonderes zu beachten?

Kurzschlüsse und falsche Verbindungen vermeiden, das könnte die parallele Schnittstelle killen. Am besten die Signalnamen noch mal mit dem Datenblatt vergleichen (S. 5), ich habe das Kabel noch nicht getestet.
... und ganz wichtig: Den Stecker nachher auch richtigrum auf das Display stecken ;D.

[list=1]
[*]Aktuellen LCDproc-Nightly-Tarball herunterladen:LCDproc-current
[*]Entpacken und in das entstandene Verzeichnis wechseln.
[*]Mit diesem Patch patchen: "patch -p1 < pfad/zum/patch.diff" (Pfad anpassen!)
[*]Kompilieren und installieren mit:
"./configure --enable-drivers=serialVFD"
"make"
"make install" (Dazu braucht man aber root-Rechte.)
[*]Die LCDd.conf anpassen:Diese sollte für parallel angeschlossene Displays passen, wenn man die "size" auf "2x20" ändert. Wenn das Display seriell angesteuert wird auch muss noch die Schnittstelle umgestellt werden.
[*]Nun kann der LCDd gestartet werden. Meistens über ein Init-Skrit oder aus der runvdr, das ist aber distributionsabhängig. Wenn vorher eine alte Version installiert war startet die neue meist problemlos.
[/list=1]

Anschluss des Displays:
Der Anschluss des Displays ist in der Dokumnentation des serialVFD-LCDproc-Treibers beschriben.
Für den parallelen Anschluss sollte das parallele FUTABA-Kabel passen.

Der benötigte Inverter für das serielle Kabel ist dort auch beschrieben.
Hier die Informationen, die noch fehlen um das Kabel zu löten:

Pin 2   <--- +5V
Pin 4   <--- +5V
Pin 6   <--- +5V


Pin 8   <--- GND
Pin 10  <--- GND
Pin 12  <--- GND
Pin 14  <--- GND


Pin 19  <--- RxD

Da ich habe diese Übersicht mehr oder weniger aus dem Gedächtnis zusammengeschrieben kann es sein, das die eine oder andere Kleinigkeit nicht 100%ig stimmt. Besonders bei der Verkabelung rate ich zu einem Kontrollblick ins Datenblatt. Ich hoffe es bring trotzdem etwas mehr Überblick.

Zitat

Schön ist das jetzt auch der Heartbeat geht. Cursor ist auch weg smile .

So soll es sein!

Zitat

Ich hätte da auch noch eine Idee, wie wärs mit drei Abstufungen mit [,(,|,),].

Ich hatte Ähnliches ganz am Anfang mal versucht, hat einen eher verwirrt als informiert und sah ausserdem irgendwie komisch aus (besonders die vhars waren komplett unbrauchbar).
Normalerweise werden bei Displays ohne Custom Characters die Balken nur Zeichenweise (bei hbars wird "-" als character verwendet) abgestuft. Die zusätzliche Stufe ließ sich aber noch sehr einfach mit den Bibliotheks-Funktionen realisieren.

Zitat

Wenn das aber nicht so toll aussieht würd ich anstatt des '-' die Pipe '|' vorschlagen.

Ich hab absichtlich '-' verwendet, da die Pipe '|' irgendwie "verloren" aussah. Du kannst es aber selber probieren, einfach das "0x2C" in "0x7B" ändern (/server/drivers/serialVFD.c Zeile 346).

Zitat

Dann hätte man auch 5 Abstufungen wie mit den Custom Charactern.

Das ändert an der Länge des Balkens nichts. Dass es da momentan zu Problemen kommt liegt warscheinlich an einer Umstellung der Client-API in der 0.5er Version. Ich will mir bei gelegenheit mal den Client anschauen.

Zitat

Helligkeit geht auch aber nicht mit Backlight

Ich meinte das Client-Kommando "backlight" mit dem der Client zwischen Dunkel und hell umschalten kann.

Zitat

aber komischerweise startet LCDd mit voller helligekit und stellt dann auf die welche in Brightness steht und nicht auf OffBrightness. Beim Start ist es immer voll hell.

Das ist normal so.

Zitat

Ich habe mir auch einmal so ein vfd bestellt. da es sicherlich eine interessante erweiterung für den vdr ist, wäre es super, wenn jemand ein tutorial und/oder ein paar bilder zur montage liefert: anschluss, lcdproc, betrieb...

Eigentlich ist alles nötige schon hier zu finden, es ist nur ein wenig unsortiert.
Zum LCDproc-Teil kann ich bei Gelegenheit mal die wichtigen Punkte zusammenkopieren.
Vom Samsung-VFD kenne ich nur das Datenblatt, weshalb ich da nicht mit praktischen Erfahrungen dienen kann.

Mit dem angefügten Patch sollten Balken-Diagramme nun brauchbar sein. (Der letzte Patch ist auch enthalten!)
Wenns auch auf dem Samsung-VFD läuft kommt es in den offiziellen Treiber.

Das mit dem IRQ-Sharing scheint zumindestens beim 2.4er Kernel nicht zu klappen. Ich habe da schon einige Versuche hinter mir. Ausserdem steht eine entsprechende Warnung in der Manpage von "setserial".

Zitat

[...] normally an IRQ line may not be shared
between two or more serial ports. If you attempt to do
this, one or both serial ports will become unreliable if
you try to use both simultaneously. [...]

Veilleicht hat sich da aber inzwischen was getan (wenn ja währ das für mich sogar ein guter Grund um endlich umzusteigen), ein Blick in die Manpage kann nicht schaden.

... so groß nun auch nicht. Dein Prozessor dürfte in den 3-5 Sekunden (zumindestens stellenweise) die zulässige Maximaltemperatur von 95°C erreicht haben.

Zitat

Das mit dem Cursor wollte ich auch noch gesagt haben. 0x14 macht ihn aus.

... und das fehlte im Init-Befehl nur scheint es noch keinem Futaba-Besitzer aufgefallen zu sein. Anscheinend ist der Cursor da per default aus.
-> Anhang

Zitat

Und das dimmen funktioniert auch nicht.Mit 0x04 0x20/0x40/0x60/0x80/0xFF setzt du die einzelnen Stufen.

Eigenartig, genau das bekommt das Display gesendet. Angesteuert wird das aber über "backlight". Man kann damit zwischen den zwei in der LCDd.conf gesetzten Helligkeiten umschalten (das machen alle Treiber so). Auf meinen Displays klappt das mit dem VDR-lcdproc-plugin. Die meisten Client machen aber keine Änderungen an der Helligkeit.
Setz mal "Brightness=100" oder so, da solltest du was sehen (Neustart nicht vergessen).

Hast du schon was mit den Balken-Diagrammen probiert? Die jetzige Lösung für Displays ohne Custom-Characters ist noch nicht so toll. Inzwischen ist mir da was Besseres eingefallen. Vielleicht bekomme ich es noch dieses WE ans laufen.

Zitat

Hi, ja sowas habe ich mir schon gedacht, RxD per Software zu steuern kommt nicht in Frage wegen der CPU Last. Evtl. kann man ja das RTS/CTS und DTR/DSR über den UART nutzen, und guckt dann einmal wie das beim Daten senden ragiert, evtl muss man dann die Daten etwas verwürfelt an die einzelnen Displays schicken aber dann hätte man nicht das Problem das man die Leitungen einzeln setzen muss. Und dann muss man das RTS aufs CTS durchscliefen und das DTR aufs DSR.

Momentan ändern sich RTS und DTR nicht, da kein Handshake verwendet wird.
Bei aktiviertem Hardware-Handshake sollten beide vor der Übertragung auf "ein" danach wieder auf "aus". Wielange dieser Verbindungs-Auf und -Abbau dauert habe ich noch nicht gefunden. Diese Impulse könnte man zum Ansteuern eines Schieberegisters nehmen. Damit so ein Impuls entsteht muss sichergestellt werden, dass die Datenübertragung nach jedem Display auch wirklich beendet wird. Da aber zumindestens ein Hardware-FIFO verwendet wird (im Kernel-Treiber ist evtl. auch noch etwas) ist das auch nicht ganz so einfach. Die Übertragung muss zumindestens in mehreren Schritten, mit ausreichenden Pausen dazwischen, erfolgen. Und wenn nur ein Fehler auftritt gerät die ganze Sache ausser Tritt.

Das ganze klingt noch immer nach einigem Aufwand wo man doch gebrauchte 4-Zeilige Displays recht günstig bekommt.

Zitat

Der Lüfter schaut insteressant aus, und passen sollte er auch! - Jetzt bin ich aber ein wenig ratlos wegen der Lautstärke-Angabe:

Bei meinem stand "18dB" und "2000rpm" drauf. Das Teil ist selbst bei geöffnetem Gehäuse praktisch nicht zu höhen (meine HDD ist lauter).

Der Rechner bleibt einfach stehen und reagiert auf garnichts mehr?
Nur der RESET-Knopf funktioniert noch?

Bei manchen Athlons gibt es Probleme, die dieses Verhalten zur Folge hat.
http://www.heise.de/ct/01/18/036/

Zitat

Fazit:
Eine Woche Arbeit, die sich doch nochmal gelohnt hat, es ist deutlich besser so!

Das ist doch erfreulich!

Zitat

Dann hab ich den Rechner angemacht und höre ein merkwürdiges Brummen, wie bei nem Trafo.

Meistens vibriert dann ein Teil des Gehäuses, das durch Lüfter oder Festplatte angeregt wird. Bei deinem Gehäuse würde ich auf den Halter des oberen Lüfters oder die Deckplatte tippen. Einfach ein kleines, dünnes Schaumstoffstück zwischen die Teile klemmen falls es wieder auftritt.

Zitat

So, jetzt scheint mir nur noch der CPU-Lüfter ein wenig zu laut zu sein, den Rest hört man garnicht mehr!

Ich habe gute Erfahrungen mit dem "Arctic-Cooling CopperSilent 2" gemacht. Kühlt ordentlich, ist fast nicht zu höhren und mit rund 6€ sehr günstig.
Ich habe ihn auf einem Sockel A Athlon im Einsatz. Wenn ich nicht Irre passten die Sockel A Kühler aber auch auf den Pentium III, ganz sicher bin ich da aber nicht.

Zur Zeit wird die Serielle-Schnittstelle auf der Protokollebene angesteuert. Das ist sehr einfach und effektiev da die Schnittstellen-Hardware(UART) die meiste Arbeit erledigt.

Will man die RTS und DTR Pins extra setzen muss man diese auf der Pinebene ansteuern. Da, meines Wissens, ein Mischbetrieb nicht möglich ist müsste man die Aufgabe des UART softwaremässig erledigen. Das ist aber garnicht so einfach da das Timing exact hinhauen muss woraus sich das eigentliche Hauptproblem, die CPU-Last, ergibt. Die Timing-Pausen sind zu kurz sind um die CPU für einen anderen Prozess frei zu machen (die Übergabe dauert zu lange, siehe Manpage von usleep()). Ausserdem muss man sicherstellen, dass der Prozess bei der Datenübertragung nicht unterbrochen wird.
Bei einem Vollausbau mit 5 Displays werden fast durchgehend Daten übertragen, so dass die CPU-Last bei annäherd 100% liegen würde und das unabhängig von der CPU!
(Die Probleme gibt es übrigens auch bei der parallelen Schnittstelle, die wird fast immer auf der Pinebene angesteuert. Da die Daten dort aber Byteweise (Aufwand / 8 ) übertragen werden und das Timing nicht so exakt sein muss lässt es sich deutlich leichter in den Griff bekommen.)

... naja, vielleicht hat ja noch jemand anderes eine Idee. Eine Chance sehe ich z.B. noch in einem speziellen Kernelmodul, gefunden habe ich bislang aber noch nichts.

In deinem Bild ist mir eben noch der Cursor unter dem ersten Zeichen aufgefallen. Ich denke den bekomme ich morgen noch weg.

Zitat

Natürlich dauerts dann immer länger bis alle Displays aktualisiert sind.

Lcdproc liefert konstant 8 Frames pro Sekunde. Das wird, wenn sich viel auf dem Display tut, schon knapp (zumindestens auf meinen NEC-Displays). 2 Displays könnten evtl. aber noch gehen.

Theoretisch gehen sogar noch mehr:
9600bps : 8fps : 8bit_pro_Zeichen = 150Zeichen pro Frame inklusive Steuerzeichen.
150 : 20 = 7,5 20-Zeichen-Displays. Wenn man die Steuerzeichen und etwas Sicherheit einberechnet kommt man auf 5 Displays. 6 Werden zu knapp, denke ich.

Zitat

In lcdproc müsste dann das eine display irgendwie virtuell vergrössert werden in dem man die Anzahl der displays angibt.

Das ist alles schon im hd4480-Treiber schon drin. Ich denke da kann man grosse Teile übernehmen.

Zitat

... und sehen ob das Shift Register die 9600baud ordentlich verkraftet ...

Sollte es locker.

Zitat

EDIT: habe was zu DTR/RTS setzen/löschen gefunden, klick , müsste man doch so hinbekommen oder nicht?

Lese ich mir mal durch. Meine Hauptbedenken sind wegen des Hardware-FIFO der Schnittstelle, die Umschaltung muss ja exact zum richtigen Zeitpunkt erfolgen.

Zitat

Habe lcdproc v0.5.0 probiert aber da lief es nicht zufriedenstellend, jede Menge Sonderzeichen und falsche Umbrüche.

Lcdproc v0.5.0 geht nicht, da ist noch ein Bug ausgerechnet in den Futaba-Kommandos.
Am einfachsten sollte es mit den Nightly-Tarballs sein: LCDproc-current

Für das Compilieren gibt es auch eine Anleitung

Zitat

Geht es eigentlich das man mehrere LCD's/VFD's über seriell anschliesst so ähnlich wie bei den parallelen typen?

Bislang geht es nicht.

Zitat

Habe da so ne idee mit Schiftregister im Kopf welches über die DTR Leitung oder so durch die Displays 'zapt'.

Würde mich interessieren, wie du das Schiftregister ansteuern willst. Die Signalleitungen der seriellen Schnittstelle einzeln anzusteuern ist recht aufwändig.

Zitat

In 3-5 Sekunden jedoch erhitzt sich das teil nicht auf 50 Grad.

... in 5 Sekunden packt er sogar auf 300! Ich dacht das entsprechende THG-Video sei allgemin bekannt.
THG-Videos (Es ist das Video ganz unten rechts!)

Zitat

Nach Einbau eines Kühlkörpers hat er gebootet.

Da hast du echt Glück gehabt, hätte auch ganz anders aussehen können (siehe Video :D).

Zitat

Das Board kann aber dadurch normal keinen Schaden nehmen oder ?

Und wie es das kann. Bei dir ist es aber anscheinend gut gegangen.

Ist der Eingang denn auch auf RGB gestellt. Nicht das er auf YUV oder sonstwas steht und du dir in der Verkabelung 'nen Wolf suchst.

Das Signal muss invertiert und auf ttl-pegel gebracht werden.
Beispielschaltungen gibt es hier und in der LCDproc Dokumentation.

Anhang: Dokumnentation des serialVFD-LCDproc-Treibers. (in .html umbenennen!)