Analyzing Sony's Multiport - Part 4

Hi again

It has been quite some time since my last post to Sony's Multiport. Sorry for the delay.
But I have some new findings for Protocol and some more tips for an alternative solution than mimicing the Multiport protocol. But more on that later.

Off to the new finding about Sony's Multiport serial protocol.
It is not very relevant for decoding the data and finding out how to control the functionalities, but it can help debugging if errors might occur.

Maybe you remeber the pictures from analyzing the serial data setup from part 3 of this series.

In the end we were recognizing that Sony is most probably using a 9600 Baud serial communication with a bit setup of: 1 Startbit - 8 Databits - 1 even Paritybit - 2 Stopbits.

The corresponding picture was the following:

This picture was from pin number 8 (serial TX) of Sony's Multiport connector. But we know there is another pin with communication. Pin 9 (serial RX).
Now I started analyzing a serial message of pin number 9 which looks like the following:

As you can see, my scope was again off with timing/packets for direct analyzation of serial data.

So when we zoom the data and add identical timing bars from the analyzation session of TX pin, we can see the following:

At the end of transmission the timing bars end, but not the bits that are transmitted!
Quoting Homer J. Simpson: Doh!

But there is no reasons for despair ;)
Having a closer look into the transmitted data (the rising and falling bit flanks) and the timing bars, you can recognize that the timing bars for the single bits are way off on some parts.

Well it is quite normal that serial transmission can be off with their timing (too short, or too wide bit timings due to bad clock, a lot of other tasks for the microcontroller, sun stroms, hickups in space time, annomalies in subspace, ...  pick your reason ;) ).
The trick in a serial transmission is normally: Every new data-block is "synced" fresh at its own starting bit.
So an error in a serial transmission doesn't sum up over a longer series of messages. Instead a timing error is only relevant for each single data packet. At least when timing is not off more than:

T_bit = T_bitexact -5.56% / +6.25% 

So I tried to allign the timing bars new for each data packet and set off for finding the edges of data packet one. I Found the startbit, 8 data bits, the matching even parity, and last but not least ....
well maybe you guessed it already: There were not 2 stop bits as expected!

But to keep in order of my analyzation process:
The stream at the the end of a data packet 'started' as expected with one logic bitvalue at 3.3V, but after that I found a logic bitvalue of 0V instead of a second bit with 3.3V.
Hmmmm......
To use a quite famous acronym you find all over the web: WTF?! Oo

I was quite puzzled to not find the serial bit layout I priorly analyzed at the serial TX pin of my camera (pin 8 - UART_TX). So I checked the complete bit stream and found that Sony obviously is using a different serial bit layout on pin 9 (UART_RX) than they are on pin 8!
Yes you have read correctly:

Serial bit layout on pin 9 is as follows:   start, d0, d1, d2, d3, d4, d5, d6, d7, parity, stop

Don't believe me? Check for yourself at the following picture:

What a baffling finding! What a bunch of sly foxes at Sony that try to bamboozle honest and hard working reengineering RC enthusiats ;)

So again a new part in this puzzle to analyze Sony's Multiport and try to reengineer the communication for an <AddYourFavoriteMicrocontrollerHere>-remote.

Let's again sum up what we know up to this point:

Hardware signals:

1. Trigger of autofocus function via shorting pin 11 to ground (="half press"; works both in photo mode and while recording video)

1. Trigger photo (= full press) via:
1. FIRST triggering AF function (shorting pin 11 to ground)
2. Shorting pin 12 to ground directly afterwards or better while shorting pin 11 to ground (my camera is NOT taking a photo when only pin 12 is shorted to ground!)

1. Switching camera on/off via shorting pin 15 to ground (only when the main power switch at photo button is priorly set to 'on'). Helps saving power when camera not needed.

1. Camera is responding on serial port (pin 8) when connecting pin 10 via a 'x' kOhm resistor to ground (for A6000, response has been seen with value of 100kOhm). 

Communication signals (Serial lines):

1. pin 8 (UART_TX) and pin 9 (UART_RX) are for serial signaling
2. Pin 8 is using a 9600 Baud serial transmission with a bit layout of: 1 start bit, 8 data bits, 1 even parity bit and 2 stop bits
3. Pin 9 is using a 9600 Baud serial transmission with a bit layout of: 1 start bit, 8 data bits, 1 even parity bit and 1 stop bit

For the baud rate I'm a bit unsure at the moment. I am convinced on serial rx line the baud rate must be a bit less than on tx line. But I will have to recalculate this.

So that is it until now for Multiport serial protocol layout.

With the tips of Jörgen in the comments of my last two posts I will hopefully find out something more about the serial contents in the near future.

Now to the last bit I learned shortly:
Linux has a library and according software for communicating and controlling a lot of cameras via a USB connection. This amazing project is called "GPhoto" and is located here.
also Sonys "Alpha" mirrorless cameras are included in this library and there seems to be quite some functionality remote controllable. But I haven't tried myself yet.
So there may be a faster or at least alternative way then reengineering Multiport. Using a (small) linux box and controlling the A6000 via USB.
This approach would have some benfits and some drawbacks. but that has to be investigated sometime else.

Hope you like the analyzation of the Multiport protocol and you will stay tuned.
If I had more time I would also write you more about my new gimbal setup (DYS NEX gimbal style) with a brand new "Storm32 NT" gimbal control board and "NT IMUs". Really great setup! Circumventing a lot of issues with I2C gimbal remotes!
And I would write you something about my new "Fabrikator Mini v1.5" 3D printer used for the IMU cases, the bimal mounts and many things more.
But that will hopefully be another story ;)

All the best to you all!