This post describes how WITS works in Eclipse Touch. We will cover some of the design principles that went into the development, the features that came out of those principles, and a few annotated examples of WITS messages traveling through the Eclipse Touch ecosystem.

Design

WITS in a simple point to point setup scenario is about as simple as it gets, both parties agree on a set of IDs and their meanings and then data exchange proceeds using that agreed upon definition over a simple serial connection. In the early versions of Eclipse Touch this was basically all that was supported. Each instance had one input and one output channel with hard coded values as to what keys it would accept and what keys it would output. If there was a new requirement, say a particular EDR was configured to send depth information with a non-standard UD this might require a special build or a new setting to be added to support that scenario. Furthermore, if somebody wanted to output to multiple logging softwares, for example, you would have to run an extra copy of Eclipse Touch to achieve that.

Generally speaking, when you find yourself making lots of changes to support specific scenarios, that is a good indicator that you should take a step back and redesign for the more general case. Due to all the possible combinations of WITS producers and consumers and customer set up scenarios requirements, it would have been unwise to build something to work specifically for each set up. We decided then to rebuild the WITS framework inside of Eclipse Touch with the following design principles in mind.

Design principles

• Flexibility: WITS should support any set up, within reason, that the customer decides they want to use
• Compatibility: WITS input and output should be completely configurable as to support any new or old or different WITS consumer or producer
• Ease of use: Potentially in contrast to the compatibility principle, WITS should not be so hard to configure as to make it unusable to someone without extensive training

Multiple Channels

Multiple generic channel support was added to satisfy the flexibility principle. This means that now on any instance of Eclipse Touch you can configure with any number of WTIS channels that you would like. Logically a WITS channel is just a serial port on the machine eclipse touch is running on paired together with an input map, an output map, and various other settings. The idea of an explicit input or output WITS channel was scrapped to make things more generic and flexible.

Figure 1. Pictured here is the WITS configuration window inside of Eclipse Touch. In this example, there is one channel setup to talk to an EDR, one setup to talk to a Gamma Logger, and another that is not configured. You could add as many as you have COM ports on your machine. Each channel here independently configurable.

Input/Output Maps

Each instance of Eclipse Touch can configure any number of WITS channels and each WITS channel has its own configurable input and output map. These maps determine what each specific WITS channel can accept and what it will output. This is what is required to be compatible with any system. The user can now select specifically what they want to accept and what they want to output and what IDs should be used or expected.

Figure 2. Pictured here is the individual WITS channel mapping configuration screen. On the left you define what the channel will accept and what label that ID should map to. On the right you define what the channel will output and what IDs to use for each label.

Everywhere Availability

WITS data consumed on any particular WITS channel of any of an instance of Eclipse Touch is available for output on any channel of any instance in the LocalSync/RemoteSync network. This contributes massively to the ease of use of the system. You can connect any consumer or producer to the closest or most conveniently available Eclipse Touch instance.

NetWITS origin

Interestingly the WITS implementation in Eclipse Touch was sort of born out of the ideas and lessons learned from the development and use of NetWITS. NetWITS would take a WITS serial input an broadcast it to any number of other instances running on the same LAN without doing any sort of translation, whatever value was input would be output directly as it was read. The Eclipse Touch implementation of WITS had to build on top of this and introduce a translation layer, to go from ID value pairs into generic label value pairs, that would configurable per channel.

Examples in practice

Generally speaking, the workflow is something like this: A WITS message is read on some channel, it’s ID is parsed out and checked for presence in the input map. If that ID does not exist in the input map for that channel then nothing more happens. If the ID is found, then the value just read in is now associated with the translated label. That new label value pair is passed around inside the Eclipse Touch network and not translated back to an ID value pair again until it hits another WITS channel mapping that contains the label. That is to say, if another channel is configured to output that label, ie it has that label associated with some ID, then the translation occurs and that new ID value pair that's just been constructed is transmitted over the serial port configured for that channel.

Here are a few examples of the different WITS setups achievable with Eclipse Touch.