Sagem-Kabel-Tuner-Treiber

[verzweifelt]

@Npq
Bei der Testbox ist der Avia(ram) nicht ganz fehlerfrei (siehe anderen Thread) allerdings denke ich mir dass sollte keinen negativen einfluss haben. Könnte es an einem zu langen Druckerkabel liegen? Mein Kabel ist etwa 0,5m lang. Ist dass schon zu lang für einen I2C Log? Woran könnte es sonst noch liegen ?

Da war ich schon so glücklich dass alles endlich geklappt hat Naja, dann versuche ich mal den Fehler zu finden.

[Token]

@verzweifelt:
... ob es hierher gehoert, weiss ich jetzt nicht, aber eine dream-dm500c
macht hier ebenso trouble bei 113/121mhz.
... die dream hat ja bekanntlich auch das enigma, so das das also kein
only neutrino problem bzw. kein only dbox2 problem ist.
... die dm500c z.b. hat einen philips-tuner cu1216, eigentlich ein wald und wiesen tuner, aber auch hier tut sich der treiber schwer.
... bei 346mhz messe ich 94% SNR ... bei 113/121mhz sind es nur noch
86/81%, und das reicht nicht ... 90% sind wohl das optimale fuer scan und
lock ... vom decodieren des signal's mal ganz abgesehen.
... die ueberarbeitung der at76c651.o und der ves1820.o treiber vor 2 jahren von homar brachten gute erfolge, hier laufen die sagem und die nokia mit den o.g. 94% SNR in einem KDG netz auch bei 113/121mhz.
... bei "meinem" dm500c problem werde ich wohl mal DREAM einen
arbeits-hinweis geben muessen.
... bei den sagem's koennte homar was dazu sagen, bzw. koennten CVS-
versteher sich mal den source und die diffs des sagem-at76c651 durch-
arbeiten, vielleicht findet sich da noch etwas ?!
... bei den nokia's scheint es ja zu 99% keine probleme zu geben ?!
cu token

[Npq]

Könnte durchaus sein, daß 50cm schon zu lang ist, ich habe das selber leider noch nie probiert.

Interessant ist halt wie die BN den PLL programmiert und da ist es ungünstig, wenn dann Bytes fehlen oder sogar verfälscht sind (und so sehen mir einige Bytes aus).

Da man ja gerade wissen will, was geschrieben wird, könnte ein falsches Bit da leider schon ziemlich irritieren.

[chkbox]

Ich würde mal tippe, dass die Pull-Up's des I2C nicht für die Aktion reichen. Da du ja nur lesen willst, könntest du einen Puffer in die dbox einbauen. Der sollte dann weniger Probleme haben, die Leistungen zu treiben. Ich weiß leider nicht, ob eher TTL oder CMOS

[verzweifelt]

Ich habe mal etwas gelesen und bei den meisten war es so dass sie sogar bei niedriger Taktfrequenz auf mehreren Metern kamen. Leider weiss ich noch nicht womit man einen Buffer so ohne weiteres umsetzen kann. Ich werde noch ein bisschen weitertesten und mal schauen was meine Bastelkiste so ausspuckt.

[chkbox]

Schau dir mal http://ivtv.writeme.ch/tiki-index.php?p ... ng+I2C+Bus an. Da beantwortet dann auch, dass es wohl CMOS ist. Du solltest das IC aber besser aus der Box wie bei der RTC versorgen.

[verzweifelt]

@Token
Dich habe ich komplett vergessen. Leider meldet sich Homar ja anscheinend nicht mehr wie hier im Forum zu lesen ist. Vielleicht ergibt sich da ja noch was. Vielleicht hilft dann ja auch wenn man die Treiber der Dream genauer anschaut. Evtl. findet man so den "Bug" im Vergleich schneller.

@chkbox
vielen Dank für den Link. Ich habe nun ein neues Kabel angefertigt, das kürzer ist und auch einen dickeren Innenleiter hat. Leider gibt es auch hier nicht wirklich eine Besserung. Ich glaube genau das IC habe ich noch irgendwo rumfliegen. Ich werde da nachher mal suchen. Eine Frage habe ich dann aber doch zu der Schaltung. Wenn ich es richtig sehe dann sind die Dioden nur da um die Datenleitungen zu schützen. Wenn ich jetzt die Spannungsversorgung über die Box mache dann kann ich doch eigentlich die Dioden weglassen und anstatt Pin 25 nehme ich einfach die Masse der Box. Ich frage nur deshalb weil ich mir irgendwie nicht vorstellen kann dass die Datenleitungen des LPT wirklich problemlos genug Strom zur Verfügung stellen.

Langsam glaube ich es ist einfacher einen Nokia Tuner in die Sagem zu bauen als den I2C auszulesen
Ist schon schlecht wenn man sich so dumm anstellt wie ich

[verzweifelt]

Mit den kleinen elektrischen Käfern ist es wie beim Lotto. Immer ist die letzte Zahl falsch

