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. 

Analyzing Sony's Multiport - Part 2

Hello there!

 It is time for a little update accoring the functionalities of Sony's Multiport interface with Sony's A6000 photo camera.

 To sumarize the last post:

 - Pinout of the Sony Multiport at the newer camera models (since 2014 as far as I know) is:

1: "VBUS" - 5V- Supply USB-Host 2: "D-" - USB-data (negative) 3: "D+" - USB-data (positiv) 4: "USB_ID" - for USB-OnTheGo (unknown if support/used by camera) 5: "GND" - in camer aconnected with Pin 14 ("AV_GND") 6: "D_3.1V" / "LANC_DC" - output supply for 3.1 to 3.3V (possible load unknown, better do not use) 7: "XRESET_REQ" - input for Reset-Request (untested) 8: "UART_TX" / "LANC_SIG" - optional output for serial data (Debug) or LANC (depends on pin 10 coding; serial interface assumed as 9600 baud, 8N1) 9: "UART_RX" / "BOOT_IN" - optional input for serial data (Debug) and Bootloader (depends on pin 10 coding; serial interface assumed as 9600 baud, 8N1; bootloader function not verified) 10: "AD_JACK_IN"/"Select" - analog input for resistance recognition to determine functionality of connected accessory (remote, programmer?, ...) 11: "LINEOUT_R" / "XAE_LOCK_SW" - optional audio out (right, assumed decoupled via camera internal capacitor) and/or input for trigger button (half press) in photo mode of camera (depending on resistance at pin 10 "AD_JACK_IN") 12: "LINEOUT_L" / "XSHUT_SW" - optional audio out (left, assumed decoupled via camera internal capacitor) and/or input for trigger button (full press) in photo mode of camera (depending on resistance at pin 10 "AD_JACK_IN") 13: "VIDEO" - optional composite-video-output (no signal at A6000 camera; video out only via HDMI at this model) 14: "AV_GND" - internally connected to Pin 5 ("GND"; USB-pins) 15: "XPWR_ON" - input for external ON/OFF-function (short to camera GND for triggering on/off)

Functionalities of this list that are working at Sony A6000 (and most probably at Sony A5100 and Sony A5000) are:


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

2. Trigger photo via (= full press):
   a. FIRST triggering AF function (shorting pin 11 to ground)
   b. 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!)

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

4. 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). 

None of these functionalities have anything to do with the Sony Multiport protocol I'm still trying to analyze. I'm very sorry I haven't any better news until now. 

One additional word to functionality number 3:

With A6000 (and presumably A5100/A5000) this functionality does only work when the camera is switched to 'on' via its main power switch at the photo button. I don't have a dummy for the battery compartment, so I can't test how much power the camera is consuming when main power is on and camera switched of via pin 15. And I bet there is some minor power consumption when shutted off via pin 15 'soft off'. 

Why do i bet? because the camera can be woken up again via the same pin. In contrary to when the camera is shut off via the 'main power switch'. So finally lets say the camera is going into some kind of power saving mode. 

I don't have a  RX100MK2 (or any later RX100 model from Sony), but as far as I know, the RX100 (since MK2) should be completly power controllable via the pin 15 function. Why? because these cameras have a power button, not a mechanical power switch. But this is unverified, at least by myself. 

Any new findings according the Multiport protocol itself?

Yes, at least a bit:

When the video recording is strated and/or stopped via the recording button at the right back side of the camera, there is some kind of status message sent via the serial pins (find out which!).

The according bus messages are as in the following pictures from my scope:

The first picture shows the overview of the two data bursts sent by the camera. The following two pictures show the first data burst in more detail and the second in more detail.
I don't know what this means yet, but I guess these are some status messages for a connected remote control. Persumably to keep camera and remote in sync.
Sadly there are no such messages when you push the photo trigger button (half & full press) or when you operate the zoom.
I will try to check if there are messages sent out when the camera is operate via the AF pin, photo trigger pin and on/off pin, but for this I will have to modify my connector again and add some more wires.

So long for today. I will keep you all posted when I have some more findings about the protocol itself. 

At least there is the easy possibility (i.e. via teensy, or any 3.3V Arduino style board)  to shoot some photos (with proir AF trigger), use AF when recording videos and to set the camera to "power safe" when you need it.

All the best!

p.s.:
I am still interested in exchanging findings or trying some serial message suggestions if someone is keen to support. :)

I also got my DYS 3 axis NEX gimbal delivered lately. Will try to post a small build log soon, because there are a lot of parts to join with this construction kit. 

Analyzing Sony's new Multiport protocol

Hi there!

