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.