Frage an die Gemeinde und probutus: Macht es Sinn evtl. mal ein Posting bei minisatip drüben abzusetzen; evtl. lassen sich die berühmten "Synergien" heben?!
Sehr gerne 
Falls Ihr da connections habt könnt Ihr die Kollegen ja mal anfragen. Ich als Noob mit 40 posts finde da wohl eher weniger Gehör. Ich unterstütze auch gerne bei der Installation/Konfiguration
Nochmal kurze Info: Falls Ihr das custom Image über die legacy Firmware flasht wartet bitte wirklich 5 Minuten (NACHDEM ihr Reboot geklickt habt). Der Timer den die Originalfirmware beim Flashen bis zum refresh runterzählt ist viel zu kurz und hat keinerlei Verbindung zum Flashprozess. Es dauert wirklich 5 minuten.
Ausserdem achtet darauf dass Ihr die Seite als http://octonet-pro/ (kein https!) angebt. Mein Browser hat die unangenehme Eigenschaft immer auf https zu springen und sich dann zu beschweren, dass da keine Webseite ist...
Der original-digitaldevices Sat-IP Server ist vorhanden. Er unterstützt SatIP-Version 1.2.0 (das ist soweit ich weiss dieselbe Version die auch Minisatip unterstützt). Ich kann auch ein fertiges Image bereitstellen, wo minisatip installiert aber inaktiv ist. Dann kann man per ssh den Original-Satip-Server abschiessen und mit minisatip spielen.
EDIT:
Der FPGA ist closed source aber alle relevanten Informationen sind im Source vorhanden. Das Tool "octoscan" was zur Sendersuche verwendet wird zeigt, wie man einen Sat-Stream auf den Arm-Kern zur Analyse "umbiegen" kann. Das zur Verfügung gestellte "octoserve", der SatIP-Server von DD zeigt wie man den FPGA anspricht um die Tuner-Steuerung zu machen. Das sind zwei relativ kompakte Programme. Es gibt sogar eine Registerbeschreibung des FPGAs (die wurde in neueren dddvb-Versionen durch Hexwerte ersetzt, aber alte Versionen haben noch eine Registermap, da sind dann die meisten Register (steuerung, CA-Modulsteuerung usw... definiert)
EDIT2: Wenn man die Sourcen selbst baut kann man auch einfach minisatip als externe Option in buildroot anwählen. Ich habe das mal eingebaut 
Das ist auf jeden Fall genial was du da hinbekommen hast. Bekommt man so die volle Funktionalität?
Alles was die Original-Firmware kann, kann auch die neue Firmware plus ssh Zugang zum Einbinden von Erweiterungen und ein Standard-Buildroot-System was auf aktuellen Distributionen läuft. Das Webinterface sieht allerdings sehr "retro" aus. Das ist aber eine Kleinigkeit die man einfach beheben kann wenn man ein Händchen für Webdesign hat. (ich kann das nicht, ich habe einmal eine Webseite designed und wurde gebeten soetwas nie wieder zu machen)...
das vereinfacht den Updateprozess natürlich. Ich schau mir heute Abend die Menüs nochmal genau an. Ich finde die Weboberfläche etwas unübersichtlich
probutus Deine Firmware lässt sich nicht direkt mit der 2.x.y einspielen?
The content cannot be displayed because you do not have authorisation to view this content.
Das Menü in der 2.2.0 kannte ich noch garnicht :).
Bis jetzt habe ich das Update immer über den Umweg -> Legacy-Firmware flashen -> auf box via Telnet /config/updateserver erzeugen mit IP-Adresse -> Update -> nach 5min alles fertig
Wenn Du direkt mit der 2.2.0 flashen willst, musst Du der Firmware ein aktuelles Datum geben (die Zahl der *img- und *sha Datei muss neuer sein als das Firmwaredatum der 2.2.0 Firmware, bitte auch den Dateinamen in octoupdateserver.py anpassen). Ich empfehle fürs erste den Umweg über die Legacy-Firmware, den habe ich mehrfach getestet und ich kam auch problemlos wieder auf die 2.2.0 zurück.
Die Version Sat-IP 1.2.0 bezieht sich auf die Version der Sat-IP Spezifikation die implementiert ist nicht die Version der Software.
Hallo Angus, vielen Dank! SatIP 1.2.0 ist der originale von Digital-Devices freigegebene SatIP-Server.
Das Release basiert auf Kernel 6.12.81 (SLTS Kernel, support bis 2035) und buildroot-ng 2025.02 mit GCC 14.3 also aktuell genug um das neueste minisatip zu bauen und zu integrieren.
Minisatip muss für die Octonet aber dahingehend angepasst werden daß die Sat-IP Daten nicht vom ARM sondern direkt vom FPGA kommen. Die komplette Verteilung des Datenstroms läuft auf der octonet in Hardware. Der Sat-IP Server ist nur das Steuerungsfrontend.
Ich habe jetzt die erste offizielle Version mit Kernel 6.12.91 fertig und auch Images zum Flashen erzeugt. Es gibt einen neuen Ordner "hostoctoupdateserver" der ein Python-Skript beinhaltet was es erlaubt das Image zu flashen.
Anleitung:
1) In der offiziellen Octonet-Firmware "downgrade to legacy image" anwählen. Das läd eine alte Version 1.1.8 auf die box wo man telnet aktivieren kann (ohne Passwort)
2) Nach dem downgrade im Menü telnet aktivieren und einloggen (user: root, password: keins)
3) Die Datei "/config/updateserver" erzeugen mit "echo <IP-Adresse> > /config/updateserver"
4) Auf einem Rechner der Port 80 frei hat als root (wegen Port 80) "python3 octoupdateserver.py" starten
5) In der Box auf "check for Updates" klicken. Es wird ein Update mit Datum 31.05.2021 angeboten. Keine Angst, das Image ist aktuell. Ich habe ein altes Datum ausgewählt daß man wieder einfach auf die aktuelle 2.2.0 zurückflashen kann (Die Updates werden bei der Octonet nicht über Version sondern über Datum geprüft)
6) Den Updateprozess abwarten. Nach ca. 5 Minuten ist das System wieder online
Features:
* Sat-IP Server 1.2.0
* Kernel 6.12.91 (SLTS-Kernel mit Support bis 2035)
* Buildroot 2025.02
* dddvb Version 0.9.41
* root Zugang über ssh (telnet ist in dem Image aus Sicherheitsgründen deaktiviert. Das Passwort ist "octonet"
* man kann relativ einfach zusätzliche Pakete in buildroot einbinden und eigene Erweiterungen schreiben
Soweit ich das mit meiner kleinen Octonet verstanden bzw. gesehen habe kann man jeweils nur eine Empfangsart für alle Tuner gleichzeitig festlegen; ein "Mischbetrieb" ist glaube ich nicht vorgesehen.
Ja, das Treiber-Bauen bei TBS sieht fummelig aus - insbesondere für Leute wie mich mit nur rudimentären Wissen.
Unter https://www.tbsdtv.com/download/index.html?path=0_6 im Abschnitt DVB-Software und unter der Beschriftung "Linux Driver Beta" gibt es zumindest bis Kernel 6.18 ein fertiges Installationspaket der Treiber vom Hersteller.
Unter https://github.com/home-debug/TBSonly hat scheinbar ein Benutzer mittels KI Scripte entwickelt, die wohl das Bauen der Treiber bis Kernel 7.0 erledigen.Die Frage für mich ist: Sind die TBS-Karten bzw. Treiber bzw. internen Abläufe "offener" als die Produkte von Digital Devices?
Naja, die Treiber für die Octonet-Karten sind komplett im Source verfügbar. Das einzige proprietäre Element ist die FPGA-Firmware, d.h. falls DD den Support für die Karten irgendwann aufgeben würde könnte man selbst den Treiber weiterentwickeln. Bei den TBS-Karten wird jedesmal ein Binärimage auf die Karten geladen was auch nicht im Source beiliegt. Die Treiber selbst sind auch komplett open source, von daher nimmt sich beides nicht viel. Die Sourcen von DD sind aber mE aktueller und weniger fummelig (soweit ich das bis jetzt beurteilen kann)
8-Tuner-Karten gibt es auch noch von TBS: https://tbs-technology.de/shop/TV-Tuner-…uner-Octa-Tuner
(Ich weiß allerdings nicht, ob die Unicable [II] können...)
Danke für den Tipp!! Ich habe mal nachgesehen, Auch diese Karte verwendet angepasste Linux-Treiber (genauso wie die octonet), d.h. immer wenn es neue Kernel gibt ist man darauf angewiesen dass jemand diese Treiber auf neue Kernel portiert. Bei der Octonet ist es genauso allerdings ist hier DigitalDevices mit dem dddvb-Paket aktueller und auch der Code im dddvb-Zweig sieht deutlich aufgeräumter aus.
Bei meiner Recherche bin ich auch auf neue DigitalDevices Karten mit 8 Tunern gestossen die zeitgleich auch DVB-C und DVB-T unterstützten. Das wäre natürlich eine Super-Lösung wenn wegen Schlechtwetter die Sat-Anlage wieder spinnt (ich habe eine 1,2m Schüssel auf dem Dach hatte aber schon bei Schneesturm trotzdem keinen Empfang). Allerdings frage ich mich wie man die neue Karte in die Octonet reinbekommt. In der aktuellen Firmware 2.2.0 sehe ich keine Option Kabel und Satellit gleichzeitig auszuwählen. Das Hardware Interface ist auf der neuen Karte ja vorhanden (GTL)
Ich finde den Test mit dem Raspberry Pi 5 schon nicht unspannend. Aber ich würde als Basis dann natürlich nicht die Octopus kaufen sondern eine PIC-E-Karte mit ausreichend Tunern.
Und dann wahrscheinlich gar kein Minisatip drauf sondern direkt den VDR. Vorteil davon wäre ganz klar, dass man den Sat-IP-Part dazwischen komplett eliminieren würde. Schlankere Lösung, weniger Potential für Probleme.
Richtig! Hast Du eine Empfehlung für eine 8-Tuner-Karte die Unicable II unterstützt?
Da hier die O-Net absolut stabil läuft, stellt sich mir die einzige Frage:
Welche Vorteile habe ich durch den Wechsel zur Custom-Fw?
Ist absolut nicht böse gemeint, aber ich verstehe den Hintergrund von Beginn an nicht recht - ausser es geht rein weg um die "Grauzone"...
Die Software läuft stabil, richtig. Der Software-Stand zumindest auf dem ARM-Kern ist aber gelinde gesagt etwas veraltet (2016!) und der Original-Software-Stand der veröffentlicht wurde konnte ohne grössere manuelle Aufwände nicht nachgebaut werden. Mich hat es gereizt, das System so aufzusetzen daß man einfach aktuelle Software bauen kann ohne irgendwelche Klimmzüge unternehmen zu müssen und jedem die Möglichkeit zu geben, das System so anzupassen wie er möchte (z.B. Funktionen für Homeassistant, Remote Steuerung etc...). Die Box hat sehr viel Potenzial und das Konzept ist genial. Leider sind die Einflussmöglichkeiten ohne die Möglichkeit, den FPGA Code zu erweitern eher begrenzt. Falls sich DigitalDevices irgendwann entschliessen sollte den FPGA-Code zu veröffentlichen sehe ich noch einiges an Features, die man hinzufügen könnte)
Ist am Ende ein recht teuerer Spaß einen Octopus Net zu kaufen und nur die MaxS8 daraus zu verwenden. Bei mir ging es den anderen Weg, habe aus meiner MaxS8 dann einen Octopus Net gemacht, der seit nun mehr 13 hier läuft ...
Stimmt Ich war nur neugierig ob ich mit der octonet-Karte auch direkt an meinen Raspi mit TV-Headend gehen kann. Die Umschaltzeiten der Sender im Vergleich TV-H/Octonet sind schon spürbar. Dank des FPGA ist das System superschnell und sehr stabil. Allerdings hat man dadurch auch auf dem ARM nur ziemlich begrenzte Einflussmöglichkeiten auf den DVB-Strem
Etwas OT: Ich habe mal in meiner Bastelkiste gewühlt und einfach zum Ausprobieren einen Raspi5 an den PCI-E-Anschluss der octonet-sx8 PCI-E Karte angeschlossen. Minisatip, tvheadend laufen out-of-the-box... Der PCI-E-Bus hat genug Reserven 8 Streams zu übertragen und alles passt in das originale 1 HE Gehäuse. Ich suche noch ein kompaktes 5V-6A/12V-2A Netzteil, falls jemand einen Tipp hat...
rjkm : ich bin gerade dabei das u-boot auf 2025.02 zu heben. Weisst Du ob der JTAG angschluss (GND, TDI, TDO etc...) auch mit dem ARM verbunden ist und ich damit z.B. via OpenOCD debuggen kann oder ist der JTAG-Anschluss nur für den FPGA?
Addendum: Die Verbindung zwischen FPGA und der Tunerkarte ist PCI-E oder was proprietäres?
Hi Joe_D Vielen Dank für die Erklärung. Das könnte der gesuchte "Umweg" sein um ein standardkonformes Interface auf dem ARM zur Verfügung stellen. Ich lese mich mal ein!
Hallo SurfaceCleanerZ die komplette Datenkommunikation der DVB-S Karte läuft über den eingebauten FPGA und der ARM-Kern ist lediglich mit einem 16bit Parallel-Interface an diesen angeschlossen. Aktuell muss ich über das Parallel-Interface die Tuner konfigurieren um dann über Ethernet den Datenstrom vom FPGA abzufangen um die Kanalsuche zu machen. Die Architektur hat den Vorteil daß der FPGA (da alles in HW gegossen) zwar fast Latenzfrei arbeitet aber die Zugriffsmöglichkeiten vom ARM und damit von Systemen wo man Dritt-Applikationen laufen lassen kann, sehr eingeschränkt ist.
Bei dem Vtuner Projekt ist hingegen die CI- und Tunerkarte direkt via PCI-E angeschlossen und die Daten laufen auch direkt über den ARM-Kern
Aktuell suche ich nach einer Möglichkeit, die Datenströme der laufenden Tuner vom ARM-Kern aus anzuzapfen
Der erste Stand ohne neue Features aber auf aktueller buildroot und mit aktuellem LTS-Kernel ist fertig
- octoserve kann alle 8 Tuner fehlerfrei verwenden
- octoscan funktioniert in der aktuellen Umgebung (epg-Scan und Kanalscan läuft)
- Images werden gebaut
- Ich habe ein kleines python-Skript erzeugt was als updateserver funktioniert
Die Basis für Erweiterungen ist gelegt. Ich beschäftige mich jetzt mit den Interna um zu sehen wie man alternative apps (zB minisatip) in das System einbinden kann. Ich habe bei der Analyse von octoscan gesehen, wie ich Daten vom FPGA auf die Host-CPU umleiten kann. Das ist ziemlich umständlich und ich frage mich ob man das nicht irgendwie auch über die Knoten in /dev/dvb/adapter0 realisieren könnte
Ich schaue mir gerade octoscan an nachdem das streamen und tunen jetzt läuft. das originale octoscan das im source vorliegt findet keine Sender. Wenn ich von aussen streame funktionieren die acht tuner fehlerfrei. Ich vermute das liegt daran, daß der neue Kernel 6.2 feststellt daß die IP-Adresse an ein lokales Interface gebunden ist und versucht den Paketdatenstrom der ja vom FPGA kommt intern umzuleiten (martian packet filter). Ich frage mich ob man das scannen nicht direkt mit dem netstream-Device machen kann
EDIT: Problem found: Der neue Kernel filtert die Pakete vom FPGA raus wenn die IP-Adresse vom selben host kommt:
Das kann man mit einem Eintrag in sysctl.conf unterbinden:
# cat /etc/sysctl.conf
net.ipv4.conf.all.accept_local=1
net.ipv4.conf.eth0.accept_local=1
net.ipv4.conf.all.rp_filter=0
net.ipv4.conf.eth0.rp_filter=0
Dazu muss noch ein kleines Problem mit dem UDP-Port Assignment gelöst werden dass immer gerade ports allokiert werden (siehe SATIP standard)
Ich habe den patch hochgeladen