Been some time since the last post, but there was a lot to do and a lot of new ideas to follow.
As you might suspect with a multicopter like the DJI s900 I wanted to carry a bit of weight with the setup and try to hunt for some nice photos and videos. For this there is a decent camera required and at the moment I'm following the path to use my Sony A6000 (well we will see what my wife will be thinking of that ;) ). But for the time being this is the plan.
Just carrying this camera with a copter like the s900 would be quite easy. But I also would like to trigger and control the camera functionalities (zoom, video, focus, trigger) from the ground. So there is a remote control for the A6000 required.
One special thing about newer Sony video and photo cameras is the new 'Multiport'. It is looking like a micro USB-interface. But there are not only 5 USB pins built in, it also has 10 additional pins furhter back within the camera jack. These pins are more easier to recognize when you look at the plug of this "Multi"-style connector. There you have a hard time recognizing USB pins, but the 10 additional "Multi" pins are easy to see:

Sony has not also some fancy new connectors, but there was also a serial protocol called "LANC" with which you could control Sony equipment over years and years. This LANC protocol is known to hobby sites around the web. And LANC gives you a multitude of possibilities at Sony's photo cameras, video cameras and even studio equipment (VTRs, ...).
Two of the best sources for the serial LANC protocol with its inverted 5V logic levels ('1' = 0V; '0' = 5V) and a baud rate of 9600 are:

Camera remote pinout lists

'control your camera' blog

My first guess after some research was, that Sony's A6000 is also using the regular LANC protocol. And there are several projects for Arduino compatible uC-boards to make us of this documented and quite easy to address communication interface (just use your favorite search engine to look things up).
So situation seems very nice on the first glance, but my estimation for A6000 + LANC was a bit to optimistic. It turns out: A6000 does NOT make use of the older LANC protocol. It is using an new (let's call it) "Multi" style serial communication. I recognized this, after I hab tinkered a Multi plug adapter and hooked up my DSO scope to the signal lines.

But first things first before talking about the protocol. At the beginning of my journey, I had to built my Multi plug. And I want to show you first how you can achieve a quite cheap adapter cable yourself:

You will needed a Multi type connector to access the several signals of your cameras Multi port. Possibilities here are:

1. buying a comercial Multi port connector cable and introduce it to some of your knifes and pliers

2. buying a Multi port connector with a (more or less) finished brakeout PCB from this site: Link

I was hovering my mouse already above the buying button from option 2, but the connector is delivered from Slovenia (as much as I know). So delivery would have taken quite some time and my tinkering weekend was near. Sorry to the shop, but in the end I decided to order an AV video cable with the sepcific Sony connector from a big commercial plattform. It looks like in the picture below and is from a company called JJC. This cable was delivered next day.

I'm very sorry for the nice owner of the shop from option 2!
(He seems quite nice and always leaves kind and open minded  comments in some forums).

But going on, I dissected the AV cable next. The steps are as follows:

1. Cut the AV cables some centimeters behind the Multi plug (OK, i did this later on, but I think now, that it would be easier to cut the cable first)

2. Remove the plug's cable bend protection rings behind the connector (gives easier access to the rest of the housing)

3. Gently cut into the side wall of the rubber/plastic housing. You only need to cut about 3mm deep. Be careful and don't damage the PCB and connector within the rubber/plastic to much!

4. Gently spread the housing open and cut along the cables embedded at the end of rubber housing. Don't pull to much at the connectors PCB. If you pull too much you will rip off some of the PCB's pads. And you really LIKE these pads later!

5. When you have freed the connector and its PCB from the nasty housing, you can take your soldering iron and remove the small cable bits left on the pads. I also used some solder wick and scrubbed the PCB pads clean of remaining solder.

And there it is, your perfect 5 + 10 pin "Multi"-style Sony connector with a nice breakout PCB for at least some of the very narrow pitched connector pins.

With this connector and a pin layout from this side here, I soldered a connection cable for the A6000's Multi port with which you can access all necessary signal lines. Here you have to be careful: the pin numbering printed on the PCB is inverted to the numbering from the great camera pinout website I mentioned. (At first I did solder the wire with matching numbering of the pins on the PCB and the website. But meassuring the pins with a multimeter when plugged into my camera I recognized the inverted pin order.)

The final (cable fitted) connector looks like this:

Layout according to the pin numbering on the PCB of the sourced Mulit connector is:

U1	VBUS (+5V, max 2A)
U2	USB D-
U3	USB D+
U4	USB ID
U5	GND_USB
---
M10	+3.3V (MULTI_DC)
M09	reserved
M08	"UART_TX" / "LANC_SIG" (At A6000 it seems to be UART; No LANC!)
M07	"UART_RX" / "BOOT_IN" (At A6000 it seems to be UART; No Bootloader/Debug)
M06	SELECT (resistor against M01 or M09 for selecting Multiport functionalitites/protocol)
M05	Audio R out / activate camera / focussing (focus with direct trigger cable)
M04	Audio L out / release shutter (shutter with direct trigger cable)
M03	Maybe composite video out (no AV-out at A6000 known to me!)
M02	GND (identical to GND_USB)
M01	Power_On/Off (short to GND)

(This pinout was updated via the pin listing at the end of this post)

Now equipped with this cable, I was ready to set off to investigate the communication capabilities of my camera. But before poking at random lines on and switching random signals, I investigated in the dark deeps of the web if there are already some more documentations available.

On my search, I uncovered some other people who already have tackled the A6000 successfully. But sadly none who wanted to share a bit of documentation for the Multi protocol.
There are quite a number of commercial possibilites available via the web. I am quite sure my listing below is not absolutely complete, but it gives an overview about the recent sold possibilities:

Product   -> Features \/	Seagull Rec	Stratosnapper 2	CAMremote	GentWire Multi	MikroKopter CamCtrl	RC Shutter
Zoom	y	y	y	y	y	y
Photo	y	y	y	y	y	y
Video	y	y	y	y	y	y
Photo@Video	?	?	?	?	y	?
Focus	n	n	n	n	?	n
Ein/Aus	y	y	y	y	?	y
Support	y	n	y			?
Price (€)	107 (incl. cable/shipping/tax)	59 + 16=75 (+X for shipping/tax)	68+44=112 (+X for shipping/tax)	100€ (+X for shipping/tax)	~ 107€ (incl shipping & Paypal)	91€ (+X for shipping/tax)
Link	http://www.seagulluav.com/product/seagull-rec/	http://littlesmartthings.com/product/stratosnapper-2/	http://vp-systems.eu/camremote.html	http://www.gentles.ltd.uk/gentwire/multi.htm	https://www.mikrocontroller.com/index.php?main_page=product_info&cPath=110&products_id=910&zenid=drupjnjb1ca6e3vk8m0f7s5cr2	http://www.rcshutter.com/index.php?route=product/product&product_id=104

(Sorry for the bad table layout. I am not that good at html. :)  )

