Warum gibt es keine TwinSAT-Durchgangsdosen?

Anzeige

Da irrst du dich. Der Elektor DiSEqC-Monitor speichert eine Folge von DiSEqC-Kommandos und die kann man sich dann als hexadezimale Folge dekodiert am LCD-Display anzeigen lassen. Die notwendigen Sachen zum einfachen Nachbau findet man heute noch bei Elektor zum Downloaden, insbesondere auch die Firmware des verwendeteten PIC-Microcontrollers. Wer das Elektor-Heft zu dem Projekt nicht hat, findet es zumindest bei archive.org als englischsprachige PDF-Datei.

 

Wie schon geschrieben, Zeitverzögerungen und Blödsinn vor und nach der eigentlichen Einkabelnachricht wird der auch nicht anzeigen. Daher wäre die Analyse per Soundkarte wirklich am zielführendsten. Und die paar Bursts bekommt man wirklich leicht als Einsen und Nullen interpretiert.

 

Höchstwahrscheinlich nicht, aber man könnte ja die Microcontroller-Firmware so anpassen, dass alles Mögliche analysiert und angezeigt werden kann, bis hin zur zeitlichen Abfolge der Signalpegel. Geht natürlich nicht mit dem alten PIC des Elektor DiSEqC-Monitors, aber mit solch modernen Microcontrollern wie dem RP2040. Die Hardware ist ja ziemlich simple und wenn es Bedarf geben würde, würde sich auch ein Programmierer für einen „universellen DiSEqC-Monitor und -Generator“ finden.

 

Wow, vielen Dank für die Info.
Als langjähriger Abonent (habe alle Ausgaben von Anfang an muss ich da doch mal in den Keller gehen und schauen, ob sich die Ausgabe findet.
Hab erst gekündigt, als sie völlig abgedreht sind und sich der Abopreis quasi verdoppelt hat. Da hat man mir noch ein paar Jahre auf meinen Protest hin einen Sonderpreis gemacht aber irgendwann war ich es Leid, jedes Jahr neu betteln zu müssen. Schade, hab das damals sehr bedauert und im Prinzip war das dann schon das Ende meiner Elektronikbastelzeit. Ich hatte es aber mehr mit den Atmels als den PICs.
... wehmütig zurückblick ....

Ja, so ein genereller Analysator + Generator wäre schon cool ... könnte ich meine Jultec JAP314TRS selber programmieren

 

Ja die Elektor, ich habe sie noch, da als Fachlektüre steuerlich absetzbar, so ist der effektive Preis erträglich. Aber ganz ehrlich finde ich da auch kaum noch etwas, wo ich etwas lernen könnte. Und nachgebaut habe ich da seit bestimmt 25 Jahren nichts mehr.

-> E2 7F FA xx xx xx xx (wobei xx xx xx xx das Bitmuster der freizugebenden Userbänder ist) -> Antwort E4 wenn erfolgreich
-> E2 7F 1A -> Antwort E4 xx xx xx xx (xx xx xx xx ist das Bitmuster der freigegebenen Userbänder)

 

Als Student habe ich mal einen Doktoranden im Messlabor geärgert, der unheimlich viele teure Messgeräte um sich herum aufgebaut hat:

"Der Intelligenzquotient des Messenden ist umgekehrt proportional zum Wert seines Messgeräteparks" ....

Hat er mir krumm genommen

 

Jeder Techniker versucht auch wirtschaftlich zu handeln, ohne dass er wie die BWLer da gleich einen riesigen Aufriss oder gar einen eigenen Fachbereich draus macht. Ich selbst habe schon mit Messgeräten hantiert, deren Wert man in Einfamilienhäusern gegenrechnen konnte (habe mal in einem Kalibrierlabor gearbeitet; einige unserer Standards wurden direkt von der PTB kalibriert). Und nahezu täglich sitze ich vor einen Networkanalyzer, für den man mehrere "normale" Autos hätte kaufen können. Aber wie geschrieben analysiere ich DiSEqC-Nachrichten gerne per Spannungsteiler und Audacity, weil es einfach die viel passendere Lösung ist, um z.B. auch Glitches vor und nach der Nachricht zu sehen, ob die Bursts sauber generiert wurden und was da sonst noch so los ist. Wenn man so eine Analyse macht, dann will man ja eigentlich auch gar nicht wissen, was da an Daten übertragen wird, sondern warum die Übertragung nicht funktioniert.

 

Gibt es Vorteile gegenüber der Verwendung eines Low-Budget (sagen wir < 1000,- €) Speicher-Oszis? Archivierung der Ergebnisse auf dem PC hätte man auf direkterem Weg.

 

Ein Speicherscope habe ich bei mir auch stehen, aber bei den meisten Geräten ist die Speichertiefe einfach nicht ausreichend, um einerseits die einzelnen 22 kHz-Schwingungen, andererseits aber die gesamte DiSEqC-Nachricht inklusive Spannungssprung davor und einer eventuellen Antwort aufzuzeichnen. Und wenn es um eine ganze Abfolge von Sequenzen geht (z.B. per JESS "UBs ermitteln"), dann reicht die Speichertiefe erst recht nicht.
Unschlagbar ist es auch, wenn man nur gelegentliche Fehler hat und tatsächlich mal ein oder zwei Stunden "mitschneidet", und dann noch immer auf die einzelne 22 kHz-Schwingung hineinzoomen kann. So habe ich mal einen Fehler in einem Gerät gefunden, bei dem ganz gelegentlich mal der 22 kHz-Ton "gehakt" hat (als wenn man einfach zwischendrin kurz "Pause" gedrückt hat). Bei so einer Analyse geht es eben darum, herauszufinden, warum es eben nicht klappt, damit man seinen Teil verbessern und fehlertoleranter machen kann.
Ein einfacher DiSEqC-Analyzer hätte bei diesem Problem den Befehl entweder verworfen und gar nicht ausgegeben oder er hätte ihn dekodiert, der DiSEqC-Switch aber ggf. nicht.
Der Audio-Eingang ist auch für I²C-Befehle nützlich. Zwar kann I²C je nach Ausführung einige Hundert kHz, aber es ist nicht verboten, den quasi beinahe statisch z.B. mit nur 10 kHz zu betreiben. So kann man SDA und SCL als Audio links/rechts aufzeichnen uns kann so auch sporadisch auftretende I²C-Fehler finden. In einem Fall habe ich so einen Fehler in einem Chip gefunden, der sich aber wiederum nur in einer Microchip-I²C-UART ausgewirkt hat.