Tuesday, 28 April 2015

Using a Pebble Watch as a Remote Shutter Release

I recently visited the Lake District for a short break. It's a place famed for its beautiful scenery, so I had to take my DSLR camera with me. I also wanted to be able to have pictures of myself against the scenery -- without having to go via the often-tedious route of the camera's countdown timer. This gave me the idea of using my Pebble as a remote shutter release for my Canon 60D. With no pre-packaged solutions readily available on the internet, I decided to embark on yet another DIY project.

There's an easy way to do this: buying a USB OTG adapter for your phone and plugging into your camera's USB port. However, not all phones have USB OTG support. If your phone does not have OTG support, I'll also be covering a second method that requires purchasing components and soldering them together. Both methods will use Tasker and Pebble Tasker.

USB OTG cable:
To use this method, you'll need an Android phone capable of hosting other USB devices. You'll then need a USB OTG adapter, and your camera's USB cable. Once you have the correct cables, you'll need to install Chainfire's Remote Release application. This will allow you to control your camera's shutter from your Android phone. In order to take advantage of this from your watch, we'll be making a Tasker task to trigger the shutter release. The Remote Release application doesn't include native Tasker support, so we'll simply simulate a screen touch to make things work. My phone is rooted, so I used shell commands (details here) to avoid having to install further plugins to Tasker. If your phone is unrooted, you'll likely have to find and install plugins to simulate a touch action (some people are reporting that the shell command method works on unrooted devices).

On my Nexus 5, the shell commands looked like this:

Once that's done, all you have to do is add the task to Pebble Tasker so that it can be activated from your watch.

DIY 3.5mm cable:
If your phone doesn't support USB OTG, or you want an alternative method that will keep your phone's MicroUSB port free, you can also build a cable that plugs into your phone's 3.5mm audio socket on one end and into your camera's remote port (2.5mm in my case) on the other end. This method uses an app called DSLR Remote.

The instructions for building the cable can be found here. I went with Variant A using optocouplers. The linked guide uses SFH 610A-4 optocouplers, but I ordered 10 PC817 optocouplers for £1.70 and they have the same pinout. I also ordered a 3.5mm male to 2.5mm male cable instead of buying a separate 3.5mm jack. If you do the same, make sure you scrape off the coloured insulation on the cable wires before soldering them to the optocoupler terminals. Here's what my (messy) cable looks like:

DSLR Remote also doesn't have native Tasker integration, so follow the same instructions as in the USB OTG method to create Tasker tasks for simulating the appropriate screen touches in DSLR Remote.

With the help of my Pebble, I was able to take cheesy photos like this:

Saturday, 14 March 2015

The Misunderstood Smartwatch

I bought my first smartwatch -- a heavily-discounted Sony LiveView -- in 2011, while I was still in school. Since then, I've been regularly asked why I'd spend so much money on a watch when I already have a smartphone, and, more recently, why I'd choose a Pebble over a prettier Android Wear device. I've come to the conclusion that this is because most people don't understand the best way to gain utility from a smartwatch, and this is only made worse by the actions of the majority of current smartwatch manufacturers.

Many smartwatches are trying to be too much. That's an unusually technologically conservative comment from me, but I feel very strongly that a smartwatch should be a simple extension of one's main device. When I bought the LiveView, I simply wanted to be able to read my text messages from friends during the school day, without risking trouble by getting my phone out in class with every vibration from a new notification. Yes, this was a 'bad' justification, but I'm still using my current smartwatch for essentially the same thing. I receive hundreds of notifications every day; owning a smartwatch allows me to glance at my wrist for two seconds to determine whether or not the notification warrants me unzipping my jacket and taking out my phone to respond. This is a small convenience that, over time, leads to a very significant utility gain.

Most smartwatch manufacturers have opted to go without hardware buttons, and this is a huge mistake. I'm able to control my music, my laptop, and my lights from my watch without having to look at any screens. Having a wrist-mounted remote is another small thing that can make a large difference with daily use. Apple's Digitial Crown is something that's laughed at by many Android fans, but it's one of the redeeming features of the Apple Watch in my opinion. I have no intentions of buying a smartwatch without hardware buttons.

