Beiträge von e9hack

Zitat

Original von pat
Schade ich verstehe es nicht mit acpi geht es sofort da passiert doch das gleich nur das er kein Datum verarbeitet.
Aber das ist für mich eine Saggasse..

Da das BIOS von 2006 ist, sollte acpi-wakeup mit Datum funktionieren. Wenn der Kernel zu alt ist, ist jedoch das Schreiben vom Weckdatum in in acpi_system_write_alarm() per #if 0 / #endif ausgeblendet.

Gruß
e9hack

Zitat

Original von UFO
Btw, imho ist verdächtig, daß die Bitrate halbiert werden mußte. Dies deutet entweder auf ein schlechtes Kartenlayout (Störungen auf dem I2C-Bus) oder einen weiteren obskuren Bug hin.

Der PLL-Chip im Tuner (TDA6404?) kann laut Spec nur 150kHz. Da ist der Standartwert von 275kHz zu viel. Daher kommt die Halbierung.

Gruß
e9hack

Zitat

Original von UFO

Da die Spec wohl nicht zu bekommen ist, bleibt nur, den I2C-Bus unter Windows zu sniffen...

Ich habe beim TT Treiber unter Windows belauscht, was er vom/zum SAA7146 liest/schreibt. Die Initialisierung des Demodulators bzw. der AGC vom STV0297 ist nicht so viel anders. Da hat vermutlich schon mal jemand gesnifft. Wenn ich die Unterschiede einbaue, bleibt das Problem bestehen. Erst das Erhöhen der I2C-Bus-Geschwindigkeit hilft.

Zitat

Dieser Code ist allerdings suboptimal. Was passiert, wenn man es probehalber mal so macht?

Code

if (short_delay)
                                udelay(10);
                        else
                                msleep(1);

Das hilft genauso wie das Erhöhen der I2C-Bus-Geschwindigkeit.

Da der Tuner über den STV0297 als Gate vom I2C-Bus abgekoppelt ist, würde ich jedoch meine Variante vorziehen. Das Polling läßt sich ganz vermeiden, wenn der I2C-Transfer im Interruptmodus vom SAA7146 läuft.

Gruß
e9hack

Zitat

Original von UFO

Wenn es hier wirklich um ein Timing-Problem geht, dann kratzt der Patch nur an der Oberfläche des Problems. Der Demod muß sich auch mit reduzierter I2C-Geschwindigkeit programmieren lassen. (Werden evtl. Register in der falschen Reihenfolge beschrieben?)

Genaugenommen geht es um zwei Probleme:

Problem 1:
Irgendetwas stimmt nicht mit der Initialisierung vom Demodulator (falsche Reihenfolge, Timing zeitkritisch, ..). Das läßt sich nur mit Hilfe der Spec vom stv0297 klären.

Problem2:
Das Timeout- bzw. Busy-Handling in der I2C-Routine vom SAA7146 ist etwas 'schräg'. Das Timout nach dem beschreiben des Transferregisters ist immer 10ms lang, unabhängig von der programmierten Geschwindigkeit. Dabei wird das Statusregister am Anfang 20 mal alle 10us gepollt und danach alle 1ms (unabhängig von der Geschwindigkeit). Bei der normalen Geschwindigkeit dauert der Transfer ca. 100us und bei halbierter ca. 200us. Bei halbierter Geschwindigkeit wird bei ca. der Hälfte der Schreibzugriffe eine Wartepause von 1ms angehängt. Das kürzere Pollingintervall ist auch noch stärker last- und laufzeitabhängig. Das führt dazu, daß auf QAM256 Kanäle synchronisiert werden kann, wenn der PC unter 'Last' läuft. Vermutlich haben langsamere PCs auch weniger Probleme.

Zitat

Ich kann nicht einfach Voodoo-Code in den Treiber integrieren.

Das soll ja auch so nicht unbedingt in den Treiber rein. Bisher sind es zwei (mittlerweile drei) Fälle, wo das Sync/Lock Problem aufgetreten ist, und wo der Patch hilft.

Gruß
e9hack

So wie lola geantwortet hat, es ist ein Kondensator 0,47uF/250VAC. Wenn er direkt an 230V (L und N) hängt, sollte es ein X2 Kondensator sein, z.B. bei Reichelt.

Gruß
e9hack

Zitat

Original von DenkerD
Ich muss den VDR jetzt eh erstmal wieder aufsetzen, da ich ja mit XP getestet habe.

Warum machst Du keine Parallelinstallation?

Gruß
e9hack

Zitat

Original von Dr. Seltsam
ich hatte diesen Patch schon mal für jemanden in meinen Kernel eingebaut, aber es gab auf seinem System keinerlei Besserung mit QAM256.

Der Patch unterscheidet sich vom vorherigen und wird auch nur bei einer TT C2300 funktionieren.

