I’m using Samsung NX1000 for aerial photography. The camera has a nifty feature of using smartphone as a remote viewfinder and shutter release but unfortunately the good idea is watered by buggy and limited program and the feature freezes the whole camera all too often. Fortunately there is a simple way of triggering the shutter via cameras usb-port. The trick is to have 68K resistor between ID and GND pins. After this USB data lines can be used to trigger camera focus and shutter.
Tip: If you have spare micro-usb cables, it’s easy to source a connector from the cable that came with the camera. Just squeeze black plastic around the connector with a pliers and the plastic casing will crack open exposing the connector. The connector on the cable has a small pcb, which makes it easy to solder the required resistor in place. If you use smd resistor, the casing can even be reassembled.
The cable described above works fine for manual use, but to use the camera for aerial photography some interface for rc receiver is needed. Fortunately this is easily achieved with a small arduino program, which reads pwm value from receiver servo port and then pulls either shutter or focus line low based on channel value. The compiled code size is under two kilobytes, so it’s possible to use small and inexpensive microcontroller like AtTiny2313.
The schematics and sources can be found at: https://github.com/JanneMantyharju/nxshutter
Compatible with (at least) following models: NX20, NX210, NX1000, NX1100 and NX2000
As with other hardware in this blog, if you need one and don’t want to make one yourself, drop me a message and we’ll see what we can do!
Update: If you don’t want to make your own, I’m selling these ready made. Just drop me a message.
My usual setup when flying FPV is to have laptop running mission planner with image capture running. This works quite well, but forces me to stand in one place to see the picture, so I wanted something more mobile. I came across Procaster DTV-007 digital TV which at 45 € price is a real bargain. I wondered how to mount it with the controller, and my father came up with an idea to machine a mounting piece that would have a slot for the controller handle.
I drew the mount as two parts, first has a slot for Auroras handle and the second has t-slot for the display. Parts fix to each other with two screws. The part was machined in G-Tronic, where they optimized the part to a single piece. Overall, I’m happy with the results, the mount is very compact and stable in use.
Since there’s now machining files for this part, the design can be replicated easily if someone should need similar part.
In my previous post I described building adapter which converts APM telemetry data to be shown on Hitec Auroras screen. Since then APM2 hardware has been released and some code changes made previous version unusable. I updated the hardware and software to support also APM2. I couldn’t get SPI transfer to work in APM2, but fortunately it has a spare serial port to use. The good thing is that now only three wires need to be connected to APM2 and nothing needs to be soldered.
APM1 is still supported, wiring instructions are in the previous post. When using with APM1, USE_SPI must be defined in main.cpp.
This version also includes support for showing GPS coordinates. Previously I thought it’s not really useful feature, but I changed my mind after searching for crashed plane in wintery forest in the light of the setting sun for a long time. Coordinates would have been useful after all. Time and Date are still unsupported since APM internal date format is yet to be decided.
Sources are uploaded to github: https://github.com/JanneMantyharju/apm-hss-emulator
Update 5.1.2013 – Error in schematic corrected. Added fet to power video transmitter after GPS lock has been acquired.
Update 7.1.2013 – Kind of a long shot, but if somebody wants to borrow me a Spectrum or Graupner system, I could modify the device to support different telemetry protocols.
A while ago I was asked to keep a small presentation about my plane in the workplace event. Here’s the slide set that I made for the presentation. Pictures can be borrowed to other uses, as long as you credit me.
I thought to gather here few of my experiences while making my own transmitter / receiver. The project started after I finally moved to 2.4 GHz technology by purchasing Hitec Aurora transmitter. One near crash later I learned that 2.4 GHz controller and 2.4 GHz video transmitter don’t play well together. Since here in Finland 2.4 GHz band is just about the only band available for video without amateur radio license, I thought to replace Aurora’s transmitter with something different.
After a little bit of googling I bought development kit XBee-PRO 868 RF-modules. They are a near perfect fit with 80 km range and data rate of 24 kbps. The kit was very complete to get started, it contained two modules, one with “rubber duck” antenna and one with wire antenna. Two interface boards were also included, one with serial interface and the other with USB. To save some time I decided to use USB-board on my ground station.
The modules have few quirks though. Receiver on the modules gets saturated easily, so during takeoff and landing, TX power must be lowered. This can be done in command mode, but unfortunately while in command mode, it’s not possible to send data. I don’t find this a problem in level flight since changing the power takes less than half a second. Another thing to note is that duty cycle of transmitter is limited to 10 %. This means that if data is transmitted faster than 2400 bps, after certain amount of time, transmitter is shut down for a while. Fortunately this can be circumvented by resetting the module periodically. Initially I reseted the module by issuing reset command, but I found this problematic since entering the command mode and issuing reset takes again about half a second. While it’s not much it can be very annoying while flying. I found that much faster way is to make micro-controller on both rx and tx side pull module reset line low briefly. This way the reset takes only about 100 ms.
Since the XBee module is quite small, it would be easy to fit it to Aurora’s module slot. Instead I decided to fit all the parts in my ”ground station” to a single box to minimize number of wires and components that can be forgotten to home when heading to airfield.
The components in the box are show in the diagram above. Stick positions are received from controller via student port and decoded by micro-controller and send to PC to be processed. Two of the available channels are used to toggle tx power and video recording and they are not being sent to save bandwidth. There is also some threshold so that insignificant position changes are not sent. PC encodes stick positions to packets and sends the packets to XBee modem.
Video received from the plane is splitted to video glasses and to video capture device connected to PC. On the PC side, live video is displayed on-screen and optionally recorded. Various data can be overlaid to video. Currently only battery voltages are show, but I’m planning to add gps to the receiver and implement location tracking to get rid of EzOSD I’m currently using.
The receiver itself is pretty simple. Atmel AVR micro-controller interfaces with XBee-module and decodes transmitted packets and creates signals to drive servos. Pushbutton on the receiver can be used to save failsafe servo positions. Currently three of five ADC channels are in use. They monitor signal strength, main battery and camera battery. During one of the range tests I noticed that ESC on the plane could not reliably provide enough power for the receiver, so I added switching regulator to draw power from the main battery.
The completed system works well enough to start adding features to PC program. The frame rate is certainly not comparable to commercial radio control systems, but fast enough for stable plane like the Twin Star that I’m using. On the plus side, transmitter has more than enough range and the whole system is quite simple and could be build very cheaply if one would omit PC and video capturing.