So getting back to the CRJ refurb...

The buyer decided to get it working again...

Step 3 - Reverse engineering the whole system (hindsight being 20/20, the overhead panel was the best place to start)

Starting with the overhead panel, I wanted to see what parts were used to make it work. It was the easiest piece to start with as it was portable and could be brought into the office area where all of our computers are.

No part numbers on the square light up panel switches... not cool... Google it is... found them! Found the pin out for the wiring... documented

Part number for the toggle switches are on the switch... that's a help... documented.

Now for a look inside the electronics box for the overhead panel... there is a power supply for something, some green boards where the wires go and a connectors.

Now for the reverse engineering... the power supply provides power for the switches... at 12VDC... what the heck?

The little green boards are made by a company called Phidget... they are digital interface boards that see the physical switches and there are 5 of them... ok, totally cool. There are more than one type... the other interfaces the encoder (only 1) and another interfaces to the LED's on the switches (one of these too). Dig up some research on the phidget boards and find out that there is a driver for them. Install the driver and I can see the boards. I can see all the boards from a head count. Another piece of the hardware is functional. Woo hoo!

There is a mess of cabling between the electrical box and the overhead panel... and a ton of wires due to the amount of switches. So I start on the task of finding out who goes where in the cables and to which I/O port on which phidget board. Three days later, I have a wonderful spreadsheet of who goes where and what the switches do. I am starting to understand what is actually going on and how the system was engineered from a hardware standpoint.

Step 4 - Back to computer land

Starting with the Visual System computer, I powered on the system and documented what software was loading (Windows 7 64-bit, nice, i7CPU nice - not too old)... hum... Prepar3d v2 (oh wow), pmControls (?), pmSounds (?) and something else. Prepar3d crashes...hummm.

So I dismantle the computer, clean the contact on the video card and the memory modules. Clean up the key system wiring mess and by-pass it. System boots. Launch Prepar3d by itself and it runs. Cool. Check the configuration on Prepar3d and it has FSUIPC install with WideFS. Have no idea why... Prepar3d has SimConnect so why us FSUIPC and WideFS... no matter... document the settings.

So what in the world is pmControl and pmSound... Google to the rescue. The "pm" stands for Project Magenta. Seems they have been around for a while and still are. I am about to find documentation on web site... I can find it on pmSounds, pmSystems (that looks interesting), pmThis and that, but nothing on pmControls. Document... figure out later. pmSounds is for the aircraft audio and interfaces to Prepar3d via FSUIPC.

Document network setup and protocols... hard IP address set... good.

Start on the next computer - the glass interface computer. Dismantle this one prior to trying to boot it up. Wobbles and boots... groans... Windows XP (holy lord the computer is 10 years old!) and WideClient runs on startup and nothing else. What? Must have something to do with the network. Check the network and it is set to dynamic (oh, what the actual ?). Router that came with system is non-functional at present. Set the IP address to one up from the Visual System and hook them both up to a switch... Launched Prepar3d and WHOA! Glass software is loading... needs a serial number (why? how?). So it would seem that Prepar3d is launching the software on the remote machine. Awesome, but how. FSUIPC documentation to the rescue. Figure that out and now I can launch the Glass without Prepar3d's help. Digging around on the hard drive, I find the actual working copy for the glass where the serial numbers work. There are three different pieces of software - one for the pilot's glass, the second for the co-pilot's glass and the last for the center glass known as the EICAS. All of the software has the EXACT SAME NAME (not cool). The exe file is named pmCRJ.exe Having the same name for the three different functioning pieces of software is a nightmare for debugging the system. You have no idea who is actually running and where. There are two more pieces of software that run on this computer. One is the auto-pilot interface and the other is for the Flight Management System (FMS). Why in the world all of this is running on a single 10 year old computer is beyond me... I figure it out (wait and see)

The glass is in the cockpit and the computer are too far apart to work on properly. So, I install VNC on the Glass Computer and remote into it with my laptop so that I can re-setup the glass panels properly. There are two very expensive video cards in the computer to run 4 displays. Read thru the documentation from Project Magenta on how to setup the displays. All nice and centered again and rotated properly. So since the pilot controls for the stick haven't been checked, I hookup a joystick to Prepar3d and see if I can fly the CRJ in the computer so that I can check the Glass software. And it works... oh wow!!

