Jump to content

Fazz

Full Member
  • Gesamte Inhalte

    98
  • Benutzer seit

Beiträge erstellt von Fazz

  1. wie und wo muss ich was ändern, damit nach jeden umschalten einmal die enxreset im bin verzeichniss ausgefüht wird.

     

    mit Telnet zur Box verbinden, dann

    "touch /var/etc/.zap_enx_reset"

    eingeben bzw ausführen.

     

     

    Steht (jetzt?) auch auf der ersten Seite.

     

    greetz

    Fazz

  2. Man kann den sectionsd ja sogar komplett killen,

    ("killall sectionsd")

    damit der aber nicht von alleine neu startet, muss man ihn vorher im

    Keyweltmenu->Systemmenu->Keep-alive-Menu ausschalten.

     

    Dauert bei mir zwar dann länger(vieleicht auch nur einbildung) bis zum zwitschern,

    aber zwitschert halt trotzdem irgendwann. :-(

     

    greetz,

    Fazz

  3. FYI:

     

    hab auch noch was interessantes gefunden,...

     

    geschrieben von nokia (tmbinc):

     

    ...

    ucode.bin:

     

    der originalucode ist beim eNX und GTX der gleiche. er kann nicht descramblen (oder wenn dann anders als die anderen), es gibt keine doku darüber (ausser bei BR), generall handelt er sections komplett anders und dafür fehlt sämtliche doku.

    für die anderen ucodes, die aus nem radix-fta-(GTX-)reciever sind (z.b.), haben wir doku und deshalb gibts dafür auch hw sections.

     

    warum das nicht ordentlich auf dem eNX läuft ist bis heute unklar. alle reset- und sonstwas aktivitäten sind wenn überhautp work arounds. es gibt nen recht stabilen fix (mit denen boxen tagelang ohne ruckler o.ä. durchlaufen), WARUM der allerdings funktioniert weiss ich auch nicht. WARUM den noch niemand anders gefunden hat ausser einer (ich war's nicht weiss ich auch nicht. Ich hab jedenfalls tagelang rumgemacht und bus-timing kontrolliert, und nichts gefunden. evtl. kann man mit nem logic analyzer mal was ausrichten. oder es liegt doch am ucode, aber das glaub ich nicht.

     

    nebenbei könnte man den mal reversen: im enx-treiber ist oder war mal nen anfang von nem debugger drin. man kann nämlich wunderbar durchsteppen durch den code. dummerweise ist völlig unklar was für ne RISC-engine da drin ist. irgendwas von samsung, so wurde berichtet.

     

    jump befehle findet man ja recht leicht, aber dann sit auch schluss.

     

    tip: die register in der umgebung vom PC sind irgendwelche anderen risc register.

    ...

  4. Nee, über den normalen Weg (SEC/cam-alpha schickt vermutlich an AVIA(?)) gibt es AFAIK kein Zwitschern.

    Nur wenn das nicht per SEC/cam-alpha dem AVIA geschickt wird(?), passiert das.

     

     

    aber nochmal, Fakt ist :

    Wenn unverschlüsselte auch schon Probleme machen, hat das nix mit der Zwitscherthematik zu tun, und ihr seid hier verkehrt. (Dann sinds eher Empfangs/Tuner/SEC -Probleme)

     

    n8,

    Fazz

  5. @Heavensonfire:

    sollte die nicht zwitschern bitte in einem anderen Thread beteiligen,

    such doch mal nach "kalte Lötstellen" im Tuner per Boardsuche.

     

     

    also, das einzige was irgendwie definitv gesichert ist, ist doch das ALLE zwitscherboxen mit Ucode 001A deutlich länger zwitscherfrei bleiben!

     

    Jetzt stellt sich nat. die Frage, wie kann das sein?

    Was macht der anders?

    Dazu zur nächsten gesicherten Erkenntis.

    001A kann kein

    - SPTS

    - HW-Sections-Filtering

     

    Ich vermute einfach mal der Ucode 0014 wird das HW-Sections immer durchführen

    (zumindest Teile davon, egal ob neutrino das auswertet oder nicht)

     

    Dadurch ist dann weniger Zeit beim 0014 für andere Dinge (z.B. eine Interruptverarbeitung,...) als beim 001A

     

    greetz,

    Fazz

  6. Nur den Quarz können wir also ausschliessen, da ja jetzt auch der erste vom Hersteller "NDK" betroffen ist.

     

    stimmt so eine Liste wäre nicht schlecht.

     

    aber irgendwie scheint das ja eh sehr unterschiedlich zu sein. Wenn ich meine mal mit z.B. Xanders vergleiche. Ich habe hier eine Extrem-Zwitscherbox.

    (denke das es letzte Zeit noch schlimmer geworden ist). Mit Ucode 0014 ist sie fast nur am zwitschern(spätestens so 30 sekunden- 2 Minuten) nach dem Start, mit Ucode 001a hält ca 30 Minuten durch.

     

    Ich hatte vorher noch ne andere Zwitscherbox, die hielt auch irgendwie länger durch!

     

    greetz,

    Fazz

  7. Ich fasse mal zusammen:

    Bis jetzt haben alle Problem-Quartze eine "0" am Ende (ausser der a0) und sind alle von HKC, richtig ?!

    Also Z0 oder B0.......ist das erste Symbol die Produktionsstrecke und das zweite das Jahr (2000) ??

    Wer kann das dekodieren.....nur so ne Vermutung......

     

    dass die 0 die Jahreszahl ist kann ja sein

    der Buchstabe die Kalenderwoche ist ja eher unwahrscheinlich

    A = KW1

    B = KW2

    ...

    Z = KW26 Zwitschert

    --------

    a = KW27 Zwitschert nicht

     

    am einfachsten wäre doch mal bei ner Zwitscherbox nen anderen 27.000 er einzulöten, ich habe noch uralte vom CBfunk mit 27.125,... hier rumliegen, die werden wohl nicht gehen? (Eher die Box vollends verwirren/desyncronisieren?)

     

    greetz,

    Fazz

  8. Jupp, Modem ausbauen ist immer gut, sorgt auch für bischen mehr Luft.

    Schaden tut es keinesfalls.

     

    Speicher der CPU können wir also erstmal ausschliessen, aber wie ist es mit den anderen beiden also AVIA und ENX? 80 ns haben die scheinbar ja eh immer, aber sind die bei euren Zwitscherboxen auch von HYUNDAI?

     

    Ich verfolge gerade noch mal einen völlig anderen Ansatz(änderung der Prozessprioritäten) da jemand meinte es liegt ev. am sectionsd:

    ein erster Versuch nur mit ( "renice 20 `pidof sectionsd`") war bei mir leider bisher nicht erfolgreich, mal sehen wann ich weiterteste,....

     

    vieleicht hat ja jemand anderes Bock mal mit den Prozessprioritäten zu spielen

    z.B.

    CAMD3 weit zu erhöhen -> "renice -18 `pidof camd3`"

    Sectionsd ganz runter -> "renice 20 `pidof sectionsd`"

     

    greetz,

    Fazz

  9. Nochmal zum Speicher:

    beim speicher ist der hersteller denke ich egal. wenn dann ist die reaktionszeit wichtig (60ns aus obigem post bei der nicht-zwitschernden).

     

    kann mal jemand ein bild posten was wir wo ablesen können?

     

    a.) Ich weiss nur aus der PC Erfahrung dass die "MT" oft auf den NoName Modulen drauf waren, die im PC-Bereich Ärger brachten(Bluescreens), HYUNDAI dagegen auf den teureren Markenmodulen, mit denen war man sicher. Daher mein Verdacht, zumal dass bei meinen 3 Boxen so schön passt

     

    b.) ablesen kann man die Geschwindigkeit an der oder den letzten Ziffern hinter dem "-"

    Das ist je nach Hersteller unterschiedlich.

     

    z.B

    -8 ist 80 ns

    -6 ist 60 ns

    -80 ist 80 ns

    -60 ist 60 ns

    -75 ist 75 ns

     

    greetz,

    Fazz

  10. Meine Zwitscherbox hat einen "HKC 27000 BO" , ist nicht an der Masse gelötet !! (frei beweglich !!)

     

    Habe 3 Stück Sagem 1x

     

    Meine Zwitscherbox hat einen "HKC 27000 Z0"(nicht gelötet, trotzdem unbeweglich) und "LV125 D7223A 107B"

    Meine Zwitscherfreie1 hat einen "HKC 27000 C1"(nicht gelötet, beweglich) und "LV125 D7223A 105B"

    Meine Zwitscherfreie2 hat einen "HKC 27000 a0"(angelötet) und "LV125 D4033A 038B"

     

     

    BTW

    Ich habe auch den Speicher in Verdacht,... also wenn ihr eh gerade beim Prüfen seid:

    die Zwitscherzicke hat "MT" Speicher (ENX:80ns AVIA:80ns CPU:75ns)

    Zwitscherfreie 1 hat "HYUNDAI" Speicher (ENX:80ns AVIA:80ns CPU:60ns)

    Zwitscherfreie 2 hat "HYUNDAI" Speicher (ENX:80ns AVIA:80ns CPU:60ns)

     

    greetz,

    Fazz

  11. @newcode:

     

    Meine Avia Firm. ist die 0028. Die 0022 und 0030 laufen schlechter. Zum Teil habe ich damit Verzerrungen im unteren Bildviertel.

     

    Hoffentlich ist das keine dumme Frage:

    kann es ev. was bringen das Script als Hintergrundprozess laufen zu lassen??

    ("&" - Zeichen ganz ans ende, also noch hinters done)

     

     

     

    BTW:

    die Mittelwertberechnung im DualPes hab ich verworfen, da manchmal keine Abweichung vom Mittelwert vorhanden war, bzw. erst nach etlichen sekunden gezwitscher, endlich eine Schwelle erreicht war.

     

    greetz,

    Fazz

  12. Puh, musste mich auch erstmal bischen mit der Bash befassen,

    aber es läuft im spts-mode

     

    Wollte die ganze Zeit noch mal die unterschiedlichen Zahlen die im Dual PES-Mode auftreten analysieren, allerdings wirken sich scheinbar auch andere Ereignisse auf die Anzahl der Avia-Interrupts aus, so das das doch schwieriger wird. Ich versuche vieleicht die Tage mal eine Standartabweichungsüberprüfung reinzubauen, auch wenn ich zweifel habe.

     

    Aber ev. könnten wir im Dualpesmode auch mit kleiner 300 millisekunden statt 1 Sekunde prüfen, da dort erheblich mehr Interrupts auftreten.

     

    andererseits könnten wir den SPTS auch noch auf 500ms "tunen" :-)

    es gibt wohl "ussleep" für mikrosekunden,....

     

    cu

    fazz

  13. Hi, newcode

     

    Das Thema mit den Interrupts hat mir keine Ruhe gelassen. Die bleiben tatsächlich weg, aber nur wenn die Box im SPTS Mode ist.

     

    womit hast Du das herausgefunden? Hast Du selbst ein Programm geschrieben was das überprüft?

     

    Ich habe dann per Script ein enxreset ausgelöst und das zwitschern hört auf. Aber oft bleibt der Ton dann ganz weg. Um ihn wieder zu kriegen muß man dann noch ein rezap machen.

    ev. könnten hier ja noch die einstellungen im "gt_proc"-menu helfen

     

     

    Ist zwar nur ne Krücke, aber besser als der timergesteuerte enxreset.

    Das will ich meinen!!!

     

    Getestet habe ich auf der beta9, sollte aber auch auf dem 2006er Image laufen.

     

    Stelle mich gerne zur Verfügung :D

     

    greetz,

    Fazz

  14. um wieder zum thema zurückzukommen:

    was ist denn für die irq-überwachung nötig?

     

    Ich habe einerseits leichte Zweifel, daß es überhaupt klappt, da beim Zwitschern ja noch demuxed und decoded wird, blos halt irgendwie unsynchron bzw. stotternd.

     

    daher werden wohl noch interrupts erzeugt und verarbeitet,...?

    mit Glück ja ev. nur unregelmäßig, so dass es für eine Detection reicht.

    Fakt ist ja das eine ehemalige Lösung(nicht benannte) das ja auch sauber hinbekommen hatte,...was wiederrum hoffen lässt!

     

    greeetz

    Fazz

  15. Hallo,

     

    bei mir tritt das Problem auch bei FTA-Programmen auf, außerdem wird ein sehr hoher BER-Wert angezeigt. Handelt es sich um das gleiche Problem oder liegt der Fehler eher am Tuner?

     

    Wie auf seite 1 und in den über 40 Seiten sehr oft beschrieben, tritt das Threadproblem nicht bei FTA (unverschlüsselten) Sendern auf!

     

    Insofern hast Du keine Zwitscherbox, sondern ein Antennen/Tuner-Problem.

    Bitte beteilige Dich an einem Thread wo es darum geht, bzw. mache einen dementsprechenden auf.

     

    Nix 4 ungut,

    Fazz

  16. Es gibt noch kein Geheimrezept um das Zwistschern vollständig zu beseitigen. Ich habe einen Enx Reset alle 10 Sekunden eingebaut, dadurch ruckt es zwar immer ein wenig, aber wenn es zwitschert dann nur kurz.

     

    Jo, und ich habe mit Ucode 001A + Tunertreiber UltimoV8 und einigen einstellungen im Avia_gt_proc Menu(z.B. Delay auf 280) mein Zwitschern auf höchstens noch alle 30 Minuten reduzieren können(teilweise rennt die Box auch 2 stunden durch),...

     

    Habe deshalb bei mir nur die Lösung mit dem manuellen eNX-Reset sowohl beim umschalten als auch auf Taste "Blau-Blau" gelegt. Die Box eignet sich zum ruckelfreien Gucken(nur Stereo) somit noch ganz gut (zum streamen natürlich nicht).

     

    @[WCR]Tomcat:

     

    das dürfte dann wohl an deinem Tuner liegen, der kann die QAM256 nicht sauber,...

    dabei hilft der Sagem-UltimoV8 Treiber auch noch nen kleinen Tick nach.

     

    Den kann man über

    "Blau -> KeyweltMenu -> SystemMenu -> ImageAktualiesierung -> ImageÜberInternetUpdaten -> ImageUpdates -> SagemTunertreiber"

     

    laden(Neustart nicht vergessen)

     

    greetz,

     

    Fazz

  17. @bahnbooster:

     

    Zur Behebung eines Problems MUSS man die Ursache kennen,....

    (ob die Behebung dann später sinnvoll ist, sei jetzt erstmal dahingestellt)

     

    Wenn wir die eNX-Chipsatz-revision als Fehlerursache ausschliessen könnten wäre das ein grosser Erfolg (btw: es erwartet sicher hier keiner von Dir, das Du den Kühlkörper entfernst)

     

    Aber in alle erdenklichen Richtungen weiterzuforschen, Daten zu sammeln, und Brainstorming zu betreiben, macht immer Sinn, und genau dazu ist doch der Thread hier da, oder?

     

    Daher bitte ich weiterhin um mehr Daten der eNX-Beschriftungen mit der zusätzlichen Angabe "zwitschert(nur bei Emu): ja/nein"

     

    greetz,

    Fazz

  18. Hi,

     

    kann es vieleicht sein das nur eNX bis zur Produktionsreihe CCxxxxx betroffen sind?

     

    alle meine Zwitscherboxen(bisher 4 stück)

    hatten CAxxxxx  CBxxxxx oder CCxxxxx auf dem Chip

     

    meine zwitscherfreie hat CDxxxxx drauf.

     

     

    und der nächste mit dem "CCxxxx"!

     

     

    gab allerdings ja auch schon "GBxxxx" hier, die zwitscherten.(könnte aber nen anderes Werk mit dem B-stepping sein, dann käme es nur auf den 2ten Buchstaben

    der letzten Reihe auf dem eNX an. Wir brauchen mehr Daten.

     

    greetz,

    Fazz

  19. So, Ich mal wieder,...

    nur so zur Info und Halb-Offtopic.

     

    ich hab eine zusätzliche Sagemkabelbox erhalten. Diese hatte einen anderen Fehler, und zwar zwitscherte die anfangs auf allen Kanälen. Durch eine Reparatur(öhem, räusper,...Hab nur den Tunerdeckel oben abgenommen, läuft se wieder tip top, und ist auch keine Zwitscherzicke, alle Transponder kommen jetzt mit nem BER von 0 rein (ausser ARD 113000(niedrigste Frequenz) hat nen BER von 5000-10000, liegt aber IMHO an der Kabelanlage)

     

    Interessante Reparaturanleitung und Hintergrundinfos zum Tuner:

     

    Link

     

    Bei meiner Zwitscherzicke, hab ich einige Transponder die haben nen BER =264000(Vollausschlag), andere Transponder hingegen BER=0. Habe nat. auch hier den Tunerdeckel abgenommen, um mal zu sehen ob wenigstens die Bildruckler sich verringern lassen durch minimieren des BER auf den entsprechenden Transpondern. Ergebnis negativ bisher.

     

    BTW: Zwitschern tut se auch auf Transpondern die nen BER von 0 haben,... Ich gehe derzeit davon aus dass meine Zwitscherzicke gleich 2 Fehler hat, eine auf dem Tuner(s.o.) und halt unseren Topic.

     

    kann das mal eben jemand bestätigen, der ne Kabel-Zwitscher-box hat, das die auf allen Transspondern sauber mit nem BER um 0 läuft.

     

    Danke und Grüße,

    Fazz

  20. Noch was zum "schlechen" Platinenlayout / Design.

     

    Dies ist IMHO eher unwahrscheinlich, da sowohl Sagem als auch Philips betroffen sind.

     

    was wirklich entgültigen Aufschluss bringen würde, ist auf eine Zwitscherplatine einen zwitscherfreien eNX draufzulöten, Leider ist dies aber nicht so möglich.

     

     

    Ich glaube nicht an einen defekt, sondern an nicht korrekt angepasste Treiber an die (zwitschernde) Version des eNX.

     

    Deshalb nochmals den Ansatz, warum wird das CW über die cam_alpha "sauber" dem eNX übergeben, über einen emu jedoch scheinbar nur zu 99,99%?

    muss der eNX(in der zwitscherreversion) ev erst einen Speicherbereich löschen damit der externe Prozess, da reinschreiben darf, o.ä?

     

    greetz,

    Fazz

  21. Es verhält sich bei mir folgendermaßen:

     

    beim abglitchen des eNX (Zwitschern),

    a.) SPTS-Mode: weder Bild noch Ton

     

    b.) kein SPTS(getrennte AV-Streams) kommt der Ton noch hörbar durch halt mit zwitschern, das Bild aber so gut wie gar nicht mehr.

     

    hierbei ist auch jeweils der verwendete UCode (0014 oder 001A) zu beachten.

     

    darum Franzisco:

    1.) welchen Ucode verwendest Du (beim erfolgreichen streamen trotz zwitschern)?

    2.) nimmst Du im SPTS-Mode auf?

     

    grüße,

    Fazz

×
×
  • Neu erstellen...