Es sieht so aus, daß AGC und/oder Demodulator vom STV0297 innerhalb einer bestimmten Zeit initialisiert sein müssen. Für die TT C2300 wurde die I2C-Bus-Geschwindigkeit der gesammten Karte wegen dem langsamen Tuner reduziert. Der Patch reduziert die Geschwindigkeit nur, wenn der Tuner angesprochen wird.

Der Windows-Treiber macht noch mehr. Wenn der STV0297 nicht synchronisiert, wird schrittweise die Sweep-Rate erhöht. Ich habe das testweise auch eingebaut (nicht veröffentlicht). Ich brauche das aber nicht, da der STV0297 mit dem anderen Patch immer beim ersten Versuch synchronisiert.

Gruß
e9hack

Zitat

Original von DenkerD
e9hack

Deinen Patch habe ich auch schon gefunden, allerdings bin ich als Newbie noch etwas ratlos, was und wie ich mit der .diff machen soll. Wäre nett, wenn Du mir da etwas helfen kannst.

Du must die DVB-Treiber von LinuxTV benutzen. Das Kompilieren ist im Wiki als Variante B beschrieben. Den Patch wendest Du vorm Kompilieren im v4l-dvb Verzeichnis mit 'patch -p1 < nexusca-qam256_2.diff' an.

Gruß
e9hack

Zitat

Original von DenkerD
Nur bei qam 256 kein Bild annsonsten alles bestens.
Das CI mit Cam funktioniert auch, Fussball auf Arena kann ich problemlos schauen.

Ich benötige den angehängten Patch, damit QAM256 Kanäle problemlos funktionieren. Ohne Patch dauert es 0,5..1 Stunde bis der Demodulator synchronisiert und Bild bzw. Ton kommen. Ich habe den Patch auf der Mailing-Liste gepostet. Es hat aber keinen weiter interessiert.

Gruß
e9hack

Zitat

Original von DenkerD
Also ich bin auch im Besitz eines Kabelanschlusses und einer TT2300 DVB-C Karte. Mit dem VDR natürlich kein Bild.

Überhauptkein Bild oder nur bei QAM256 kein Bild?

Gruß
e9hack

Hi,

es sieht so aus, daß die vier nicht entschlüsselbaren Sender immer die niedrigste SID auf der jeweiligen Frequenz haben. Was passiert, wenn die CAID von Hand von 1 auf 1702,1722,1801 gesetzt wird?

Gruß
e9hack

Zitat

Original von kls
Vom Antennenanschluß geht eine Leiterbahn über den ersten Pin des Tuner-Gehäuses an eine Schaltung in deren Nähe auch ein 78M05 ist. Allerdings kann ich keine Leiterbahn finden die in diesem Zusammenhang an einen Pin eines anderen Chips geht.

Wenn die Versorgung für die Antenne von außen kommt, dann wird sie vermutlich von keinem Chip im Tuner geschaltet. Damit fällt meine Idee mit dem PLL-Chip (Mailing List) flach. Das Signal könnte auch vom FlexCop-Chip kommen. In den SAT-Varianten kann der ja die LNB-Versorgung schalten.

Gruß
e9hack

Zitat

Original von MajestyIV
Ich habe den Patch von e9hack angewendet. Leider ohne sichtlichen Erfolg.

Es sieht so aus, daß der Patch nur in einem bestimmten Eingangspegelbereich funktioniert.

Aktuell habe ich den I2C-Transfer beim Kanalwechsel (QAM64 nach QAM256) vom TT-Windows-Treiber mitgeschrieben. Der TT-Treiber führt beim Kanalwechsel keine Neuinitialisierung vom STV0297 durch. Der weitere Ablauf ist näherungsweise gleich (wie der original Treiber ohne meinen Patch). Es gibt einige Wartezeiten mehr. Es wird ein anderer Wert für die Demodulationsfrequenz benutzt, der auch QAM abhängig ist. Die Corner-Detection (was auch immer das ist) wird auch bei QAM256 aktiviert. Die Werte für Sweep-Rate und Carrier-Offset sind beim ersten Versuch wie bei Linux. Damit bekommt der STV0297 kein Sync/Lock. Beim zweiten Versuch werden andere Werte benutzt und der Sync/Lock ist erfolgreich. Weiterhin wird die Inversion direkt gesetzt während Linux ständig wechselt (auto), natürlich immer mit dem falschen Wert startet und damit dann mindestens zwei Versuche benötigt. Daher sollte man den Wert für Inversion immer in der channels.conf angeben.

Ich werde die Werte vom TT-Treiber übernehmen und hoffe, daß sich das QAM256-Verhalten verbessert.

Gruß
e9hack

Möglicherweise beinflußt eines der 4 Register die BER/UNC Werte.

Zitat

Original von Dr. Seltsam
hast Du eine idee, warum das bei der 1500C nicht klappt? Muss eventuell außer av7110 noch ein budget-Modul gepatcht werden?

