-
Notifications
You must be signed in to change notification settings - Fork 36
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Topology (_top) information correctness #79
Comments
It is a lot of trial and error to figure out what the bytes in that command mean. Our interpretation of that could well be wrong, and I know there are other errors in that command but it is the hardest one to figure out. Would you mind sharing the output file from https://builds.julusian.dev/atem/atem-connection-data.exe? It simply records all the commands the atem sends while opening a connection, which is useful to help interpret some of these more difficult ones without needing physical access to every model |
Overall your interpretation of _top looks more accurate than other libraries. I am using macOS so I cannot run your exe... do you have a nodejs equivalent of that program? Otherwise I can also just send you a dump from Wireshark. |
Here is a package dump of my 1ME Production Studio 4K |
I am also making an implementation of the protocol (at Swift-Atem) and using that implementation I created a simple program that simulates an ATEM switcher so that I can test it against the official ATEM Software Control GUI app from Blackmagic. (Below tests are done using ATEM Software Control V8.2.1) Using the simulator I can confirm that
You mapped (in 6048802) So I don't know when you figured out bytes (6,7,8,9,10) but I think they shifted one byte. |
A wireshark dump is also good, so thanks for that. That explains why your name was familiar, I have had a look through github for other atem implementations at various points in time to see what there is out there and if there was anything I could learn from them. It looks like the problem is that these byte offsets have changed over time. Something that might interest you is the work I have been doing in https://github.com/LibAtem/LibAtem, which is where I put most of my reverse engineering work (with bits getting copied here when needed). For that I am writing a suite of tests comparing the implementation against the offical sdk to check for correctness. While I am focussing on getting 8.1 100% complete first, I can see that hidden amongst the expected 8.1.1 failures is an incorrect number of hyperdecks. |
I can confirm that on my TVS HD under firmware version 8.2 the topology command is incorrect:
A dump from 8.1 shows everything correctly for me, so this probably changed in protocol version 2.30 (fw 8.1.1) I have created a prerelease of our library with a preliminary fix for this, can you test this against your device with version |
Then maybe they added something ATEM-mini related at byte 6 and all the other bytes got shifted one byte? |
Atem mini support was added in 8.1 and this changed in 8.1.1 so it could be anything. It looks like byte 6 changed to 0x01 on both my Atem TVS HD and your 1 M/E. @Julusian if you have the time could you check what it says on your Mini? |
For my mini:
So it doesnt look like something for the mini. |
It looks like this is resolved for now. Im going to close this, but please do open another issue if you have more questions or find other things which look wrong |
Looking at
https://github.com/nrkno/tv-automation-atem-connection/blob/3f8cfe7bdd7434b193c4807fc521546b3790c1ad/src/commands/DeviceProfile/topologyCommand.ts#L18
From where do you know that byte 8 describes the
DVE
's?My Atem 1 M/E Production Studio 4K gives me
04
for this value. And I know that this atem only has one DVE. So I think this is incorrect.The text was updated successfully, but these errors were encountered: