Erste Sat>IP-Geräte vorgestellt: Hardware- und Erfahrungs-Sammel-Thread

  • Ich bin durch Zufall auf folgende interessante Produkte gestoßen:


    Schwaiger:
    MS41IP 031 SAT>IP Multischalter


    Erste SAT>IP fähige Receiver


    DSR41 IP SAT>IP fähiger Media-Player auf Android-Basis


    Inverto:
    Multibox inverto IDLS 400s
    Sat>IP Umsetzer, bietet auch PVR und NAS Funktionalität bei Anschluss von USB-HDD


    Telestar:
    Digibit R1-Transmitter - Der Preis ist mittlerweile bei 180€ ohne Mwst -- ist wohl einiges günstiger als 4 DVB-S2-Tuner in einen VDR zu bekommen...


    passend dazu der Telestar Digibit R1 (Receiver) , schon ab 106€


    Triax (Hirschmann-Multimedia):
    Triax TSC 100 IP Receiver
    Triax TSS 400 SAT>IP Server
    Infos gibt's bis jetzt nur hier



    Vor allem SAT>IP Multischalter/Server wären doch interessant als VDR-Kopfstation - somit müsste man nur noch ein LAN-Kabel zum VDR ziehen und spart sich den Einbau von Tunern!


    Was haltet ihr von den Geräten?


    Gibt es schon erste Erfahrungen damit?


    Hat es jemand im Einsatz in Kombination mit VDR?

  • Die Geräte von Inverto, Telestar und GSS scheinen mir baugleich zu sein.
    Interessant ist was da bei GSS bei den technischen Daten steht:

    Quote

    Betriebssystem: Linux

    Dann muss es auch irgendwo den Quellcode dazu geben, das lädt zu Spekulationen ein :D .


    Bislang konnte ich leider nichts zu den verwendeten Komponenten heraus finden.
    Das wäre schon interessant um abzuschätzen, ob es sich lohnt damit zu experimentieren.


    Ist jemandem schon so ein Ding in der freien Wildbahn begegnet?
    Bei einem ausgepackten Gerät könnte man vielleicht was vom Innenleben erkennen.
    Bislang hab ich nur einen Digibit R1 im Karton gesehen, das war nicht wirklich aufschlussreich.

    Gruss
    SHF


  • Die Geräte von Inverto, Telestar und GSS scheinen mir baugleich zu sein.
    Interessant ist was da bei GSS bei den technischen Daten steht:

    Dann muss es auch irgendwo den Quellcode dazu geben, das lädt zu Spekulationen ein :D .

    Laut englischem Wikipedia ist auch die IDL400S 'Linux-based'. Unter Clients suppported steht auch der VLC-Player drin. Kann mans denn dann für den VDR schon umsetzen?

  • Direkt kann man es noch nicht nutzen, da fehlt noch ein entsprechendes Plugin oder ein Treiber der das als DVB-Karte verfügbar macht.
    Da die Spezifikation offen und nicht besonders kompliziert ist, dürfte es aber nur eine Frage der Zeit sein bis da was kommt.
    Ob das dann den Ansprüchen für den VDR-Betrieb (Umschaltzeiten, Stabilität usw.) genügt ist dann die nächste Frage.


    Ich bin derzeit aber eher am überlegen, den VDR als Server direkt auf dem Teil zu installieren.
    Wenn man das Datenblatt von dem Zinswell ansieht, sieht das garnicht so schlecht aus. Zwar ein Bisschen wenig Flash, aber 512Mb RAM, damit könnte man was machen.
    Die Frage ist halt, ob die Tuner auch Intern verfügbar sind, sonst sieht es schecht aus.

    Gruss
    SHF


  • Frage:


    Wäre es mit SAT>IP prinzipiell möglich, das Signal via Internet an z.B ein Ferienhaus mit Internetanschluss weiterzuleiten?


    Da mein Vermieter an der Ferienadresse keine Sat-Antennen duldet, wäre dies doch die Optimale lösung, wenn's dann funktionieren würde?!?!?

  • wohl kaum - außer du hast eine dicke Internetleitung (Upload)


    VDR mit Streamdev und externremux kann dir aber helfen...

    Server: 19" Rack - yaVDR 0.5, 4x DVB-S2
    Server (Reserve): 19" Rack Server - Ubuntu 10.04 + yaVDR Repo (COMPUCASE 4HE, GIGABYTE 770TA-UD3, SNT-BA3151-1 Backplane, Athlon II X2 245e, 4 GB, 2x WD Caviar Green 2TB, 3x TT-budget S2-1600)
    Client "Wohnzimmer": Zotac ZBOX (MLD 4.0.1, Nvidia, Atom)
    Client "Schlafzimmer": Zotac ZBOX (MLD 3.0.3, Nvidia, Atom)
    Client "Kinderzimmer": Asus EeeBox EB1012P-B0550 (yaVDR 0.5, Nvidia, Atom)
    Client "Fitness": Zotac ZBOX (MLD 3.0.3, Nvidia, Atom)
    Client "Küche": Asus EeeBox B202 (Lubuntu+VLC)
    Client "Büro" (Lubuntu)
    Client "Terrasse": NSLU2 (Debian, MPD)

  • Wenn es die bauliche Lage erlaubt, dann ist denn Stuhl auf dem Balkon sicher erlaubt ;) http://www.reichelt.de/?ARTICLE=111920;PROVID=2028;&utm_source=Preisvergleich&utm_medium=CPC&utm_campaign=Preisvergleich_google_feed


    cu

  • Also im Triax TSS 400 SAT>IP Server ist ein STI7108-Prozessor verbaut. So wie es aussieht, kommt das Board von "zintech". Auf dem Board ist die Bezeichnung "ZIM-1800" zu finden.


    Mal sehen, ob man einen SeriellPort oder sonst irgendwas findet :)

  • Ein wenig necrobumping, aber das hier hab ich sonst noch nirgends direkt gefunden. Ausserdem war grad der Artikel in der c't, weshalb einige moeglicherweise wieder sensibilisiert wurden. ;)


    Der Triax TSS400 ist offenbar bauglich zum ZIM-1800. So einen hab ich neulich fuer die neue Haus-Sat-Anlage bestell (den Triax, nicht den ZIM).


    Der Grundig GSS 400 und das Inverto-Geraet scheinen ebenfalls baugleich, benutzen aber nicht unbedingt die gleiche Software. Zumindest haben die Firmware-Updates ein anderes Format (bei diesen Geraeten: id4k.bin, was offenbar ein uImage mit Kernel und dazugelinktem initramfs ist).


    Bei Triax gibt es inzwischen ein Softwareupdate hier: http://www.triax-gmbh.de/?alPage=&rkPage=&articleId={DD19082B-15C5-4586-B5A6-A76D2FB267CB}


    In den img-Dateien ist am Anfang ein 64 byte grosser "ZinImage"-Header.


    Wenn man den abschneidet, faengt im satip_sw.img dahinter in Kernel-uImage an und im satip_data.img ein UBI-Image.


    Unter der Annahme, dass das rootfs ebenfalls als UBI-Image vorliegt, kann man mit


    Code
    1. grep -P -a -b UBI# --only-matching satip_sw.img


    den Anfang herausfinden, bei mir Offset 2022152.


    Das kann man dann extrahieren:


    Code
    1. dd if=satip_sw.img of=sw.ubi bs=1 skip=2022152


    und unter Zuhilfename des nand-Simulators mounten:


    Code
    1. modprobe nandsim first_id_byte=0x20 second_id_byte=0xa2 third_id_byte=0x00 fourth_id_byte=0x15
    2. modprobe ubi
    3. ubiformat /dev/mtd0 -f sw.ubi
    4. ubiattach -m 0 /dev/ubi_ctrl
    5. mkdir ubi
    6. mount -t ubifs ubi0 /mnt/ubi


    Das gleiche kann man mit dem data-Image machen, hier benutzt man als Startoffset fuer dd dann skip=64 um den ZinImage-Header wegzuschneiden.


    Das rootfs ist recht rudimentaer. Hier gibt es eigentlich nur busybox und die beiden proprietaeren binaries "CliConsole" und "zim1800" sowie die Kernel-Module aus dem STAPI-SDK.


    Bemerkenswert ist, dass im Update die root-shell auf port 99 entfallen ist, die Zeile ist in satip.sh auskommentiert.


    Im zim1800-Binary findet sich u.a. folgender String:


    Code
    1. STAPI_SDK-REL_36.0


    Siehe hier: http://www.stlinux.com/stworkb…ction/STAPISDK_linux.html


    Es gibt wohl auch eine serielle Konsole "ttyAS1". Im Update laeuft hier das satip.sh.

  • Linux und Busybox bedeutet im Umkehrschluss, dass der Hersteller auf Anfrage auch Sourcecode rausgeben muss. Hat da schonmal jemand nachgefragt?


    Naja, das ST-SDK kriegt man wohl so, und die ganzen spannenden Sachen (source vom zim1800 usw...) fallen nicht zwangslaeufig unter die GPL.


    Interessant waer z.B. 'nen headless-vdr direkt auf dem Ding laufen zu lassen.


    Die Frage ist, wie man eigenen Krams da dauerhaft installieren kann. Das rootfs auf ubi muesste man recht einfach r/w mounten koennen. Dummerweise ist die root-backdoor beim Update wohl deaktiviert. Evtl. gibt es noch eine zusaetzliche, wenn man einen USB-Stick mit einer Triggerdatei (enable-telnet-console) anschliesst, passiert da irgendwas.


    Im zim1800 binary ist auch eine Sektion, die irgendwie wie eine Hilfe zu einem Command Line Interface aussieht, da gibt es u.a. auch ein Kommando SHELL.


    Andere Ideen, das Backdoor beim Update ohne das dranfrickeln einer seriellen Konsole zu erhalten waeren:


    - nicht updaten. :wand Die Auslieferungsversion kann aber evtl. kein DLNA
    - Nach obiger Beschreibung das Update extrahieren und die Dateien einzeln austauschen (fuer die busybox vermutlich garnicht noetig, aber fuer das zim1800-binary)
    - Binaerpatch fuer das Update und den '#' vor dem Start des telnet-Servers durch ein Space ersetzen. Dabei koennte aber evtl. eine Pruefsumme im ZinImage-Header oder im UBI-Image kaputtgehen. Ein neues UBI-Image zu erstellen waere moeglich, die Tools sind alle offen.


    Wenn meine Hardware da ist, werd ich aber erstmal gucken, wie man an den Bootloader kommt (wird wohl u-boot sein) und wie der Update-Mechanismus funktioniert (ein ubi-image kann ja nicht das laufende rootfs ueberschreiben).

  • Ein wenig necrobumping, aber das hier hab ich sonst noch nirgends direkt gefunden. Ausserdem war grad der Artikel in der c't, weshalb einige moeglicherweise wieder sensibilisiert wurden. ;)


    Hi,
    es gibt sehr wohl einen Thread, der sich mit Sat>IP beschäftigt: Offene Runde SAT>IP
    Ich habe den Artikel auch die Tage gelesen und bin ehrlich gesagt ziemlich angetan von dem Prinzip. Was jetzt eigentlich fehlt ist ein Plugin, mit dem man den Empfänger von einem VDR transparent nutzen kann und zwar inklusive verschiedener Audio IDs, EPG, Teletext usw. Auf der Kiste selber einen VDR laufen zu lassen finde ich nicht so zielführend, da dann wieder nur ein bestimmtes Gerät unterstützt wird und die VDR-VDR Kopplung über Streamdev jetzt auch nicht die tollste Lösung ist. Dann doch lieber so eine Kiste (oder zwei oder drei?!?) auf den Dachboden neben den Multiswitch und einen nativen Client auf eine Raspberry Pi o.ä. am Fernseher. Zum Aufnehmen dann noch einen headless VDR auf die NAS, so dass die Daten auch gleich an der richtigen Stelle landen.


    Gruß Darkstar.

    Hardware: Seagate Dockstar@1500MHz, GSS Box DSI 400 SAT>IP Server, VDR 2.1.6 mit Streamdev-Server
    Videoausgabe: RaspberryPi mit MLD-4.0.1-RPi an LG 42LM660

  • Linux und Busybox bedeutet im Umkehrschluss, dass der Hersteller auf Anfrage auch Sourcecode rausgeben muss. Hat da schonmal jemand nachgefragt?


    Meines Wissens muss er nur den Teil des Sourcecodes herausgeben, der unter GNU o.ä. steht. Wenn er das System erweitert mit eigenem Code, dann darf er diesen unter Verschluss halten.


  • Meines Wissens muss er nur den Teil des Sourcecodes herausgeben, der unter GNU o.ä. steht. Wenn er das System erweitert mit eigenem Code, dann darf er diesen unter Verschluss halten.


    Stimmt teilweise. Vielleicht verstehe ich dich aber auch nur falsch. Wenn ein Programm, welches unter GPL steht, nämlich erweitert, bzw. verändert wird, dann muss der komplette Sourcecode inklusive Veränderungen wieder veröffentlicht werden.

  • Stimmt teilweise. Vielleicht verstehe ich dich aber auch nur falsch. Wenn ein Programm, welches unter GPL steht, nämlich erweitert, bzw. verändert wird, dann muss der komplette Sourcecode inklusive Veränderungen wieder veröffentlicht werden.

    Wie ich oben schon schrieb, die interessanten Teile (sprich: das zim1800 binary, was das ganze DVB-Zeug abhandelt, und CliConsole) fallen mit hoher Wahrscheinlichkeit nicht unter die GPL, und den Rest kann man sich vermutlich sehr einfach mit einer der gaengigen Embedded-Linux-Distributionen nachbauen.


    Nicht-GPL Kernelmodule, die nur binaer vorliegen "tainten" den Kernel zwar, fallen aber selbst ebenfalls nicht unter die GPL. Man erweitert dabei ja nicht den Kernel, sondern interagiert nur mit dem Kernel (auch wenn das hinzufuegen eines Moduls eine Erweiterung darstellt).


    tl;dr: Ja, hier liegt vermutlich eine GPL-Violation vor. Nein, es wuerd beim Basteln mit dieser Box nicht grossartig helfen, wenn die Hersteller die Quellen rausruecken wuerde, die er rausruecken muss.