ScreenMaster III 3216 – Restoring a Classic – Part 2

In the first post in this series, we walked through upgrading the internal PC hardware within a ScreenMaster III 3216 hardware controller. In this post, we’re going to start creating the software to communicate between the internal computer and the hardware buttons, joystick, rotary encoders, and T-bar. All of the work discussed in this post lives in a GitHub repository that you can look through and use.

Before we dive in, let’s quickly agree on some terminology. I’m going to refer to the buttons, joystick, rotary encoders, and the T-bar collectively as the ‘keyboard’. Additionally, I’m going to refer to the Windows PC-based computer inside the console as the ‘host’. When we want to turn on or of a lamp for a button, for example, we’ll consider that to be a ‘host’ to ‘keyboard’ communication. Alternatively, when a user presses a key or moves the joystick a ‘keyboard’ to ‘host’ message will be generated. Hopefully this makes sense. Luckily the GitHub repository mentioned earlier in this post uses the same terminology in it’s documentation.

So how do we interact with the console hardware?

Communication between the host and keyboard is all performed using an internal Ethernet connection. This proved to be extremely helpful when upgrading the hardware, since we didn’t need esoteric connections to interface with the hardware. The keyboard has a hardcoded IP address of 192.168.1.3, and is hardcoded to send event messages to our host computer at the IP address of 192.168.1.2. This is quite limiting, but since it was initially designed to be an internal Ethernet connection we simply added a second USB network adapter during our PC upgrade dedicated to this interface. The image below shows the high-level Ethernet connectivity within the controller:

Over Ethernet, the messages between the host and keyboard are all simple UDP packets, with a very basic structure. I won’t detail the protocol here, but if you’re interested I’ve written up the protocol and published it within the GitHub repo here. Effectively, here’s the main list of things that you can do:

Host to Keyboard:
– Set lamp lights on or off for each button
– Set the LCD button background to Off, Red, Green, or some alternating combination
– Set the LCD button text – 3 lines, 6 characters per line

Keyboard to Host:
– Get event when button is pressed or released
– Get event when the joystick x, y, or z axis value changes
– Get event when a rotary encoder is turned (+/- change value)
– Get event when the T-Bar position changes

Time to write some software…

I’ve written and published a .Net Standard 2.0 library to implement the keyboard protocol and make it easy to consume from an application. The repository (listed at the beginning of this post) makes it simple to subscribe to events and control the simple pushbutton lights and LCD display buttons.

The repository contains a console test application that subscribes to events and writes these events to the console output. It’s a good example of how to use the library, and I’ve included a snippet of the test program’s Main function below for reference:

using Spyder.Controllers.ScreenMaster3;

static async Task Main(string[] args)
{
    // Initialize connection to keyboard
    var keyboard = new KeyboardInterface();
    await keyboard.StartupAsync();

    // Subscribe to events from the keyboard
    keyboard.TBarValueChanged += Keyboard_TBarValueChanged;
    keyboard.KeyPressed += Keyboard_KeyPressed;
    keyboard.KeyReleased += Keyboard_KeyReleased;
    keyboard.RotaryValueChanged += Keyboard_RotaryValueChanged;
    keyboard.JoystickValueChanged += Keyboard_JoystickValueChanged;
    keyboard.KeyAction += Keyboard_KeyAction;
    Console.WriteLine("Listening for events");

    Console.WriteLine("Press enter to exit");
    Console.ReadLine();

    Console.WriteLine("Shutting down...");
    await keyboard.ShutdownAsync(); 
}

If you’re playing along at home, you can pull down the library and build it from source, or for convenience I’ve also published it as a Nuget package for easier consumption.

Mapping out the buttons

With a software driver library and a test application created, we can now go through the process of pressing and releasing every button on the controller, and watching the event data to determine the logical button ID associated with each physical button and rotary encoder. The console has well over 200 buttons, so it took a bit. My GitHub repo has a Visio document with some different pages that include the index map, and below is an image of this as well as a keycap map for the ScreenMaster III 3216.

Now where are we, and where do we go next?