The Pebble does both of the above very well. Its transflective E-paper screen has excellent visibility in all situations. Its four hardware buttons mean I've got a range of 'blind' control over my connected devices. This, combined with the fact that the Pebble is a good 'dumbwatch', is why I remain with it when beautiful smartwatches like the Moto360 and LG G Watch R are available. It's a good 'dumbwatch' because I can keep it on 24/7 - I wear mine to bed and in the shower. The fact that the screen is always-on and the battery lasts a week means that I don't have to worry about my watch becoming a simple bracelet during the day. The Pebble gets it right. A Pebble with a full-colour circular display would be my ideal, but the Pebble Time Steel looks like a good compromise for now.

If you find yourself asking why you need a smartwatch, the answer is that you don't need one, just like you don't need a smartphone. But after you've correctly used one as an extension to your phone, you'll always want a smartwatch.

Thursday, 29 January 2015

My DIY Automatic Wake Up Light

Every year I notice that I have little issue waking up at 7am during summer months, yet waking up at 8am during winter is always unpleasant. Some quick research led me to find that the body is gradually woken up by light, which is why products such as the Phillips Wake-Up Light exist. However, with  a starting price of £60 for the (very) basic version, I've opted to make my own smartphone-connected, automated wake up light instead.

My aim was to create a setup that could automatically turn on a bright light 20 minutes before the next alarm on my phone - something that I could 'set and forget'. Simple solutions are always favoured because they're usually cheap, so I decided to go with a desk lamp connected to a timed mains switch. This unfortunately means that there's no dimming of the light. For the phone-based automation, I chose Belkin's WeMo WiFi timed switch (£30 from Maplin). There are cheaper Chinese alternatives available, but my research found them to be lacking in third-party support. I then decided on getting a 5000K lightbulb, since that's apparently a close match to the colour temperature of summer daylight. I found a 50W (200W equivalent) fluorescent spiral bulb on eBay for £5. I've already got a standard E27-screw desk lamp, so the total cost for this project was £35.

The desk lamp (with the huge daylight bulb fitted) is flipped to on, then plugged into the WeMo switch, which is connected to my WiFi network. This allows me to be able to turn the lamp on and off from my phone. Getting the automation working correctly was a bit more difficult.

Belkin's WeMo Android app is very basic, with a slow interface and no Tasker integration. I decided to use WeMoWay, a fast and lightweight alternative with (buggy) Tasker integration. WeMo Manager also has Tasker integration, but it's not free and, unlike WeMo Way, would require a second always-on server device for my plans to work correctly. I wanted to make sure that everything would work even if my internet connection went down, which is why using services like IFTTT was out of the question. I've had to install three other plugins to get everything working as I like: AutoAlarm, Taskkill, and WiFi Connect. The last two are used to get WeMoWay Tasker integration working reliably; AutoAlarm is used to get the time of the next alarm in Android.

We'll first of all want to create a task that checks when the next alarm is and then sets two custom variables for 20 minutes before that alarm (to turn on the lamp) and 10 minutes after (to turn off the lamp and clear the variables). I'll simply be copying the task description and adding screenshots along with a brief explanation of what the task does.
CheckNextAlarm (13)
A1: Wait [ MS:0 Seconds:30 Minutes:0 Hours:0 Days:0 ]
A2: AutoAlarm [ Configuration:No configuration needed Package:com.joaomgcd.autoalarm Name:AutoAlarm Timeout (Seconds):5 ]
A3: Wait [ MS:0 Seconds:1 Minutes:0 Hours:0 Days:0 ]
A4: If [ %seconds > 2 ]
A5: Variable Set [ Name:%seconds To:%TIMES + %seconds - 1200 Do Maths:On Append:Off ]
A6: Variable Convert [ Name:%seconds Function:Seconds to Date Time Store Result In:%Nextalarm ]
A7: Wait [ MS:0 Seconds:1 Minutes:0 Hours:0 Days:0 ]
A8: Variable Section [ Name:%Nextalarm From:12 Length:5 Adapt To Fit:Off Store Result In:%Nextalarm ]
A9: Flash [ Text:%hours Long:Off ]
A10: Variable Set [ Name:%seconds To:%seconds + 1720 Do Maths:On Append:Off ]
A11: Variable Convert [ Name:%seconds Function:Seconds to Date Time Store Result In:%Afternextalarm ]
A12: Variable Section [ Name:%Afternextalarm From:12 Length:5 Adapt To Fit:Off Store Result In:%Afternextalarm ]
A13: End If

This queries the phone for the time until the next alarm. It then adds this time in seconds to the current time in seconds before subtracting 1200 seconds (20 minutes). It then stores this time in a variable (which you have to create yourself, titled %Nextalarm) before adding 12 minutes to that time and storing this value in another variable (%Afternextalarm). All of the "if" statements and wait times in these tasks are important, as there are slight delays in getting values.