So with this overview you can see where the pricing is tended: Too expensive for an Arduino style controller the is just pumping out some inverted serial commands via a proprietary connector. (At least this was the first thought with false knowledge and the conviction that A6000 is using the LANC communication)

With my false knowledge, I set sail for having a try with LANC protocol. As I still have some uC boards available at home (Arduino and Teensy). I pulled up my Teensy, gathered some code and libraries and had a try...

With Teensy connected to the camera and digging out my DSO scope again for investigating the back and forth on the signal lines I discovered the first difference between the regular LANC protocol and the newer (past 2014) Sony cameras:

Sony A6000 has a logic level on its communication line (Pin 3 "MULTI_com") of 3.3V instead of 5V at regular LANC! 

The MULTI_com line was permanent 3.3V. So the camera is not putting out any data on the MULTI_com signal line at all without any external stimulation. Even when switching the camera on or off, there is no communication on the MULTI_com line.

Now when digging in the documentation of the regular LANC protocol, there is a resistor with 180kOhm mentioned. This resistor is to be introduced between the SELECT line and ground or LANC_DC (in our case MULTI_DC). I decided to connect the resistor first to ground as a more save bet for the health of the camera. And voila! The MULTI_con signal line twitched several times and ended at permanent high (3.3V) again.
The communication from the camera looks like below:

On the above screen you can see a "zoomed out" signal trace. The Camera is trying 11 times to reach a counterpart for serial communication.

One frame of this communication is in total 5.56ms in duration

This is a com frame with a little more zoom from start to end

Distance between the beginning of the com frames which the camera is waiting for a retry is 60ms

Gained knowledge:

A6000 is trying to communicate via MULTI_com signal line when SELECT line is pulled to ground via a 'x' kOhm resistor. Number of communication attempts is 11 times and we know the timing of the frames and between the attempts.

Why am I writing 'x' kOhm instead of the prior mentioned 180kOhm in LANC protocol? I recognized the following in my reengineering:

A6000 is answering more reliably on a 100kOhm resistor between SELECT line and Ground instead when using a 180kOhm.

Is it save to lower the resistor value for the camera?
Let's tackle the numbers a bit. SELECT line has also about 3.3V.
At 100 kOhm you will have a resulting current between SELECT and ground of 33 microamps (3.3V / 100kOhm). With a 180kOhm resistor the resulting current will be 18 microamps (3.3V / 180kOhm).
I'm guessing I have a tough camera that will handle this difference with ease! ;)

