onsdag den 24. februar 2016

Carbon Fiber REPTILE X-Mode Alien 500 500mm Multicopter Quadcopter Frame Kit

A quick look at the Reptile X-mode Alien 500 quadcopter frame. The frame arrived nicely packed with the appropriate  screws, a battery strap and a mounting plate for a front faced camera and 4 vibration pads for the camera mounting plate. There is no manual with the shipment, so mounting is done by guess work. A very nice light frame, very easy to assemble, 


 The top and the bottom plate.

The arms are easily mounted on the top plate using four screws.


 I did not tighten the screws entirely until the bottom plate was mounted

 The CC3D was mounted on a CC3D Atom Flight Controller Anti-Vibration Damper Shock, this damper is a little too tall to fit under the hood as the wiring becomes an issue. The header pins from the ESC's were not able to fit without bending. I ended up removing the housing of the header pins and isolating each cable with heat shrink and mounting each signal cable on the CC3D.




 The dampening plate was mounted using plastic screws, these are of coarse not supplied, so you need to have hese lying around

 Very little space between the top plate and the CC3D header pins if you use the

 The bottom plate is mounted using two screws on each arm.


 The rig is very light, with only the flight controller mounted, it checks in 346 grams.


 The motors fit on the mount arms with no hassle, I did find the Hobbykings NTM 28-26 1100 motors had to be turned 90 degrees to mount all 4 screws. This meant that the wiring from the motors stuck out sideways, whilst the Sunnysky motors could be mounted so the wiring was parallel to the arm.


 A normal sized ESC fits  very neatly on the arm.

 A word of advice, always REMOVE your props when testing indoors, once again i failed to adhere to this and ended up cutting up my fingers on the props, while configuering the quad.

 What to do, if you don´t have any plaster to take care of your injuries. Gaffa tape and toilet paper can also take care of things.
i will post a few more photos of the finished product

Mounted a red LED lighton the right side for orientation purposes and a blue on the left



 The carriage is mounted with a white LED

 The battery is strapped down on top of the frame

The reciever is mounted with velcro to keep it from moving around




søndag den 7. februar 2016

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. 

onsdag den 3. februar 2016

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.