The next step is to create the task that will turn on the lamp 20 minutes before an alarm. Because WemoWay is still in beta, it's rather buggy. I've also noticed that sometimes the instructions sent from WemoWay don't get through until I've manually reconnected my WiFi connection in Android. The task shown below will restart WiFi and then force a connection to my home network. It will then kill the WemoWay service before manually launching the app and then executing a command to toggle the lamp. This has been reliable so far.

Togglewemo for alarm (25)
A1: WiFi [ Set:Off ]
A2: Wait [ MS:0 Seconds:2 Minutes:0 Hours:0 Days:0 ]
A3: WiFi [ Set:On ]
A4: Wait [ MS:0 Seconds:1 Minutes:0 Hours:0 Days:0 ]
A5: WiFi Connect [ Configuration:"Yeezus Lives" Package:jp.meridiani.apps.wificonnect Name:WiFi Connect Timeout (Seconds):0 ]
A6: Taskkill [ Configuration:Method=Extreme; Package=com.twolinessoftware.android.wemo.wemotoolkit Package:com.laptopfreek0.taskkill Name:Taskkill Timeout (Seconds):0 ]
A7: Wait [ MS:0 Seconds:3 Minutes:0 Hours:0 Days:0 ]
A8: Launch App [ App:WemoWay:activity.MainActivity Data: Exclude From Recent Apps:Off ]
A9: Wait [ MS:0 Seconds:4 Minutes:0 Hours:0 Days:0 ]
A10: WeMo Device [ Configuration:Toggle WeMo Alarm Lamp Package:com.twolinessoftware.android.wemo.wemotoolkit Name:WeMo Device Timeout (Seconds):0 ] 

We then create another task that will run 12 minutes after the alarm has sounded. It will toggle the lamp off, and then clear the values for the variables we created. You can simply clone the task above and then add variable clears for %nextalarm and %afternextalarm.

The final step is to create three profiles. We want to create a profile that will trigger the task that checks when the next alarm is. I've opted to check for the next alarm 30 seconds after the Android Clock application has been opened (this is why there is a 30-second wait at the start of the CheckNextAlarm task). You can do this by creating a profile based on 'application', and then selecting the clock application. Run the 'get next alarm' task for this profile.

The next profile will be triggered based on time. This is where the variables we made come in. Add a time profile, and tap on the intertwining arrows on the left, below "From:". Here you can select %Nextalarm. Do the same for the "To:" field. Run the 'toggle wemo on' task for this profile..

The final profile is the same -- a time profile, but using %Afternextalarm for the time instead of %Nextalarm. Run the 'toggle wemo off/clear variables' task for this profile.

Once all of this is done, all you have to do is make sure you set your alarm within 30 seconds of opening the Clock application, and everything else will be done automatically. This setup has made my early mornings much, much easier.

Thursday, 8 January 2015

Using My Phone to Automatically Record Lectures

I've been trialling integrated university lecture timetables in Google Calendar since last year, and it's been very useful so far. One of the added bonuses is that it's allowed me to automate lecture audio recordings on my phone; when a lecture calendar event is active, my phone records from the microphone and then stops at the end of the lecture event. It also gives the recording a filename based on the date, time, and module title. This has been achieved using Tasker, an excellent tool for Android automation.

First you'll want to create a task to start the the recording and to name it appropriately. We'll do this using the Record Audio action. Under the File field, type in the path to where you'd like to save the recording (in my case, I save them in a folder called AudioRecordings), followed by %DATE%TIME%CALTITLE. These are variables for current date, time and calendar event title.

Next you need an event to stop the recording. All you need here is the Record Audio Stop action.

Finally, you'll need to create a profile that's triggered by specific calendar events. To do this, create a new profile based on State, and search for Calendar Entry. Here you can specify how to determine that it's a lecture event. I've simply specified that the title should match the module that I want recorded. You could also specify that every event under a specific calendar account should trigger the audio recording task. Add the Record Lecture task as the main task, and the Stop Record Lecture task as the exit task. That's it.

Using default settings, a two-hour recording is about 12.5MB in size. During lectures I'll usually place my phone on my desk, with the microphone pointed towards the front of the room.  Doing this allows me to be able to easily understand lecturers during playback of the recordings.

Disclaimer: please obtain permission from your lecturers prior to recording them.