So at this point, I have working glass and a working visual system. I know that the overhead panel is functional from a hardware point of view and I know what software has to be installed to see it on the computer.

Dismantle the Instructor's station... and it boots. Isn't as new as the Visual System, but newer than the Glass Computer. Has two video cards and one goes to the FMS??? Why?? The only software that loads on the Instructor Station is the Instructor Station software. Check the network settings and give it the next hard IP address in the list and it talks to Prepar3d. Awesome.

The Radio Computer... dismantle it... DEAD... DEAD power supply, DEAD mainboard, DEAD video card, DEAD hard drive. Burnt parts... poor thing... Have no idea what it controlled or how it worked in the system.

Step 5 - The actual cockpit hardware

So we have already had a bit of trouble with this part of the hardware. The USB hubs in the electronics box had been damaged and replaced. At this point, I don't know if there are damaged Phidget boards as well. So this box is a bit more complicated than the overhead electronics box. There is the same power supply (again - why...), 4 encoder boards, 2 analog input boards, 12 digital input boards and a LED board. So I grab the laptop and do a headcount... 4 encoder boards, 1 LED board, 10 digital boards and something is getting HOT. So I have two missing phidget boards and something sucking current. Start systematically unplugging boards from the USB hubs... one of the analog boards is sucking current. Troubleshoot and find bad wires - not used - and disconnect. Analog boards are for the pilot controls and the throttles... check those with the phidget software and they all work.

So on to the bad digital boards... As we begin to check out the system, it comes to our attention that some of the digital cards are wired, but not even used on this system. It is like the box is generic and what you need to make the system work is all that is hooked up. That's awesome for assembly work as they are all the same. Sucks if you have to troubleshoot the system. Figured out who was going to where and moved the wires that were required on the non-working phidgets to phidgets that worked and not being used. Rechecked the system and all of the switches work again. Document everything.

Onto the glareshield, auto-pilot panel and the side panels... this has it's own box. Everything works in that box - WOO HOO. Another power supply (still haven't figured this out... could have just put it in the center panel and powered the whole thing with one), 18 encoder boards (there isn't this many encoder knobs on the system), 5 digital inputs, and two LED boards (have no idea why it requires 2 of these... one is for the AP and the other is for the glareshield switches. Each LED board can take care of 64 LED's - oh well, what a waste). Check out the encoder boards - 14 of them are used, there are a few left over digital inputs and we could wire up a Christmas tree with what is left of the outputs on the LED boards.

So at this point... all the hardware works in the cockpit - every switch, LED, phidget... onward.

Step 6 - Hardware and Software working together

Now, if you have been doing your math, you might realize that there are 19 encoder boards, 4 LED boards, 2 analog input boards and 21 digital boards... and that they are all USB. That is a total of 46 USB devices in the system. There is a limit to what you can hook up to a USB on a computer. Each box has a set of USB hubs. There are 6 hubs in total which there are 5 outputs to the computers. Geez... One computer cannot see that many devices without help. Check the photos from the tear-down and behold, one box is connected to one computer and another is connected to another and so one.

Each phidget has it's own serial number. Awesome. I can cross-reference the serial number to the switch and what I/O it is connected to.

According to the phidget software, the phidgets can be seen across a network. ok.... that might work and would explain why they could be plugged into different computers. Onward...

Plug in all of the cables to the Visual System... we are short 4 boards. Cool... 4 of the encoder boards are not being used. Remove those from the system and now all of the phidget boards are being seen by the computer and the Phidget software.

Start the other computers and wait for them to boot. Start Prepar3d and move it to the second display. Start pmControls and pmSounds. We are sitting at the terminal and dead cold and quiet. Glass is not working (or so it seems - the aircraft was actually turned off). Reposition the aircraft and start the engines in Prepar3d with the keyboard. Glass comes on-line. Pilot flight controls are working. Throttles are working. Associate takes off down the run way and flies the plane! Cool Beans!! But...

No switches, no landing gear, no nothing... everything has to run from the keyboard. What is going on?

Stay tuned for how all of the switches are interfaced (nothing is documented) and how we managed to get the plane started from cold and dead in part 3...