Für die 1500C steht die Inittabelle für den STV0297 in budget-ci.c. Ich sehe da Unterschiede bei den Registern 0x43, 0x61, 0x62 und 0x53 gegenüber der FF-Karte.

Gruß
e9hack

Zitat

Original von Dr. Seltsam
STR (was der Pegel sein sollte) ist jetzt ein schwankender Wert um 82%. Allerdings zeigt sich da keine Veränderung, auch wenn ich ein regelbares Dämpfungsglied von 20dB dazwischenschalte.

Meine Interpretation, wie die TT-Windows-Software den Signalpegel ermittelt, war etwas voreilig.

Zitat

Original von Dr. Seltsam
BER ist konstant 0 (schön wäre es , wenn das ein realer Wert wäre -glaube ich aber nicht.
Beide Werte zeigen beim Auf- und Zudrehen des Dämpfungsreglers keine Veränderung, obwohl es z.T. Artefakte gibt.

BER und UNC sollten mit dem anderen Teil vom Patch angezeigt werden. Bei meiner TT-C2300 wird ab BER>1500 dann auch UNC>0 und es gibt die ersten Klötzchen. Die Werte für BER/UNC sind unbrauchbar, wenn der Lock immer mal wieder verloren geht.

Einen BER-Wert von 0 habe ich nur ganz selten. Die Werte liegen zwischen 0..100 bei QAM64 und 300..600 bei QAM256.

Gruß
e9hack

Hi,

ich habe mir einen Windows-Treiber geschrieben, der den TT-Treiber patcht und die Zugriffe auf den SAA7146 belauscht. Es scheint, das die Werte für Pegel und Signalqualität unter Windows aus den Registern für 'SNR' und der BER-Rate abgeleitet werden. Wenn die Signalqualität angezeigt wird, wird auch permanent der Carrieroffset (?) gelesen.

Ich habe die Funktion für den Signalpegel vom STV0297-Frontend mal dafür angepaßt. Der Patch ist für das aktuelle v4l-dvb Repository von linuxtv.org.

Gruß
e9hack

Zitat

Original von der-wolff
Beim Überfliegen der Sourcen habe ich noch nichts gefunden.

Da wirst Du auch nichts finden. Zum Ermitteln der Signalwerte ist die Spec vom STV0297 notwendig. Ich habe vor einiger Zeit mal eine Supportanfrage nach der Spec an ST gestellt. Es kam keine Antwort. Ein Registerdump vom STV0297 unter Windows bringt auch nichts. Es ist kein sinnvoller Zusammenhang zwischen der Signalstärke und irgendwelchen Registern vom ST0297 zu finden. Um die Signalwerte lesen zu können, muß möglicherweise erst ein Triggerbit gesetzt werden (so wie bei BER und UNC).

Gruß,
e9hack

Zitat

Original von vdrchuck
Also die TT C-2300 Hybrid läuft bei mir mit QAM256 Sender (113Mhz ISH NRW) nicht!
Habe heute unter Windows getestet und dort laufen die Sender mit QAM256 (113Mhz)!

Ich habe ein ähnliches Problem. Die QAM256-Sender benötigen unter Linux zwischen 0,5..1 Stunde zum synchronisieren. Ich verwende die aktuellen Treiber von linuxtv. Mit einem kleinen Patch habe ich das Problem für mich gelöst. Unabhängig davon benötige ich einen zusätzlichen Antennenverstärker.

Gruß
e9hack

Zitat

Original von joe0815
sind das chips auf der Karte, die auch so benannt sind? Und was muß/kann ich dan tun? Kann man die Karten dann eigentlich umtauschen wenn die nicht auf QUAM 256 funktionieren? Sind nämlich noch recht neu.

Welcher Demodulator=Frontend benutzt wird, sieht man beim starten der DVB-Treiber. Über dmesg sollte sich folgendes finden lassen:

Linux video capture interface: v2.00
saa7146: register extension 'dvb'.
saa7146: found saa7146 @ mem fdaaec00 (revision 1, irq 58) (0x13c2,0x000a).
DVB: registering new adapter (Technotrend/Hauppauge WinTV Nexus-CA rev1.X).
dvb-ttpci: info @ card 0: firm f0240009, rtsl b0250018, vid 71010068, app 80f22623
dvb-ttpci: firmware @ card 0 supports CI link layer interface
dvb-ttpci: DVB-C analog module @ card 0 detected, initializing MSP3415
dvb-ttpci: initializing saa7114 @ card 0
saa7146_vv: saa7146 (0): registered device video0 [v4l2]
saa7146_vv: saa7146 (0): registered device vbi0 [v4l2]
DVB: registering frontend 0 (ST STV0297 DVB-C)...
input: DVB on-card IR receiver as /class/input/input3
dvb-ttpci: found av7110-0.

Gruß
e9hack