[size=6]Hello![/size]

Teensy boards are cheap, Arduino-compatible USB project boards that, uniquely, have native support for communicating with X-Plane. This makes it very easy to connect all kinds of hardware to X-Plane, and build cheap control panels, instruments, etc. It has an X-Plane plugin which handles the computer's side of the communication - you just program the Teensy board (in C++, through the Arduino compiler) to link up the sim's datarefs and commands with the Teensy's pins or with easy-to-use Arduino hardware interface libraries.

Here's a demonstration of a 'hello world' Teensy project, filmed using the world's worst phone camera:

http://www.youtube.com/watch?feature=player_embedded&v=K8YCFy65yMk

For more information, see [url="http://www.pjrc.com/teensy/td_flightsim.html"]the official guide to Teensy Flight Sim Interfacing[/url] or my blog: [url="http://simelectronics.wordpress.com"]simelectronics.wordpress.com[/url]. I'll be adding general how-to guides, and descriptions of my own projects, in due course.

[b]Please consider starting a new thread[/b] instead of posting more into this one. I started the simelectronics blog precisely because this thread is far too big to easily read!

Here's a rough table of contents for this thread:
Early development of the code, from post 1 (here!)
People begin to use Teensies and the posts stop being about beta bugs, from [url="http://forums.x-plane.org/index.php?showtopic=55952&st=160#entry631980"]post 168[/url].
Building servo-driven instruments (flaps position, VSI), from [url="http://forums.x-plane.org/index.php?showtopic=55952&st=220#entry638460"]post 226[/url].
Using an LED matrix display, [url="http://forums.x-plane.org/index.php?showtopic=55952&st=230#entry639316"]post 239[/url].
Garmin G1000 control board, [url="http://forums.x-plane.org/index.php?showtopic=55952&st=250#entry643709"]post 255[/url].
Making an LED flash, [url="http://forums.x-plane.org/index.php?showtopic=55952&st=280#entry646491"]post 264[/url].
I argue against putting simulation code (rather than plain interface code) into a Teensy sketch, then show a (now obsolete) method of making an annunciator simulator on a Teensy, [url="http://forums.x-plane.org/index.php?showtopic=55952&st=320#entry650241"]post 327[/url].
Connecting a rotary switch to a single analog-input pin, [url="http://forums.x-plane.org/index.php?showtopic=55952&st=330#entry656518"]post 335[/url].
Using the TeensyControls plugin with programs that aren't X-Plane, [url="http://forums.x-plane.org/index.php?showtopic=55952&st=340#entry664991"]post 346[/url].
Another discussion on annunciator simulation begins: [url="http://forums.x-plane.org/index.php?showtopic=55952&st=400#entry684219"]post somenumber[/url].
Building the 737's master warning system: [url="http://forums.x-plane.org/index.php?showtopic=55952&st=420#entry685314"]post 421[/url].
Introducing the SimLED class, for a dead easy way to connect LEDs to datarefs, and optionally have multiple master-warning light, bulb test buttons, power supply simulation etc: [url="http://forums.x-plane.org/index.php?showtopic=55952&st=460#entry687269"]post 465[/url]. SimLED is still being actively worked on and I'll write about it at simelectroncs.wordpress.com when it's a bit more refined, but it is very usable and helpful as it is today.
Arduino-based (but relevant hardware and electronics) X-Plane control panel: [url="http://forums.x-plane.org/index.php?showtopic=55952&st=470#entry688494"]post 474[/url].

I hope you enjoy reading about Teensy boards, and the empowering experience of building your own hardware.

Cheers!
Dozer

Disclaimer: nothing to disclaim. I have no association with Teensy, PJRC, Paul Stoffregen, or their business partners, distributors etc, except as a happy customer!

The rest of this post is as originally written.

[hr]
Hi all,