As my scope is equiped with a serial analyzer, I just tried my luck on told the scope to interpret the communication bits and bytes. As LANC has a 9600 baud 8N1 protocol with inverted logic, my scope delivered the following results:

Looking at the first picture above from my scope, you will see a more detailed view of one communication attempt from the camera. The transmitted data can be decoded via serial RS232 protocol with inverted logic into the following data (in hex):

[6D], [EE], [EE], [6E]

When we use the bit timing of LANC and 9600baud for the MULTI protocol, we can trace down the first byte of the first com block into the following bits:

What have we learned from the scoping above?

A6000 is most probably using inverted serial protocol at 9600 baud data rate

A6000 has a bit length of about 104 microseconds to 106 microseconds

A6000 is most probably using a serial layout of 8N1 (8 data bits, no parity, 1 stop bit)?

New finding: A6000 is most probably using a serial layout of 8E2 (1 start bit '0V', 8 data bits, 'even' parity bit, 2 stop bits '3.3V') LINK

But for the last one I am not that sure.
Maybe there are some interested people out there that have some additional knowledge of serial protocols and can support in decrypting the A6000 communication.

So what have we achieved in the end?
We gained some knowledge about differences between the already known Sony LANC protocol and the somewhat "new Sony 'MULTI'-style protocol".

And we know the new communication differs from the "old" LANC protocol in some ways!

There are no sync triggers sent from the camera when a connector is plugged in (= 100kOhm resistor connected between SELECT and ground).

(On the LANC protocol pages linked above, you can read that with LANC, the camera is always triggering communication with a start bit)

I also tried to confront the camera with a "Record video" LANC command in a 25ms pattern with the help of the following code, but with no luck. The camera din't answer or perform any actions in response.

I guess the next step is either buying one of the cheap cable remotes that mimic Sony's "RM-VPR1" remote (which can control the A6000), or just buy one of the quite "heavy on the pocket" commercial RC remotes mentioned in the first table of this article.

If someone else already has some knowledge about the new "MULTI"-style Sony protocol (which is incompatible to the already known "old" LANC protocol) I would be very glad to cooperate with other people who are interested to avoid quite expensive commercial products.

Don't get me wrong here: I would be willing to pay for a good and already functioning product some guys have invested quite some time and effort into. But my limit here would be something like 60 Euros. 100 Euro is definetly too much for my taste, when you are buying a product where the hardware is maybe something 20€ in total (PCB, ATMEGA328p, SMD birdseed and some connectors). --> :/

I will be posting any new knowledge about controlling the A6000 as soon I have more time to tinker on the camera and maybe a cheap rebuild "RM-VPR1" remote.

All the best!
Sebastian

P.S.:
Have discovered a forum post (only in german, sorry) where someone has found the official Sony names for the pinout of Sony MULTI port plug:

• 1: "VBUS" - 5V-Eingangsspannung vom USB-Host
• 2: "D-" - USB-Datenleitung (negativ)
• 3: "D+" - USB-Datenleitung (positiv)
• 4: "USB_ID" - für USB-OnTheGo
• 5: "GND" - in der Kamera mit Pin 14 ("AV_GND") verbunden

• 6: "D_3.1V" / "LANC_DC" - Ausgang für 3.1 bis 3.3V Spannung
• 7: "XRESET_REQ" - Eingang für Reset-Anfrage
• 8: "UART_TX" / "LANC_SIG" - optionaler Ausgang für serielle Schnittstelle (Debug) oder LANC
• 9: "UART_RX" / "BOOT_IN" - optionaler Eingang für serielle Schnittstelle (Debug) und Bootloader
• 10: "AD_JACK_IN" - Analoger Eingang für Widerstand zur Erkennung des angeschlossenen Kabel-/Zubehörtyps
• 11: "LINEOUT_R" / "XAE_LOCK_SW" - optionaler Audioausgang (rechts, in der Kamera über Kondensator entkoppelt) und/oder Eingang für Auslöser (1. Stufe) im Fotomodus der Kamera (und mit richtigem Widerstand an AD_JACK_IN)
• 12: "LINEOUT_L" / "XSHUT_SW" - optionaler Audioausgang (links, in der Kamera über Kondensator entkoppelt) und/oder Eingang für Auslöser (2. Stufe) im Fotomodus der Kamera (und mit richtigem Widerstand an AD_JACK_IN)
• 13: "VIDEO" - optionaler Composite-Video-Ausgang
• 14: "AV_GND" - in der Kamera mit Pin 5 ("GND") verbunden
• 15: "XPWR_ON" - Eingang für externen ON/OFF-Taster (gegen GND)

Big THANKS! to those guys on the german forum!
Attention! Pin numbering differs through the web for this plug.