Hunterqual
Active member
You're thinking a hardware dock, rather than a software-only solution, correct?
How the F35 Camera Dock Communicates - Unlocking the Missing Features
- Thread starter Viddovation
- Start date
Viddovation
Veteran
Well, software has to be executed by hardware. But I'm absolutely looking at a finished product that is self contained, as small as possible, enclosed, and dockable to the camera. The laptop I'm using now is just for testing and "proof of concept."
I think it's possible the finished controller might be the size of a hyperdeckshuttle, certainly no larger than the current IF box.
Viddovation
Veteran
So, some notes on timing. Starting this project timing was one of my worst fears - I realized that if the different components refused to operate in lockstep, behavior would quickly become undefined. Fortunately, timing has been less of a problem than I initially anticipated, but it is still a nuisance in particular respects.
Essentially, the SRW1 VTR sends a data packet every video frame, and the F35 returns one. Emulating this behavior wasn't difficult, and apparently the camera isn't picky about exactly when it receives this packet - it would seem it adjusts it's timing sync to match the incoming data packet. This sets the timing of the video output. The Sony SR-R1 and Atomos Samurai easily adjust to the timing of the F35 SDI stream, and both recorders loop back the return feed with timing that the F35 finds acceptable. So far so good.
There are a couple concerns though - one is, sending the data packets at the right timing interval. They need to be sent at the exact frame rate, and I'm not sure how many nanoseconds of deviation are acceptable. The microcontroller will need to be capable of being within the required margin of error, with accurate enough timing to not confuse the camera. I'm not sure what that behavior would look like. With the laptop I've used a Blackmagic UltraStudio Mini Recorder to ensure I have the right clocking pulse timing. Mind you, I'm confident this can figured out, but it's worth mentioning.
And here's the one that has some end user ramifications:
While both the Samurai and SRR1 loop back live playback with correct timing to pass the CRC check, the Samurai stops using the F35 SDI clock timing when it goes into playback mode. What this means is that it's playback video in the VF and the monitor ports is severely distorted, and should be considered unusable. The SRR1 doesn't suffer this problem and plays back perfectly - but only when still receiving the F35 input feed, proving that it's running off the F35 timebase. For the Samurai this is frustrating news, but not terrible news - afterall, it has a built in screen. But I suspect the Hyperdeck Shuttle and other recorders will suffer the same problem, and with the Shuttle in particular, getting playback through camera would have been of particular benefit.
There may still be a fix, but it's a low priority for me to resolve. But such a fix would essentially involve finding out how recorders like the Shuttle fire their timing pulses, and intercepting that signal, replacing it with a timing pulse from the micro-controller. It's potentially possible, but outside of the scope of my current project.
Essentially, the SRW1 VTR sends a data packet every video frame, and the F35 returns one. Emulating this behavior wasn't difficult, and apparently the camera isn't picky about exactly when it receives this packet - it would seem it adjusts it's timing sync to match the incoming data packet. This sets the timing of the video output. The Sony SR-R1 and Atomos Samurai easily adjust to the timing of the F35 SDI stream, and both recorders loop back the return feed with timing that the F35 finds acceptable. So far so good.
There are a couple concerns though - one is, sending the data packets at the right timing interval. They need to be sent at the exact frame rate, and I'm not sure how many nanoseconds of deviation are acceptable. The microcontroller will need to be capable of being within the required margin of error, with accurate enough timing to not confuse the camera. I'm not sure what that behavior would look like. With the laptop I've used a Blackmagic UltraStudio Mini Recorder to ensure I have the right clocking pulse timing. Mind you, I'm confident this can figured out, but it's worth mentioning.
And here's the one that has some end user ramifications:
While both the Samurai and SRR1 loop back live playback with correct timing to pass the CRC check, the Samurai stops using the F35 SDI clock timing when it goes into playback mode. What this means is that it's playback video in the VF and the monitor ports is severely distorted, and should be considered unusable. The SRR1 doesn't suffer this problem and plays back perfectly - but only when still receiving the F35 input feed, proving that it's running off the F35 timebase. For the Samurai this is frustrating news, but not terrible news - afterall, it has a built in screen. But I suspect the Hyperdeck Shuttle and other recorders will suffer the same problem, and with the Shuttle in particular, getting playback through camera would have been of particular benefit.
There may still be a fix, but it's a low priority for me to resolve. But such a fix would essentially involve finding out how recorders like the Shuttle fire their timing pulses, and intercepting that signal, replacing it with a timing pulse from the micro-controller. It's potentially possible, but outside of the scope of my current project.
Viddovation
Veteran
I just unlocked one of the remaining stumbling blocks - a challenge-response sequence that seems to have no purpose but to deter this sort of experiment.
Essentially, in addition to all other steps, the camera won't output dock video until the VTR gives the correct one byte response to a two byte challenge. At first glance the questions and answers appear random. On closer inspection, the answers may be being generated by some sort of CRC polynomial math. But I'm really not good at that stuff, so I'm not sure.
Closer inspection also revealed that the challenge numbers really only went up to 1021 - which takes up 10 bits in binary flip-flops. The total storage space of the challenge is 16 bits, (two bytes), but the four most significant bits are a variable flag for whether the challenge is active at all (0 for off, 1 to 16 for on), the next two are always zero, and the lowest ten store the challenge number.
I couldn't determine the math... but I was able to brute force query the SRW1 for all 1,021 answers. I've implemented the key in my emulation software and now the camera boots and enables the dock power and video signals in under 15 seconds flat, reliably.
If anyone is good with CRC math, let me know and we'll try to figure out the math. Otherwise, storing the key is only about 1KB in memory, which while not preferable, is acceptable.
Guys - it works. I've ordered a couple parts so I can start rewriting the code for a pic32 embedded micro-controller.
Essentially, in addition to all other steps, the camera won't output dock video until the VTR gives the correct one byte response to a two byte challenge. At first glance the questions and answers appear random. On closer inspection, the answers may be being generated by some sort of CRC polynomial math. But I'm really not good at that stuff, so I'm not sure.
Closer inspection also revealed that the challenge numbers really only went up to 1021 - which takes up 10 bits in binary flip-flops. The total storage space of the challenge is 16 bits, (two bytes), but the four most significant bits are a variable flag for whether the challenge is active at all (0 for off, 1 to 16 for on), the next two are always zero, and the lowest ten store the challenge number.
I couldn't determine the math... but I was able to brute force query the SRW1 for all 1,021 answers. I've implemented the key in my emulation software and now the camera boots and enables the dock power and video signals in under 15 seconds flat, reliably.
If anyone is good with CRC math, let me know and we'll try to figure out the math. Otherwise, storing the key is only about 1KB in memory, which while not preferable, is acceptable.
Guys - it works. I've ordered a couple parts so I can start rewriting the code for a pic32 embedded micro-controller.
keithlango
Well-known member
I, for one, welcome our new robot overlords. All hail Viddovation!
Viddovation
Veteran
Output quad-link 50p RGB 444 10bit? From a single dock port? Oh, yes we can.
Jusgorilla
Well-known member
That's just awesome
Viddovation
Veteran
Here's an interesting wrinkle -
12bit output with a docked VTR doesn't seem to be fully implemented. When coerced to do so, the code the camera outputs for 444 10bit and 444 12bit is exactly the same, so there's no way to distinguish between them. But more importantly, if a user selects a 12bit mode on the camera, it doesn't even attempt to set the mode or ask the VTR if it supports the mode - it just reverts to the prior setting.
There's a potential work around, although I don't have complete resources right now to fully verify it. Essentially, you may be able to set the 12bit mode, then turn on the VTR emulator, and the camera will keep the 12bit mode and occasionally throw a warning in the VF saying "UNSUPPORTED FORMAT."
EDIT: For what it's worth, using the work around the dock does output the 12bit signals. You just lose the communication between camera and VTR that is more readily possible with 10bit.
12bit output with a docked VTR doesn't seem to be fully implemented. When coerced to do so, the code the camera outputs for 444 10bit and 444 12bit is exactly the same, so there's no way to distinguish between them. But more importantly, if a user selects a 12bit mode on the camera, it doesn't even attempt to set the mode or ask the VTR if it supports the mode - it just reverts to the prior setting.
There's a potential work around, although I don't have complete resources right now to fully verify it. Essentially, you may be able to set the 12bit mode, then turn on the VTR emulator, and the camera will keep the 12bit mode and occasionally throw a warning in the VF saying "UNSUPPORTED FORMAT."
EDIT: For what it's worth, using the work around the dock does output the 12bit signals. You just lose the communication between camera and VTR that is more readily possible with 10bit.
Last edited:
Viddovation
Veteran
Update:
This project had been on hold for close to a month and a half because I was waiting on receipt of parts. But I have them now, and this past week I've been coding for the microcontroller.
It's good news, I'm glad to say. The PIC32 microcontroller is fast enough for this project, running at 80MHz. I've still got plenty of work to do, but as of this morning, I've successfully coded and tested the unit for monitor out port SDI trigger recording. To be specific, in this mode of operation, the micro-controller only communicates with the camera, and the external recorder receives it's video input from the camera monitor out port. The distinction is, when the record button is pressed, the monitor out port will send a Sony SDI record trigger that can be read by popular external recorders like the Atomos Samurai. Additionally, this mode will also reduce the camera fan to minimum during recording, and will activate the camera and EVF tally lights.
This is all done by a tiny PIC32 microcontroller on a PCB about 2 inches by 3 inches. A second PCB is currently required for the RS422 driver. But this is all done without a laptop or desktop computer.
Next, work begins on operation to communicate with recorder units, either via Sony 9-pin deck control, or via LANc.
This project had been on hold for close to a month and a half because I was waiting on receipt of parts. But I have them now, and this past week I've been coding for the microcontroller.
It's good news, I'm glad to say. The PIC32 microcontroller is fast enough for this project, running at 80MHz. I've still got plenty of work to do, but as of this morning, I've successfully coded and tested the unit for monitor out port SDI trigger recording. To be specific, in this mode of operation, the micro-controller only communicates with the camera, and the external recorder receives it's video input from the camera monitor out port. The distinction is, when the record button is pressed, the monitor out port will send a Sony SDI record trigger that can be read by popular external recorders like the Atomos Samurai. Additionally, this mode will also reduce the camera fan to minimum during recording, and will activate the camera and EVF tally lights.
This is all done by a tiny PIC32 microcontroller on a PCB about 2 inches by 3 inches. A second PCB is currently required for the RS422 driver. But this is all done without a laptop or desktop computer.
Next, work begins on operation to communicate with recorder units, either via Sony 9-pin deck control, or via LANc.
Viddovation
Veteran
As of this morning, I've interfaced the Sony F35 to the Atomos Samurai through the dock via LANC. Pressing "RUN" on the camera will trigger the recorder to start recording. Pressing "RUN" again will instruct the Samurai to stop recording. Tally lights and low fan noise are also activated for this recording period. While untested, it should be possible to daisy chain a LANC controller to the Samurai, for a remote start/stop button.
However, hitting record on the Samurai will not cause the Samurai to provide feedback via LANC, so it is not possible to change the camera record state based on information from the Samurai, since the Samurai provides no such data.
The LANC protocol itself is designed to provide even more feedback - information about the camera, timecode, time of day, etc. However, it appears clear that Atomos only programmed the Samurai to read the LANC signal for recording status - not to provide any feedback. Therefore, at least for the Samurai the LANC implementation is likely limited to record start/stop. That said, it would still be possible to power the Samurai through the dock, and feed it the dock's video signals.
Other recorders may provide more LANC feedback and therefore features. But unless and until I get my hands on one, I simply couldn't tell you. I'd need it on my bench to program the features.
Next step... Sony 9-pin protocol, also referred to as Sony deck control. Available on the SR-R1, as well as certain AJA & Sound Devices recorders (mostly rack mount stuff, sadly), and of course, full size decks. I'm primarily implementing it for the SR-R1.
However, hitting record on the Samurai will not cause the Samurai to provide feedback via LANC, so it is not possible to change the camera record state based on information from the Samurai, since the Samurai provides no such data.
The LANC protocol itself is designed to provide even more feedback - information about the camera, timecode, time of day, etc. However, it appears clear that Atomos only programmed the Samurai to read the LANC signal for recording status - not to provide any feedback. Therefore, at least for the Samurai the LANC implementation is likely limited to record start/stop. That said, it would still be possible to power the Samurai through the dock, and feed it the dock's video signals.
Other recorders may provide more LANC feedback and therefore features. But unless and until I get my hands on one, I simply couldn't tell you. I'd need it on my bench to program the features.
Next step... Sony 9-pin protocol, also referred to as Sony deck control. Available on the SR-R1, as well as certain AJA & Sound Devices recorders (mostly rack mount stuff, sadly), and of course, full size decks. I'm primarily implementing it for the SR-R1.
dangtienanh
Active member
Viddo,
What do you have in mind for the micro-controller -- recorder communication? Isn't everything unlocked now?
What do you have in mind for the micro-controller -- recorder communication? Isn't everything unlocked now?
Viddovation
Veteran
Forgive me, but I'm not sure I understand the nature of the question.
I'll try to answer regardless.
My personal end goal is to have the Sony SR-R1 recorder and the Sony F35 camera effortlessly communicate with one another through the dock port, with all of the recorder's pertinent wiring re-routed internally through the dock (SDI IN, SDI OUT, data control communication, and power). As such, the recorder will be able to be docked and undocked in the same fashion one one would connect and disconnect the SRW-1, OB-1, or Codex OnBoard recorder to the F35.
The majority of features the camera is designed to offer to those recorders would be available with this implementation. That includes not only the use of the record button and the associated benefits of fan noise reduction and tallly lights, but also features like displaying correct timecode and media time remaining on the F35 display, automatically watching playback and "record review" through the camera viewfinder or monitor out port, all adding up to a better operator experience.
The SR-R1 is capable of nearly all record modes the Sony F35 offers. The primary exclusion is that the SR-R1 does not accept the ramping and VariSpeed setting of the F35. The second is that the SR-R1 will not natively record RGB444 above 30p (however, it will record two separate 444 streams as "3D" so with 3G multiplexers and a post conversion, it is *possible*). The third is that the dock port VTR configuration is dedicated to 10bit mode. Recording to 12bit while using the dock is possible with a very quick work-around, but the camera will visibly display the "error" in the viewfinder and with the tally lights.
This is all possible because the Sony SR-R1 has a full Sony Remote port, for full VTR control, just like a regular rack mount size Sony deck. Simpler recorders like the Atomos Samurai do not offer this degree of I/O, so this degree of integration isn't possible with them - at least not without tearing them open and wiring directly to something deeper inside.
dangtienanh
Active member
Oh man, somehow I missed you 2nd latest post. I was trying to ask what else do you have in mind after unlocking the record trigger button and tally lights. But well...
Apologies and many thanks. I've been following this thread since the beginning. It's mind-blowing.
Apologies and many thanks. I've been following this thread since the beginning. It's mind-blowing.
Viddovation
Veteran
No worries!
Also, as of today... I've got a working "alpha" of the SR-R1 to Sony F35 software on the micro-controller. The basic functionality is present and working: you can start and stop recording on either the camera or recorder, tally lights operate, fan noise reduces to minimum during recording, timecode generated by recorder is displayed on camera, camera displays remaining minutes of media, and camera also automatically switches and watches playback when present and the respective camera mode is enabled.
To be honest, there's not much more functionality left to program. A lot of it is now clean up and debugging. I also plan to implement some shutdown procedure code that stops any active recording before a loss of power, and a method of showing emulator error codes on the F35 LCD display when possible.
I also think I can implement a limited amount of frame rate validation and correction. That is to say, a feature where if you change the frame rate on the recorder, the frame rate on the camera switches to match automatically, therefore eliminating the need to make two changes. However, it won't detect the change between color spaces, and likely won't be able to distinguish between 23.98/24p or 29.97/30p and possibly the interlace modes as well. Under these conditions, the user would need to manually update the camera as well. But if you were jumping back and forth between 23.98p 422 and 50p 422... I think I can make that a single switch. Maybe.
Then the huge step - figuring out how to configure and mount hardware!
Also, as of today... I've got a working "alpha" of the SR-R1 to Sony F35 software on the micro-controller. The basic functionality is present and working: you can start and stop recording on either the camera or recorder, tally lights operate, fan noise reduces to minimum during recording, timecode generated by recorder is displayed on camera, camera displays remaining minutes of media, and camera also automatically switches and watches playback when present and the respective camera mode is enabled.
To be honest, there's not much more functionality left to program. A lot of it is now clean up and debugging. I also plan to implement some shutdown procedure code that stops any active recording before a loss of power, and a method of showing emulator error codes on the F35 LCD display when possible.
I also think I can implement a limited amount of frame rate validation and correction. That is to say, a feature where if you change the frame rate on the recorder, the frame rate on the camera switches to match automatically, therefore eliminating the need to make two changes. However, it won't detect the change between color spaces, and likely won't be able to distinguish between 23.98/24p or 29.97/30p and possibly the interlace modes as well. Under these conditions, the user would need to manually update the camera as well. But if you were jumping back and forth between 23.98p 422 and 50p 422... I think I can make that a single switch. Maybe.
Then the huge step - figuring out how to configure and mount hardware!
dangtienanh
Active member
Very nice work...
What excites me the most is still how you can trigger the recorder to record using the rec button on the camera. That would complete it for me with my F35 + Gemini444 setup!
What excites me the most is still how you can trigger the recorder to record using the rec button on the camera. That would complete it for me with my F35 + Gemini444 setup!
Viddovation
Veteran
Well, I've not used either the Gemini or the new Odyssey recorders from Convergent Designs, so I'm not completely certain about how they're setup, although if Mitch Gross is still lurking on this forum, perhaps he can clarify for us.
That said, the SDI record flag is only available from the monitor out port, which is 422. So, if you intend to rely on the SDI record trigger, you'll only get 422 recording and you'll be using the monitor port.
Otherwise, you'll need to wire to a remote port on the Gemini or Odyssey, and the emulator would need to conform to the remote port specifications for that device. Convergent Design's website indicates that both products have remote ports, although the one on the Odyssey is only listed for "future support" and may not be currently enabled. Neither device seems to have publically published protocol information for their remote ports, which would be needed if something were going to be programmed.
Note: One page for the Gemini indicates "LTC" regarding the remote port, so it could take timecode in, and if the timecode were record run, that could be used to start and stop recording. Unfortunately, that's not ideal for this generator, although it may be possible to fake LTC data within an acceptable timing parameter.
Viddovation
Veteran
So, I bought a new chip for the software. And I just did a successful test.
This is a *tiny* $30 chip & board that can emulate the SRW1, and unlock the myriad of features available with the VTR connection: http://www.mikroe.com/mini/pic32/
That board is smaller than the circuit board used for the dock connection itself.
Note: The board only outputs UART logic signals, an extra chip is required to emulate RS422. But those are about as big as a dime.
This is a *tiny* $30 chip & board that can emulate the SRW1, and unlock the myriad of features available with the VTR connection: http://www.mikroe.com/mini/pic32/
That board is smaller than the circuit board used for the dock connection itself.
Note: The board only outputs UART logic signals, an extra chip is required to emulate RS422. But those are about as big as a dime.
Viddovation
Veteran
Pimp my ride.
... Well, first and foremost, I'll be applying this to my camera and recorder rig. Beyond that... it really depends on the community. It's not going to be free - even though the computing chip is only about $30 there are other hard costs, including the dock board, wiring, housing... and I'm not sure how much these conveniences are worth to everyone.
From the side of my labor... I'm reluctant to simply give away the software. It's essentially been a summer of a job. Here's the flat truth: If Sony or I handed the protocol information to an experienced coder, they could write a program like mine in a couple days, and debug it in a couple more. The real labor was reverse engineering the protocol without Sony's whitesheets.
I have real costs in this project, beyond the time - specialty equipment I purchased, as well as two SRW-1 recorder units I acquired for the reverse engineering. Without at least one of them, the project would not have been possible.
So, in a way, I really don't know.
What would all of you like? How much are these feature worth? How would you want it packaged? Would you need it to be switchable between different recorders? Which recorder would you use it with? Do you want the protocol information for your own projects? I'm happy to listen to ideas.