Closed RoseOO closed 4 years ago
Also here is the command for recalling the user preset Hex 02 recalls User preset 2
180000000000000000000800020000000100080001000000
I've also attached a picture of the UI for reference.
Is the protocol two way? And similar the other way?
Yes the protocol is two way and it is similar the other way, the data rate is quite high the software generates a few hundred packets every few seconds so I had to do some filters to get the commands out.
I believe 0800000000000000 polls the status from the mixer but I haven't looked heavily into what the returned values mean yet.
Would a pcap file be useful?
Received my Stream Deck XL today and thought mocking up a button layout be good to show what kind of functions would be useful. You could have similar pages for the Key Aux Bus selections, is it possible to have a button to act as a selector for each aux bus so you can select different sources for each on the same button? Similar to how the supplied software works.
I've also emailed Datavideo to see if they may be willing to release a specification, having feedback easily for these buttons would be great.
Did a bit more collection of the button values
DSK 1 PGM ON: 18000000000000005b000200010000007f00020001000000
DSK 1 PGM OFF:18000000000000005b000200000000007f00020000000000
DSK 1 PVW ON: 10000000000000007f00020001000000
DSK 1 PVW OFF:10000000000000007f00020000000000
DSK 2 PGM ON: 18000000000000006d000200010000008000020001000000
DSK 2 PGM OFF:18000000000000006d000200000000008000020000000000
DSK 2 PVW ON: 10000000000000008000020001000000
DSK 2 PVW OFF:10000000000000008000020000000000
KEY 1 PGM ON: 180000000000000013000200010000005000020001000000
KEY 1 PGM OFF:180000000000000013000200000000005000020000000000
KEY 1 PVW ON: 10000000000000005000020001000000
KEY 1 PVW OFF:10000000000000005000020000000000
KEY 2 PGM ON: 180000000000000031000200010000005100020001000000
KEY 2 PGM OFF:180000000000000031000200000000005100020000000000
KEY 2 PVW ON: 10000000000000005100020001000000
KEY 2 PVW OFF:10000000000000005100020000000000
NORM REV ON: 10000000000000005500020001000000
NORM REV OFF:10000000000000005500020000000000
REV: 10000000000000005400020001000000
TRANS PVW ON: 10000000000000005300020001000000
TRANS PVW OFF:10000000000000005300020000000000
KEY PRIORITY ON: 10000000000000005200020001000000
KEY PRIORITY OFF:10000000000000005200020000000000
FTB ENABLE ON: 10000000000000008500020001000000
FTB ENABLE OFF:180000000000000085000200000000000a00070000000000
FTB ON: 10000000000000000a00070001000000
FTB OFF: 10000000000000000a00070001000000
TBAR POSITION: 1000000000000000010002000000c842 TOP
M/E TRANS (SET TO 30): 1000000000000000030007001e000000
M/E TRANS (SET TO 15): 1000000000000000030007000f000000
DSK TRANS (SET TO 30): 1000000000000000080007001e000000
DSK TRANS (SET TO 15): 1000000000000000080007000f000000
FTB TRANS (SET TO 30): 10000000000000000d0007001e000000
FTB TRANS (SET TO 15): 10000000000000000d0007000f000000
I've also attached a packet capture with me launching the panelControl1200 software and clicking through the program and preview bus sources and a couple of cuts and autos.
Just looked quickly over the pcap, and the first two bytes are always the length of the packet, little endian.
So early on, the server says it will send 0x510c bytes (20748 bytes), and then continues to send the bytes over several packets, max 1448 bytes each packet.
So what you call a status request, is in reality 6 bytes of 00. Which I might think is just a NOP, to keep the connection alive, because the server seldom answers to it. But you might also be right, if the server is allowed to ignore it when it is busy.
The long packets from the server kind of looks like the full state of the device, or something. Since it looks like formatted short data pairs.
I will continue looking at the dump later.
@haakonnessjoen Sounds great, I'm not really experienced with reverse engineering protocols. I was mostly happy with at least being able to identify some parts, but this will be a really nice learning experience.
I would also be willing to setup an environment so my SE-1200 could be accessed for testing.
You can get root shell access too but I don't think it's all that interesting as the linux side pretty much just loads an FPGA program, but might be worth some exploring.
Also just wondering if there is any correlation in the protocol with the RS232 control spec linked below, at a glance the values used to set the program crosspoint are different but the structure may shed some light on things.
http://www.resource.datavideo.com/downloads/SE-1200MU%20RS-232%20Commands_E1_A4_EN_20171204.pdf
More thoughts as I'm searching around, I see DVIP mentioned a lot and while I can't find a specific document for the SE1200 there is one for the SE2200.
The SE1200 also lists its control protocol as DVIP. I may send another email to Datavideo asking is they have a DVIP specification for this device, that may be wording their support will understand.
http://www.resource.datavideo.com/downloads/Datavideo_DVIP_Ethernet_Control_Operation_Guide.pdf
Great they replied within a couple of hours this time. Spec attached.
bitfocus/companion-module-datavideo-dvip#2
Just to update I'm now looking at bringing this into the style of krocheck's novastar module as it seems very compatible with what I want to achieve.
Hi,
I've been doing some digging into the SE-1200MU and it's undocumented TCP control protocol.
It receives data on port 5003 and needs persistent TCP connections as a lot of new connections seem to lockup the system.
There are also other transition controls and other DSK transition controls but they have a toggle so the value sent changes.
It would be lovely to see this implemented anyway, if you need anymore information please let me know.