PSX Arduino Integration

[John Golin]

G'day;

With the detailed systems information available from the PSX interface, I thought we might be able to take advantage of off the shelf microcontrollers such as Arduino, and make them work with PSX.

I've been playing with this for a while, trying to get things working - and here is a vid of the Hydraulics panel lights: (see notes below the video in Youtube for more info).

http://youtu.be/W_INKWPZ5oc

The hardware behind this is;
- an Arduino Uno
- an Ethernet Sheild
- MCP23S17 chips (for inputs)
- TLC5940 (for outputs)

The software is:
- A HEAP of custom libraries and code!


Note - there is NO PC between the 'panel' and PSX.  The Arduino+Ethernet connects direct to PSX over the network.

Still in the early stages and lots to get done, but very promising so far and it shows what sort of stuff is possible with the amazing systems detail and incredible 3rd party interface PSX provides!

Apologies for the terrible quality - initially this was posted internally for Hardy, but he suggested I post it here as well.

[Roel Raeven]

Thx John,

Well done. I have an Arduino over here, but never found time, beside from the standard Arduino stuff to test it in a simulator environment. Looks promising. Are you willing to share the code in a later stadium? I'm willing to help you developing the code, but I'm not on the fast track now because my daily business costs me a lot of time and energy.

[John Golin]

Yes, the intention is to make it all available to others - however it will still be a while before it is in a suitable state.

Through the use of custom libraries and functions, only relatively simple changes are required to customise for particular solutions (e.g. Hydraulics panel, *Circuit breakers, etc).

As the Arduino is so open there are a lot of options available - much of the process has been finding the right mix of hardware, configuration and software to get the job done AND work together.  (e.g. you can't get a TLC5940 working with an Ethernet shield 'out of the box').  There are also a lot of caveats and gotchas with the Arduino chip itself - which is fine, as long as you are aware of them! Another challenge has been performance optimisation - the Arduino is single threaded, so the code must be very efficient and avoid blocking as much as possible - e.g. 'raw' scanning of inputs (the traditional way people program Arduinos) is not suitable for low latency code, we need to use interrupts extensively.

And lets not even talk about the restricted RAM - 32k program and only 2k working!

We'll have to document this to explain why things are designed the way they are, which is a major exercise in itself.    There are a lot of other components to the solution that are not immediately apparent - automatic Lexicon handling, basic web server for on-the-fly tweaking of some settings (including storage of settings in EEPROM for persistence on power down), etc.

All this means it's actually easier for me to develop on my own at the moment... the dependencies across hardware and software are quite significant!  There is already  an unnamed elf looking at tidying up the hardware circuits with more dilligence than my prototyping (decoupling capacitors etc!).

Anyhow, more to come.

* The Circuit breaker panels were the main driver for this implementation.  I wanted to be able to wire them all up simply and cheaply - which is now possible. All other types of switches, gauges, lights etc flowed from that initial goal.

[John Golin]

Here are some additional hardware interface examples - again apologies for the quality - they are Alpha Proof-of-concept videos!

Circuit Breakers: http://youtu.be/ohUj2xsGhg8

Crew Comms Display: http://youtu.be/MLT-A1mDE5Y

Servo / button / switch (Outflow Control Panel): http://youtu.be/rksMIbi35wY

[Hardy Heinlin]

Servo / button / switch (Outflow Control Panel): http://youtu.be/rksMIbi35wY

John, have you worked in an animation studio before? I think you've done a nice choreography here with  these black feathered ducks and their white heads. They are probably married. At 00:40 the left duck is turning his head over to her asking, "Will you give me a kiss?". Alas, at 00:47 she's turning her head away.

The funny music matches this animation very well :-)


/-|

[John Golin]

Hehe... definitely not... the music is the free stuff you can put on in Youtube, and was something I chucked on there to cover up the background noise and mobile phone buzzing.  Any appearance of deliberation is purely coincidental!

[martin]

these black feathered ducks

My immediate association on seeing the video: some rather sinister birds in dialog (was thinking more of vultures, though, or possibly some avian wraiths from the Tolkienian Universe...)
 :shock:

[frumpy]

I'm trying to make a simple MCP too. It's supposed to work
with X-Plane (Teensy board). Hardware part is mostly done,
now comes the programming.  :?

[falconeye]

Hello Frumpy,