I want to build small hardware modules representing specific autopilots, panels etc from particular aircraft, for instance the S.E.P.2 autopilot used in the Comet and Constellation and featured in Guy Montagu-Pollock's upcoming Comet model - see the second screenshot here: [url="http://www.dh-aircraft.co.uk/news/files/e940e09b4dec51f8310fd546a0f99a6e-68.html"]http://www.dh-aircra...0f99a6e-68.html[/url]

It's a simple unit, basically comprising thirteen switches (seven toggle switches and six pushbuttons in various forms) and one annunciator light. Ignoring the light for the moment (and the fact that some of those switches won't do anything in sim yet), couldn't I wire the switches to a [url="http://www.pjrc.com/store/teensypp_pins.html"]Teensy USB HID board[/url] (price: next to nothing), configure it with [url="http://generichid.sourceforge.net/index.html"]GenericHID[/url] as a games controller with 13 buttons (price: free), then plug it into any Windows, Mac or Linux computer and bind the switches to X-Plane controls without further fuss?

And also, if the device works, would it be possible to build a bunch of small hardware devices, each simulating a small part of a specific aircraft, say the overhead panel of the MU-2 or the BK-117 pedestal, and run off a single USB HID board configured as a games controller? Then when you'd like to fly a particular aircraft you could plug in the panels you have for that aircraft, place them around your desk, and fly with a little less panning round the cockpit.

It just seems a little cheaper and possibly more convenient than some of the flight sim specific boards out there (which I've spent all of two days fitfully researching).

Configuring outputs would require more work and probably platform-specific work - I understand that for input a USB HID can be plug-and-play on all platforms if it's reasonably simple, but for output there must be plugins and device-specific USB drivers to link the plugin to the particular device.

Edited October 31, 201212 yr by Dozer

Over the last years I heard many reports on USB:
Problems arise with multiple USB devices, typically beyond 7 devices, even with powered hubs.
Numbering and initializing USB devices seems to be non-deterministic and inconsistent between repeated starts of your OS.
This problem is aggravated by your desire to swap devices depending on aircraft.
With inconsistent numbering all your assignments are moot.
With the popular recommendation of deleting your preferences your assignments are gone once more.

All these problems happen across all platforms - speak of true platform independence here! As there are only few people with such "heavy" setups, these knowledge is very sparse, and I accumulated it over several years.

It can be done and it will even work with a determined setting, but you are opening a nasty can of worms in terms of configuring all those devices.

Good luck!

[quote name='Dozer' timestamp='1325414245' post='619037']
Hi all,

I want to build small hardware modules representing specific autopilots, panels etc from particular aircraft, for instance the S.E.P.2 autopilot used in the Comet and Constellation and featured in Guy Montagu-Pollock's upcoming Comet model - see the second screenshot here: [url="http://www.dh-aircraft.co.uk/news/files/e940e09b4dec51f8310fd546a0f99a6e-68.html"]http://www.dh-aircra...0f99a6e-68.html[/url]

It's a simple unit, basically comprising thirteen switches (seven toggle switches and six pushbuttons in various forms) and one annunciator light. Ignoring the light for the moment (and the fact that many of those switches won't do anything in sim yet), couldn't I wire the switches to a [url="http://www.pjrc.com/store/teensypp_pins.html"]Teensy USB HID board[/url] (price: next to nothing), configure it with [url="http://generichid.sourceforge.net/index.html"]GenericHID[/url] as a games controller with 13 buttons (price: free), then plug it into any Windows, Mac or Linux computer and bind the switches to X-Plane controls without further fuss?

And also, if the device works, would it be possible to build a bunch of small hardware devices, each simulating a small part of a specific aircraft, say the overhead panel of the MU-2 or the BK-117 pedestal, and run off a single USB HID board configured as a games controller? Then when you'd like to fly a particular aircraft you could plug in the panels you have for that aircraft, place them around your desk, and fly with a little less panning round the cockpit.