At this point we have a controller with a modern computer inside, and we have a software library that allows us to interact with the hardware keyboard. With these in place, the real technical challenges are out of the way and we can focus on building an application to control something similarly modern. With my history and existing software libraries and software applications to control Spyder video processors, it’s probably not a spoiler alert to say this is where I’m heading.

I’m not sure yet if the next blog post will be software heavy (yet) – I’m planning to spend some time planning a good console application before diving too far into code. That being said, I couldn’t resist getting some simple app(s) started. As such, I’ll leave you with a quick video showing an app framework that works with the keyboard interface and is setting the selected page based from menu button presses.

If you’re still with me reading through this blog series, thanks! I don’t expect this project to amount to much more than a love letter to an old product that holds nostalgic value to me, but I hope it might resonate with a couple people out there. And if you’re lucky enough to have one of your own ScreenMaster III or a Montage controller lying around, let me know about it!

ScreenMaster III 3216 Console

ScreenMaster III 3216 – Restoring a Classic – Part 1

The ScreenMaster III 3216 and it’s half-sized little sibling the 1608 were some of my favorite consoles every made at Vista Control Systems (later renamed to Vista Systems and later acquired by Christie Digital). These were the first consoles to incorporate 15″ touch screen displays to compliment the massive button boards from prior console generations. This console, like others before it, were purpose built to control a combination of Folsom (now Barco) VFC-2200 scalers and either Extron, Pesa, or Sierra routing switchers. We’re talking analog video only here – this was the nineties after all, when 1080p video was king.

It’s worth a note that this console would be appear again in the future as the control surface for the Vista Montage video processor, painted in blue and re-dubbed as the Montage SC-3200 console. This stuff is all but lost in time, even on the internet these days, and so I’ve included a picture below for full historic reference.

Let’s talk about this got started

Let’s talk about eBay. eBay is a great place to get great deals, and is a great place to troll late nights when you can’t sleep to find stuff you didn’t know you needed (and probably don’t need). One night I happen to be aimlessly looking around the internet, and somehow I made it to this posting on eBay:

This picture of the console immediately gave me ‘the feels’, as it has solid sentimental value. I remember shipping the first of these consoles, sometime back in the nineties. We had a problem with a driver for an internal USB network adapter, and it was causing the console to bluescreen. We weren’t sure it was fixed, but I ‘thought’ I had resolved the issue with an updated driver. We got the console in it’s case and brought it to the back door. After talking a bit about this bluescreen, Jeff Wilson and I opened the console up and made sure it booted successfully five times. As long as it could boot five times in a row, then we’d ship it. Good news – that was the day unit #1 shipped.

<rant>Just to touch briefly on that last point – this was a time when Windows was considered to be generally unstable, and we caught a lot of flack from rental and staging customers (and competitors). Here we were though, shipping a device with Windows (NT Embedded I vaguely recall) and asking customers to entrust their high-dollar live events on it. Software bugs aside, I think this ask proved to be a reasonable one and these consoles were way ahead of their time (my opinion). </rant>

So this console on eBay had an asking price of $599, and I sent an offer for $299 which was accepted. I don’t remember the real figure, but I think this console cost around $45,000 new. From the pictures I could see some button-board activity and a boot failure, and so I knew that (1) the embedded part of the console was alive and (2) the PC was ‘alive’ and the Compact Flash card we used for the hard drive had likely failed. After some back-and-forth on the shipping, we decided to drop the shipping case to avoid going freight, and all-in I think I was down $500.

The arrival

It took about a week for my console to arrive, and it showed up packed tight with instant-foam in a box that must have had a roll of fiber tape for additional support. It took a solid hour to practically chisel the console out of this foam tomb, but it shipped in pristine condition so I can’t complain.

After getting the console freed from it’s shipping cocoon, I gave it a good look over and powered it up. The screen showed the same hard drive failure message that I saw on the eBay post. The quick-keys (the top-right green button array) showed diagnostic counters that I was able to use to verify that the buttons, joystick, T-bar, and rotary encoders were all functional (minus a few burnt-out incandescent switch lamps). So far so good. Next up is to take inventory of the computer hardware and try to get it working again, but before we move on go ahead and take a hard look at that good-looking piece of hardware ūüôā .

