Beiträge von LED_TP_

Danke für die Antwort, Pesi! Ich kann nun den tpm2-Frame als korrekt vorausezten.

Nach einem weiteren Sonntag vormittag habe ich das serielle tpm2-Protokoll verworfen. Anscheinend liegt es tatsächlich an der Software die den virtuellen COM-Port emuliert. Hatte keine Lust mehr mich mit dem seriellen Port auseinander zu sezten. Ich bin jetzt auf das tpm2.net Protokoll umgestiegen, was sich mit VB.NET auch recht leicht realisieren lässt.

Ich nutze also jetzt UDP zum versenden meines tpm.net Blocks und Jinx! kommuniziert jetzt wunderbar mit meiner Applikation!!!
Bin als jezt heilfroh und es kann weitergehen.

Im folgenden will ich das vorhegen für die Allgemeinheit erklären:
Ich sende Daten für alle 7 Remote Kanäle von Jinx! (Jinx 2.4). Die im folgendem präsentierten Bytes im Hex-Darstellung werden dabei in einem Byte-Array über UDP versendet. Zum allgemeinen vorgehen beim versenden von Daten über UDP gibt es reichlich Tutorials im Netz. Daher will ich es hier neutral und unabhängig von einer Programmiersprache darstellen:

/ Protokoll-Header
        BlockStartByte    = 0x9C    /Blockstart-Byte nach tpm2-Spezifikation (seriell)
        TypeByte          = 0xDA    /Es sollen Daten gesendet werden 
        FrameSizeHighByte = 0       /Highbyte zur Definition der Gesamtframegröße
        FrameSizeLowByte  = 7       /Lowbyte zur Definition der Gesamtframegröße. 7 Bytes werden versendet um die 7 Remote Control Kanäle von Jinx zu steuern.
        Packetnummer      = 1       /Angabe der Packetnummer nach tpm2.net-Spezifikation. 
        Packetanzahl      = 1       /Angabe der Packetanzahl nach tpm2.net-Spezifikation. =1 Für einfache Kontrolle von Jinx.


/Jetzt kommen 7 Datenbytes zur eigentlichen Stueerung von Jinx! 2.4. Die gültigen Werte können Jinx! User Manuel entnommen werden
        SceneLeft         = 1       /die erste Szene soll auf der linken Seite dargestellt werden
        SceneRight        = 0       /Szene rechts. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
        Chase             = 0       /Chase. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
        CrossfadeMode     = 1       /Crossfade Mode. Laut User Manuel: Werte zwichen 0 und 20 entsprechen dem Progressive Mode
        CrossValue        = 0       /Crossfade einstellen. Wert 0 steht für "ganz links"
        Strobo            = 0       /Master Stobo: Wert 0 steht für "off"
        MasterBright      = 0xFF    /Master Brigthness, Entspricht dem maximalen Wert.


        BlockEndByte      = 0x36    /Blockende-Byte

So. das wars erstmal für heute. Das Gesprojekt wird folgt, wenn es einen soliden Stand erreicht hat.

Danke für den Tipp, Pesi! Mir ist es gestern Abend wie Schuppen von den Augen gefalllen: Jetzt habe ichs geschnallt: Die Frame-Größe wird über den 16 Bit Wert angebenen (so wie es auch in deinem tpm2-Thread bechrieben wird!) Also vollkommen Falsch von mir. Habe es gestern Abend noch direkt implementiert

Stimmt laut User Manuel 2.4 steht dort wörtlich: Jinx! will receive every tpm2 frame with a minimum of 4 and maximum of 512 channels
and will use the given start channel for the first control.

Darauf hin habe ich direkt versucht alle Jinx Control Känäle (Insgesamt 7) jeweils über ein Byte anzusteuern (Zahlenwerte gemäß Jinx User Manuel 2.4) und hatte jetzt nach Tagen des Versuchens sogar einen kleinen Teilerfolg: Jinx empfängt Bytes und stürzt sofort ab.

Ich habe diverse Varianten bezüglich des versendens über die Visual Basic Write-Methode ausprobiert: Das einzige was anscheinend wirklich gut funktioniert ist, dass senden über meine Visual Basic Applikation und das Empfangen der Bytes von Jinx. Ich kann dies über eine unabhängige Monitoring Software sehen.

Ich möchte nochmals die Bytes hier aufführen die ich versendet habe. Evtl. liegt es ja ein einem kleinen Syntax- oder Denkfehler den ich beim ansprechen von Jinx! Remote Control übersehen habe. Ich versende die Bytes gleichzeitig in einem Byte-Array:

