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://gitorious.org/nxshutter/nxshutter
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!
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.
A while ago Farnell sent email to me and offered one (inexpensive) product as a sample in exchange for mentioning it at this blog. I browsed for a while for an interesting part and settled with Microchip MRF24WB0MA/RM WiFi module (Order code 1823142). This module is quite inexpensive and is used in products like WiShield and thus has good Arduino support.
I wanted to upgrade my electricity meter to communicate with WLAN to get rid of XBee receiver at the back of my server. After some prototyping I ended up using RN-XV module from Roving Networks. Since my application did not have to do any fancy network stuff, RN-XV was a perfect match. It has the same footprint as XBee module, which I was already using, so the hardware required no changes. The module supports WPA2 security and can remember it’s settings. Communication via HTTP request is incredibly easy, I set up the module to generate http request to my home servers address each time when AtMega output measurement data.
Unfortunately some thing are just too good to be true. The module soon proved to be quite unreliable. Each time after about 14 hours of operation the module lost connection to accesspoint for ever. I tried to solve issue with technical support. By default if module looses AP, it does not try ever to reconnect unless linkmon parameter is specified, which to me is quite braindead default setting. Even with the linkmon RN-XV did not work for long with my Cisco AP. I tried everything including rebooting the module every hour, adding commands to force reconnect and even doing hardware reboot to the module, but without much success. Eventually I changed the RN-XV to connect to different AP. It still looses the connection every now and then but it’s able to reconnect after random time. Still in every 24 hours the module is unavailable for about total of 3 hours due to lost connections. RN-XV firmware version I have is 2.36.
In the end, only changes I made was to modify server backend to accept HTTP requests and change the code running on the AtMega to output measurement data periodically instead listening request from XBee.
The RN-XV was configured with following commands:
set ip dhcp 1 # get ip from dhcp
set wlan auth 4 # use wpa2-psk encryption
set wlan phrase password # set network password
set wlan ssid network # set the name of accesspoint to connect
set wlan linkmon 5 # After 5 tries declare connection to AP lost and try to reconnect again.
set ip proto 18 // turn on HTTP mode=0×10 + TCP mode = 0×2
set ip flags 0×6 # close tcp connection if accesspoint is lost
set ip host ip # server ip address
set ip remote 8080 # server port
set com remote GET$/? # GET string to be sent to server. Any data from uart will be concatenated to this string
set uart mode 2
All in all, for simple projects, I can really recommend the RN-XV module over the MRF24 due it’s simplicity, but definitely not for reliability. Both modules cost about the same, but apart from Sparkfun I don’t know who else has them in stock. Farnell could start selling them, since ordering from Sparkfun can get expensive if you don’t live in the states.
Sources can be found from the repository: https://gitorious.org/home-automation/home-automation
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 gitorious: https://gitorious.org/apm-hss-emulator/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.
After completing the home electricity meter hack I looked for options to have small display hanging on the wall, which would show useful information. I had previously bought Samsung SPF-87H photo frame which can be used as an external monitor. The frame connects to computer with usb and the picture is updated by simply sending it in jpeg format. Few caveats are that display needs to be first initialized to “mini monitor”-mode and the picture size must match exactly to the display resolution (800×480 in case of SPF-87H). I chose Beagleboard as the embedded computer to keep the power usage low. BB has one usb and one usb-otg port. I’m planning to change the Beagleboard to Raspberry Pi, when they became available since this doesn’t use all the resources provided by the Beagleboard.
Even that the Beagleboard has only one true usb-port, I did not need to add the usb-hub to setup, since the usb-otg port can also be used as host. The display connects to otg-port, since it has it’s own power supply (otg-port can’t supply power) and the regular usb port is used for wlan adapter.
The photo frame has desk stand but no hole to hang it on the wall. This was fixed by using hot glue to attach a piece of wire to the backside to act as hanger. I learned later that I should have made a loop to the both ends of the wire to increase gluing surface. The frame dropped to floor after couple of days, resulting small crack to bezel and a dent to floor. Fortunately the display continued working.
The finished display looks quite nice. The Beagleboard and the power supply are hidden on top of cupboard and the display cables are hidden inside cable duct.
The software “WallDisplay” running on the Beagleboard is written in C++ and uses Qt. The software simply reads Sqlite database, which contains a list of urls and time, how long the url is displayed on the screen. The web pages are loaded to QWebPage and its contents are exported as jpeg file, which in turn is pushed to the display. Qt’s webkit implementation has too many ties to the user interface for it to be used as command line QtCore-application. Since the program does not have to actually show anything on a real monitor nor accept user input, I’m using xvfb to simulate X-server. In future I’m planning to add web interface to make it easier to manage the displayed pages.
Currently the display is rotating following pages:
- Electricity usage
- Weather forecast
- Calendar, exported from iCal
- Irc log from the channel we used with my friends
- Last picture from the security camera
The sources are available at: https://gitorious.org/home-automation/walldisplay
You also need to install software for controlling the display from here: https://github.com/Gekkio/samsung-photo-frame-ctrl
See rc.local file for an example how to run the application. Path to database and path to frame-ctrl program must be given as arguments. The database creation command is in the readme.txt file.
I wanted to gather statistic about the electricity usage at my new house, mainly to see how much using the fireplace lowers the bill. The meter installed by the utility company has a led that blinks at the speed that is relative to the usage. Text on the meter says that 480 blinks equals 1 kWh used. I thought that building a device that keeps count of these blinks should be easy enough to make. I used photoresistor attached on top of the led with blu-tack. This way the measuring circuit is isolated from the mains and the setup doesn’t require tampering with the meter. The led on the meter is not very bright, so the circuit is quite sensitive to ambient light, but works reliably when the cabinet enclosing the meter is kept closed.
The schematic for the device is quite simple:
Currently I’m using XBee to communicate with the server which gathers the measurements. The meter itself is at the utility room, which is too far to run cables to. I’ve already bought XBee pinout compatible wlan transmitter to get rid of the XBee eventually.
In the circuit, analog part on the left turns value of photoresistor (R3) to digital signal read by ATtiny2313. Sensitivity of the photoresistor is changed with the variable resistor R5. The avr responds to two commands (in current code “LUKU” and “VALI” translation would be “COUNT” and “INTERVAL”). Count simply returns number of blinks since the last count command. When read periodically, electricity usage can be calculated from the number of blinks and the time used to count them. Second command returns the time between two last blinks, so current consumption can be calculated from that.
I’d like to show the picture of the setup, but currently I’m using circuit boards from the past projects, one has the avr and the other contains the XBee, so the setup is quite messy. I’ll create custom PCB as soon as I get the wlan transmitter working. The attached AVR code is also quite messy and currently compiles to ATmega8. It could be easily ported to ex. Arduino if needed.
The server part consists of two scripts. Measurer.py runs constantly and queries the device every 5 minutes and records the consumption to sqlite database together with temperature, which is parsed from the web page provided by local university. It also provides unix socket for the second script to query current consumption and temperature.
The second script, show_graph.py is meant to be run by web server. It returns graph about the usage and the temperature as png picture. Cgi parameters (to, from, interval) can be used to get graph about specific time period. Interval is used to set time in minutes for how long period of measurements are averaged. I’ve found it useful in winter time to average measurements for at least an hour, because on shorter periods consumption varies greatly based on how many heaters are running at the time. The variance makes it hard to understand what is going on and to compare the usage.
All project files are available at Gitorious: https://gitorious.org/home-automation/home-automation
Wall display for showing the graph: http://antibore.wordpress.com/2012/03/05/info-display-for-home/
I updated my charged to balancing one a while ago, but for some reason I didn’t buy one of those new multichargers, which pack a number of separate chargers in to one device. I use two 3S battery packs in parallel configuration on my plane and I have three sets of those. After a day of flying, charging six 3S packs separately is a long and laborious task. Since my charger can handle 6S packs, I thought why not to make an adapter cable to charge two packs at once. Since all the cells are rated the same capacity, charging 2x3S packs in essentially same than charging one 6S pack.
The following cables were build:
First adapter combines balancing leads from two packs to one connector. If you look closely, you can see that the ground wire is a little wriggly. When soldering the cable I did not think it all the way through and connected ground wires from both connectors together. When I connected the batteries, one of the ground wires vaporized with a loud pop. So be sure to leave second ground wire unconnected (pin 1 of the 2nd connector).
Second adapter is more obvious, it just connects the two packs in series. I suggest to number the battery connector which ground wire goes straight to the charger with number one and also the balancing connector which has ground wire connected as number one. These numbered connectors should be connected to same battery.
After connecting the batteries, set your charger to double voltage that the rated pack voltage (22.2v in this case) and charging current to the same as the rated charging current of the pack. It does not matter whether the packs are as empty or not, since the individual cells get balanced (although if there are big differences, balancing seems to take time at least on my charger). All that matters is that both packs have the same capacity and can handle the same charging current.
You can also make the same kind of adapters for 2S batteries, or even for the batteries more than 3S. The only limiting factor is that how many cells your charger can support at one time.
Schematics of the adapters:
My friend was moving to a new apartment and gave me broken LG 32LC46 flat panel television, which was only been in use for a little over a year before going dead. I googled that model and discovered that most probable problem is the poorly designed power supply in the television, so I decided to try repairing it.
When inspecting the PSU board, three capacitors could easily be seen broken from their swollen caps and leaking electrolyte.
All the faulty capacitors were of value 2200 µF / 10v. I replaced those with 2200 µF / 16v low ESR-models which I had on hand. After this, the tv started working without problems. Of course this does not solve the original overheating problem, so I probably need to do this again sometime, but with the annual upkeep, 6 € for capacitors is not that bad for otherwise free tv.
I’ve been wondering, what would be the easiest way to route telemetry and commands from APM to Internet. Using 3G modem, would provide almost unlimited range (I know there has been some discussions about this in DiyDrones forum. Here in Finland the GSM network is very covering, but due the way the cellular towers are optimized, maximum altitude where the connection works is probably less than 200 m.)
In theory, list of required hardware is not long. One just needs to receive messages from APM and encapsulate them to UDP packets and send via 3G modem and vice versa. Unfortunately handling PPP communications is too large task for simple microcontrollers. I ended up using BeagleBoard for the sake of easy development and since I had one at hand. I realize that BeagleBoard (which essentially is full computer by itself) is an overkill, but it’s not very heavy and fits easily inside Maja’s fuselage. Basically any embedded system, capable of running linux and acting as an usb host would do. Maybe in the future I figure out some additional tasks for BeagleBoard to do.
The software that handles the communications is a simple Python script. Since APM has no onboard configuration interface, the program fetches configuration at start-up (and every 5 minutes) from URL, given as parameter. Currently configuration consist on ground station IP-address and port. Since typically ground station is connected to internet with 3G modem, it’s IP-address is not fixed. Current address can be then updated to the configuration file and file uploaded to some known server.
When the script is running, it simply listens to serial port and when it receives valid MavLink packet, it sends to to ground station and vice versa. I made couple of fixes to UDP handling for APM Planner. By the time this text is published, modifications should already be included on the latest version (without the fixes, connection usually fails when Planner queries parameters from APM and expects to get those in a numbered order, but with UDP, packets may arrive in random order)
Hardware wise setup is very simple. Beagleboard needs to be powered from 5v source. Due to 3G modem, power demand is very “spiky”, so regulator must have enough power output (big enough capacitor helps too). I connected APM telemetry port to BeagleBoard main serial port. Since Beagle has standard RS-232 levels and APM uses +3.3v logic, I used common MAX3232 driver between those. The downside is that console on BeagleBoard’s only easily accessible serial port must then be disabled. Be sure to do this only after you make sure, you can connect to Beagle via internet.
It’s also possible to use second serial port on Beagle. It’s however not enable by default and enabling requires compiling new kernel. Second serial port uses +1.8v logic, so level shifter is needed.
- Script to connect using 3G modem
- Script to bring up interface at boot and reconnect if needed.
- Disable console on serial port
- Place configuration file on known server
- Script to launch MavProxy at boot
- Connect ground station to net and check it’s ip
- Update ip to configuration file and upload it to specified server
- Power-up the plane and wait until it BeagleBoard boots up (Usually 3G modems have some kind of indicator light notifying when it’s connected. You can use this to check when the plane is ready)
- From APM Planner, select “UDP” as port and press connect (Plane must be sending data at this point)