Posts by SHF

    Die Projektionsspots Jansjö und Tived von IKEA machen sehr saubere Lichtkegel.

    Gleichmässig hell zu komplett dunkel, Übergang an einer scharfen Linie. Wie bei einer fokussierbaren LED-Taschenlampe.

    Abstrahlwinkel dürften etwa die gesuchten 20° sein.


    Das sind allerdings Komplettlampen.

    Die Vorschaltgeräte sind AFAIK Konstantstrom-Typen, da könnte man aber was anderes verwenden und dann mehrere Leuchten in Reihe schalten.

    hier gibt es auch ein (leider wieder) abgespecktes Schaltbild vom 4er

    Man sieht wie die Spannungsregler aufgebaut sind, aber sonst ist leider nicht viel damit anzufangen.

    Wenigstens so ein grobes Schema, welche Buchse an welchem IC hängt, hätten die doch machen können.


    Was leicht erreichbar wäre, ist USB-OTG. Das haben die auf die USB-C Buchse gelegt. Reicht aber nicht für Festplatten.

    Die Versorgungsbuchse scheint laut Schaltplan endlich zumindest mit USB2 belegt zu sein.


    Wenn es als einfacher USB2 nutzbar wäre, würde mir das an USB reichen.



    Gibt es für den Raspberry PI 4 eigentlich auch noch den MPEG2 Codec zu kaufen?

    Ich habe schon mal gesucht, aber nur alte Seiten gefunden.

    Ich habe zwar schon etwas überlegt aber so recht fällt mir kein Anwendungsfall ein bei dem ich ohne USB auskomme.

    Ganz ohne USB ist natürlich nicht so toll.

    Man müsste mal schauen, wo die USB2-Buchsen dran hängen.


    Irgendwo müsste man für einen VDR-Server halt auch noch Festplatten ranhängen.

    An einen SATA-Controller.

    Deshalb will ich ja den PCIe frei kriegen ;).


    Würde so eine Digital Devices DVB-Karte an einer einzigen PCI-E Lane laufen?

    Ja, die sind nur PCIe x1.

    Und die Karten laufen auch an PCIe-Splittern. (siehe I2C Timeouts mit ddbridge)


    Jede Antenne mit einem Gewinn von mehr als 0dB hat eine Richtwirkung.

    Da hast du natürlich Recht. Das war von mir ungünstig formuliert.

    Mich würde interessieren, ob die Antenne etwa wie eine (liegende) Stabantenne reagiert, oder ob sich eine Keule von der Platine weg entwickelt.


    Funktionsmässig hatte ich mir auch was in der Art vermutet.

    Nur wie kommen die das bei der Grösse hin? Wenn ich mich nicht grob verschätzt oder verrechnet habe, liegt die grösste Abmessung deutlich unter Lambda/4.


    Sehr wahrscheinlich auch ein sehr schmalbandiges Design.

    Schätze ich auch.

    Die zweite, kurze Leitung, neben der eigentlichen Speiseleitung, wird dazu dienen, das die Antenne bei 2,4 und 5GHz funktioniert, vermute ich.


    Es gibt PCIe Adapter mit denen man PCIe Karten an einem USB Port kann. Dann könnte man SAT Karten weiter benutzen. Ob die Dinger was taugen?

    Diese Buchsen sind kein USB!

    Das ist "echter" PCIe x1 auf einer USB3 Buchse.

    Die USB3 Kabel und Buchsen passen elektrisch, zufällig nahezu perfekt auch für PCIex1 und werden darum dafür missbraucht.


    Wenn man es mit der Kabellänge nicht übertreibt, läuft das wohl auch einwandfrei (siehe Link oben).

    So wie ich das verstanden habe ist man aktuell noch dabei die Raspberry-Bibliotheken überhaupt auf einen Stand zu bekommen, dass die GPU sinnvoll funktioniert.

    Schade, damit ist das Teil für mich momentan genauso interessant, wie all die anderen Boards, wo die GPU nicht gescheit unterstützt wird.


    Da muss man wohl mal abwarten, ist momentan eh nicht das Wetter für sowas.

    Raspberry-Leuten traue ich es zumindest zu, es zu schaffen, es bis zum Winter grob zum laufen zu bringen.


    Das irgendwann jemand den PCIe rausleitet um andere Karten daran zu betreiben ist abzusehen.

    Das ist ja auch eine Steilvorlage.

    USB-Chip raus und die PCIe-Pins auf die USB3 überbrücken. Dann kann man so einen 10€ Mining-Riser verwenden.


    Nur das Gehäuse von dem USB-Controller könnte zum Problem werden.Das ist auf der Rückseite vollflächig verlötet, keine Ahnung wie und ob man das gescheit runter bekommt.

    Da fragt man sich doch warum die dann nur zwei USB3-Buchsen bestückt haben?

    Ist mir auch schon aufgefallen.


    Die nächste Frage ist, ob die USB2-Buchsen überhaupt an dem Chip hängen oder direkt am SOC.


    Ich hatte schon überlegt, ob die noch mit USB3 angebundene Komponenten auf dem Board haben, aber ich sehe nichts.



    Hat von euch jemand eine sinnvolle Erklärung zur Funktionsweise dieser "Proant resonant cavity antenna" gefunden? Interessantes Design, aber mehr als "da schwingt was im Spalt" hab ich bislang nicht gefunden.

    Mich als Anwender würde unter anderem interessieren, ob die Antennne eine Richtwirkung hat.

    Wie sieht es denn mit dem HW-Decoder für h.264 aus?

    Ist das Teil abwärtskompatibel, so das aktuelle Software (Xine) läuft?


    An sich sieht das Teil aber echt interessant aus und endlich ist die Peripherie auch gescheit angebunden. Nur wenn wenn es dann wieder Jahre dauert, bis Xine die Decoder Unterstützt, kann ich den als Client erstmal vergessen.


    Das einzige, was mir auf dem Papier nicht so gefällt, ist der USB-Chip von VIA.

    Die USB-Controller von denen waren früher nicht so der Binger. Mal sehen, vielleicht haben die ja inzwischen dazugelernt ...
    Da der USB-Controller per PCIe angebunden ist und ich eigentlich kein USB3 brauche, könnte man da auch was anderes mit der USB3-Buchse anstellen :mua. Das Board könnte echt interessant werden!

    [...] Ganz so trivial ist die Geschichte nicht.

    Klar, falsch machen kann man immer was.

    Generell ist PCIe aber wohl deutlich unempfindlicher als PCI.

    So ein 1m "USB3"-Rieserkanel wäre PCI undenkbar.


    Ausserdem gibt es bei PCIe x1 nur ein Aderpaar je Richtung.

    Wenn da irgendwas falsch läuft muss es eigentlich alle Übertragungen betreffen.


    wer sagt denn, das dem nicht so ist? Wer hat das in der Tiefe genau analysiert?

    Wir nutzen mit der gleiche CPU ein Board von Faytech ( FAY003 gefertigt von ASUS) das ein solches Verhalten nicht aufzeigt.


    Selbst hier bei den beiden Asrock PCI-Brigdes sind (laut lspci) nicht identische Controller im Einsatz.

    Laut meinen Informationen (man korrigiere mich, wenn ich falsch liege), ist die PCIe-Hostbridge Teil des J3455 SOC.

    D.h. alle Boards mit dem Celeron J3455 haben die gleiche.

    die CorrErr+ werden ein Indiz aber nicht das Problem sein

    Die "CorrErr+"-Flags setzt der Empfänger, wenn er defekte Datenpakete empfängt, die er aber noch korrigieren konnte. (Durch Anforderung einer erneuten Übertragung oder wie auch immer.)

    Erst wenn Korrektur scheitert, wird auch "UnCorr+"-Flag gesetzt.


    Solange also nur "CorrErr+" gesetzt ist, sind die Daten die man bekommt (noch) in Ordnung.


    Trotzdem sind dauernd gesetzte "CorrErr+" ein eindeutiges Indiz, dass die Übertragung nicht "sauber" läuft.


    Und da die "CorrErr+" immer nur in einem Link auftauchen, an dem eine DD-Karte beteiligt ist, kann das eigentlich nur bedeuten, dass die die Ursache ist.


    es wird schon, so wie von DD vermutet, ein HW Design Fehler vorliegen. Entweder was im Chipsatz und/oder im PCB Layout.

    Meine Vermutung geht in Richtung BIOS.


    Am Chipsatz kann es nicht liegen, sonst wären andere Boards mit dem SOC auch betroffen.

    Und was kann man bei 6 Daten-Leitungen gross falsch machen?


    Dann wird es wohl auch so sein, das mehrere Parameter sich hier addieren und nicht einer allein ganz "Schuld" trägt.

    Für mich sieht es so aus:

    Die Karte arbeitet nicht "sauber" und produziert bei der Übertragung Fehler.

    Bei J3455M funktioniert die PCIe-Fehlerkorrektur nicht richtig.

    Trifft beides zusammen knallt's.


    Aber nur auf der "Gegenseite":

    Das "CorrErr+" wird immer vom Empfänger der Daten gesetzt. (Geht ja auch nicht anders, wie sollte der Sender wissen, ob die Übertragung fehlerfrei war.) Über den Verursacher des Fehler sag das überhaupt nichts aus.

    In dem Fall bedeutet das also nur, dass die Fehler in den Daten Richtung Mainboard waren.


    Bei einer DVB-Karte gehen typischer Weise viel mehr Daten von der Karte zum Mainboard, als umgekehrt. Daher ist es auch eigentlich zu erwarten, dass die Fehler häufiger in der Richtung auftreten.


    Hat DD auch diese Karte mit dem PCie Analyzer getestet? Es wäre interessant zu wissen, ob es damit auch diese unerwarteten "Nak"s gibt.

    Das wäre wirklich mal interessant.

    Meine Vermutung ist, die kommen nicht.


    Je öfter ich mir die Bilder ansehe, um so weniger sicher bin ich, ob die "Nak" falsch sind.

    Logischer finde ich inzwischen, dass das "Ack" direkt nach der Übertragung falsch ist. Angenommen in diesem Paket ist ein Fehler oder es ist unvollständig, müsste nach einem Timeout ein "Nak" folgen (und dann einer erneute Übertragung). Wenn in der Zwischenzeit aber schon ein "Ack" gesendet wurde, weiss die Gegenstelle was sie tun soll, weil das nicht dem Standard entspricht.


    Je schneller der Empfänger das "Ack" nach einem Datenpaket zurück schickt, desto eher kann der Sender das nächste Paket schicken. Das Steigert natürlich den Durchsatz.

    Für mich riecht das nach einem experimentellen Feature zur Beschleunigung des PCIe-Durchsatzes, das versehentlich noch aktiviert ist. (VIA lässt grüssen ;).)

    Interessante Einblicke, danke fürs Teilen.

    - gleichfalls an DD für die Erlaubnis dazu.

    Die aktuelle Aussage von DD ist, dass es sicher am HW-Design des ASRock J3455M Motherboards liegt, wie die angehängten Screenshots ihres PCIe-Analyzers zeigen sollen.

    Für eine Sequenz erst ein "Ack" zu senden und dann später ein "Nak", finde ich auch irgendwie unüblich.

    (Zur genaueren Bewertung müsste ich mich damit aber näher beschäftigen.)


    Nach dem "Nak" hätte ich auch eigentlich eine erneute Übertragung der betroffenen Pakete erwartet. Die findet anscheinend nicht statt.

    Wobei die vor dem "Nak" schon akzeptiert wurden ("Ack"), eventuell liegt es daran.


    Da scheint also irgendwas mit der PCIe-Fehlerbehandlung auf dem Board falsch zu laufen.



    Damit alles auf das Board schieben, macht es sich DD IMHO aber etwas zu einfach.

    Die Datenfehler "CorrErr+" wandern immer mit der DD-Karte, ans andere Mainboard, an den PCIe-Riser, ....

    Da muss also irgendwas nicht 100% sauber laufen (die anderen Karten machen die ja nicht).
    Solange das Fehlerbehandlung klappt, geht die DD-Karte wohl. Erst in Verbindung mit der defekten Fehlerbehandlung wird es dann irgendwann knallen.

    Aber da die anderen PCIe-Karten (Riser, Lan, DVBSky und auch alle meine), es schaffen keine "CorrErr+"-Fehler zu produzieren, sollte man sich überlegen, da auch mal anzusetzen.


    Ohne die"CorrErr+"-Fehler würde DD auch im J3455M laufen, da würde ich drauf wetten. Das ist da wohl einfach ein ungünstiges Zusammentreffen.


    Man ist wohl mit ASRock in Kontakt, aber ob sich von deren Seite was tut, ist ungewiss.


    Vielleicht ist es schon etwas spät, der Nachfolger ist schon raus und das Board ist praktisch im Abverkauf.

    Mal sehen, ich drücke die Daumen.


    Mit dem J4105M läuft die DD-Hardware dagegen soweit stabil.


    Naja, die CorrErr+ hatte die DD-Karte auf dem Board doch auch?

    Einige Debug-Infos zu den Aufnahmen hätte ich mir, bei der Fehlersuche, auch schon ab und an mal gewünscht.

    Wäre echt toll, wenn das direkt in den VDR rein kommen würde :tup. Dann hätten alle den gleichen Stand.


    Aktuell fallen mir da zwei Sachen ein, die mich interessieren würden:

    - Das verwendete DVB-Device ein.

    Während der Aufnahme kommt man problemlos dran, später aber nur noch über die Logfiles (falls überhaupt noch vorhanden).

    - Fehlende Pakete der Aufnahme.

    Da der TS der Aufnahme ja eh neu gepackt werden muss, würde es anbieten an der Stelle die ankommenden Pakete auf Vollständigkeit zu überprüfen. Prinzipiell muss das sogar schon irgendwie gemacht werden, sonst würde ein Fehler ja alles ausser tritt bringen. Ob man da aber einfach einen Fehlercounter dran bekommt, aber ich mir noch nicht angesehen.

    Ich habe die erste Variante versucht und danach war das Webinterface nicht mehr erreichbar.

    Das ist soweit normal. Dass Fritz.box nicht mehr geht, war zu erwarten. Der DNS der Box wird ja deaktiviert.

    Die IP ändert sich natürlich auch, die bestimmt jetzt der DHCP-Server auf dem anderen Router (FB ist nur noch Client!).


    Die IP für die FB musst du auf dem anderen Router raus finden (und am besten fest zuweisen).
    Dann geht auch das Webinterface wieder.

    irrecord: fatal error in configfile line 50:
    irrecord: "begin remote" isn't valid at this position

    Immer der Fehler?

    Wie sieht denn die konkrete Zeile aus? Das angehängte Beispiel hat keine Zeile 50!


    Kann man in kleineren Häppchen lernen, so dass der Verlust nicht so groß ist, wenn es schief geht?

    Man kann mit einer lircd.conf mit Header, also mit "remote" aber ohne "codes" starten.

    Dann fällt die Erkennung der FB weg und man kann gleich anlernen.


    Die Muster / Gaps sonstwas werden unterschiedlich erkannt,

    Bei deutlichen Unterschieden, läuft schon bei der Erkennung der FB was schief.

    Weitere Versuche ohne korrekten Header sind nach meiner Erfahrung zwecklos.


    Leider senden die Universal-FBs oft mit einem ziemlichen Jitter, so dass die Erkennung schwierig ist.

    Ich hatte den Fall selber mal, dass eine funktionierende RC5-FB nicht als solche erkannt wurde. Erst als ich den Header von einer anderen RC-5-lircd.conf "geborgt" habe ging es dann.


    Dein Codeschnipsel (SPACE_ENC|CONST_LENGTH und 32Bit) sieht nach NEC oder Samsung-Protokoll aus (Die_IR-Protokolle_im_Detail). Die Werte sind etwas daneben.

    Entweder mal anpassen versuchen oder bei Lirc eine entsprechende lircd.conf suchen und nur deren Kopfteil verwenden.

    Ich stehe dem Vorschlag, in der info-Datei ein Zeichen für Plugins zu definieren, offen gegenüber und halte das mal für die 2.5.x fest.

    :tup

    Bitte dabei nur auch an die Skripte-Bastler denken, die nur einfach eine Zeile anhängen wollen.


    Recording hooks Script, prüft auf TS-Fehler nach Schnitt und sorgt dafür, daß "alles" bei der Aufnahme bleibt:

    Mit der extra Datei im Aufnahmeverzeichnis gab es bei mir irgendwie Probleme.

    Wenn ich das noch recht erinnere blieb die beim Löschen der Aufnahme stehen. Kann aber sein, dass das inzwischen nicht mehr auftritt.

    Leider hat sich dank Seahawk1986s Link herausgestellt, dass die 6490 zu den Boxen gehört, die sich nicht als IP-Client einrichten lassen.

    Da gibt es zwei Möglichkeiten das einzustellen:

    "vorhandener Zugang über LAN"

    "weitere Internetanbieter -> andere Internetanbieter -> Anschluss an externes Modem oder Router -> Vorhandene Internetverbindung mitbenutzen"

    Beides versucht?

    Die Anzahl der continuity Fehler der Aufnahme. Sehr hilfreich, wenn man Aufnahmen manchmal erst viel später anschaut, um gleich zu wissen, ob sie OK sind.

    Das hatte ich vor einer Weile vor per Script machen zu wollen und leider kein Feld für den allgemeinen Gebrauch in der info-Datei gefunden.


    Evtl. könnte man sich ja ein Zeichen für Plugins überlegen?

    +1 (s.O.)


    Alternativ die könnte man auch die Kommentar-Zeilen (#) beim Schnitt mitnehmen. Damit könnte man auch was anfangen.

    Wenn man sich schon die Mühe macht, ein Kommentar in der info einzufügen, dann will man es normalerweise auch drin behalten.


    Es wäre schöner, wenn der @ Tag mehrfach vorkommen darf.

    IMHO keine gute Idee.

    Die @-Zeile wird derzeit aus dem Aux.Feld vom Timer erzeugt. Wenn sich ein Programm drauf verlässt, gibt's Chaos.


    Ich hab jedenfalls von der Zeile lieber die Finger gelassen, nicht dass es mit EPG-Search Probleme gibt.

    Sorry, dass ich mich erst relativ spät zurückmelde.

    Dito sorry, ich hab die Antwort übersehen.

    Positionen 5W und 23.5E sind schon mal gestrichen, da Unicable I nach SHF sowieso nur 2 Positionen unterstützt und

    um die Gefahr böser Überraschungen zu vermindern. Da Unicable I älter als Unicable II ist, hoffe ich dass es ausgereifter ist.

    Problem ist IMHO eher, dass derzeit nicht viele nicht viele Endgeräte Unicable II unterstützen.


    Wenn ich richtig gegoogelt habe, kosten sie ungefähr 150 Euro :-/ . Diese Summe wäre wahrscheinlich besser in einen professionellen Satinstallateur investiert.

    Den du dann aber auch im Fehlerfall erneut beauftragen müsstest.


    Beim Monoblock reichte die Stromspeisung des Receivers. Anhand der vorausgehenden Erläuterungen verstehe ich es so: beim Quad Monoblock braucht der Receiver immer nur das gerade benutzte LNB des Monoblocks mit Strom zu versorgen; bei zwei Unicable LNBs jedoch, müssen beide ständig aktiv auf Signale horschen, ob ein Receiver ihre Dienste benötigt und gegebenfalls die Daten des gewünschten Transponders liefern.

    Das Problem ist, dass einfach nicht zu sagen ist, welcher LNB wann wie viel Strom zieht. Daher muss man vom schlimmsten Fall ausgehen.


    Der Quard Monoblock braucht meist etwas mehr als ein einfacher LNB. Er ist aber so ausgelegt, das er an einem Receiver läuft. Das ist ja der normale Anwendungsfall.

    Ich glaube mich aber Fälle zu erinnern, wo diese Monoblocks an den alte FF-Karten auch mal Probleme machten.


    Eine Idee wäre vielleicht Splitter und Combiner in eine Wasserdichte Dose zu stecken; somit blieben nur die F-Stecker am LNB im Regen.

    Das ist mehr oder weniger zwingend, falls man nicht spezielle Outdoor-Versionen verwendet.


    Aber ausser Regen gibt es auch noch Kondenswasser und UV-Strahlung, die der Installation zusetzen können.

    Die "Dose" sollte also schon was taugen ...


    Mein erster Gedanke war auch, die Stromeinspeiseweiche müsste zwischen Combiner und Splitter, damit die Receiver an den 4 Koaxkabel davon profitieren.

    Das ist richtig.


    Ich bin mir nicht sicher, was du mit den zwei Splittern meinst; ich nehmen an du wolltest folgendes sagen: von den 4 Koaxkabeln, die mir zur Verfügung stehen, werden 3 benutzt, um Receiver zu versorgen und der vierte, um den Strom einzuspeisen. Die 3 Receiverkabel gehen an einen Splitter draußen der sie verbindet; dieser Splitter und der 4. Koaxkabel mit dem Strom gehen an einen zweiten Splitter, der sie verbindet; dieser zweite Splitter geht an den Combiner...


    In der Zwischenzeit frage ich mich dann, warum ich den 4. Koaxkabel mit dem Strom nicht einfach an den ersten (vom Zimmer aus gesehen) Splitter mit den anderen 3 Koaxkabeln verbinden kann. Außerdem, muss ich überhaupt ein Koaxkabel für die Stromeinspeisung reservieren? Vor dem Combiner kommt sowieso alles zusammen; warum also nicht einfach die Stromeinspeiseweiche zwischen einem Receiver und einer Satsteckdose anbringen. Übersehe ich vielleicht etwas?

    Das eine Kabel nur zur Fernspeisung zu verwenden ist wohl geschickter.



    Wenn es Platzmässig aussen machbar ist, würde ich einen fernspeisbaren Multischalter bevorzugen.

    Das sollte aber unbedingt ein Modell für den Ausseneinsatz sein und ich würde es auch nur Wetter geschützt montieren.

    warum nimmst Du nicht einen Einkabelmultischalter bsw. den hier --> http://jultec.de/JPS1701-16.html

    Guter Fund.

    Der sieht ja fast so aus, als ob das Gehäuse einigermassen wetterfest ist. Leider steht nichts in der Anleitung

    Das hat jetzt zwar etwas länger gedauert, da ich ich das Plugin doch noch nicht drauf hatte.


    Aktuell geht mit der "jw9" aber folgendes:


    Angezeigt werden können die folgenden Ereignisse:

    Code
    1. static const char * OutputFunctionText[]= {"Off", "On", "Recording DVB1", "Recording DVB2", "Recording DVB3", "Recording DVB4", "Replay", "DVD", "MPlayer", "MP3", "MPlayer + MP3", "User1", "User2", "User3"};

    Die Liste ist IMHO nicht ganz ideal. Sachen wie "MUTE" und generell laufende Aufnahmen fehlen leider.


    Zuordnung zu den LEDs, in deinem Fall Icons, geschieht im Menü unter OutputNumber.


    Die Zuordnung LED -> Icon aus dem LCDproc-Manual:


    0 Play
    1 Pause
    2 Record
    3 Message
    4 Mail (at-symbol)
    5 Mute
    6 WLAN tower
    7 Volume (the word)
    8…12 Volume (decimal 0…28)
    13…14 WLAN strength (0…3)



    Viel Spass beim testen.

    Der Code ist seit Urzeiten im Plugin drin.

    Ursprünglich diente er zum Ansteuern von LEDs, die parallel zum LCD an geschlossen werden konnten.


    Es kann sein, dass es im Menu auch LED oder so ähnlich heisst.

    Ich hab das Plugin schon länger nicht mehr drauf. Ich kann aber nachher mal nachschauen.

    Ich kannte solche Bauteile nur als "Verbinder" von SAT und terrestrischen Signalen.

    Der ist aber technisch was anderes.

    Es handelt sich dabei eher um eine Frequenzweiche. Sie Frequenzbereiche von SAT und terrestrischen Signalen überschneiden sich nicht und können daher "übereinander gestapelt" werden.

    Das funktioniert auch rückwärts.


    Beispiel: GOOBAY 67054 SAT-TV-Einschleuseweiche

    Quote

    Der Combiner kann auch "rückwärts" genutzt werden. Dann werden die Signale wieder aufgesplittet.

    Meistens ist das aber in der Antennendose eingebaut.



    ... Ist aber immer noch ein anderes Bauteil als ein Splitter ...

    Es gibt für SAT zwei Splittertypen:

    1. Der "übliche" zum Anschluss mehrerer Tuner an ein LNB.
      Bsp: Kathrein EBC 10 Verteiler 2fach 2,4 GHz
      Mit eingebauten DC-Entkopplungsdioden
      Stromflussrichtung nur von je von jedem der beiden Ausgäng zum Eingang.
    1. Den mit DC-Durchgang
      Bsp: Kathrein EBC 110 Verteiler 2fach 2,4 GHz
      Ohne Entkopplungsdioden gedacht für den Einsatz in Einkabel-Systemen.
      Die eingespeiste Spannung liegt bei dem Typ an allen Ein- und Ausgängen an.

    Der zweite Typ sollte theoretisch auch als Combiner gehen.



    Tatsächlich werden die LNBs hier in den SCR Kanälen/User Bändern gleich programmiert, eben der eine als Position "DiSEqC A", der andere als Position "DiSEqC B". Wird jetzt z.B. ein SCR Kanal für "DiSEqC A" angesprochen, wird gleichzeitig auf dem "DiSEqC B" LNB, der entsprechende SCR Kanal abgeschaltet und damit geschützt.

    Problematisch wird es aber, wenn ein LNB Amok läuft und sich nicht dran hält. Das kann das ganze System stören.




    Von Inverto gibt es auch einen Unicable kompatiblen Power Inserter zur Speisung der LNBs.

    Allerdings kann der auch nur 750mA liefern. Man bräuchte also einen pro LNB.

    Ohne zusätzliche Kabel wird es mit dem also auch nichts bei 4 LNBs.

    Ähm, naja, die Lösung, je 1 LNB pro SAT Position im Multifeed an einer Schüssel, funktioniert nur mit einem vorgeschalteten DiSEqC Schalter.

    Da ist aber immer ein DiSEqC Schalter pro Tuner verbaut. Die Schalter schalten auch das komplette Kabel um, prinzipiell wie ein normaler Wechselschalter. So kenne ich das zumindest.


    Hier bräuchte man aber einen Frequenzselektiven Schalter. Das bekommt man nicht für 10€ VK gebaut.


    Man kann sich nun streiten ob das passive Geräte sind oder nicht

    Die DiSEqC Schalter sind definitiv aktiv.

    Ein Signal vom Receiver wird ausgewertet und entsprechend umgeschaltet.

    Da ist also mindestens eine Auwerte-Elektronik für das DiSEqC und eine Art HF-Relais drin.


    Ein einfacher Splitter ist passiv. Da ist ein Richtkoppler oder was ähnliches drin.

    Im Endeffekt ist das nur ein kleiner Ringkern mit etwas Draht drum und ein paar Kondensatoren. Und halt noch die Dioden für DC.


    Richtkoppler kann man auch zum zusammenführen von Signalen verwenden (siehe unten im Link).


    Die SCR LNBs wissen von Ihrem Glück und voneinander nix ...

    Wissen sie doch!;)

    Die LNBs müssen entsprechend programmiert werden, wenn man mehr als einen verwenden will.

    Soweit ich das verstanden habe, muss mindestens jedem eine unterschiedliche Sat-Positions-Nummer zugewiesen werden.


    Hast Du denn schon eine genau auf deine Antenne abgestimmte Feedschiene, auch mit Höhenjustage der einzelnen LNBs?

    Von Gilbertini gibt es diese Schienen, da hattee ich schon mal geschaut.

    Ich selber habe die 100er von denen.


    Können die LNBs für Dein Vorhaben dort passen?

    Ich bezweifele das, die Dinger sind echt breit.

    Anfangs hatte ich einen Inverto-Quard verbaut (der Typ mit dem eingebauten Wasserschaden ;)), der hat ein ähnliches Format (Breite) wie die aktuellen Unicable-LNBs.

    Als minimal möglichen Abstand hatte ich da mal irgendwas kurz unter 15° ausgeknobelt. An der 85er wird das noch mehr.