Over this past weekend I set out to create a camera tally device for the Spyder video processor. Specifically, I wanted to try to use my relatively new Raspberry Pi 2 board running the Windows 10 IoT Core operating system to make something useful. If you’ve read through my older blog posts, you’ve likely noticed that the Spyder is still my go-to target platform for playing with new technologies. Let’s face it – when you’re playing with shiny new toys, it helps to mate it up with something you know very well so you don’t feel completely lost. Before I get into the details, check out this brief video showing a working tally controller in action:
The whole process of building this device was simply fantastic. The barrier to entry for people making hardware devices has gotten incredibly low over the past couple years, both from a cost and ease of development perspective. The whole build process was very quick, and I had such a great time with it that I went ahead and put together a full 30 minute hardware and software video walk-thru for the project (more on this below).
Getting Started Making your own
To get started making your own, here are a couple links for the main hardware used on this project, as well as the wiring diagram for your reference.
Links to the full source code, documentation resources, and a full YouTube walk-thru video are below. This video has a ton of valuable information in there, covering the hardware specifics, Spyder implementation details, and the full process of creating our software application. This is the first time I’ve gone through and made something this elaborate (and narrated the video), and I’ll be very interested to know what you think of it (so leave me a comment below if you’re so inclined).
GitHub Project (Source Code and Documentation): Click Here
The tally controller we’ve created is certainly functional. but in it’s initial form the server IP address and tally source lists are hard-coded. In the next stage of this project, we’re going to build a desktop application that can connect to the device remotely over the network and view/configure these properties. We’ll also explore creating a user interface to run on the Pi’s HDMI output, which could be useful for monitoring and troubleshooting the device.
Until next time, take a look through those walk-thru video and the resources in the Github repository, and try to make one yourself. I hope you enjoy going through this content as much as I enjoyed making it.
So a few weekends ago I decided that I’d like to embark on a fun project of making a network enabled garage door opener. A few weeks ago I was walking home from a neighbors, and found myself wishing I could open the garage from my phone, or ideally from my Band. This seemed like enough of a pretense to embark on a new project, and after a few weeks of tinkering I’ve emerged with the following working home accessory:
When I started this project, I laid out a few key requirements:
Build an application targeting an existing Wi-Fi enabled Raspberry Pi I had laying around.
Build and debug the application on the Pi, and write it in modern C++.
Setup Git on the Pi, and keep the code up in GitHub.
Breadboard the hardware required to switch the garage light and door.
Integrate a temperature/humidity sensor to allow me to play with garage cooling options over the upcoming summer months.
Add a garage door closure sensor so the device can tell when the door is open or closed, so the app can provide open/closed status back to network clients.
Integrate my X10 Firecracker dongle, to allow me to control my existing X10 outlets/lights
The C++ requirement came partly from a desire to tackle a ‘real’ project with the language using modern language features like smart pointers, and to try out some of the Boost library’s programming constructs for asynchronous networking. I’ve also been playing around with building basic electronic circuits, and making some necessary hardware for the Pi seemed like a fun time.
It took a while to get the electronics working, and I learned a decent amount along the way (even though there really isn’t much to this). I started trying to trigger my 3.3v relays directly using the GPIO pins on the Pi, and when that didn’t work I had to go back and figure out that GPIO pins can’t drive the level of current required. I was also using a shift register initially to reduce the number of pins coming off of the Pi, but it ended up being unnecessary and was eventually removed.
Testing first iteration using shift registers
The second iteration two introduced some diodes and transistors, and then I was up and running. I added a couple momentary contact switches to provide local light and door control, and picked up some DHT11 to do my temperature/humidity sensing.
I put everything together on a breadboard, with a plan to solder everything together and put it into a clean enclosure with my couple of surface mounted switches, but I quickly fell in love with the idea of just putting an acrylic top over it, and mounting the Pi and breadboard together on another sheet of acrylic (spray painted black on the back), as-is. It has a fun look to it, and that might be what I like about the whole project most.
Second iteration of electronics using transistors, diodes, and opto-couplers
The one part that sadly hasn’t made the cut yet is the X10 firecracker. This is a control device I used to have connected to my PC (back when I had a serial port), which works in conjunction with a wireless receiver to send On/Off power commands to outlets and switches throughout my house. I found and installed an RS-232 shield on the Pi, but later found out that it doesn’t connect the RTS/CTS lines used to power and signal the Firecracker. Oh well, I’ll think of something in the future…
I chose CodeBlocks as my IDE of choice on the Pi, after seeing a few recommendations online for people coding in C++ on the Pi. I was able to target C++ 11 features, and although it took a while to figure out how to get the Boost libraries to link up to my project, the process wasn’t too bad. In general, however, I wouldn’t recommend that people try to write code directly on the Gen 1 Raspberry Pi, at least when you’re trying to do it using an IDE on top of x-windows. It’s really slow, not only when trying to compile (which takes a long time even for trivial programs), but even typing code into the editor is noticeably delayed. I eventually started writing and testing as much as I could in Visual Studio, and then bringing the code files over to the Pi for final testing and implementation. For final debugging/testing I eventually ended up editing files using VI over SSH to skip the UI overhead on the PI, and that seemed much more usable.
Running CodeBlocks on the Pi
I have the project checked into GitHub, and you can check it out here. With any luck I’ll actually come back and check in some schematics for the hardware portion of the application, but for now at least the software is up there in case the Pi dies in the extreme heat of my garage over the summer.
Trying it Out
I was pretty excited the first time I was able to trigger the door and light manually using the new Pi-based controller, and even more so when triggering it from my desk. The design has two LEDs, one that blinks on/off at roughly a one second interval, and one that lights red when the door is open.
Talking to the garage door using Putty
In the next post, I’ll cover writing Windows Phone and hopefully a Microsoft Band apps to talk to our garage door.
The software library used for the Spyder Client for the Windows Store is now available for use as a nuget package (for .Net developers), and the source has been made available up on GitHub. This library provides an implementation of the documented UDP control protocol, and additionally provides some of the ‘secret sauce’ used by richer control clients. From the GitHub readme:
Full implementation of the published Spyder UDP control protocol
System Config File parsing – provides full Spyder data object model to clients
Drawing Data (live view) data stream deserialization (Supports 2.10.8 – 4.0.4)
Spyder quick file transfer procotol (QFT) implementation. List, get, and set files
Thumbnail Manager – provides background downloading, multi-resolution scaling, and memory lifetime management of system thumbnail images
Consuming the Nuget Package (.Net Developers)
The Nuget package is the easiest way for .Net developers to consume the Spyder client library, and can be used to target Windows Phone 8.1 or later, Windows RT / Store apps, or .Net 4.5 or later desktop applications. Get it from Visual Studio using the Nuget package manager (see screenshot below).
If you want to build the library yourself, peruse the source, or even port it to another platform, head over to GitHub to get access to the source code (link above). This source uses the Apache 2.0 license, so you can do whatever you want with it. Please do use the issue tracker or submit pull requests if you have anything you’d like to add or fix, and have fun!
In future posts, we’ll explore some sample applications that use the library to do common things like control command keys, perform file backup/restore, and possibly even create a display simulator control that works from the Spyder server’s real-time data stream. I’ll also be working on some general documentation that I’ll post on the GitHub site, so keep an eye on the project’s GitHub page.
One of my favorite areas working on in the Spyder Client for Windows 8.1 was the live view, which not only shows a real-time visualization of the Spyder server’s PixelSpaces, but allows for live interaction and command key creation. While it’s not necessarily new, I thought it would be fun to create a Camtasia video showcasing the live control available from the Spyder Client. I certainly enjoyed making it, and I hope you enjoy watching it (and using it).
Under the Hood – Leveraging Spyder’s External Control
Internally, the Spyder Client uses the Spyder server’s publicly accessible external control protocol for all control actions performed by the application. This is for a few reasons, one of the more notable of which is that Windows Store applications do not support .Net Remoting (which is how the Vista Advanced client communicates to Spyder). If your curious how the Spyder Client is doing something you can simply check out the Spyder server’s logs to see what commands are being executed (see screenshot below). Just make sure to set the server tracing level to information or success so that the command logs actually appear. Of course, if you have a specific question, feel free to leave a comment under this blog post. I’m always happy to help out a fellow coder.
Viewing remote server logs in Vista Advanced
Just in case you don’t already know, the external control protocol documentation is included with the installation of the Vista Advanced client software. If you have Advanced installed, then the external control protocol PDF document is already available from your start menu.
My favorite feature in the Spyder Client for Windows 8.1 is the command key thumbnails it displays. These thumbnails are smart, in that they combine the live look on screen with the expected execution plan for the command key, resulting in a true thumbnail preview of what the screen(s) can be expected to look like after the command key has executed. In the video below, I give you a quick overview of this feature in action.