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!

Analyzing Sony's Multiport - Part 3

Hi

Here is the third post with some updated information to the Multiport protocol used in most of Sony's (photo) camera's since 2014.
This time I grabbed one of the data streams I priorly captured with my DSO and tried to find some patterns.

I started with the following data stream:

To start the analysis I tried to not take any priorly known knowledge for settled. The only properties of this data stream I took into account were:

• It must be a serial protocol!
• There should be a start bit for syncing.
• There must be some data bits (commonly 8)
• There could be a parity bit or no parity bit.
• There could be one to 'x' stop bits (regularly 1, 1.5 or 2 bits)

So what to do at the beginning? Trying to find a bit width should be a good start. An from post number 1 in this series, combined with the assumption that the max bitlength can be seen at possible start bit, I added timing bars to the above data stream. The result looks like this:

I also added a count of the single bits to the timing bars in the above picture. As you can see, there are at least 69 completly identifiable bits. And possibly some more at the end of the data stream. 

With the above picture I tried to make an educated guess and marked the start bits in the whole stream. With the first bit as a "0V" sign, I assumed that there are only possible start bit with a "low" value. 

With the assumption that you have a start bit and 8 guessed following data bits, I marked the bits in the picture as follows:

As you can see with the first assumed byte in the above picture I marked the data as follows:

1. Startbit as '0v' (low)
2. 8 Databits
3. some other bits (3 as you can see)

And this was my first finding. It seems the serial protocol has the form of: "1 start-bit; 8 data-bits; 3 other-bits". 

So in the end I assume there are 12 bits per transmitted data-byte. 

With this knowledge I finalyzed the timing bars as in the following picture (added some at the end to finish the stream):

As you can see at the end of the data frames I added bits 71 and 72. 

So in the end in the analyzed data stream you have 6 bytes (8 data-bits) with each possesing one start-bit and 3 'other'-bits. In total 72 bits.

Now the only thing unknown are these 3 'other' bits in each packet. 

The possible reasons for bits after the data-bits in a serial stream are 'parity'-bits and 'stop'-bits.

As the parity information is always one bit, we can check if the first of the 'other'-bits is changing and if there is a pattern related to the prior data bits. And the finding is, that in data packet 3 and 4 you have different bit values for the assumed parity, compared to in data packets 0, 1, 2 and 5. So we can assume this is a parity bit at last. 

This leaves the last two bits in the several data packets without a property. And the only rational use for these last two bits are to be 'stop'-bits.

The only thing we need to figure out is, if the parity bit is of 'even' or 'odd' style. To answer this question, we only need to perform a 'XOR' operation over all 8 data bits within a packet and compare the calculated 'Xored' bit with the value of the assumed parity bit. Doing this with the first packet, we find the following:

First packet is:    start, 1, 1, 0, 0, 0, 1, 0, 0, parity, stop, stop

We need to perform the following calculation: 1 xor 1 xor 0 xor 0 xor 0 xor 1 xor 0 xor 0 = 1

As the parity bit in this packet is also '1', we can assume we have an even parity bit. 

If we apply this finding to the other data packets, we can confirm that even party is also applied in the remaining packages.

So to summarize our findings at the end we are now assuming the following:

1. Sony's multiport protocol is a serial protocol with two serial data lines (at A6000 camera: pin 8: UART_TX; pin 9: UART_RX)
2. Serial speed is 9600 Baud
3. Serial data setup is: 1 Start-Bit, 8 Data-Bits, 1 Parity-Bit (even), 2 Stop-Bits => 8E2

We don't know anything about the sent and received data yet, that is controlling the camera and signaling the camera states. But I hope there is more knowledge to come. 

So as final words:
Please don't give anything on the data shown in the scope pictures I posted in the prior posts one and two, as I configured the scope for 8N1 decoding in these screenshots.