Topology (_top) information correctness

[Dev1an]

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.

[Julusian]

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

[Dev1an]

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.

[Dev1an]

Here is a package dump of my 1ME Production Studio 4K

Initialize 1ME PS4K.pcapng.zip

[Dev1an]

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

• Changing byte 2, adds/removes downstream keyers in the official GUI
• Changing byte 5, adds/removes media players
• Changing byte 7, enables/disables the remote RS422 settings pane
• Changing byte 8, adds/removes hyperdecks in the settings pane of the official GUI
• Changing byte 10, enables/disables the STING button under Transition Style

You mapped (in 6048802)
https://github.com/nrkno/tv-automation-atem-connection/blob/7b4037414df5c1df63589a72fb9e2efa37b7bf45/src/commands/DeviceProfile/topologyCommand.ts#L10-L20

So I don't know when you figured out bytes (6,7,8,9,10) but I think they shifted one byte.

[Julusian]

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.
From the collection of dumps we have, as recent as 8.1.0 has byte 7 as 0x04: 5f746f70 01 18 02 01 04 02 01 04 01 (from https://github.com/nrkno/tv-automation-atem-connection/blob/master/src/__tests__/connection/tvshd-v8.1.0.data) Then in 8.1.2 it becomes byte 8 with the 0x04 value https://github.com/LibAtem/LibAtem.ComparisonTests/blob/master/LibAtem.MockTests/TestFiles/Handshake/2me-v8.1.2.data
So this appears to have changed in 8.1.1

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.

[mint-dewit]

I can confirm that on my TVS HD under firmware version 8.2 the topology command is incorrect:

"mixEffects": 1,
"sources": 24,
"downstreamKeyers": 2,
"auxilliaries": 1,
"mediaPlayers": 2,
"serialPorts": 1,
"maxHyperdecks": 1,
"DVEs": 4,
"stingers": 1,
"superSources": 0,
"cameraControl": false,
"advancedChromaKeyers": true

So I don't know how you figured out bytes (6,7,8,9,10) but I think they shifted one byte.

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 2.0.0-nightly-feat-proto-v230-topology-changes-20200418-110107-20e1513.0

[Dev1an]

Then maybe they added something ATEM-mini related at byte 6 and all the other bytes got shifted one byte?

[mint-dewit]

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?

[Julusian]

For my mini:

8.1.0 = 5f746f70 01 0e 01 01 00 01 00 04 01 0000000000010000000000
8.1.1 = 5f746f70 01 0e 01 01 00 01 00 00 04 0100000000000100000000

So it doesnt look like something for the mini.
The changelog doesn't indicate anything that might use a flag here though, so this wont be a simple change to figure out

[Julusian]

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