0
\$\begingroup\$

Before I get started, I am a software developer and I have extremely limited knowledge of circuitry, so please be gentle.

In it's most basic form, I guess my question is, how can I wire up a SPDT switch so that when I change its position, a signal is sent to my Mac running OS X as an input device? I want to build a panel of switches for use with a flight simulator (X-Plane 10) running on my Mac.

Originally, I planned on purchasing this:Desktop Aviator Model 2237. I would then solder a number of switches onto the circuit board and when I flicked a switch, the processor would recognise the change and send a 1/4 second signal to my Mac, which would be picked up and used as an input into my flight simulator to flick that particular switch in the simulated world. The end product would end up looking something like this: Desktop Aviator Model 2620. Unfortunately, the circuit board is not compatible with Mac OS.

Is there a way I can buy (or create) something similar that will work with my Mac?

I have had a look at a few other questions on here and found

electronics.stackexchange.com/questions/74/pic-microcontroller-programming-on-mac-os-x

most relevant, but not particularly helpful. (Sorry, can't post more than 2 links with my lack of rep on this site). One of the answers to that question referenced this product:

www.teammojo.org/PICkit/pickit1.html

, but I am not sure if this is what I am looking for (as in, I don't understand what it does). As I said, I am absolute beginner and I understand that the Mac side of things isn't particularly well documented. My initial Google searches just returned a heap of OS X Cocoa code for programmatic switches.

Are there any tutorials or articles that might point me in the right direction?

Thanks a lot in advance.

\$\endgroup\$
  • 1
    \$\begingroup\$ How many switches do you need? What is your flight simulator software? Specifically, how does it expect to get information from switches? There are many, many possible hardware solutions, but the constraint is the software that you need to talk to. Without that information, we are just guessing. \$\endgroup\$ – gbulmer Jan 20 '16 at 11:00
  • \$\begingroup\$ As I've mentioned, it is X-Plane 10. What additional info do you require about the software? And about a dozen switches would be great but I guess as many as possible. The software recognises inputs the same way it recognises pressing a button on a joystick. I guess ultimately if I could make a device that is registered like a gaming joystick with buttons that would be great. \$\endgroup\$ – Matt Kelly Jan 21 '16 at 9:58
  • \$\begingroup\$ Why do you say "Unfortunately, the circuit board is not compatible with Mac OS"? What evidence is their? That raises alarm bells for me because a Mac supports standard USB devices. I'd like you to find out how the X-Plane 10 software interfaces with switches. For example, does a switch box that works look like a common USB device, e.g. CDC serial, or HID? If it isn't a common USB device, what is it? Making a USB serial is much easier than other USB devices. \$\endgroup\$ – gbulmer Jan 21 '16 at 17:32
  • \$\begingroup\$ I apologise if I've offended you, that was not my intention. As I mentioned, I have very limited experience with electronics, could you please explain what you mean by CDC serial and HID? I was told by the manufacturer that the product is not compatible with Mac. That is all I have to go on. I was hoping someone on here might be able to point me in the right direction to answer some of my questions, but now I just have more. All I know is that X-Plane recognises input from USB joysticks and the buttons on them. Could you please explain in laymans terms what further information you need? \$\endgroup\$ – Matt Kelly Jan 22 '16 at 4:38
  • \$\begingroup\$ I am not offended. However, you seem to be missing a lot of crucial information, at least from your question. The fact that the software recognises a USB joystick (which may look like a mouse), and some buttons, doesn't mean that the game is prepared to receive switch information. What causes you to believe that the game, when running on Max OS X, can receive switch information from a hardware device? \$\endgroup\$ – gbulmer Jan 23 '16 at 5:05
0
\$\begingroup\$

Wiring up lots of switches is easy.

The hard part is making the switches look like a hardware device which the Mac version of the X-Plane 10 software will listen to. (AFAICT, you don't know of any such device. Yes?)

As a software developer, I assume you understand that the game will only interact in specific ways with specific hardware devices. It can't magically talk to something it wasn't programmed to interact with. So if X-Plane-on-Mac doesn't support reading messages to directly control switches, then it is going to be practically impossible.

Preferably the game will talk to a USB device, and that USB device will be a common standard device which Mac OS X already supports.

(Are their keyboard shortcuts which change switches in the Mac version of X-Plane? If their are, it should be straightforward.)

Edit 2:
You've confirmed, there are keyboard and joystick shortcuts to control all of the switches you need to control.

So assuming that is a none-proprietary keyboard (reasonable), then you need to implement a USB HID device (as other answers say).

There are a bunch of approaches:

The most compact, neatest, solution would be Paul Stoffgren's Teensy USB boards; I think his work is outstanding. Also, for alternatives, Adafruit's ATmega32u4 Breakout Board and Sparkfun's Pro Micro

Sparkfun's Pro Micro link is an article showing how to emulate a USB HID keyboard, and send characters when pins are grounded (e.g. using a switch). This seems like a very good place to start.

Once you read and understand that, you can choose a bunch of ways to implement your hardware, using the list of options above.

The Arduino UNO with its built in ATmega16u2, might be easiest to get hold of; my local electronics store have them, or electronics distributers with next day delivery. There appears to be lots of information on the web too.

Note: Arduino-Nano hasn't got an ATmega8u2/ATmega16u2/ATmega32u4, so it is not suitable.

If the keyboard or joystick are proprietary, then read on ...

From a USB host system's view, USB hardware (devices) come in many 'flavours'. Each 'flavour' is a different type of hardware device. Each type of hardware device only implements a specific conversation with the host. The host OS needs to be prepared to have lots of different types of conversations with USB devices. The OS uses a device driver to do some of that work.

For example, USB mouse or keyboard (HID, Human Interface Device) is different from USB Flash drive, different from a USB CDC, etc. Mac OS X has device drivers that can interact with a USB HID devices, different device drivers for USB CDC, others for USB Flash drives, etc.

Some types of USB device are easy to build, some are hard. An OS will have device drivers for many standard USB devices. A game author could use a standard USB device. But that doesn't seem to fit with the "I was told by the manufacturer that the product is not compatible with Mac." comment. Try to get hold of the Windows USB device and try it on your Mac.

A way to 'lock' the USB device to the game is have a proprietary 'conversation' with their own USB device over that communication channel. So the USB hardware device might appear to be a standard USB device, and it may even work with other games, but it might share a secret conversation with its game, preventing other similar USB devices from other vendors working with their game.

Edit:
If X-Plane-on-Mac doesn't seem to work with a USB device that works with X-Plane-on-Windows, then X-Plane-on-Mac might not expect switches from a standard USB HID (Human Interface Device). This is probably the first thing to get clear.

Worse case; the author of the game may have decided to use some weird non-standard way to talk to, e.g. a game-controller, which only they sell, to make it harder to pirate a game, and to get extra income from sales of the game controller.

If it isn't USB, or a very simple technology that can be connected via USB, then it will likely be hard on Mac OS X.

The comments "Unfortunately, the circuit board is not compatible with Mac OS." and " I was told by the manufacturer that the product is not compatible with Mac." makes me suspect that the manufacturer may have done something to restrict the use of the 'switches' game controller.

It may be innocent, and it is just that Mac OS X does something weird when it sees the device.

So, figuring out exactly what game controller the game can use is crucial. It may be a standard USB device, or it might be deliberately perverse. Until you find a product, which works with your game while running on Mac OS X, there is no reason to believe that it is possible.

It might be possible to keep the game happy, and fool it into thinking it is talking to a special device. I imagine carefully worded web searches might find that information. However the game publisher may go after anyone publishing ways to subvert their technology, so that information may be hard to track down.

So you are going to need to do some research and detective work.

You might be able to find forums where people have used a third party games controller (i.e. set of switches) to work with your game.

To become familiar with some of the terminology, you might try Wikipedia, USB, "System Design".

You might also look at DTrace, which is a technology built into Mac OS X which might help you see enough of how the game interacts with USB devices to achieve your goal. For this to be useful, you'd need to have access to a Mac, running the game, and that needs to successfully listen to a product which behaves like a set of switches.

I don't want to dampen your enthusiasm. I might be wrong, and misunderstood what you are trying to do, or ow hard it might be to do.

However, unless it is much easier than you are making it sound, I think you need to find someone who has done something similar already, or can help you figure out the software/communication part of the problem. Otherwise it will be hard. I have done some simple reverse engineering of USB conversations (without hardware tools like a USB-sniffer), but with a well understood USB device, involving Open Source software (though so exotic it was slow to see exactly what was happening). Even that took days, and I understood quite a lot of stuff that you seem very unfamiliar with.

Edit:
If you can get hold of a 'USB sniffer' (low-speed may be enough), then you can see what the game is exchanging with the USB device. A USB sniffer inserts in the USB connection between host and device, and sends all the data to PC. It is brilliant for reverse-engineering higher-level USB communication.

If you can't get a USB sniffer, then one technique which may help nail the protocol is to run Windows & the game in a virtual machine, and try to observe its interaction with the USB device via the underlying operating system. I haven't tried it, but it might work on your Mac using DTrace to observe the communication.

Another technique is to make a 'poor-mans' DIY USB sniffer. It won't be as good as the real product, but would be lower-cost, and may be enough. Use a programmable device, which can emulate different USB devices, with several different devices already implemented. Look at LUFA which implements quite a few USB protocols, and Paul Stoffgren's Teensy USB boards, which use some of the LIFA libraries. The benefit of getting this to work is the same device could also be used to make your switch panel.

Whatever hardware you choose, it needs enough speed and memory and a USB device library, to pretend to be the USB device the game wants to see. It will also send everything (maybe over a serial-to-USB) to a monitoring PC. It may be trial and error, but unless the game is insanely profitable (in which case they may do something very weird), the USB device the game expects is likely to be something very standard with an extra bit of stuff on top.

\$\endgroup\$
  • \$\begingroup\$ Thanks @gbulmer, this is what I was looking for. I'll do some research and have a look. Thanks for pointing me in the right direction. \$\endgroup\$ – Matt Kelly Jan 24 '16 at 2:21
1
\$\begingroup\$

In short terms, any common USB HID device will do this. Keyboards and game pads use two slightly different versions of Human Interface Device reports. They use momentary switches. You could hack one up to add on/off switches. Bluetooth uses HID over bluetooth, essentially the same.

Or you can create a HID device from scratch, using any number of usb enabled microcontroller. Msp430 usb launchpad, Arduino Pro Micro or Leonardo, etc.

USB HID devices are universally supported by OSX. If Your software can't handle HID gamepads, use something like USB Overdrive to map gamepad to keyboard commands.

\$\endgroup\$
0
\$\begingroup\$

Use one of these: https://www.pjrc.com/teensy/teensy31.html -- it's a small Arduino MCU which can act as differing USB peripherals including a mouse, keyboard or joystick. Some simple programming of it can read many switches and send results back over USB.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.