It just seems a little cheaper and possibly more convenient than some of the flight sim specific boards out there (which I've spent all of two days fitfully researching).

Configuring outputs would require more work and probably platform-specific work - I understand that for input a USB HID can be plug-and-play on all platforms if it's reasonably simple, but for output there must be plugins and device-specific USB drivers to link the plugin to the particular device.
[/quote]
You may want to look at what I have done for the Saitek pro flight series (Switch, Radio, Multi, BIP) which are all HID based. My project is open sourced so anything you find in there is available for you to use and is cross platform. For the HID specific differences between the platforms I use a library called hidapi by Alan Ott that allows the same call to be used for each platform. Any help or added info please feel free to contact me here of by PM.

Happy New Year Bill

Thanks very much for the replies!

Dr Coolgood I very much appreciate your experience - I had no idea I'd be opening such a can of worms with USB. I had the idea that USB was a magical system where an indefinite number of arbitrary devices can be plug-and-play'd.

Thanks very much Bill - I'm just beginning a 12-hour night shift doing not very much. I'll be studying your code. Thanks for the examples!

I think I might go ahead with a USB HID autopilot unit, and maybe a Monroy ATD-300 TrafficWatch device (it's probably easier to build a hardware version than to retrospectively add one to the 3d cockpits of existing aircraft). That way I can get experience in hardware building and device configuring.

Perhaps the ultimate method is to use ethernet and have each hardware module as a standalone Arduino-esque device - perhaps the [url=http://www.raspberrypi.org/]Raspberry Pi[/url]. This would require platform-specific drivers to communicate with the hardware, and platform-specific plugins to communicate with the drivers - unless it can all be done by the plugin.

If you only have one HID device with all the gadgets hanging off it, USB bus numbering is no longer a problem. So that plan is probably a smart way to go about it.

There is also this: http://usbip.sourceforge.net/

The "USB is magical" perception is mostly a projection based on the positive experience with your keyboard, mouse, audio and web cam - devices you seldomly remove. Still all need drivers and if those are poorly written - I heard of people installing the exact same printer driver for _each_ USB connector their box had...
For network access our [url="http://www.cross-simulator.com"]Simulator Communication System[/url] uses the same 50 lines of code for each platform, including Android. By using the standarized CAN Aerospace protocol we made our communication task simple. While a CAN processor costs 5 - 10 Euro you get a rock solid interface - which proves its sturdiness in millions of cars and airborne equipment.

Thanks Dr Coolgood, I remember Philip mentioning this re Eurofighter simulators a while back. Do you know where I might find CAN processors similar to the [url=http://www.pjrc.com/teensy/index.html]Teensy++ USB HID board[/url] in terms of price and capability?

That would be this: http://www.embeddedartists.com/products/lpcxpresso/lpc11C24_xpr.php

It looks like it would be as easy, or perhaps easier, to use CAN over Ethernet and an Arduino or similar, for hooking up controllers.

Fantastic! Thanks very much Andrew! Aaargh now I have a dilemma - go to sleep after my 12-hour shift, or spend a few hours now reading about LPCXpresso boards and end up waking up fifteen minutes before my next 12-hour shift...

For windows OS the easiest and cheapest solution is using multiple keyboards with HIDmacros utility: [media]http://www.youtube.com/watch?v=l0tRyMpekQY[/media]
The video is for FSX, but same can be done for XPL.

Andrew, thats what we say for several years now.
The HID videeo above did not convince me. Most people want to touch a rotary for changing frequencies. This is a matter of personal taste, many people fly X-Plane without joystick. Still it only works for Windos, leaving half of the X-Plane community down.

[quote name='me2d' timestamp='1325490875' post='619255']
For windows OS the easiest and cheapest solution is using multiple keyboards with HIDmacros utility:
The video is for FSX, but same can be done for XPL.
[/quote]
Thanks for that Me2d, but I'd rather go with something that works for Mac and Linux!

Edited January 2, 201213 yr by Dozer

I've just ordered a couple of Teensy USB HID cards and a load of pushbutton and toggle switches. I'll use them for practise, try and build some cheap, crude, throwawayable hardware, then see about moving onto CAN or ethernet devices when I've got more experience of hardware building and be less likely to brick their more expensive boards. They won't arrive for a few weeks, and I'll be busy at work until the end of January, but that will give me time to develop my ideas for how to actually build the components.

I'm thinking of just mounting the switches on a cardboard box, with a Teensy board on a breadboard inside. Or cut holes into the casing of a dead DVD or HDD drive. There's a lot for me to learn...

Well, preliminary tests confirm all you said about the dangers of USB. I got a wired Microsoft Xbox 360 gamepad and plugged it in, planning to assign it to autopilot functions until I can build my own hardware. But X-Plane/WinXP placed it as the first controller, displacing my X-52 and rudder to be second and third controllers, so none of the key or axis commands were in the right place Worse, when I removed the controller, all the axis assignments reverted back to the way they were before. So if you're using USB HID game controllers through the OS, your choice is to either never change the controller setup, or be prepared to reassign everything whenever you add or remove one single controller. At least on Windows.

Anything other than a test device must use other ways to communicate with the sim...

Edited January 8, 201213 yr by Dozer

Hi everyone... I'm the guy behind the Teensy USB boards. Dozer and I have exchanged numerous emails recently. I've long wanted to better support DIY flight simulation controls. This project is motivating me to finally work on it seriously.

I'm currently writing an X-Plane plugin and support in Teensyduino for reliably linking devices to X-Plane command and data refs. I'm doing the initial development on Mac, but of course I'll port to Windows and Linux when it's working.

At the moment I don't have a lot of details to share. I just want to let you know I'm working on this. If anyone else is interested, I could really use early feedback or beta testing (especially on Mac OS-X). My direct email is paul at pjrc dot com.

Fantastic! Thanks Paul.

I've made a lot of progress on my plugin. It's currently mac only. It's now receiving command refs and sending data refs. I just finished soldering a rotary encoder to a couple pins on my test board, so now I have a source of input that will be useful for testing data refs from Teensy to Mac.

I do have a question about the order to apply change. If multiple input messages appear during the same simulation frame, should I do execute commands before writing data refs? That's what I've got so far. Or does it make sense to write to data refs first, then do commands? Of course, any data refs that get read to be sent to Teensy (presumably for display) are read after all the queued commands and data ref writes are finished.

In a few days I hope to have a Mac-only beta test ready. Windows and Linux should come about a week later.

Are you adding yet another protocol to the existing varieties, or are you relying on something stable and standarized like CAN Aerospace like we implemented in the [url="http://www.cross-simulator.com"]Simulator Communication System[/url]?

Hey Dr.Coolgood,

Out of curiosity, is the extension for CDU I/O already implemented on SCS? I wonder if that's what Phillip is using for his remote interface to the CRJ's CDU. If so, do you know if it's documented?

Edited January 11, 201213 yr by wotaskd

If I understand it right, Paul is writing directly from Teensy to X-Plane's existing datarefs and plugins. Which basically puts it on the same level as 2d generic instruments and 3d manipulators/animations in terms of interaction with the sim. If I understand it right...?

Today I purchased a drill, a bunch of HSS bits, and some scraps of sheet aluminium. Going to try panel-mounting some switches...

Hi Paul!

I am very interested in checking out your teensy plugin for mac. My experience with HID devices that have a plugin to interface with x-plane seem to offer better reliability than devices that depend on the generic joystick support found in the OS and x-plane. Go flight modules are a classic example. I can have any go flight modules in any configuration or bus order and the plugin remembers the settings. So I am very excited with what your working on. I currently have 14 usb devices running my 737-300 and I figure another 30 or so inputs and about 6 rotary encoders left until Im done. Any way, if I can add more devices and do it cheaper and more stable I'm on board. Thanks again and I look forward to your progress. If you need any help please let me know.

Cheers

If you'd like an early beta test copy, please email me directly, paul at pjrc dot com. I'm planning to send a few Mac-only copies out this weekend. Next week I'll start porting to Windows and Linux, as well as fill in a number of missing bits and pieces.

This only works with the Teensy and Teensy++ USB boards. If you don't have a Teensy to actually wire up any buttons or indicators, this code won't do you any good.

Here is a quick photo of my test board, with an LCD showing the NAV1 frequency. The 2 pushbuttons send the fine up and fine down commands, and the rotary knob changes the value directly.



[img]http://www.pjrc.com/teensy/beta/xplane_demo1.jpg[/img]


Here is the Arduino-based code used on this Teensy to make this work. Sadly, I can't seem to get this forum to preserve the indenting, so it's not as easy to read as it should be. (If anyone knows how, please tell me and I'll edit this post)

The magic here is in the 4 special X-Plane variables. A variable of XPlaneInteger type works very much like an ordinary integer within Arduino, but when you write to it, USB communication sends your change a plugin which writes to the actual dataref within X-Plane. The plugin tracks when X-Plane changes data and keeps your program running on Teensy updated. You can set up a function to be automatically run when X-Plane makes changes, as you can see below with the update_lcd() function.

Arduino is a very popular platform for DIY electronics, mainly because it provides a powerful but easy-to-use programming environment. There is a huge market of very affordable hardware available, and numerous website with DIY info about interfacing pretty much anything you can imagine. Teensy is an Arduino compatible board, but with special USB capability not found on normal Arduino. This project uses that native USB communication to bring access to X-Plane commands and data refs into very easy-to-use Arduino programming.

[b]EDIT: the variable types and other details have changed since this very early code. PLEASE DO NOT USE this code. See the examples that Teensyduino installs in Arduino's menu, File > Examples > Teensy > USB_FlightSim.[/b]

[b]EDIT: ancient code removed. Please download Teensyduino, install it into Arduino, and then open the examples.[/b]

Edited June 14, 201213 yr by PaulStoffregen

Just a few more details....

My plugin detects Teensy boards being attached and removed, so you can plug devices in while the simulator is running. Because the exact data ref names are in your code running on Teensy, they automatically work. You can even reprogram a Teensy while the simulator is still running, and when it reappears with your new programming, whatever command and data refs you're using automatically work without restarting X-Plane or the plugin.

Any number of Teensy boards can be used with the plugin. While USB theoretically supports up to 127 devices, probably beyond about 30 to 50 boards, bandwidth issues might show up. Hubs with the "multi-TT" feature should always be used. Powered USB hubs are definitely needed if arranged in 2 tiers.

The plugin supports any number of command and data refs. Because Teensy is a small, low-cost microcontroller platform, a rough guideline would be to implement no more than about 50 data refs per Teensy board. If you need to access more, a good strategy would plan to divide the work between multiple Teensy boards.

A few people have asked me how to use this with SCS, or how it relates to SCS. The simple answer: it doesn't. SCS is a very advanced system using Ethernet and CAN protocols, with sophisticated software layers that can map functions to multiple simulators. Teensyduino's new flight sim USB support is a very simple, low-cost system. It is only USB and can not support any specific protocols like CAN Aerospace. It currently only works with X-Plane. There is no multi-simulator support, or any other software layers translating protocols.

The functionality is merely very simple mapping X-Plane's commands and data refs to variables you can access with Arduino-based code. Teensy is a low-cost platform ($16 plus a USB cable), and this development aims to make the electronics for DIY flight controls easy and affordable.

Paul, this is absolutely fantastic. Can't wait for my boards to arrive!
What amazes me more than anything is that you've got all this working in less than eight days!

Now it's probably easier to build physical controls than to model them in 3d.

Edited January 12, 201213 yr by Dozer

It has come together pretty quickly, but then I'm building on top of the existing Teensyduino platform that has excellent USB support, which in turn is built on top of Arduino which supports tons of DIY hardware. X-Plane's plugin API has some of the best documentation I've ever seen... not too much, but just enough to be perfectly clear and lots of examples. That definitely helped!