could you pleae tell me which switches you use or
where you have bought them? When PSX is out I plan to make
something similar. If I have enough time then :-)

Greetings

[frumpy]

If you mean the LED-buttons, they are a little hard to find:

http://www.conrad.de/ce/de/product/701157/Miniatur-Anreih-Print-Drucktaster-125-VAC-1-A-mit-integrierter-LED-Schwarz-LED-Art-Gruen-Drucktaster-1polig-Ein

Qualitywise they are "okay", do not expect anything too fancy here.

Encoders are cheap ALPS. Next time I would go for a more distinctive click,
they are too soft.

If I have the time, I will do a little tutorial how to build and integrate
into X-Plane. Right now I am trapped with the Pareto-principle.  

[falconeye]

Aha Conrad. Thank you for the hint.
And yes, a tutorial would be great.
Good luck with the programming.

Cheers

[John Golin]

I'm trying to make a simple MCP too. It's supposed to work
with X-Plane (Teensy board). Hardware part is mostly done,
now comes the programming.  :?

Ah the fun bit!

[the mad hatter]

Hi John

Is it still your intent to make this code available if so is it going to carry any $$$  to it ? Looking at various options Arduino is certainly the way to go.

If you are going to make this available when do you think this will happen? Are you prepared to make available what you have achieved thus far ? No doubt this has been mammoth task!

[John Golin]

G'day!

Yes, the intention at this state is to make it all available for free for non-commercial use...

We've still got some 'tuning' and refining to do of the various libraries and code which  allow us to do things faster and utilise less memory - making one set of libraries compatible across a variety of cockpit interfaces with such stringent memory and speed restrictions can sometimes require redesign across several different libraries, so it will be a little while until it is in a settled state suitable for release.

For example, at the moment I have been working to greatly increase the speed of reading the Ethernet traffic - the default way described on the Arduino site is okay, but digging into the code reveals there are other ways to read the data with much less overhead.  I don't want to run the risk of ever hearing anyone complain that there was a delay or a missed button press so am recoding some sections to use this new technique.

I think my  (internal) technical background doco has reached around 90 pages of information on specific techniques, tricks and design decisions - I'm sure it will get longer!

e.g. did you know that division on the Arduino is a very slow process? And 'floats' are very, very bad performance wise. Also, switching between the multiple analog inputs and taking a reading takes a big chunk of time... And if you scan a heap of digital inputs to see if a switch has changed state, this time adds up and you might miss something else.