0xC9 / Blockstart-Byte nach tpm2-Spezifikation (seriell)
0xDA / Ich will ein Datenbyte senden. Richtig für einfache Jinx! Szenenauswahl? Oder muss ich über das Kommando-Byte gehen (also 0xC0)
0x00 / Highbyte zur Definition der Gesamtframegröße
0x07 / Lowbyte zur Definition der Gesamtframegröße. Ich will 7 Bytes versenden um die sieben Remote Control Kanäle von Jinx zu steuern.

0x05 / die fünfte Szene soll auf der linken Seite dargestellt werden
0c00 /Szene rechts. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
0x00 /Chase. Keine ansteuerung gewollt. Laut User Manuel mit Wert 0 realisierbar, da dieser ignoriert wird
0x01 /Crossfade Mode. Laut User Manuel: Werte zwichen 0 und 20 entsprechen dem Progressive Mode
0x00 /Crossfade einstellen. Wert 0 steht für "ganz links"
0x00 /Master Stobo: Wert 0 steht für "off"
0x78 /Master Brigthness, Entspricht ca. dem Dezimalwert 120. wollte ich auf ca. der hälfte haben.

0x36 / BlockEnde-Byte nach tpm2-Spezifikaiton

Evtl. kann mir beim Problem jemand helfen.Ich sitze beteits schon mehrere Abende an diesem Probelm dran und kann mir nicht vorstellen, dass es so schwer ist ein paar Bytes an Jinx zu senden.

Wenn ich mit meiner kleinen VS.NET-Applikation fertig bin, werde ich den Code in allgemeiner Form hier zu verfügung stellen, damit jeder was davon hat. Gerne auch im 1:1 Original Visual Basic Code mit Bildern meines LED-Projekts.

Gruß,

TP

Auf den SMD Bauteilen ist immer der sogenannte SMD-Code aufgedruckt. Es gibt dafür recht viele Suchmaschinen. Das Foto sieht nach dem SMD Gehäuse SOD323 aus, was recht häufig für Dioden infrage kommt. Der Code auf dem Bauteil wird unter anderem laut Datenblatt des Herstellers Rohm (http://www.rohm.de/web/de/products/-/product/KDZ30B verwendet) für eine Z-Diode verwendet.

Falls es sich wirklich um eine Z-DIode handelt kann man diese einfach mit einem Multimeter und einer Spannungsquelle testen ob eine Z-Diode noch funkitonsfähig ist. Man könnte so einen Testaufbau vieleicht mit ein paar Krokodilklemmmen oder einem Steckbrett zusammensteken. Am besten mal kurz Googeln: Z-Diode testen Multimeter o. ä.

Gruß,

TP

Hallo zusammen,

nach tagelangem Versuchen und rumexperemtieren möchte ich kurz mein Problem erläutern. Ich denke es passt zu diesem Thread:

Ich möchte Jinx! über eine Visual Basic Applikation steuern um einfache Szenen auszuwählen (Nutze also die Jinx! Remote Control Funktion). Ich ich habe mich für das tpm2 Protokoll entschieden, da es für mich den schnellsten Einstieg in kombination mit Visual Basic bietet (Einfache versendung von Bytes über die Write-Methode). Um meine Applikation mit Jinx Remote Control zu verbinden nutze ich die Software "Virtual Serial Port Emulator (VSPE)" von Volodymyr Ter.
Laut Monitoring-Bericht versendet meine Visual Basic Applikation die entsprechenden Bytes die das tpm2 Protokoll benötigt. Jinx! ließt diese auch entsprechend aus dem COM-Port aus.

Laut Jinx-User Manual 2.4 interpretiert Jinx einen 8 Bit Wert (also ein Byte) um z.B. eine Szene auf Kanal 0 auszuwählen.

Die Frage ist nur: wie muss der genaue Aufbau in tpm2 aussehen, damit Remote Control (Jinx) einen Szenenwechsel vollführt (Z. B. Szene 5 wählen)???

In meinem Fall sende ich über die Visual Basic Applikation folgende Bytes als Array.

0xC9 / Blockstart-Byte nach tpm2-Spezifikation (seriell)
0xDA / Ich will ein Datenbyte senden. Richtig für einfache Jinx! Szenenauswahl???
0x01 / Framegröße des Highbyte
0x01 / Framegröße des Lowbyte
0x05 / Mein Datenbyte (hier soll Szene 5 gewählt werden) entpricht im Dezimalsytem ebenfalls dem DataByte = 5
0x36 / Blockende-Byte nach tpm2-Spezifikation

Kann mir jemand helfen? Ich sitze schon recht lange an diesem Problem und habe schon X Varianten in Visual Basic durchgespielt.

Oder muss ich Jinx Remote Control über das Kommando-Byte ansprechen (also Byte 0xC0 anstatt 0xDA)? Falls dies der Fall ist: Was muss ich dann bei Kommando-Kontrol-Byte beachten?

Viele Grüße,

TP