Na dann suche ich mal nach einer anderen Lösung ansonsten muss ich bis Montag warten. Tut mir Leid.

[chkbox]

Du musst weiter 12,13 und 25 anschließen (den Rest nicht). Als Chip geht eigentlich jeder Logik-Chip: ein Puffer, UND bzw. ODER mit verbundenen Eingängen, bei Inverter, NAND und NOR zwei nacheinander
Mal Beispiele

[michaelstaehle]

Ich habe hier noch Sagem Images rumliegen.

PM bei Interesse an mich.

Ciao Micha

[verzweifelt]

Ich habe hier leider nur noch TTLs kein CMOS, da habe ich mich versehen Ich werde mich aber am Montag sofort mit einigen Chips eindecken, die kosten ja nur ein paar Cents. Am liebsten würde ich da heute noch einbrechen

Ach was solls, ich schau noch mal ob ich nicht doch noch irgendwo was habe. Vielleicht hat ja noch ein alter VCR soetwas in sich.

Auch wenn es jetzt nicht mehr so ganz passt, hier das was ich vorher geschrienen habe :
---------------------------------------------------------------------------------

Kann es sein dass bei der Schaltung etwas falsch ist ?

Laut Datenblatt ist Pin 13 sowie 16 überhaupt nicht belegt.
Was nützt es dann wenn Pin 15 und 16 gebrückt sind und Pin 13 an +5V liegt?
Warum sind Pin 5 und 6 gebrückt wenn der Ausgang auf Pin 4 unbenutzt ist ?

Ebenso ist Pin 9 auf Masse, am ausgang 10 ist jedoch nichts angeschlossen ??


Also effektiv bleiben da nur folgende Pins übrig:
Pin1 -> + 5V
Pin2 -> LPT_Pin13
Pin3 -> DBOX_CLOCK
Pin8 -> Masse
Pin11 -> DBOX_DATA
Pin12 -> LPT_Pin12

Kann mir das jemand erklären? Hat es einen Grund warum die Schaltung so ist wie sie ist?

Ist ja eigentlich schon beantwortet

[just_me]

Ich habe hier leider nur noch TTLs kein CMOS, da habe ich mich versehen

Sollte eigentlich nichts gegen TTL in dieser Anwendung sprechen:

Versorgung stimmt (5V),
Eingangsschaltpegel sind anders aber passen auch,
die internen Pullups von TTL sind eher von Vorteil,
Ausgangspegel reichen für den Druckerport.

Wenn Du einen Sockel verwendest, könntest Du Montag bei Bedarf noch tauschen. (Für CMOS die unbenutzten Eingänge noch z.B. an GND anbinden, TTL braucht dies nicht)

[chkbox]

Kann mir das jemand erklären? Hat es einen Grund warum die Schaltung so ist wie sie ist?

http://tech-www.informatik.uni-hamburg. ... os_dt.html erklärt das ganz nett: Bei offenen Eingänge können Kurzschlüße im IC entstehen

[Npq]

Vielleicht hilft dann ja auch wenn man die Treiber der Dream genauer anschaut. Evtl. findet man so den "Bug" im Vergleich schneller.

Die Treiber der Dream Boxen sind closed und liegen nicht im Quellcode vor, verwenden aber vermutlich auch nicht den Atmel-Demod.

Selbst wenn, Tuner sind Komplettbauteile, die vom Hersteller auch spezifisch eingemessen werden, die Angaben in den Datenblättern sind da meist eher grobe Richtschnur, aber ein erfahrener Hardwareingenieur wird in der Lage sein, solche Parameter noch abzuändern, um sie zu optimieren.

Und genau da fängt es dann an, warum Werte aus Datenblättern plötzlich schlechter spielen als die, die verwendet wurden

Es dürfte wirklich am sinnvollsten sein, mit den Betanovawerten zu vergleichen.

[verzweifelt]

Danke, ich habe jetzt was in meiner Bastelkiste gefunden. Hoffentlich kommt da was brauchbares raus.

Kann mir das jemand erklären? Hat es einen Grund warum die Schaltung so ist wie sie ist?

http://tech-www.informatik.uni-hamburg. ... os_dt.html erklärt das ganz nett: Bei offenen Eingänge können Kurzschlüße im IC entstehen

Auf jeder Toilettenpapierpackung steht "Achtung geben sie die Verpackung keinem Baby oder Kleinkind, es könnte ersticken!" Aber so eine Information in einem Datenblatt unterzubringen ist wohl zu viel verlangt Zumindest weiss ich jetzt warum eine kleine Schaltung die ich im letzten Jahr gebaut hab nicht funktioniert hat.

[verzweifelt]

Da bin ich wieder und wieder mit schlechten Neuigkeiten. Ich habe ein TTL inverter genommen. Ich habe immer zwei Negierungen zusammengeschlossen damit wieder das am Ausgang anliegt was auch am Eingang anliegt. Alle unbenötigten Eingänge habe ich auf Masse gezogen. Dann habe ich die Box angeschlossen und erstmal einen riesen Schreck bekommen:

debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
Board_EventWait: timed out
debug: WARNING: unsupported FP ID 0x0
debug: write to fp io reset reg failed, rc -22

debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
Board_EventWait: timed out
debug: WARNING: unsupported FP ID 0x0
debug: write to fp io reset reg failed, rc -22

debug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
debugdebug: DDF: Calibrating delay loop... debug: DDF: 66.76 BogoMIPS
Board_EventWait: timed out
debug: WARNING: unsupported FP ID 0x0
debug: write to fp io reset reg failed, rc -22

Hab dann die Schaltung wieder entfernt und siehe da alles wieder im grünen Bereich. Sieht so aus als ob der kleine Käfer tot ist. Ich habe den aus meiner Bastelkiste und er war ausgelötet. Ich denker er war versehentlich dort und eher für die Mülltonne bestimmt. Naja Morgen ist auch noch ein Tag und die bei Reichelt freuen sich immer wenn sie mich sehen

PS Die Sagem ist jetzt wirklich eine Testbox, einige Kabel gehen zu irgendwelchen ICs, andere sind im Netzteil verlötet, der Kartenleser fehlt und das Display auch. Das Ding sieht aus wie ein Prototyp von sagem

[verzweifelt]

Zuerst möchte ich mich entschuldigen dass es so lange gedauert hat denn eigentlich hatte ich heute frei aber immer kommt es anders als man denkt.

Ich habe die kleine Schaltung mit Mos4050 gebaut und das Ergebnis ist jetzt wesentlich besser. Kann sich mal jemand das Ergebnis anschauen und sagen ob jetzt alles okay ist ? Dann mache ich den gleichen Scan von Linux oder mache mit der Fehlersuche weiter.

http://rapidshare.de/files/14866123/Betanova_neu.html

[verzweifelt]

Hi, in der Sagem dbox2 gibt es folgende I2C-Clients:

At76c651: 0x0d
PLL: 0x61
Frontprozessor: 0x30
Alpha: 0x37
AVS: 0x48
SAA: 0x44

Der Mitschnitt scheint nicht ganz störungsfrei zu sein, weil zum Beispiel beim PLL manchmal weniger als 4 Byte geschrieben werden. Hmm.

Sind jetzt immer 4 Byte

[chkbox]

Code: Alles auswählen

    634uS: 36 W  -nak-  
 44.148mS: 30 W 8D   
    358uS: 30 W 02   
 12.578mS: 0D W   
    748uS: 61 W 1A E2 8E   . . 
    186uS: 00 W  -interrupted-  
    388uS: 0D W 0B C0   . 

nur 3 byte für den PLL. 100%ig scheint es immer noch nicht zu sein. Ich kenne mich mit lmilk nicht aus, aber die "interrupted" scheinen mir ein bischen häufig. und warum es doch recht viele naks gibt, verstehe ich auch nicht. ist das normal in einer dbox?

[verzweifelt]

Oh nein, ich wollte gerade Linux posten

http://rapidshare.de/files/14870261/JTG_Linux_neu.html

Was kann ich jetzt noch machen???

Ich habe ein kurzes Anschlusskabel und den 4050 dazwischen

Code: Alles auswählen

748uS: 61 W 1A E2 8E   . . 

Die Stelle muss ich wohl übersehen haben.

[verzweifelt]

würde es evntuell was bringen wenn ich zwischen der Box und dem kleinen 4050 bei clock und Data je eine BAT42 legen würde ?

[verzweifelt]

wenn man weiter nach unten scrolled dann gibt es häufiger solche Zeilen

Code: Alles auswählen

 31.327mS: 61 W 70  

so wird das nichts

[verzweifelt]

Wie heisst es bei lmilk so schön:

99% aller Druckerports werden gehen, nur 1% wird nicht gehen. Ratet mal zu welchem % ich gehöre

Ich habe jetzt den PC getauscht und siehe da keine Naks, interrupted oder was auch immer.

Hier die neue Version

http://rapidshare.de/files/14873400/Betanova_final.html

und hier für Linux

http://rapidshare.de/files/14875834/jtg ... final.html


so nachdem jetzt alles stimmt hoffe ich es findet sich auch jemand der damit etwas anfangen kann. Wie schon oben mehrmals erwähnt, wenn ihr noch andere Logs braucht, dann sagt es nur.

[verzweifelt]

Betanovascan ist ja immer 10x so gross wie der bei Linux das ist leider das einzige was ich erkenne. Ansonsten sind das für mich nur viele Zahlen.

Darf ich mal vorsichtig fragen ob irgendjemand mehr darin erkennen kann?

[Npq]

Ja, das ist ein cooles Log, auf den ersten Blick sehen allerdings nur die GPIOs für 121 MHz etwas anders als bei Tuxbox.

Hab die Demodwerte aber noch nicht genauer verglichen.