Each of these things in themselves may not be a big deal, but when you try to do quite a few things at once with the board, you need to look for smarter ways of doing each.  This can include specific addon hardware (e.g. chips that provide an interrupt on change so you don't constantly scan inputs), or using smarter lower level coding in the software libraries (write directly to all the inputs at once, rather than one at a time).

[the mad hatter]

HI John

thank you for the very quick and full reply ... Yes I fully understand what you are saying the libraries and the contents thereof is both time time consuming and complex

may I also ask do you have say something one can play with in the interium that is not dependant on such complex issues that I can play with with help get me used to the processes involved that would give me a happy face

I look forward to your release in the not too distant future

thanks

[the mad hatter]

Its okay good sir have since resolved my issue thanks and I will not be going that route although Arduino is user friendly:  As you said the libraries are just way to complex and require unique coding

[John Golin]

MCP 7 Segment Displays:

Another quick update - I'm still working my way around the various inputs and displays on the flightdeck writing libraries# for them...

One recent creation was libraries to handle all the 7 Segment type displays in the cockpit (MCP, RCP, XPDR),

You can get a simple led display set on eBay, connect it up to the Arduino on 3 pins, and add a few lines of code to check for updates from PSX and update the displays (using the new libraries).

Here is a vid of some of the cool things PSX lets you do:

Video: http://youtu.be/U9rvGrWunyE

Note - Turning the physical encoder does not directly update the seven segment displays!  This is a HUGE change for software and hardware integrators to get their head around.

Turning the rotary encoder sends the rotary encoder information to PSX (i.e. 'Alt knob turned +1').  PSX then updates the Altitude window display and I read this on the network and display the value PSX provides.  PSX is God.

e.g.

* MCP alt is set at 22000
* Rotary encoder turned clockwise 1 unit
* I send to PSX Qh80=1  (Qh80 is the MCP Alt knob).
* PSX turns it's MCP Altitude knob 1 unit clockwise
* PSX now has the MCP Alt Window displaying 22100

Any changes are sent over the network, so:

* PSX sends Qi35=22100 (Qi35 is the MCP Altitude Window display)
* I am listening for Qi35 - I parse the string
* I send 22100 to the display

Rinse, repeat.


___________________________________________________________________

# libraries are just a bunch of code that takes all the hard work out of the main program, and provides you a couple of simple commands to do things.  e.g. 'Print' would have a bunch of code behind it, but you don't need to see that, you just type 'Print(hello)' and some library somewhere has a function 'Print' that does all the hard work.

In this case, there are a couple of libraries - PSXLedControl and PSXLedWindow

- PSXLedControl is the chip and all it's attached digits.
- PSXLedWindow is the specific display item - e.g. heading or altitude

Below is a simplified example of what these libraries allow you to do


tell the Arduino what is attached: (the two variables are the logical aircraft power circuit for this display, and the number of actual hardware chips I have attached)

Code Select Expand


PSXLedControl myLedControl(gT137, 2);                            // set up the hardware



how you want to use it: (the variables are the hardware we are displaying on, the type of the display, the chip this will display on, and the number of the rightmost  digit on that chip for the item)

Code Select Expand


PSXLedWindow myAlt(&myLedControl, ALT, 0, 0);                       // chip 0 digit 0 - Create object for the Alt characters
PSXLedWindow mySpd(&myLedControl, SPD, 1, 4);                       // chip 1, right char is at digit 4 (reading right to left)
PSXLedWindow myHdg(&myLedControl, HDG, 1, 0);                       //  chip 1, pos 0



Then in the running loop, and when we detect the variable from PSX, update that Output: (qIndex is the code we are waiting for, qChars is the data from PSX).

Code Select Expand


else if (qIndex==McpWdoAlt)  {myAlt.updateOutput(atoi(qChars));}  
else if (qIndex==McpWdoHdg)  {myHdg.updateOutput(atoi(qChars));}  
else if (qIndex==McpWdoSpd)  {mySpd.updateOutput(atoi(qChars));}  


[/i]

[JP59]

I'm really interested about your investigations to create an interface for our cockpit hardware, thank you very much to make it accessible to the whole community for free. Witch software do you use to create libraries / program the arduino ? Is it the software from Arduino ?

Edit : What about the 14 I/O of the Arduino Uno ? Do you plan to use an expansion module in order to handle the hundreds of switches we have in our cockpits ? And do you think you can store all the lines of code and libraries of a complete cockpit in the 32Kb of an Uno ? Sorry for these many and maybe stupid newie questions but I just try to understand.

[John Golin]

We have thrown out the old way of thinking and moved to an entirely new philosophy

Basically, each sub panel or small collection of panels will have it's own Arduino / breakout card and ethernet connection to PSX.  So, for example, the Hydraulics Panel has a power connector (say 12V or 28V) and an ethernet connector to the outside world, and that is it.   There may be one or two small panels where we link them together (the IRS,  the EEC etc) but generally each panel will have it's own hardware.

To keep costs down we look at purchasing Arduino clones such as the ProMini and connecting to a clone Ethernet shield.  

Addon chips are essential to a fast, accurate and flexible solution.  A LOT of work has gone into finding various chips that are flexible, 'common' in the Arduino world, cheap / reasonably priced, and can work together.... and then crafting the code to make it so!

The general chips used are MCP23S17 for inputs and TLC5940NT for outputs.

Oh and I use the Arduino IDE for the specific 'sketches' for a panel, but the libraries are written in C++ in Notepad++

[JP59]

Thank you John for this very detailed brieffing. I have some difficulties to understand physically what is wired with what, through witch technology (USB, Serial or Ethernet). I just try to immagine how many Arduino a complete cockpit will contain, may be 40-50 ! How do you connect physicaly your Arduino Uno to the computer, USB (direct) or Ethernet (via Arduino Ethernet Shield) ? How do you expect to make the connexions to the outside world ? With a giant USB/Ethernet hub ? I do not understand the concept of clone Ethernet Shield, maybe it is the key for understanding.

Edit : One more question : why do you work with one Arduino Uno plus one Arduino Ethernet Shield and not consider to get the Arduino Ethernet card directly ? Is it a question of "talking" with the I/O Microcontrolers ?