Open semenovnick opened 2 years ago
Hello there semenovnick π
Welcome to TallyArbiter!! ππ₯³
Thank you and congratulations π for opening your very first issue in this project. TallyArbiter fosters an open and welcoming environment for all our contributors.πΈ Please adhere to our Code Of Conduct.
Incase you want to claim this issue, please comment down below! We will try to get back to you as soon as we can.π
Feel free to contact the author or for any other information, please visit www.techministry.blog. π©βπ» We would love to hear your interesting ideas and engage in discussions.π
I think it would be pretty straight forward to implement this as it's just a relatively simple hexadecimal protocol. The tally par is still a little unclear to me, so it may require a few iterations to make it work.
Would you be open to a remote coding session where I remote into a computer on your network with the switcher and do some reverse engineering of my own?
Ok, tomorrow i'll try to make more detailed file from wireshark session
Best thing you could do is make a pcap file thats filtered to the switcher for each input and switch through the states. That would let me create the integration.
Hello. Here is three different wireshark cap files 192.168.2.99 - Switcher IP
01 - t-bar-mode - open desktop app => enter switcher view => switching the inputs on the switcher by moving t-BAR (preview => live) 02 - fast (autocut) mode switching 1-2-3-4 - open desktop app => enter switcher view => switching between 1-2-3-4 inputs (no preview) 03 - t-bar mode manual inquiry - i am manually send udp "<"T0000f14001000032">" message from udp sender windows app and moving t-bar and switching between inputs Cannot attach files here Files are here: https://disk.yandex.ru/d/VyZmVUGi74L-dQ
Awesome! Would you be able to do one more with tally? Or is tally contained in the T-bar action?
After T0000f14001000032 command to mixer. Mixer send back two packets 1 response F0000f14001160048 And 2 tally data: It's in that packet
0301010101010100000000000000000000010100000b
first 3 bytes are state of inputs "03" - Fourth first - preview second 01 as i understand - devider third - program "01" - is for second input
To send to mixer T-Bar movement you should send sequence of commands
T 00 00 78 00 00 02 00 7a> - initiation of T-Bar movement T 00 00 78 08 03 00 00 83> - set zero position ////// here is commands with numbers between 03 00 to 00 04 second byte is higher T 00 00 78 08 00 04 00 84> - set end position T 00 00 78 00 00 04 00 7C> - end of t-bar movent (without that comand there is no "cut to program" effect)
Ok. The tally protocol is starting to make sense. Can you do one more pcap where you go through and put input 1 in preview then program, input 2 to preview then program, input 3 preview then program, then input 4 preview then program?
I think after that I should have all the data I need to make a module for it.
https://disk.yandex.ru/d/rozNraLEAhDajA
Here it is. My actions are: 1 (pgm) 2 (prv) => t-bar => 2 (pgm) 1 (prv) => 2 (pgm) 3 (prv) => T-bar => 3 (pgm) 2 (prv) => 3 (pgm) 4 (prv) => T-bar => 4 (pgm) 3 (prv) => 4 (pgm) 1 (prv) => T-bar => 1 (pgm) 4 (prv)
I finally had time to sit down and isolate the tally protocol. Now that I have a firm grasp on how that works, I should be able to get a working module in the next two weeks.
What feature would you like to see added to TallyArbiter?
Hello. I asked manufacturer for API, and he send me this document: API(EN).pdf Here is enought information to control switcher but it is not all info. I start to reverse ingeneering communication protocol between desktop app and switcher and results are: As mentioned in document sctructure of UDP message is: <T - for question <F - for feedback from mixer then 00 then program generates sequently increasing numbers from 01 to FF mentioned as "sq" then code of command XX YY Then three bytes of DATA AA BB CC Then checksum "ck" of 00 + sq +XX + YY + AA + BB + CC show as "ck" and ending ">"
On start program send broadcast messages <T 00 sq 68 01 000000 ck> - broadcast message 192.168.1.255 <F 00 sq 68 01 410101 ck> - from switcher <T 00 sq f1 44 000000 ck> - broadcast message 192.168.1.255 ask for serial number <F 00 sq f1 44 001500 ck> - response 0320474UF1R21Q005553h - SN of switcher
Then program entrance to switcher view
<T 00 sq 68 01 000000 ck> - to mixer <F 00 sq 68 01 410101 ck> - response
<T 00 sq f1 c0 000000 ck> - to mixer <F 00 sq f1 c0 000000 ck> - response
Small pause
<T 00 sq 68 a1 000000 ck> - to mixer <F 00 sq 68 a1 000000 ck> - from mixer
<T 00 sq 68 66 000000 ck> - connect message <F 00 sq 68 66 000000 ck> - response
<T 00 sq 81 0f 050000 ck> <F 00 sq 81 0f 053200 ck>
<T 00 sq a2 18 000000 ck> - T-BAR position <F 00 sq a2 18 000004 ck> - T-BAR position
<T 00 sq 78 13 000000 ck> - Read T-BAR mode (There two ways - direct cut to camera or "t-bar mode" with preview and live) <F 00 sq 78 13 010000 ck> - Answer - T-BAR=T-BAR And now begins main cycle of questions to mixer, it loops forever and sometimes currupts by commands ! TALLY ! <T 00 sq f1 40 010000 ck> - Ask for TALLY <F 00 sq f1 40 011600 ck> β all info about tally is in the next packet: 00 01 03 010101 00000000000000000000000 1010000 09 PRV 01 MST 010101 00000000000000000000000 1010000 09 (last is checksum) 00 - First inpur 01 - Second 02 - Third 03 - Fourth
<T 00 sq f1 03 000000 ck> - Input state request <F 00 sq f1 03 002100 ck> Next packet 02020202020202020202020202020202 0a7f7f7 fffffffffffffffffffffffff9b 0a - 1920x1080x60p 7f - empty
I'm not good in coding, I hope for your support. Hopefully, together we will add this mixer to the ecosystem of Tally arbiter. Thanks