Genelec GLM Netzwerk verstehen

Player, Streamer, Wandler, Vorverstärker usw.
Antworten
LegoTechniker
Aktiver Hörer
Beiträge: 7
Registriert: 27.12.2020, 15:59

Genelec GLM Netzwerk verstehen

Beitrag von LegoTechniker »

Hallo,

hier ein kleines Projekt, das evtl für den ein oder anderen Genelec Besitzer interessant sein kann.
Ich möchte zumindest die gröbsten Funktionen des GLM Interfaces/Protokolls dokumentieren. Genelec selbst gibt leider, auch auf Anfrage, keine Daten zum Protokoll preis.
Für die, die sich fragen wozu das gut sein soll:
Über das GLM Interface erfolgt nicht nur die Kalibrierung der SAM Lautsprecher von Genelec. Man kann auch die Verstärkung anpassen, sie Ein- und Ausschalten, die LEDs abschalten etc. Bei einigen Funktionen reicht es sie einmal vom PC aus eingestellt zu haben. Andere hätte man doch gerne einfacher im Zugriff. Die Verstärkung kann man noch über ein Poti oder eine Properitäre Funkfernbedienung einstellen, das war es dann aber auch.
Wenn man das GLM Protokoll einmal dokumentiert hat kann man sich mit Teilen für ein paar € eine beliebige Schnittstelle bauen und man könnte die wichtigsten Funktionen über eine IR-Fernbedienung, WLAN oder Bluetooth bedienen.

Also fangen wir an. Zuerst müssen wir wissen wie das Protokoll auf Hardwareebene ausschaut. Das GLM USB Interface ist schnell zerlegt und die entscheidenden Teile lokalisiert:
- Der Bustreiber ist ein ADM483. Ein RS-485/RS-422 Transceiver.
- Dann haben wir ein Terminierungsnetzwerk VCC - 360 Ohm - A - 110 Ohm - B - 360 Ohm - GND und ein paar Kondensatoren, da muss ich bei Gelegenheit mit einem LCR-Meter die Werte ermitteln.
- Das geht auf eine RJ-45 Buchse. Pin 1 - A, Pin 2 - B, Pin 3 - 7 unbelegt, Pin 8 - GND. Die Lautsprecher sind dann alle einfach durchverbunden.

Ein Oszilloskop verrät uns dann noch die Baudrate von etwa 288 kBaud und die Kodierung mit 9 ! Bit, keine Parity und drei Stopbit.
Bit 9 wird nur beim ersten Byte eines Frame gesetzt und ist sonst Null. Eine start of Frame Erkennung oder Markierung des Address Byte?
Zusätzlich kann man hier schon erkennen das ein Frame mit 0x7E abgeschlossen wird (und nicht gesetztem Bit 9).
Eine etwas ungewöhnliche Baudrate und Kodierung.

Damit wäre schon etwas mehr als nur die Hardwareebene abgehakt, los geht es mit dem Protokoll:
Mit einem "fast" beliebigen RS-485/RS-422 Transceiver und einem ESP32 kann man die wichtigsten Teile mitschneiden. Bit 9 kann man zumindest mit der Arduino lib nicht analysieren und 3 Stopbits lassen sich auch nicht einstellen, aber zum abhören reichts. Für einen µC der das mal senden soll wird das schon interessant für die Auswahl.

Und hier jetzt die Frage: Ist das auch für andere Interessant? Möchte jemand mithelfen? Gibt es Wünsche was die spätere Schnittstelle können soll?

Die Aufarbeitung der Mitschnitte würde mich etwas Zeit kosten. Wenn sich jedoch noch jemand an der dekodierung beteiligen möchte kann ich das gerne machen oder bei der Erstellung eines eigenen "Analyzers" helfen.

Was ich bis jetzt herausgefunden habe / vermute:

Aufbau:
- Byte 1: Die Adresse. Nur hier ist Bit 9 gesetzt.
01: Das GLM USB Interface bzw Adresse des Master.
02 ... : Die Adressen der Lautsprecher nach Adressvergabe.
F0: Adresse eines noch nicht adressierten Lautsprechers.
FF: Broadcast.
- Byte 2: Kommando.
1F: Volume
- Byte 3...: Nutzdaten
- Checksum: 1 oder 2 Byte, format ????
- Last Byte: 7E

Besonderheiten:
- Broadcasts werden zwei mal gesendet.

Volume im Detail:
0 dB: FF 1F 7F FF FF 83 2F 7E
-4,5 dB: FF 1F 4C 3E A7 E1 42 7E
-20 dB: FF 1F 0C CC CC 54 81 7E
Die Nutzdaten scheinen 24 oder 32 Bit mit Vorzeichen zu sein, MSB first.
Der Wert für Volume wird nicht in dB sondern linear übertragen.
Es scheint eine 8 oder 16 Bit Checksum oder CRC zu geben.

WakeUp:
FF 3A 3 7F 6C 13 7E
FF 3A 3 1 F3 4A 7E

Shutdown:
FF 3A 3 2 C3 29 7E
FF 3A 3 0 E3 6B 7E

Warum jeweils zwei Kommandos?

Soweit für heute.
LegoTechniker
Aktiver Hörer
Beiträge: 7
Registriert: 27.12.2020, 15:59

Beitrag von LegoTechniker »

Mit reeng konnte ich jetzt auch die verwendete CRC Version rausfinden: CRC-16/GSM
Polynom: 0x1021
initial Value: 0x0000
Final XOR: 0xffff
Es geht die gesammte Nachricht, bis auf die Checksum selber und den Terminator 0x7E in die Berechnung ein. Das zusätzliche Bit 9 wird natürlich auch ignoriert.
Somit wird die Lautstärke als signed 24 Bit übertragen.
Die Lautsprecher Version etc wird in ASCII übertragen.
Bild
Chon
Aktiver Hörer
Beiträge: 18
Registriert: 19.08.2020, 07:38
Wohnort: Detmold, Schalksmühle, Norddeutschland

Beitrag von Chon »

Hallo,

gibt es zu deinen hochinteressanten Analysen schon wieder etwas neues ?
Ich finde die "Fernbedienung des Interface traurig bis unverschämt und würde sehr gerne auf etwas anderes umswitchen...

Dein Thema ist zumindest für mich SEHR interessant !

Grüße Christian.
Bild
LegoTechniker
Aktiver Hörer
Beiträge: 7
Registriert: 27.12.2020, 15:59

Beitrag von LegoTechniker »

Mein nächster schritt ist es eine einfachste Version des Protokolls auf einem ESP32 zu programmieren und dann zu testen, dafür sind aber ein paar Tricks nötig und bis jetzt hatte ich keine Zeit dafür.
Bild
Antworten