Console internals

When you open the bottom of this console, you immediately see that there is a LOT going on. Luckily, when we look closely at the internals of the console there are two main subsystems – the embedded computer (PC) and the physical control interface (buttons / T-Bar / Joystick) subsystem. The picture below shows the console on it’s side with the bottom removed.

The application board is the main embedded component which houses the programming required to read and write the physical hardware. Luckily for us, the interface between the embedded computer and this application board is Ethernet. It’s difficult to see in the pictures, but there is an Ethernet crossover cable between a second Ethernet port on the SBC and the application board. This is great, because it means that we can upgrade the embedded computer without worrying about obscure hardware interface dependencies.

Before we move on to replacing the embedding computer, let’s take a second to talk about the embedded computer that came with the console. This was an EBX form factor computer called the ‘Olympus’ and was manufactured by Arcom Controls (datasheet here). This was a 1.0 Ghz Celeron processor and 128MB of RAM. The hard drive was provided with a 128MB Compact Flash card, which has limited read/write cycles and almost certainly explains why the console eventually stopped working. I did try jump-starting the console with a new Compact Flash module, but the SBC was so old that it felt that even if I could run a modern operating system on it (unlikely) that it would be terribly slow. It was also sporting a 3.5″ floppy disk drive, for those of you who remember what that even is, and I knew that needed to be brought into the modern age as well. With that back-story out of the way, let’s get to upgrading.

Upgrading the Embedded Computer Hardware

Full disclosure here – this console sat on it’s side in my living room for several weeks, and I’d give it occasional blocks of evening and weekend time. This wasn’t particularly hard, but there were some time-consuming parts of the effort that I’ll bullet point rather than writing a book about:

  • Removed the prior EBX form-factor PC board and graphics adapter
  • Removed the existing floppy disk drive
  • Drilled holes in the chassis to fit a new Mini-ITX form factor PC
  • Bought a +12V to ATX power adapter module to power the new SBC
  • Added two USB to RS-232 cables to drive the touch screens
  • Added a USB to Analog adapter to drive the second touch screen (the SBC had one VGA port I was able to use as well)
  • Replaced the Neutrik Ethernet connector running to the back of the console with a new one
  • Modeled and 3D Printed a custom bracket to hold a new Solid State hard disk and expose 2x USB 3.0 ports to fit in the old floppy disk drive spot.

The mounting and retro-fitting of the new SBC and parts was a pain, but I’m pretty happy with how it came out. This thing feels like it could travel and be as reliable as the original console was. I am particularly proud of the 3D printed module that I made to hold the hard drive and expose a couple USB ports, and you can see this along with a bunch of other build pictures below

After the aforementioned evenings and weekends spanning may weeks, the hardware for the console was done. It was now sporting an Intel i7 processor with 16GB RAM and a 512GB solid state disk, and was running quite nicely. I did sneak in a picture of installing Windows on the replacement Embedded PC / Single Board Computer (SBC), but I’ve saved this for the last section of this post.

Let’s put Windows 10 on this thing

A modern console needs a modern operating system. I actually considered installing Ubuntu Linux for the fun factor, however ultimately I decided to install Windows 10 Pro. It’s less ’embedded’, but it allows for wider flexibility for software to run (including Vista Advanced / Spyder Studio / Spyder Client software).

One wrinkle that I did run into was around the touch screens. They have RS-232 serial controllers, and the native 3M driver didn’t work. I remember running into this with my Car computer touch screen (same hardware), and so I knew I needed to pony up and buy a license for a software called touch-base that makes the touch controllers work with Windows 10. Related note – the screens for the console are each 1024×768 resolution and VGA, and if I were braver I would crack open the top and try to replace them with some newer displays. Maybe someday.

Big reveal time

I don’t need a lot of words for this – I’ll let the pictures of the console working speak for themselves. For those curious, the pretty looking Spyder control software is the Spyder Client application that is available on the Windows 8/10 Store.

So where are we, and what’s next?

