Repairs_2019/Phantom3Standard_BadCamera/docs/4.tex

\documentclass[11pt]{article}
%Gummi|065|=)
\usepackage{graphicx}
\usepackage{caption}
\title{\textbf{Phantom 3 Drone Repair / Diagnosis}}
\author{Steak Electronics}
\date{}
\begin{document}

%\maketitle
\textbf{Phantom 3 Drone Repair / Diagnosis}

%\tableofcontents

\section{Overview}
User reports drone is unable to sync to mobile phone. Upon testing drone, I find that the gimbal is not able to get a proper level base. It continously moves around.
\section{Work Log}
Unfortunately a lot of my work in not in notes, although I thought I had written it down, but in any case... I've looked at this drone a bit. The issues are likely in the camera / gimbal assembly. The price of a new assembly is \$200 on ebay, and extremely expensive. The drone used is about \$240 or \$300 on ebay now (Jan - June 2019).

The pin connector that goes to the gimbal board from the drone is about 10 pins. Not bad. The ribbon connector on the gimbal, that goes to the camera is some obscene 50+ pin, double stacked monster. Not easy to decipher without schematics. There are a few motors on the camera board, which all seem to work. The issue is with the self test, at which point the drone never stabilizes. The user reported that he had a crash, but he also reported that he replaced the gimbal board.

\subsection{Open Bench Logic Sniffer}
Looking at this device in detail, it relies on a mobile phone app to work with the drone. This app doesn't work on my old phone. I tried an Ipad model one, and that didn't work either. The only phone I was able to get the app to work on was a more recent apple phone (that I do not own). So, right away we are having trouble interfacing to this device. The future doesn't bode well for this drone. What will 10 years in the future be like?

I've somewhat given up on any interest in repairing this. It's a black box, and cheaply made. Instead, I'm going to tap into the 8 wires going hetween the drone and the gimbal and just take a look. I've needed an excuse to use my Logic Analyzer for a while, and here's a good one. Let's see what / if we can learn, if anything.

\subsubsection{Open Bench Logic Sniffer Setup}
First off, I need a case for this board. It's exposed. I found two on thingiverse. Let's fire up the 3d printer and get one of those made. Looking at the two cases, they are nothing more than bottoms for the boards. Helpful, but I would've liked a top on these. A bit too rushed. (see cad folder). I'll just throw some electrical tape on the bottom, just as good as these cases.

\subsubsection{Abandoned Project?}
The github\footnote{Not a fan} repo https://github.com/GadgetFactory/OpenBench-Logic-Sniffer/issues seems to be quiet. Is the project abandoned?

\subsection{Setup Cont...}
Let's get this thing. Running. On devuan ascii (d9), follow the quick start guide here:

http://dangerousprototypes.com/docs/Logic\_Sniffer\_quick\_start\_guide
Linked from the main logic sniffer page.

It looks like the Sump program runs as a shell script (without any installation), so you can follow that page where they link to here:

http://www.lxtreme.nl/ols/

and download the latest client. Then extract, untar and run the programm. Unfortunately there is no verifcation of the tar files that I see. A bit shady. A package for a distribution is warranted here... Also looks like the Sump client is customized for Open Bench Logic Sniffer, and as a result, hasn't been updated as the project has been somewhat quiet...

\subsection{Basic Test}
The demonstrations section shows some basic tests. They use a bus pirate, but instead, you can just plug in an Arduino Uno (much easier). Here's what you do.
\begin{itemize}
\item Plug in Arduino, set it to Serial Read example, confirm that some data is being spit out.
\item Plug in TX of UART on Uno to pin 0-7 of the OLS (open logic sniffer). Also, obviously you'll need to tie the grounds together. Do that too.
\item Set the sampling frequency to be lower than the 200MHz default. Lower sampling frequency means longer sampling times, but less detail.
\item Do a sample, then go into UART decode mode in the menus, choose auto detect speed, and run a sample, making sure to assign the TX pin of the UART decode to whatever your TX pin is connected to in OLS (this is somewhat obvious, so just fool around with the program until you get it).
  \item Note that what speed works for your given application may vary. With a 9600 baud UART, I can do 50KHz sampling and get everything, but 5KHz returns garbage (seems obvious). Again, lower the sampling rate, the longer the sample.
  
  \end{itemize}

Should work. The decoding on the main time line view is poor, but the UART printout works reasonably well in its own menu.

Some things to do: enable side measurement window. And go to preferences - theme - Logic Sniffer. Looks better.

I think I've seen enough, let's try to connect it to the Drone.



\section{Drone Logic Sniffing}
I was looking at the feet of the drone, and noticed something I had not seen before. There are two wires (antennas or thermocouples) on two legs, and then on a third, there was a board, with four wires going to it. The wires appear to be synchronous SPI, as there is a GND, and an SDA, SCL wire. I plugged the OLS into this, and started recording, but then the battery died. I did realize that in order to get the sampling rate right, you'll have to first probe with an Oscilloscope, and at least look at the signal first. Then after you have an idea of what you are dealing with, you program OLS and go after decoding.

\subsection{SPI Decode}
The pins on the board indicate SDI, which is a SPI pin. Using the Open Logic Sniffer, at 1MHz speed, I am able to get 24ms of sampling. Unfortunately, this is not enough to read more than one packet. Thus, the limitations of this speed show up.

Another drawback, is that it's not seamless to re-sample, when using OLS. In order to get SPI decoding, I have to begin capture, then go into the measurement menus, and click analyze. In order to get a 2nd sample, I have to close that analyation window, and click  begin capture again, and then open a new SPI decode window. The workflow, needs work. Ideally, I could capture, and re-analyze in the SPI window (perhaps one button), without needing to click through menus. 

The limited sampling issue is addressed on the Dangerous Prototypes website:
\emph{"The major difference is that the OLS has a limited number of samples, while the hobby USB analyzers can theoretically take infinite samples. Most of our debugging is done with the first few hundred samples, so this feature isn’t usually important to our work, your situation may be different. Future versions of the OLS will definitely have more sample storage, and we can work an infinite sampling mode into a future firmware update too."}
Seems that they acknowledge this as a flaw.

In any case, I'll have to get a Saleae, I think... In order to do further testing. I'll buy one used. I don't wish to use a clone, and I can't afford to pay \$150 for one.

Let's tap into the 10 pins from the main board while we have the drone on the bench though. 

\section{Tapping into Main Wires}





\section{References}

http://dangerousprototypes.com/docs/Open\_Bench\_Logic\_Sniffer
\vspace{0.2in}

\end{document}