There is a constant problem in the microscopy community, which I have stumbled upon too many times to mention, over the last 20 years. An end user purchases a microscope, with “imaging software” included in the purchase. At some time in the future, the user decides to add a new device, or capability, to the instrument. It is here the problem lies, because often times, the user is surprised to learn that this new widget is not “supported” by the software he or she has paid a high sum to own. So – here is a microscope, with well refined commercial software, but no capability to operate the newest or most-applicable hardware.
TL:DR Summary
ARC has invented a new solution for the problem described, with the Universal Translator. This device can emulate a series of available protocols, communicating with host software, while also communicating with a unsupported device on the back-end. In effect, the device “translates” between supported and unsupported communication protocols, unlocking the use of a wide array of devices for use on existing software platforms. Read more about the Universal Translator on the product page here.
Why take on a support nightmare?
From the perspective of any reputable manufacturing organization, adding support for devices may be considered a risk. When a software package claims to “support” a device, to some degree, the provider of the software is making assurances of operation with a piece of hardware they have no real control over. It follows that regardless of what might no be working, the software organization is likely the first to be blamed for anything going wrong. Admittedly, most of the difficulty of maintaining a stable system does fall on software developers, but the simple truth that supporting a device becomes a software support burden, is a real point. Further, writing a driver is not a completely simple task. To support a device someone has to write, test, debug, and maintain a piece of code (the driver). This includes code that may need to change when a piece of hardware comes out with new firmware. For any software organization, the numbers on the support then need to make sense. For instance, if I already manufacture or support a quite nice XYZ stage controller, or perhaps a LED engine, why would my company invest resources to support a competing product? In the end, many times the answer to this question is: don’t support the competing product.
End user restriction
For the owner of said software, this sensible approach by the company results in an effective lockout of technology. Perhaps the end user needs a somewhat novel and “low volume” device, which, while not competing with a manufacturer, simply doesn’t sell enough to justify a return on the investment of driver development. Or perhaps the user wants to drive outdated hardware already on-hand in the lab, which the company has no interest in supporting. Further, perhaps a new, novel and exciting technology is attempting to enter the microscopy market, but nobody wants to write a driver at-risk, just hoping the new technology actually succeeds. There isn’t a “bad guy” in these examples, just competing forces of resources, time, etc. Yet the end-state remains that the user cannot drive a device when he or she wishes to.
A solution to unlock thousands of devices, for use today
Working in-field over the years, I came upon this problem more times than I can remember. Yet – until recently, the notion that these devices could be effectively and reliably emulated posed a great challenge. To effectively emulate a device, the translator had to support 2 drivers, do so at a short time delay, and be able to bounce between many different communication types (Serial, USB, TTL, Analog). To truly be effective, such a device should support more than 1 sub-devices, so that complete systems would function with short communication overhead. With the advent and now widespread use of SBC’s, and the widespread implementation of python scripts for communication, it is now possible to solve this problem with a few bits of available hardware.
Our solution relies on a front-side microcontroller for USB emulation, providing emulation capability to the host PC of one or more serial-usb ports, a raw HID device, a hard disk, a joystick, a MIDI controller, a keyboard, a mouse, as well as other device types. This flexibility allows a wide array of methods to interface with existing hardware. On the client hardware side, the device supports Ethernet, up to 4 USB connections, AnalogI/O, and TTL interfacing.
Several Drivers developed, more on the way
ARC has already written front side emulators for existing filter wheel controllers, LED engines, XYZ Stage controllers, and other devices. If you are interested in a custom driver solution for your device, please get in touch!
Learn More
I’ve posted a video demonstrating the UT in action on a commercial software platform, which can be found here.