So we have a large powerful hardware console alive and well, and we have a working PC operating system on it. Probably a way over-powered PC in there hardware spec-wise, but we still don’t know what we’ll do with it so hard to say. By the time I write this, the console has actually been sitting in my dining room for the past two months. I’ve already done some development and created a software interface to integrate the hardware with the PC, but I’ll save that for a future blog post.

In the next post, I’ll talk about how the PC-to-embedded hardware interface works, and we’ll probably have a simple app to show take a look at. I expect the next post will be a bit shorter – this one was a monster and it feels like it just skims the surface. With that, thank you for reading and see you next time!

Using NPM packages from RunSmart microservices

The RunSmart workflow environment uses node.js for it’s microservice system, and in addition to the built-in libraries it’s possible to install and use Node Package Manager (NPM) packages. This is incredibly handy, and this post briefly shows how to install these packages and consume them from RunSmart workflow scripts.

Note: It is of course possible pull down the code for npm modules and maintain native RunSmart libraries, and gives tighter control of the code running on your system. In practice however, this becomes a large task with anything than non-trivial npm packages due to the number of package references they tend to use.

Installing NPM Packages

To install npm packages, you’ll need to remote onto the server hosting your Windows Workflow Services installation. From this computer, open a node.js command prompt, and navigate to your installation directory for RunSmart (usually c:\Program Files (x86)\BASELAYER). This is the directory that will be used as the search path for node_modules, and if you look at the contents of this directory you may already have this directory present. If you don’t, no worries as it’ll be created when you install your first package.

To install a package, you can usually just run npm install <package name>. In the screenshot below I’m installing the TeslaJS package, which I use for monitoring my car.

Installing an NPM package to be consumed by RunSmart Workflow microservices

Using NPM Packages in your RunSmart Microservices

From your RunSmart microservice scripts, you can use the normal node.js require statement to bring in your libraries. The library loader will first look for a local (in database) script matching the require statement, and will afterwards search the node_modules directory.

Importing the npm module ‘teslajs’ (line 5 of the microservice script)

That’s all there is to it!

The great garage refresh of 2018

In December I pulled the trigger and ordered a new Tesla Model X. Being more of a computer on wheels than a car with a cool computer and autopilot system, this car speaks to me on a level deeper than I can comprehend. The time from order to delivery was a little over three months, and it became apparent immediately that it would need a worth garage to call it’s home. This blog post is a chronicle of the creation of just such a garage.

Where we Started

The garage had years worth of stuff packed into every corner, and hadn’t seen a car actually parked in it for quite some time. I wouldn’t allow my shiny new car to bake in the driveway, so initially it seemed obvious that a clean-out and maybe some paint on the walls and cabinets was in order.

First Attempt

At first all I really wanted to do was paint the walls and cabinets, and clean up the junk that I had accumulated over the years. As the space cleared out and I went to painting, I started noticing how the cabinets weren’t really in great shape, and were starting to crumble. I went to painting anyway, but realized quickly that there wasn’t going to be much of an improvement. I got through a couple walls, but didn’t even get to painting the cabinets. I knew this was going to become a much bigger project…

Tearing it all Down

The cabinets were garbage. I ripped out all the cabinetry, and then was faced with bare studs that would need some drywall. The garage had previously been a carport, and so the walls it did have were exterior walls or just bare studs. These exterior walls were 1/2″ wood with slats, and I finally broke down and ripped all that out as well. The covering of the uneven wall along the house came out and revealed a door and a window that had been covered over on the other side during a previous remodel. One wall after another, I kept tearing more and more down until I had pulled almost all walls, with the exception of half the wall running along the house, down to the studs.

Adding more Power

While the studs were exposed, I added electrical outlets to the outside and back walls, and ran the power line up to the attic. I also added a pair of 8′ LED strip lights which look like fluorescent fixtures to give the room a brilliant white light. This lighting alone was a major improvement both for working in the garage as well as the finished product.

