Interning Behind the Movie Scenes


MEDFORD, Ore. ( – I had been looking for a place to hone in my appetite for technological-knowledge acquisition, so last summer my father suggested interning with Sorenson Design. The company is headed by Michael Sorenson, a family friend and a successful venture-capitalist. While Sorenson Design develops a myriad of hardware equipment for various professional purposes, one of its top flag-bearers is the Ravensclaw Inc. division.

The Ravensclaw’s featured product is the Talon, a remote-controlled pan-and-tilt device used to control a camera. Such devices are used by any viable corporate media entity as well as many independent news organizations. This device might come in handy, say, in an IndyCar race. New channels, competing for the highest quantitative-multitude of views, would desire to offer the most comprehensive, up-close, real-time, high-quality footage.

The problem with offering such features is that it means that a camera must be placed adjacent to the race-track, a fatally dangerous location for a human to be while sleek cars are zipping at over 200 miles-per-hour, skidding along speedway turns, inches away from the camera-holder. It makes sense, then, that some sort of tripod must be placed there. However, a tripod without a human to control it will only offer a momentary flash of red or blue, possibly unfocused and ill-positioned. One would want to be able to perform humanoid functions, such as irising, focusing, and adjusting the pitch and orientation, and rotating the camera. The Talon fills this gap.

The Talon is a multicomponent device that can perform almost any action a human could with a camera. And the fact that it can readily duplicate previous operations and is so easy to use has made it attractive to news casts to use even in a scenario a human could man a camera.

Major news corporations, such as NBC, have even abandoned most of their previously-used apparatus in favor of the Talon. The Talon ships with two remote control systems, one more adept to mobile use, both with a straightforward graphical user interface. They both display the x, y, and z position of the camera down to the millionths of an inch, and they have an interface allowing the user to record sequences of operations stored in simple files that execute commands to the computer on the tripod.

One of the components uses simple wheels to control the focus, zoom, and irising of the camera with a simple interface. Here is it depicted both independently and on the camera:

 Ravensclaw Inc. also offers a myriad of methods to control the camera, ranging from a handheld remote to a sophisticated joystick system.

When I first entered the shop, I was astounded to see the amount of vertical-integration involved in the shop. Most of the equipment was hand-manufactured in the shop, behind the offices, and the programmer, with whom I was destined to intern with, directly coordinated with the processing chip designer in the adjacent room, so he could write the functions (he wrote all the top-level commands he used) to operate through the serial ports, making an ideal and brisk system with code that runs almost as fast as assembly code (code that directly manipulates bits and bytes).

I was immediately given the job of updating a programming written in the C++ Windows API, the Microsoft Foundation Class, abbreviated as MFC. This class required Microsoft Visual Studio Professional, and was not usable in the Express version, a quandary that initially caused the programmer and I much confusion. Without any second thoughts, Sorenson Design purchased the 2008 version, which cost approximately $100. It was interesting to see, throughout the code, how data was conducted across multiple 16 and 32-bit serial ports.

Now, I have a different job.  Recently, my mentor acquired the job of upgrading the Darex XPS-16 firmware. The XPS-16 is an advanced drill sharpener that can sharpen multiple sizes of drills bits including ¾ inch ones, among a cornucopia of others. I was astounded to see how practicality can combine with electrical engineering to create seemingly-advanced converters. For example, the XPS-16 detects when a drill-bit is being sharpened simply because when the drill bit is pressed against the metal sharpener, the ampere naturally increases. The current can be converted to digital bits, and sent through serial ports to detect this additionally charge, a simple, but elegant solution (“simple” in terms of electrical engineering).


The firmware is being designed for a TFT-LCD display. TFT (thin film transistor) is an LCD display that is used commonly for touch screen purposes. It’s possible your phone could possess such a display. It detects a touch’s x and y coordinates by measuring the differences in pressure from both sides of the display. The operating system is being reformatted for a higher-resolution display.

Basically, my job was to convert monochrome bitmaps into a C character array of hexadecimal characters. Monochrome bitmaps are pictures that only contain black and white pixels. It’s simple from a binary point of view: a 0, one bit, is one pixel, and 0 is black. White is the other value the bit can contain, so 1 would be white. The sequence of 00001000 would have, for that row, a mostly black bitmap with one white pixel in the middle. A byte is 8 bits, and the character array is in hexadecimal, a base-16 number system, not a base-2 one. That means that for a white space it would be f, 15 in a decimal number system, but 1111 in a binary system. A byte of white would be ff. However, my mentor’s libraries are designed to interpret the bits in the opposite fashion: 0 as white and 1 as black. Because I don’t want to individual type out the bits, I’ve written a program to do the work for me, but I’m having trouble inverting the values, because the programming language I am using is high-level, allowing me to quickly assemble the program, but encounter problems when I try to fundamentally shift basic operations.

From this new project, I learned the resounding message that is coursing through my future career: software engineering. The moral is that, while there are plenty of programmers to write applications for the end-user, a dwindling amount can actual program digital electronic components anymore. I was reminded how far removed programming has become when I was warned of the folly of adding a few hundred bytes to create a color bitmap. It is easy to forget that while our expensive laptops have up to eight gigabytes of memory (or even more), the majority of electronic components do not, and programmers can now forget how to be frugal. I never expected to learn so much from a mere internship, but I know I have only scratched the service of the scientific wonders available in just one of the many electronic hubs an unaware person could dismiss Ashland and Medford for not having.

Print Friendly, PDF & Email