As a good friend of mine, Ville Kotimäki (who is also an excellent photographer btw) just finished his PhD, some figuring out some present to give was in order. I got an idea to machine some really solid piece out of aluminum and engrave it with text. I also wanted it to play something, as it seems to be a recurring theme for me.
The initial idea was to build a fire alarm siren inside an aluminum container, which would be welded shut and would only have ON button, but no means to turn it off. The idea was shortly scratched because also I would have to listen to it. The second iteration was to make the container read out the thesis like an audiobook.
Fortunately I managed to recruit my friend Heikki to do all the laborious tasks. We started by downloading the thesis pdf. The pdf was converted to text and Heikki did they most annoying part of the project by cleaning the text files from badly converted items like equations, picture captions and tables etc. In the meanwhile I tried a few different speech synthesis programs. I would have liked to use some open source software, but most of them sounded like Stephen Hawking on a bad day.
The commercial Nuance was far superior to everything else I tried. Nobody seemed to have a license for it but there is a nifty feature in OS X that it has text to speech support by Nuance and from system preferences menu you can even download additional voices from Nuance. Heikki proceeded to write a script, which splits the text file to single pages. These pages are then converted to speech with “say” command in OS X and resulting AIFF files are converted to WAV files suitable for wav library we used in Arduino.
The container itself was first drafted on a piece of paper. The measurements were dictated by the speaker we used (diameter 66mm) and the fact that on the inside there are speaker, 9v battery and power switch on top of each other. My brother machined the container shape from solid aluminum with a manual lathe from the drawing. Engraving and machining of the legs and drilling the bottom to let the sound out was designed with Alphacam software and machined with Haas UMC-750 5-axis machining center at my company G-Tronic.
I thought the engraving would be an easy job with Alphacam , but it turned out that the post processor which generates code for the machining center from cad drawing had a few nasty bugs resulting the tool occasionally to go through the work piece. Eventually I had to resort the help of professional machinists at the company, but (or because of that) the finished product looks great! The black effect on text is achieved by coloring it over with a black sharpie and wiping it over with a tissue dipped in acetone.
The schematic for the device is really simple. SD-card is connected in parallel with ISP interface to ATMega328p. Since SD-cards operate with 3.3v voltage, LM328 regulator drops voltage from 9v battery to 3.3v. BC547 transistor acts as a extremely simple audio amplifier, switching 9v voltage to speaker commanded by processors pwm output. Not and audiophile solution but works surprisingly well in this case. Since Heikki wanted to learn some electronics, I just drew the schematic in Eagle and left him the job of figuring parts arrangement on the stripboard and soldering the parts together.
We had a great trouble with the first version. We tried to use LD1117V33 fixed voltage regulator. When measured, it outputted solid 3.3v but the ATMega just would not start to execute the code. The thing worked without problems when powered with PSU. Only explanation I can think about is that the regulator starts to oscillate, but when we checked the output with oscilloscope, there was nothing obvious visible. In the end we exchanged the regulator with trusty old LM328 and the problems went away. The circuit draws about 170 mA, which translates to roughly 3h of usage from 9v battery, but we figured out that no sane person wants to listen this for more than couple of minutes at the time. Note that the connector SV2 pinout is not the same than SD-card pinout! For example how to connect the SD-Card to avr, see here.
The firmware itself is quite straightforward, the only difficulty was the user interface since there is only a power button and we did not want the device to start at the beginning of the book each time. We also wanted a couple of different voices to read the book. On the SD-card, audio files are saved with file name pattern <page (number)>-<voice (number)>.wav. When the device is turned on, it randomizes one of the three voices to use. Each time it finishes playing one page (one file), it saves the next page number to eeprom memory. When device is turned on, it starts to play from the saved page. If the device is turned off before it finishes to play back one page, the counter resets to the beginning of the book. There’s even a nifty page turn sound saved in every other file.
When we initially tested the setup on Arduino UNO board, we used TMRPCM library. It worked well, but on the final hardware, we used the internal 8MHz oscillator instead of 16MHz crystal and found out that the library does not support other that 16MHz clock speed. We changed the library to superior SimpleSDAudio, which enabled us to use 31.250 kHz sampling rate @ 8 Mhz. The library seemed also to have smaller compiled size, but that was irrelevant to us since we are only using 10k of 32k code space.
- Source, scripts and schematics are available at: https://github.com/JanneMantyharju/thesis-grenade
I was really happy with the finished device. Some Ville’s friend dubbed the device to “Thesis Grenade”, which is quite accurate by the looks of it =) The video below is a little bit repetitive, I tried to demonstrate the different voices used, but the random generator decided to use one same voice for many times.
I needed a tool that can play back recorded serial stream “in real time”, so that the playback perfectly reflects the stream that was originally sent. Rather than building my own, OpenLog project seemed to be a perfect starting point. The board itself is very small, about the size of a micro-sd socket that is on the bottom of the board. By default the device records serial data received to standard ftdi-pinout serial port. The device is Arduino UNO compatible and code can be compiled and uploaded with the Arduino IDE. The device is configured by editing CONFIG.TXT file on the sd-card. If the file is not present on the card, the device creates one with default settings at the startup.
Example of config file:
As you can see, I added the timestamp option at the end. If this option is enabled, each received byte in the log file is prefixed with 4-byte unsigned long timestamp. The timestamp is in little endian order and in milliseconds. Unsigned long type provides about 55 days before counter rolls over. The value can be decoded for example in python with struct.unpack function:
buf = f.read(4) timestamp = struct.unpack("<L", buf) char = f.read(1)
The logged files will be four times larger than without timestamping, but with large sd-cards this does not really make a difference. I quickly tested the performance and the device still seemed to be able to log the data without data drops at 115200 bps speed.
The python script that plays back the stream in real time can be found from the examples folder.
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
Update: If you don’t want to make your own, I’m selling these ready made. Just drop me a message.
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=0x10 + TCP mode = 0x2
set ip flags 0x6 # 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://github.com/JanneMantyharju/electricity-monitor
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 Github: https://github.com/JanneMantyharju/electricity-monitor
Wall display for showing the graph: https://antibore.wordpress.com/2012/03/05/info-display-for-home/
Every now and then it’s good to pack light and leave the laptop at home and just enjoy flying. Running out of battery at inconvenient time is however a concern of mine. I just recently finished a project to display telemetry data from APM on Aurora’s screen. I’m not particularly proud of the technical side of the implementation, but this seems to work fine.
Hitec’s Optima receivers interface with “Sensor station” via I2C, receiver being the master. APM has I2C-bus and it should support multiple masters, but I could never get it working reliably. My solution was to use ATMega88 to receive data via SPI from APM and relay the data to forward by answering queries send by the receiver. I originally considered tapping to xbee wires and decoding mavlink to get the data. This would however meant more work and I’m lazy.
Good things in this approach are that I can more flexibly get internal data from APM (not limited to data provided via mavlink messages) and the device can be used to extend APM (like add digital outputs etc). The downside is, that this requires changes to APM code and soldering couple of wires to oilpan, since it does not have connectors for SPI.
The circuit itself is really simple, just the avr, two resistors and a decoupling capacitor.
The prototype is constructed to stripboard. Atmel ISP-connector is also used to connect the board to APM and the other connector is for the receiver. If there is interest, I can provide these devices constructed to decent pcb, with needed wires and programmed controller.
All the information that the sensor station suppors is emulated from the data from APM, even including fuel meter, which tells how much mAh are remaining from the rated capacity of the battery. The only thing that I haven’t implemented is GPS position and time, since they are not really useful without a map (except maybe when the plane is lost). One nice thing in Aurora is that you can rename temp and rpm labels. I’m using rpm-1 value for mAh’s used and rpm-2 for airspeed. Temp-2 is used to show the current throttle (0-100). Temp-3 and 4 are still left for some other data.
I’m really happy to get this working, since all the important data is available from transmitter screen with one glance and since the APM sends the data via xbee, this is a nice to have backup feature.
Sources are uploaded to github: https://github.com/JanneMantyharju/apm-hss-emulator
The code probably will have bugs on altitude and speed reporting, I haven’t yet tested it on flight due to bad weather. I’ll try to update it soon.
Read the comments from ReadMe.txt file. The included Makefile probably work only on OS X. I had trouble finding decent Makefile that could compile AVR code on commandline, using libraries from Arduino. There is hex file included ready to be flashed. When programming the controller, remember do disable the fuse that divides internal clock by 8. The code needs to run at 8MHz.
Connecting board to APM
Three wires must be soldered to OilPan shield, marked in the picture above. Power, either 3.3v or 5v can be taken where you want, but one option is to solder I2C pinheader to OilPan shield and take power from those.
Please, drop a comment if you build this device. Patches to improve the code are also welcome!
[Update 10.5.2012] Code now supports APM2 and GPS coordinates. More info here!