I had an electrician come in to wire up the outlets to a new 20-Amp breaker, as well as wire a new circuit to an 80-Amp Tesla wall charger unit which would live on the back wall of the garage. We had a few surprises – my electrical box is 3-phase, wasn’t grounded, and needed some work to fit some new breakers. We got through it in a few days, but between the Tesla wall charger, parts, and labor the whole endeavor set me back just over $2,000.

Building it Back Up

I framed out the half of the previously uneven wall against the house. The garage is notoriously an oven in the summer, so I decided to insulate all the walls and the attic while I had the opportunity. The ceilings are 8′ high, so I initially put in drywall strips vertically (they come 8′ x 4′). About the time I finished I found out that I should be putting a 1/2″ gap between the floor and the drywall, and also using special ‘green board’ drywall which is treated to resist moisture. I ripped all my hard work out and started again with new green board. There were some ceiling gaps that I fixed up along the back wall due to the prior 1/2″ wood boards being thicker than my new 1/4″ drywall.

To mud and tape the drywall together, I hired a professional. That is an art in itself, and I figured for all my work I wouldn’t want to do a bad job here and not get the benefit of clean/smooth walls. Had him mud the entire ceiling while he was in there, to get rid of the prior texture and some other holes and cracks that needed to go. $950 later I had something starting to resemble a legitimate garage again.

Finishing the Job

Painting the walls was easy, but painting the ceiling was much more difficult than expected. I stayed up many nights until 2AM just painting, and the excitement as it started to look like a showroom fueled me to push hard. With the walls painted, the floor became an instant eye-sore. It quickly became apparent I was going to need to go all the way and epoxy the floor. The idea of a showroom look had taken hold, so I committed to going with a white color.

The prep work and application of the epoxy floor took as much time as the walls. I ground down the floors with a large grinder rented from the Home Depot. I ground down along the walls by hand using a hand grinder. Then I acid washed the entire garage to prep the concrete. Then I spent hours sealing cracks in the concrete to ensure a smooth surface. This process alone spanned weeks and cost a couple hundred dollars. The actual epoxy (two coats) and associated sealer/hardener (also two coats) cost around $600 and also spanned over a week due to curing time between coats.

The very final step was trim, which I waited several weeks before knocking out. Simple white, pre-primed trim pieces went up in an afternoon, and after a quick bead of silicon caulking I was finally done.

Completed Garage Renovation

Overall Thoughts Now that it’s done

At the outset if you told me I would spend over $5,000 to renovate my garage, I likely wouldn’t have started at all. But that’s not how great projects work. This garage is awesome, and makes me happy. Sometimes I go out to my car, stop, and pull out my phone to take a picture or two. It looks walking into a showroom every day. It’s worth it, and I hope for everyone to have something that brings them recurring joy like this. It’s a prefect compliment to the car, which also brings me boundless joy.

For those wondering or hating on the white floor – I mop it once a week and it looks brand new again after three months. The car doesn’t drip random oil or other fluids on the ground, so at worst you end up with some tire tracks after a few days. If you live somewhere rainy, your mileage may vary. In Phoenix Arizona it’s not bad.

Future Stuff

I would very much like to install three of the Tesla PowerWalls and some solar. Beyond the energy benefits, the visual design of those PowerWalls would really look amazing along that red wall in the garage.

I need to build a home for my bike, which is now living in the back yard. It’s covered, but it’s also an expensive machine that shouldn’t be left outside.¬† I already have some plans for this – look for that in another post soon.

Building a Camera Tally Controller for Spyder

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.

Raspberry Pi 2 Kit ($70):  Amazon Link
8-Channel Relay Board ($9):  Amazon Link

Tally Wiring Diagram

Hardware Wiring Diagram for our Tally Controller

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

Next Steps

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.

Garage Door Opener Project: Part 1

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:

The Plan

When I started this project, I laid out a few key requirements:

  1. Build an application targeting an existing Wi-Fi enabled Raspberry Pi I had laying around.
  2. Build and debug the application on the Pi, and write it in modern C++.
  3. Setup Git on the Pi, and keep the code up in GitHub.
  4. Breadboard the hardware required to switch the garage light and door.
  5. Integrate a temperature/humidity sensor to allow me to play with garage cooling options over the upcoming summer months.
  6. 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.
  7. 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.

