Viddovation
Veteran
Hi guys. I'm no longer an F35 owner, but I was recently contacted with questions about my prior work reverse engineering the Sony F35 dock protocol. I've decided to release here a reference to the protocol. This information is provided AS-IS, and I assume no liability for anything whatsover that may occur if you use it. All risk is yours. This reference was created through reverse engineering, and I never had any access to confidential Sony materials, nor have I ever signed any NDAs with Sony. I have every reason to beleive that the release of this information is legal under US law. However, I cannot speak to the legality of its use - please consult your own attorneys with any concerns you may have.
This reference may have typos. It may have errors. It is most certainly incomplete. You better understand hex. Without further ado...
*******************************************************************************
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
*******************************************************************************
The Camera Message Protocol
The SRW-1 uses two communication protocols over the same serial link.
One, “VA” doesn’t seem to be understood by the Sony F35.
The other shall be called the “Camera” protocol.
Camera Protocol Basics
The first byte of the message is always 0xAB.
The second byte of the message is always 0x80.
The third and fourth bytes indicate the directionality of the message (F35 to SRW1, or vice-versa).
The fifth byte of the message is always a message length count, in bytes.
The sixth byte of the message is always a counter.
The seventh and eighth bytes are a message code.
The ninth byte is the start of the message content. Some messages have a subcommand here.
The last byte is always a checksum, the two’s complement of all preceding bytes in the message.
The message may never be an odd number of bytes. Some messages therefore have a blank byte before the checksum.
The shortest possible message is 0x0A bytes.
Directionality
For messages sent by the SRW1 to the F35, bytes 3 and 4 will always be 0x7111.
For messages sent by the F35 to the SRW1, bytes 3 and 4 will always be 0x1171.
The Counter
The sixth byte of all messages is a counter. Each device uses it’s own counter for it’s outgoing messages.
The counter increments by one on each message. Upon reaching 0xFF, the counter returns to 0x00.
The Handshake
Upon initial power-up the camera and recorder must determine that they are docked to one another,
and have an authentication “handshake.” Until this handshake is completed successfully, the camera
will not output HD-SDI video signals, and features like the “REC Run” button on the camera will not be
enabled. The handshake has several steps, and I will enumerate them here.
In their initial, default states, the camera and the recorder will both send out 0x0301 messages. They
do this until they each respectively receive the responses they’re seeking. The recorder seeks a 0x0402
response from the camera, and the camera seeks a 0x0602 response from the recorder. Both devices must
answer the other device’s 0x0301 message, or behavior will be undefined.
I should quickly note that in the initial state, the recorder will also send out packets of a different protocol
standard (starting with a 0x43 byte). The camera simply ignores them. They appear to either be for a different
device connection or purely for troubleshooting. The recorder stops sending these after receiving a 0x0402
response. There is no requirement to emulate these packets for the camera.
After it receives a 0x0402 response from the camera, the recorder will send a 0x0614 request to the
camera. The camera will answer this with a 0x0884 response, but only if it has already received a 0x0602
response to it’s 0x0301 message. The content of the 0x0614 and 0x0884 messages isn’t understood, but may
refer to model information or other defining parameters of expected operation.
Once the recorder receives the 0x0884 response, it will start sending frame-by-frame 0x3783 messages.
For each 0x3783 message received, the camera will respond with a 0x1D13 message. Under some testing conditions
the camera responded with 0x1D83 messages, but this behavior has not been reliably repeated, and the 0x1D83
messages appeared to contain similar content to the 0x1D13 messages. These 0x3783 and 0x1D13 messages are
essentially play-by-play status updates that include timecode, deck status and such.
Additionally, shortly after sending the 0x0614 request the recorder will issue three 0x0331 messages, each
specifying a different information request. The three requests are for video output format, video encode format,
and the current select FPS setting, per the camera. If not answered, these requests will be reissued every few seconds,
as will the 0x0614 request if left unanswered. The camera will issue two 0x0632 responses and one 0x0432 response
to these three queries.
At this point, the handshake should be complete.
AB Protocol Messages:
*****************************************************************************
*****************************************************************************
Command: 0x0301 “Hello” (Query)
Total Length: 0x0A
Sender: VTR, CAM
This is the first message sent by both the camera and the recorder.
It is the exact same message. Will be sent on repeat, at a
frequency of roughly once per second until answered.
There is no content to the message, and the sole message byte is
blank.
————————————————————
Byte 0x09 is 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0331 “Info Request” (Query)
Total Length: 0x0A
Sender: VTR
This message is sent by the VTR when requesting certain types of
information from the camera.
————————————————————
Byte 0x09 specifies what information is requested.
0xC2 - Video Encode Format
0x86 - Video Output Format
0x81 - Select FPS setting
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0390 “Camera Action Request”
Total Length: 0x0A
Sender: CAM
The recorder sends this request when the camera “Run” button is
pressed. The recorder does not issue a response in kind, but if the
command is accepted, it will be reflected in the immediately following
0x3783 frame packets from the recorder.
The recorder also sends this request when the camera “REC Review”
button is pressed, with a follow up 0x0490 message.
————————————————————
Byte 0x09 is 0x02 the first time after power up this command is issued
for a “REC Run” request.
It is 0x08 on subsequent “REC Run” requests. (at least as observed so far)
It is observed as 0xA5 for a “REC Review” request.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0402 “Camera Hello Response”
Total Length: 0x0C
Sender: CAM
The camera sends this response when it receives a 0x0301 message
from the recorder.
The meaning of the content bytes has not been decoded.
————————————————————
Byte 0x09 is expected to be 0x00.
Byte 0x0A is expected to be 0x04.
Byte 0x0B is expected to be 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x04XX FAMILY: “Select FPS Flags”
Total Length: 0x0C
This defines a family of commands that use similar formatting and
bit flags to specify Select FPS settings. This setting is usually requested
or defined in tandem with the video format settings. Both the camera
and recorder have the capability to push updated settings to the other device
but must receive confirmation that the new setting is supported by the
receiving device. Further, while the camera only actively uses a single toggle
for the Select FPS setting, there is a second one hidden for the VTR to push
new settings to.
————————————————————
Byte 0x08 contains the lower byte of the command code. Each complete command
code has a different function. Sender listed after code.
0x30 - VTR - defines desired FPS setting (on/off). (Requestor)
0x32 - CAM - confirms definition of FPS setting. (Receiver/Status check)
0xB0 - CAM - defines desired FPS setting (on/off). (Requestor)
0xB2 - VTR - confirms definition of FPS setting. (Receiver)
————————————————————
Byte 0x09 defines the setting being modified - but there’s only the one.
0x80 - Standby Select FPS on/off flag.
0x81 - Select FPS on/off flag.
————————————————————
Byte 0x0A is the Select FPS flag.
0x00 = “Select FPS OFF”
0x00 = “Select FPS ON”
————————————————————
Byte 0x0B is expected to be 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0602 “Recorder Hello Response”
Total Length: 0x0E
Sender: VTR
The recorder sends this response when it receives a 0x0301
message from the camera.
————————————————————
Byte 0x09 is expected to be 0x00.
Byte 0x0A is expected to be 0x10.
Byte 0x0B and 0x0C are expected to be 0xF270. I believe this
is the firmware version of the VTR. (Tested on VTR with V2.70)
Byte 0x0D is expected to be 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0614 “Recorder Parameters Request”
Total Length: 0x0E
Sender: VTR
The recorder sends this request after it’s 0x0301 “Hello” has
received a response message from the camera. However, the
camera will not answer unless it’s 0x0301 has also been answered
by the recorder.
Purpose of the content bytes unknown. Parameters is just a guess.
————————————————————
Byte 0x09 is expected to be 0xF0.
Byte 0x0A is expected to be 0x01.
Byte 0x0C is expected to be 0x02.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x06XX FAMILY: “Video Format Commands”
Total Length: 0x0E
This defines a family of commands that use similar formatting and
bit flags to specify Video Formats. Both the camera and VTR have the
capability to request the other device conform to their video format setting.
Since the camera and VTR may have some formats the other does not support
it is necessary for the the requesting device to get confirmation from the
receiving device that the the requested setting is support.
Further, while the camera only visibly shows one video format setting to
the operator, it actually stores at total of four video formats concurrently -
two standby formats, a base format, and a “Select FPS” format that
overrides the base setting (becoming the user visible setting) when the
bit flag for Select FPS is active - which is controlled by a separate set of commands.
This organization of settings is sincerely different than the manner in which
the settings are presented to the camera operator, and should be reviewed
carefully.
————————————————————
Byte 0x08 contains the lower byte of the command code. Each complete command
code has a different function. Sender listed after code.
0x30 - VTR - defines new video format. (Requestor)
0x32 - CAM - confirms definition of video format. (Receiver/Status check)
0xB0 - CAM - defines new video format. (Requestor)
0xB2 - VTR - confirms definition of video format. (Receiver)
————————————————————
Byte 0x09 defines which of stored video formats is being defined/confirmed.
The “Standby” formats are the ones modified during setting updates,
The active ones are requested on power-up to verify matched settings.
0xC0 - Standby base format
0x84 - Standby variable FPS format
0xC2 - Base format - typically the encoded format by the VTR.
0x86 - Variable FPS format - active when Select FPS is “On”.
———————————————
Byte 0x0A specifies frame rate with bit flags: (fractional TC’s have the 0x80 flag)
0x00 = “24”
0x01 = “25” (progressive or interlace)
0x02 = “30”
0x05 = “50”
0x80 = “23.98”
0x82 = “29.97” (progressive or interlace)
0x86 = “59.94”
0x06 = “60”
Bit flag for the 0x84 select FPS format settings:
+0x40 = “Default” FPS settings.
———————————————
Byte 0x0B specifies the frame option:
“Interlace” +0x00 to subtotal
“progressive” +0x40 to subtotal
“progressive, high speed” +0x80 to subtotal
“1080” +0x00 to subtotal
“720” +0x04 to subtotal
———————————————
Byte 0x0C specifies SDI Link and color space settings:
“Singe-link” +0x00
“Dual-link” +0x20
“Quad-link” +0x40
“4:2:2 Color Space” +0x00
“4:4:4 SQ Color Space” +0x04
“4:4:4 HQ Color Space” +0x05
“4:2:2 Dual Stream” +0x08
Bit flag seen from camera, but not decoded:
unknown +0x02
———————————————
Byte 0x0D is always 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0884 “Camera Parameters Response”
Total Length: 0x0E
Sender: CAM
The camera sends this response after it receives a 0x0614 request
from the recorder. If the camera’s 0x0301 message has not been
answered, it will not provide this response.
Purpose of the content bytes unknown. Parameters is just a guess.
————————————————————
Byte 0x09 is expected to be 0xF0.
Byte 0x0A is expected to be 0x01.
Byte 0x0C is expected to be 0x05.
Byte 0x0D is expected to be 0x1E.
Byte 0x0E is expected to be 0x01.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x1D13 “Camera Frame Packet Response”
Total Length: 0x24
Sender: CAM
The recorder sends this response when it receives a 0x3783
frame information message from the recorder.
It will be sent once per frame. In the event of select FPS, it will still
be sent on “dead” frames.
————————————————————
Byte 0x09 is expected to be 0xF0.
Byte 0x0B is expected to be 0x03.
Byte 0x0C is expected to be 0xFF.
Byte 0x0D is expected to be 0xFF.
Byte 0x0E and 0x0F are some sort of code. Generally 0xFFFF, but also
seen as 0x0201.
Byte 0x10 expected to be 0x03.
Byte 0x11 usually 0x00. Seen as 0x80 when camera requesting power down.
Byte 0x14 is the current frame rate, expressed as an integer. When
select FPS is active, this is variable, matching the current selected FPS.
Otherwise, it will match the current encode frame rate. Fractional frame rates
are rounded to their closest integer.
Byte 0x1A and 0x1B are used for some sort of challenge code. Value will be
0x0FFF when not actively using challenge. Otherwise, contains an unpredictable
value. The purpose and method of this code is not yet determined.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x3783 “Video Frame Info”
Total Length: 0x3E
Sender: VTR
This message is sent once per frame.
****Much of it isn’t decoded yet.
————————————————————
Byte 0x09 observed to be 0xF0.
————————————————————
Byte 0x0B observed to be 0x05.
————————————————————
Byte 0x0C contains Media Status information.
The information is encoded as bit flags, but practically, here are
the anticipated statuses:
0x01 - Media present, Record Inhibit Off (Norm)
0x03 - Media present, Record Inhibit On
0x21 - No media.
————————————————————
Byte 0x0D contains Deck Status information.
The information is encoded as bit flags. Note that some settings are mutually
exclusive. Here are the known codes:
0x00 - Default when no tape present
0x10 - Eject mechanism activated
0x20 - Standby Off
0xA0 - Standby
0x81 - Play (and play-lock)
0xC1 - Play-Pause
0x41 - Play-Pause* (asterisk… standby thing)
0x88 - Rewind
0x84 - Fast-Forward
0x80 - Shuttle (any speed forward/reverse)
0xC2 - Rec-Pause
0x83 - Record-Play
0x42 - Rec-Pause* (asterisk… standby thing)
The logic for the given setting will make more sense if you break them into
their respective bit flags:
+0x10 tape eject mechanism active.
+0x20 tape is stopped.
+0x40 tape is paused.
+0x80 Servo is engaged.
+0x01 tape plays
+0x02 tape records (when play-record the “plays” flag will be active as well.)
+0x04 tape fast-forwards
+0x08 tape rewinds
————————————————————
Byte 0x12 is the tally light control. Haven’t tested yet for “low” mode. Blinking is done by turning this on/off on the recorder side.
0x00 = tally off
0x80 = tally on
————————————————————
Byte 0x14 is a record inhibit flag, should the media be so flagged.
0x00 = “Record Inhibit Off”
0x01 = “Record Inhibit On”
————————————————————
Byte 0x16 is a condensed set of bit flags, not all decoded.
+0x01 flag instructs cam to not show the playback (“PB”) feed when set to “auto” mode for VF/monitor. When off, cam takes PB feed.
Observed as 0x0B when low battery on recorder. That’s 0x0A when excluding the PB flag.
Observed as 0x8D during recording. Does not seem required though.
————————————————————
Byte 0x1B is for Signal Generator status. Uses bit flags. Default is 0x00.
+0x10 if Video SG active (regardless of signal chosen)
+0x20 if Audio SG active (regardless of signal chosen)
————————————————————
Bytes 0x1C and 0x1D are a “Tape Speed” or “Media Speed.” Indicates the current speed of tape movement.
Indicates commanded speed, not necessarily momentary speed. Stored as a signed 16bit value, with negative values
for when the tape is playing in reverse. Values in decimal:
“Stop/Standby” 0x0000 or 0 (0x)
“Play” 0x03E8 or 1,000 (1x)
“Shuttle +2.0” 0x079E or 1,950 (2x)
“Shuttle +5.0” 0x1356 or 4,950 (5x)
“Shuttle +8.0” 0x1F0E or 7,950 (8x)
“Fast Forward” 0x35B6 or 13,750 (14x)
“Shuttle -2.0” 0xF862 or -1,950 (-2x)
“Shuttle -5.0” 0xECAA or -4,950 (-5x)
“Shuttle -8.0” 0xE0F2 or -7,950 (-8x)
“Rewind” 0xCA4A or -13,750 (-14x)
————————————————————
Byte 0x1E and 0x1F contains the media (tape) remaining in seconds. (uint16) Value of 0xFFFF when no media present.
————————————————————
Bytes 0x21 usually 0x00. When camera sends power down request, turns 0x81. Last frame before actual power off 0x83.
Looks like when the cam initiates it’s own shut down the codes are 0x01 and 0x03 respectively. So the +0x08 designates
that the recorder received the shutdown request from the camera.
This byte can also have flags for low battery. +0x04 is low battery “Near end”.
Untested, but +0x08 is expected to be “End” battery.
————————————————————
Bytes 0x22 is the VTR DC voltage in volts. Stored as an integer 10x the real value (12.4v stored as 124)
————————————————————
Byte 0x23 is unknown. Expected value 0x01
————————————————————
Bytes 0x24 and 0x25 appear to be a display code. (what gets shown on the F35 display)
Display code values include:
0x1801 = “TCG”
0x1901 = “UGB”
0x0201 = “CTL” (0x0202 and 0x0205 also show “CTL” may be related to playback.)
0x0100 seen preparing for play lock
0x0200 seen during playback
————————————————————
Byte 0x26 contains what I’m calling config bits.
responds to changes on SRW1 of 12/24 hour time. This is a bit flag.
+0x00 - “24H”
+0x20 - “12H”
+0x00 - “Audio Meter - Full Peak” or “Full Ref”
+0x80 - “Audio Meter - Fine”
+0x08 - “PB” power config mode & “EE(TCR)” mode. Also seen when pressing “play”, temporarily.
A playback power config mode perhaps kills the live SDI signal from the camera to the recorder to conserve power.
————————————————————
Byte 0x27 contains some sort of security code response to 0x1D13 camera packets. Otherwise 0x00.
————————————————————
Byte 0x28 is the timecode display frames position.
Byte 0x29 is the timecode display seconds position.
Byte 0x2A is the timecode display minutes position.
Byte 0x2B is the timecode display hours position.
————————————————————
Bytes 0x2C and 0x2D observed as 0xFFFF.
————————————————————
Bytes 0x2E and 0x2F are an error code. If there is no error it is 0xFFFF.
Known error codes include:
0x0030 “No SDI input”
0x0072 “Camera Response Stop”
————————————————————
Bytes 0x30 and 0x31 are Audio Input Select bit flags, as such:
=0x0000 - if all tracks SDI input
+0x0100 - track 1 analog input
+0x0200 - track 2 analog input
+0x0400 - track 3 analog input
+0x0800 - track 4 analog input
+0x1000 - track 5 analog input
+0x2000 - track 6 analog input
+0x4000 - track 7 analog input
+0x8000 - track 8 analog input
+0x0001 - track 9 analog input
+0x0002 - track 10 analog input
+0x0004 - track 11 analog input
+0x0008 - track 12 analog input
————————————————————
Bytes 0x34 and 0x35 observed as 0x1E01.
—————————————————————
Map:
00112233445566778899AABBCCDDEEFF
00 AB8071113E543783F0000501810000
11 00000000000001000000000003E8FFFF
22 000077010201000002000000FFFF0030
33 000000001E010000000000000000DC
*****************************************************************************
*****************************************************************************
Other messages:
0x0490
0x0684
0x1D83
0x0631 – VTR confirm/set request when pushing a format change
0x03B1 – Camera confirms/sets the new definition for video format.
uses 0x84 for fps video format, uses 0x80 for fps on/off
0x04B0 – Camera defines new push setting for FPS on/off
uses 0x80 for fps on/off variant, 0xC1 to close session.
This message is not part of the required chain. May deal with an error or alternate configuration.
If VTR sends: AB8071110EYY0684F001000100ZZ
Camera will reply: AB8011710EXX0684F001000500ZZ
When “REC Review” was pressed on camera:
Record Command Received.
0390 A5
Unidentified Camera Packet:
0490 A1F100
second time:
Record Command Received.
AB8011710ABE0390A5 (same)
Unidentified Camera Packet:
AB8011710CC30490A1F1005E (same)
*******************************************************************************
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
*******************************************************************************
This reference may have typos. It may have errors. It is most certainly incomplete. You better understand hex. Without further ado...
*******************************************************************************
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
*******************************************************************************
The Camera Message Protocol
The SRW-1 uses two communication protocols over the same serial link.
One, “VA” doesn’t seem to be understood by the Sony F35.
The other shall be called the “Camera” protocol.
Camera Protocol Basics
The first byte of the message is always 0xAB.
The second byte of the message is always 0x80.
The third and fourth bytes indicate the directionality of the message (F35 to SRW1, or vice-versa).
The fifth byte of the message is always a message length count, in bytes.
The sixth byte of the message is always a counter.
The seventh and eighth bytes are a message code.
The ninth byte is the start of the message content. Some messages have a subcommand here.
The last byte is always a checksum, the two’s complement of all preceding bytes in the message.
The message may never be an odd number of bytes. Some messages therefore have a blank byte before the checksum.
The shortest possible message is 0x0A bytes.
Directionality
For messages sent by the SRW1 to the F35, bytes 3 and 4 will always be 0x7111.
For messages sent by the F35 to the SRW1, bytes 3 and 4 will always be 0x1171.
The Counter
The sixth byte of all messages is a counter. Each device uses it’s own counter for it’s outgoing messages.
The counter increments by one on each message. Upon reaching 0xFF, the counter returns to 0x00.
The Handshake
Upon initial power-up the camera and recorder must determine that they are docked to one another,
and have an authentication “handshake.” Until this handshake is completed successfully, the camera
will not output HD-SDI video signals, and features like the “REC Run” button on the camera will not be
enabled. The handshake has several steps, and I will enumerate them here.
In their initial, default states, the camera and the recorder will both send out 0x0301 messages. They
do this until they each respectively receive the responses they’re seeking. The recorder seeks a 0x0402
response from the camera, and the camera seeks a 0x0602 response from the recorder. Both devices must
answer the other device’s 0x0301 message, or behavior will be undefined.
I should quickly note that in the initial state, the recorder will also send out packets of a different protocol
standard (starting with a 0x43 byte). The camera simply ignores them. They appear to either be for a different
device connection or purely for troubleshooting. The recorder stops sending these after receiving a 0x0402
response. There is no requirement to emulate these packets for the camera.
After it receives a 0x0402 response from the camera, the recorder will send a 0x0614 request to the
camera. The camera will answer this with a 0x0884 response, but only if it has already received a 0x0602
response to it’s 0x0301 message. The content of the 0x0614 and 0x0884 messages isn’t understood, but may
refer to model information or other defining parameters of expected operation.
Once the recorder receives the 0x0884 response, it will start sending frame-by-frame 0x3783 messages.
For each 0x3783 message received, the camera will respond with a 0x1D13 message. Under some testing conditions
the camera responded with 0x1D83 messages, but this behavior has not been reliably repeated, and the 0x1D83
messages appeared to contain similar content to the 0x1D13 messages. These 0x3783 and 0x1D13 messages are
essentially play-by-play status updates that include timecode, deck status and such.
Additionally, shortly after sending the 0x0614 request the recorder will issue three 0x0331 messages, each
specifying a different information request. The three requests are for video output format, video encode format,
and the current select FPS setting, per the camera. If not answered, these requests will be reissued every few seconds,
as will the 0x0614 request if left unanswered. The camera will issue two 0x0632 responses and one 0x0432 response
to these three queries.
At this point, the handshake should be complete.
AB Protocol Messages:
*****************************************************************************
*****************************************************************************
Command: 0x0301 “Hello” (Query)
Total Length: 0x0A
Sender: VTR, CAM
This is the first message sent by both the camera and the recorder.
It is the exact same message. Will be sent on repeat, at a
frequency of roughly once per second until answered.
There is no content to the message, and the sole message byte is
blank.
————————————————————
Byte 0x09 is 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0331 “Info Request” (Query)
Total Length: 0x0A
Sender: VTR
This message is sent by the VTR when requesting certain types of
information from the camera.
————————————————————
Byte 0x09 specifies what information is requested.
0xC2 - Video Encode Format
0x86 - Video Output Format
0x81 - Select FPS setting
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0390 “Camera Action Request”
Total Length: 0x0A
Sender: CAM
The recorder sends this request when the camera “Run” button is
pressed. The recorder does not issue a response in kind, but if the
command is accepted, it will be reflected in the immediately following
0x3783 frame packets from the recorder.
The recorder also sends this request when the camera “REC Review”
button is pressed, with a follow up 0x0490 message.
————————————————————
Byte 0x09 is 0x02 the first time after power up this command is issued
for a “REC Run” request.
It is 0x08 on subsequent “REC Run” requests. (at least as observed so far)
It is observed as 0xA5 for a “REC Review” request.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0402 “Camera Hello Response”
Total Length: 0x0C
Sender: CAM
The camera sends this response when it receives a 0x0301 message
from the recorder.
The meaning of the content bytes has not been decoded.
————————————————————
Byte 0x09 is expected to be 0x00.
Byte 0x0A is expected to be 0x04.
Byte 0x0B is expected to be 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x04XX FAMILY: “Select FPS Flags”
Total Length: 0x0C
This defines a family of commands that use similar formatting and
bit flags to specify Select FPS settings. This setting is usually requested
or defined in tandem with the video format settings. Both the camera
and recorder have the capability to push updated settings to the other device
but must receive confirmation that the new setting is supported by the
receiving device. Further, while the camera only actively uses a single toggle
for the Select FPS setting, there is a second one hidden for the VTR to push
new settings to.
————————————————————
Byte 0x08 contains the lower byte of the command code. Each complete command
code has a different function. Sender listed after code.
0x30 - VTR - defines desired FPS setting (on/off). (Requestor)
0x32 - CAM - confirms definition of FPS setting. (Receiver/Status check)
0xB0 - CAM - defines desired FPS setting (on/off). (Requestor)
0xB2 - VTR - confirms definition of FPS setting. (Receiver)
————————————————————
Byte 0x09 defines the setting being modified - but there’s only the one.
0x80 - Standby Select FPS on/off flag.
0x81 - Select FPS on/off flag.
————————————————————
Byte 0x0A is the Select FPS flag.
0x00 = “Select FPS OFF”
0x00 = “Select FPS ON”
————————————————————
Byte 0x0B is expected to be 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0602 “Recorder Hello Response”
Total Length: 0x0E
Sender: VTR
The recorder sends this response when it receives a 0x0301
message from the camera.
————————————————————
Byte 0x09 is expected to be 0x00.
Byte 0x0A is expected to be 0x10.
Byte 0x0B and 0x0C are expected to be 0xF270. I believe this
is the firmware version of the VTR. (Tested on VTR with V2.70)
Byte 0x0D is expected to be 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0614 “Recorder Parameters Request”
Total Length: 0x0E
Sender: VTR
The recorder sends this request after it’s 0x0301 “Hello” has
received a response message from the camera. However, the
camera will not answer unless it’s 0x0301 has also been answered
by the recorder.
Purpose of the content bytes unknown. Parameters is just a guess.
————————————————————
Byte 0x09 is expected to be 0xF0.
Byte 0x0A is expected to be 0x01.
Byte 0x0C is expected to be 0x02.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x06XX FAMILY: “Video Format Commands”
Total Length: 0x0E
This defines a family of commands that use similar formatting and
bit flags to specify Video Formats. Both the camera and VTR have the
capability to request the other device conform to their video format setting.
Since the camera and VTR may have some formats the other does not support
it is necessary for the the requesting device to get confirmation from the
receiving device that the the requested setting is support.
Further, while the camera only visibly shows one video format setting to
the operator, it actually stores at total of four video formats concurrently -
two standby formats, a base format, and a “Select FPS” format that
overrides the base setting (becoming the user visible setting) when the
bit flag for Select FPS is active - which is controlled by a separate set of commands.
This organization of settings is sincerely different than the manner in which
the settings are presented to the camera operator, and should be reviewed
carefully.
————————————————————
Byte 0x08 contains the lower byte of the command code. Each complete command
code has a different function. Sender listed after code.
0x30 - VTR - defines new video format. (Requestor)
0x32 - CAM - confirms definition of video format. (Receiver/Status check)
0xB0 - CAM - defines new video format. (Requestor)
0xB2 - VTR - confirms definition of video format. (Receiver)
————————————————————
Byte 0x09 defines which of stored video formats is being defined/confirmed.
The “Standby” formats are the ones modified during setting updates,
The active ones are requested on power-up to verify matched settings.
0xC0 - Standby base format
0x84 - Standby variable FPS format
0xC2 - Base format - typically the encoded format by the VTR.
0x86 - Variable FPS format - active when Select FPS is “On”.
———————————————
Byte 0x0A specifies frame rate with bit flags: (fractional TC’s have the 0x80 flag)
0x00 = “24”
0x01 = “25” (progressive or interlace)
0x02 = “30”
0x05 = “50”
0x80 = “23.98”
0x82 = “29.97” (progressive or interlace)
0x86 = “59.94”
0x06 = “60”
Bit flag for the 0x84 select FPS format settings:
+0x40 = “Default” FPS settings.
———————————————
Byte 0x0B specifies the frame option:
“Interlace” +0x00 to subtotal
“progressive” +0x40 to subtotal
“progressive, high speed” +0x80 to subtotal
“1080” +0x00 to subtotal
“720” +0x04 to subtotal
———————————————
Byte 0x0C specifies SDI Link and color space settings:
“Singe-link” +0x00
“Dual-link” +0x20
“Quad-link” +0x40
“4:2:2 Color Space” +0x00
“4:4:4 SQ Color Space” +0x04
“4:4:4 HQ Color Space” +0x05
“4:2:2 Dual Stream” +0x08
Bit flag seen from camera, but not decoded:
unknown +0x02
———————————————
Byte 0x0D is always 0x00.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x0884 “Camera Parameters Response”
Total Length: 0x0E
Sender: CAM
The camera sends this response after it receives a 0x0614 request
from the recorder. If the camera’s 0x0301 message has not been
answered, it will not provide this response.
Purpose of the content bytes unknown. Parameters is just a guess.
————————————————————
Byte 0x09 is expected to be 0xF0.
Byte 0x0A is expected to be 0x01.
Byte 0x0C is expected to be 0x05.
Byte 0x0D is expected to be 0x1E.
Byte 0x0E is expected to be 0x01.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x1D13 “Camera Frame Packet Response”
Total Length: 0x24
Sender: CAM
The recorder sends this response when it receives a 0x3783
frame information message from the recorder.
It will be sent once per frame. In the event of select FPS, it will still
be sent on “dead” frames.
————————————————————
Byte 0x09 is expected to be 0xF0.
Byte 0x0B is expected to be 0x03.
Byte 0x0C is expected to be 0xFF.
Byte 0x0D is expected to be 0xFF.
Byte 0x0E and 0x0F are some sort of code. Generally 0xFFFF, but also
seen as 0x0201.
Byte 0x10 expected to be 0x03.
Byte 0x11 usually 0x00. Seen as 0x80 when camera requesting power down.
Byte 0x14 is the current frame rate, expressed as an integer. When
select FPS is active, this is variable, matching the current selected FPS.
Otherwise, it will match the current encode frame rate. Fractional frame rates
are rounded to their closest integer.
Byte 0x1A and 0x1B are used for some sort of challenge code. Value will be
0x0FFF when not actively using challenge. Otherwise, contains an unpredictable
value. The purpose and method of this code is not yet determined.
*****************************************************************************
*****************************************************************************
*****************************************************************************
*****************************************************************************
Command: 0x3783 “Video Frame Info”
Total Length: 0x3E
Sender: VTR
This message is sent once per frame.
****Much of it isn’t decoded yet.
————————————————————
Byte 0x09 observed to be 0xF0.
————————————————————
Byte 0x0B observed to be 0x05.
————————————————————
Byte 0x0C contains Media Status information.
The information is encoded as bit flags, but practically, here are
the anticipated statuses:
0x01 - Media present, Record Inhibit Off (Norm)
0x03 - Media present, Record Inhibit On
0x21 - No media.
————————————————————
Byte 0x0D contains Deck Status information.
The information is encoded as bit flags. Note that some settings are mutually
exclusive. Here are the known codes:
0x00 - Default when no tape present
0x10 - Eject mechanism activated
0x20 - Standby Off
0xA0 - Standby
0x81 - Play (and play-lock)
0xC1 - Play-Pause
0x41 - Play-Pause* (asterisk… standby thing)
0x88 - Rewind
0x84 - Fast-Forward
0x80 - Shuttle (any speed forward/reverse)
0xC2 - Rec-Pause
0x83 - Record-Play
0x42 - Rec-Pause* (asterisk… standby thing)
The logic for the given setting will make more sense if you break them into
their respective bit flags:
+0x10 tape eject mechanism active.
+0x20 tape is stopped.
+0x40 tape is paused.
+0x80 Servo is engaged.
+0x01 tape plays
+0x02 tape records (when play-record the “plays” flag will be active as well.)
+0x04 tape fast-forwards
+0x08 tape rewinds
————————————————————
Byte 0x12 is the tally light control. Haven’t tested yet for “low” mode. Blinking is done by turning this on/off on the recorder side.
0x00 = tally off
0x80 = tally on
————————————————————
Byte 0x14 is a record inhibit flag, should the media be so flagged.
0x00 = “Record Inhibit Off”
0x01 = “Record Inhibit On”
————————————————————
Byte 0x16 is a condensed set of bit flags, not all decoded.
+0x01 flag instructs cam to not show the playback (“PB”) feed when set to “auto” mode for VF/monitor. When off, cam takes PB feed.
Observed as 0x0B when low battery on recorder. That’s 0x0A when excluding the PB flag.
Observed as 0x8D during recording. Does not seem required though.
————————————————————
Byte 0x1B is for Signal Generator status. Uses bit flags. Default is 0x00.
+0x10 if Video SG active (regardless of signal chosen)
+0x20 if Audio SG active (regardless of signal chosen)
————————————————————
Bytes 0x1C and 0x1D are a “Tape Speed” or “Media Speed.” Indicates the current speed of tape movement.
Indicates commanded speed, not necessarily momentary speed. Stored as a signed 16bit value, with negative values
for when the tape is playing in reverse. Values in decimal:
“Stop/Standby” 0x0000 or 0 (0x)
“Play” 0x03E8 or 1,000 (1x)
“Shuttle +2.0” 0x079E or 1,950 (2x)
“Shuttle +5.0” 0x1356 or 4,950 (5x)
“Shuttle +8.0” 0x1F0E or 7,950 (8x)
“Fast Forward” 0x35B6 or 13,750 (14x)
“Shuttle -2.0” 0xF862 or -1,950 (-2x)
“Shuttle -5.0” 0xECAA or -4,950 (-5x)
“Shuttle -8.0” 0xE0F2 or -7,950 (-8x)
“Rewind” 0xCA4A or -13,750 (-14x)
————————————————————
Byte 0x1E and 0x1F contains the media (tape) remaining in seconds. (uint16) Value of 0xFFFF when no media present.
————————————————————
Bytes 0x21 usually 0x00. When camera sends power down request, turns 0x81. Last frame before actual power off 0x83.
Looks like when the cam initiates it’s own shut down the codes are 0x01 and 0x03 respectively. So the +0x08 designates
that the recorder received the shutdown request from the camera.
This byte can also have flags for low battery. +0x04 is low battery “Near end”.
Untested, but +0x08 is expected to be “End” battery.
————————————————————
Bytes 0x22 is the VTR DC voltage in volts. Stored as an integer 10x the real value (12.4v stored as 124)
————————————————————
Byte 0x23 is unknown. Expected value 0x01
————————————————————
Bytes 0x24 and 0x25 appear to be a display code. (what gets shown on the F35 display)
Display code values include:
0x1801 = “TCG”
0x1901 = “UGB”
0x0201 = “CTL” (0x0202 and 0x0205 also show “CTL” may be related to playback.)
0x0100 seen preparing for play lock
0x0200 seen during playback
————————————————————
Byte 0x26 contains what I’m calling config bits.
responds to changes on SRW1 of 12/24 hour time. This is a bit flag.
+0x00 - “24H”
+0x20 - “12H”
+0x00 - “Audio Meter - Full Peak” or “Full Ref”
+0x80 - “Audio Meter - Fine”
+0x08 - “PB” power config mode & “EE(TCR)” mode. Also seen when pressing “play”, temporarily.
A playback power config mode perhaps kills the live SDI signal from the camera to the recorder to conserve power.
————————————————————
Byte 0x27 contains some sort of security code response to 0x1D13 camera packets. Otherwise 0x00.
————————————————————
Byte 0x28 is the timecode display frames position.
Byte 0x29 is the timecode display seconds position.
Byte 0x2A is the timecode display minutes position.
Byte 0x2B is the timecode display hours position.
————————————————————
Bytes 0x2C and 0x2D observed as 0xFFFF.
————————————————————
Bytes 0x2E and 0x2F are an error code. If there is no error it is 0xFFFF.
Known error codes include:
0x0030 “No SDI input”
0x0072 “Camera Response Stop”
————————————————————
Bytes 0x30 and 0x31 are Audio Input Select bit flags, as such:
=0x0000 - if all tracks SDI input
+0x0100 - track 1 analog input
+0x0200 - track 2 analog input
+0x0400 - track 3 analog input
+0x0800 - track 4 analog input
+0x1000 - track 5 analog input
+0x2000 - track 6 analog input
+0x4000 - track 7 analog input
+0x8000 - track 8 analog input
+0x0001 - track 9 analog input
+0x0002 - track 10 analog input
+0x0004 - track 11 analog input
+0x0008 - track 12 analog input
————————————————————
Bytes 0x34 and 0x35 observed as 0x1E01.
—————————————————————
Map:
00112233445566778899AABBCCDDEEFF
00 AB8071113E543783F0000501810000
11 00000000000001000000000003E8FFFF
22 000077010201000002000000FFFF0030
33 000000001E010000000000000000DC
*****************************************************************************
*****************************************************************************
Other messages:
0x0490
0x0684
0x1D83
0x0631 – VTR confirm/set request when pushing a format change
0x03B1 – Camera confirms/sets the new definition for video format.
uses 0x84 for fps video format, uses 0x80 for fps on/off
0x04B0 – Camera defines new push setting for FPS on/off
uses 0x80 for fps on/off variant, 0xC1 to close session.
This message is not part of the required chain. May deal with an error or alternate configuration.
If VTR sends: AB8071110EYY0684F001000100ZZ
Camera will reply: AB8011710EXX0684F001000500ZZ
When “REC Review” was pressed on camera:
Record Command Received.
0390 A5
Unidentified Camera Packet:
0490 A1F100
second time:
Record Command Received.
AB8011710ABE0390A5 (same)
Unidentified Camera Packet:
AB8011710CC30490A1F1005E (same)
*******************************************************************************
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&&
*******************************************************************************