The Hardware

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

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…

The Software

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

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

What’s Next?

In the next post, I’ll cover writing¬†Windows Phone and hopefully a ¬†Microsoft Band apps to talk to our garage door.

Open Source release of C# Spyder control library

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:

Key Features

  • 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).

Nuget Package Info Page:  http://www.nuget.org/packages/SpyderClientLibrary/

Getting the Spyder Nuget Package

 

Getting the Source

GitHub Project Link:  https://github.com/dsmithson/SpyderClientLibrary

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!

What’s Next?

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.

Spyder Client for Windows 8.1 – Live Control

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

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.

Spyder Client Command Key Visualization

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.

First App in the Windows Store (Yes it’s another Spyder Client)

Historically, when I’m taking a new platform or development tool out for a spin, I end up creating a control client for Spyder.¬† It’s nice to be able to work against a well-known and well-understood platform, so you can focus on the new and exciting stuff.¬† In this case, which is no exception, I fired up a Windows Store application targeting the Windows 8.1 platform.¬† In all truth, I think I started this about 5 months ago, however the project didn’t make real traction until the week of Christmas this year (which I took off from work).¬† I put forth a hard goal of getting the application into the store by the end of that week, in hopes that I wouldn’t aimlessly squander away my week at home.¬† At the end of the week, a new application had indeed been introduced to the store, and while it’s pretty ‘fresh’ I’m proud¬†of the results so far.

Check out the app’s official page on this site here

Check out the app and download it from the Windows Store here

Feature Set on Day One (What’s there and what isn’t)

Getting something into the store on a compressed timeline is tricky, and there are always a lot of features that get dropped.¬† I’ve been reading The Lean Startup, and one of the concepts reiterated regularly is the concept of getting something out there early to collect feedback to iterate against.¬† Waiting too long for something to be perfect (which isn’t a real thing) means that you can spend an inordinate amount of time working on features that people don’t care about.¬† This is pure waste, and in a project like this where all development is happening in my free time, there simply isn’t time for waste.¬† All that being said, here are the features as they exist on day one, and my current view of where they could go in the future.

Note that this is my list, and I’m providing it to you in hopes of hearing some of your feedback.¬† Tell me what is and isn’t important to you, and together we’ll be able to make this app better.

Main Screen

 

Home Screen

The main screen is the landing page for the application when opened, and displays all servers available on the network, each with a thumbnail sized live view and launch buttons to command keys, function keys, and still image pages.¬† The functionality is pretty straight forward, so I won’t list out what is there in more detail here, but there are a few things that I would really like to see go into a near future version of the application:

Planned Main Screen / General App Features

  • View of system health / user diagnostics¬†(with launch button to a health screen)
  • Ability to select any of the buttons and open their associated pages in a new window, allowing multiple views to be displayed simultaneously.¬† This could be a big deal for multi-monitor users, and opens up more complex control and monitoring scenarios for even single monitor users.
  • Sources view / list, showing thumbnails and tally status.¬† Used in combination with the previous feature bullet, this could allow for drag-drop support onto the live view

Live View

Spyder Client - Live View

This is effectively a display simulator view, designed to give a real-time view of the system’s PixelSpaces and layers using thumbnails pre-configured in Spyder.¬† Creating a full-featured simulator¬†brings a number of complexities, and this control is very primitive by the standards of the simulator in Vista Advanced.¬† The live view control will undoubtedly be the benefactor or the majority of near¬†future development work as a result, and to get the most bang for the buck I’ve re-used this same control to provide thumbnail visualizations for command keys and the thumbnail view on the main page.

Live View Features on Day One

  • Preview / Program PixelSpaces
  • Solid Color Borders with bezel luminance offsets
  • Thumbnails for PixelSpaces and Layers
  • Smooth motion views of layers and background transitions

Planned Live View Features

  • Full bitmap borders and shadows
  • PixelSpace Stackups (different view configurations for PixelSpaces)
  • Layer number indicators
  • Interactive control¬†(layer pinch resize, reposition support)
  • Drag/Drop support for sources / stills

Command Keys View

Command Keys

The live thumbnail view within the command keys page is (in my humble opinion) the most interesting feature within the application.¬† This works extremely well at showing what-if scenarios for recalling relative command keys, but is very limited today by the general render capabilities of the live view control used to¬†generate thumbnails.¬† I don’t think I can understate this; the renderer is pretty feature light and falls down quickly when showing more than the most basic of looks.¬† As stated previously though, this will gain all the development benefit of work applied to the live view, and so I think it’s only a matter of time for this to get flushed out.

Command Key Features on Day One

  • Displays user defined register colors for command keys
  • Groups buttons by existing user defined pages
  • Live generated preview of ‘Program’ (Cue 1)¬†look for command key
  • Absolute / Relative Indicator
  • Preview / Program tally indicators

Planned Command Keys Features

  • PixelSpace stackup switching
  • Ability to turn off live view integration with thumbnail previews.¬†¬†Not sure if anyone would actually want this feature¬†– seems to me like once you have a feature like this you would never want to turn it off (would love your feedback)
  • Option for different button sizes to condense more command keys onto the screen
  • Pinch zoom support to jump between pages quickly
  • 320 pixel wide snap view support
  • Link to a full script grid view showing all command key cues with individual thumbnail previews.¬† I have a lot of thought into this, and will probably need a blog post all it’s own to describe further.

Stills View

Stills Viewer

The stills view came about early on as a side effect of needing to¬†validate the¬†image file processor / transport software, but was handy enough to keep around.¬† The¬†Advanced client has¬†the ability to¬†obtain thumbnails from the server in a round about way (once you’ve seen them in the simulator they are cached locally in¬†the ‘C:\Spyder\Images’ folder on your PC).

Stills View Features on Day One

  • View all Still images defined in the Still registers list on the Spyder server in thumbnail form
  • View a full screen view of all images by clicking a thumbnail
  • Ability to save image files locally via the app bar
  • Ability to share one or more selected images using the ‘Share’ charm in windows

Planned Stills View Features

  • Native shape file viewer (custom bitmap border shapes)
  • Native shape file creator, with the ability to simply draw a shape on screen and have it saved onto the Spyder server as a shape file.¬† This would have the ability to load an image into the background to be used as a stencil, and additionally preview the resulting shape at a number of different source aspect ratios.
  • Different thumbnail sizes to show more thumbnails on the screen at once

Function Keys View

Function Keys

I think the Function Keys view is off to a good start; it works (which helps), and it’s approach of showing a very brief text description of it’s execution action makes it easy to see what the button will do before you actually press it.¬† An interesting note about function keys:¬† the Spyder data model actually has support for custom register colors for function keys, but this is not brought forward into the Vista Advanced interface.¬†¬†The Spyder client has support for¬†displaying custom register colors as it does in the command keys view, and so this¬†will auto-magically start working if this becomes implemented in Advanced in the future.

Function Key View Features on Day One

  • Display of Function key names
  • Display of the type of command key
  • Short text describing the action which will be performed when the key is executed (limited to one line of text, may be clipped depending on things like the number of layers affected)

Planned Function Key View Features

  • A pseudo-tally feature which would evaluate the state of the system and show a red tally indicator if the function key appeared to be in it’s executed state.¬† An assign source function key, for example, would show a program tally indicator if it’s associated source was already assigned to it’s target layer(s)
  • Relative layer recall support.¬† Function keys with relative layer/device assignments require the layer/device IDs to be specified at the time of recall, and currently there is no way to¬†provide these when¬†executing a relative function key from the Spyder client.
  • Option for¬†a more¬†compact view of buttons to display more function keys on the screen at once
  • Pinch zoom to quickly navigate between pages

Again, the planned features are on my wish list based on what I think would be great additions.¬† It’s entirely possible that I’m missing the boat on functionality that I’m just not thinking about, and if you think that’s the case then I’d like to hear from you.¬† Please leave your comments on this post, and in general let me know what you think of the app.

In a future post I’ll talk about the back-end development, project management, and source control technologies, and possible future directions for the platform.