All of it. The pilot is going through a checklist. The checklist is not going to have unnecessary steps in it. When pilots don't follow the checklist sometimes they die, so they are pretty religious about following the checklist.
That is a pretty new 737 (someone speculated 737-800). Note the flat panel primary displays (color LCDs), that is the tip-off that this is pretty new.
> Note the flat panel primary displays (color LCDs), that is the tip-off that this is pretty new.
Glass cockpits have been around for some time now. Also many older 737s (at least with US-based airlines) have been retrofitted with newer equipment. For example, all of SWA's 737-300 series aircraft (the oldest in their fleet) have been upgraded to glass cockpit controls.
I wrote a lot of the "Dual FMS" BootROM and also the cross-FMS data link communications handling (TCP/IP originally over a high baud rate async serial channel). Most of my code is deeply embedded.
Awesome!!! Never knew it actually operates over TCP/IP, I always assumed some custom protocol/ARINC interop between the two units. Can you perhaps elaborate in some way on the dev environment When working on "stuff like that"? :)
New systems (not the 737 FMS) use ARINC-664[1] - UDP/TCP/IP/ethernet with all the good parts disallowed. :-) The original Dual FMS predates ARINC-664.
The original Dual FMS was a Motorola 68040 (the predecessor FMS was the TI TMS9900 architecture implemented in bit-slice processors(!), later an ASIC, because the TI 9900 was a bust. The original code was Fortran, with the Dual FMS it was ported to Ada.
The development environments back in the late 1980s, early 1990s was custom hardware and in circuit emulators (ICEs). The ICE plugged into the processor socket and emulated the processor but with breakpoints and trace. The 68040 was about the end of the line where this worked (the head of the 68040 ICE was pretty large. There were no "eval" boards to develop code on... we wrote code and waited for the hardware guys to get the first article built. When the hardware guys got done with the initial checkout on the first article, we got the system and started making the code work.
Once we got the hardware, software development was a lot like now: start with basic functionality, cross your fingers, burn and learn. With the ICE, "burning" was faster because you substituted ICE RAM for the target flash and the trace of the ICE was a lot more useful than today's JTAG-based debuggers - you could see everything for the last 1K-4K instructions, including the actual states of the pins of the processor.
The development lab had real equipment (e.g. the Control Display Units (CDUs)) and a lot of simulated I/O. The simulated I/O was driven by a flight simulator running on a Dec MicroVAX. The flight simulator simulated the flight characteristics of the 737, responding to the commands given by the FMS. Since I was mostly low-level, I didn't do much with the flight simulators, but I could enter flight plans (typically "company routes" which are pre-canned airports, runways, and waypoints) and go through all the motions of flying. The simulator could speed up time to save time waiting for things to happen. IIRC, 4x real time was about as fast as you could go because the systems would go wonky.
Hey jrbeal, I've had the same problems. I taught myself ROR over the past year and I had huge issues getting it off the ground. I've been through over 20 different sets of tutorials, so I'm sure I can help out.
I also had a lot of initial difficulty setting up my environments, but I've gotten a lot better at it now.
If you'd like, send me an email benigeri@stanford.edu and I can try to help you and point you to good resources. It's a little hard to suggest anything right now since I don't have any context.
So send me an email and I'll try to help you as much as I can, pro-bono.
Thats an awesome idea. Unless I get any better suggestions, I think I'll go with this. Shoot me an email: paul|at|benigeri|dot|com and I'll send you a link when its released.
This year's BASES Startup Career Fair is scheduled to take place at the Lawn behind the Gates Computer Science Building on the Stanford Campus. We had over 900 students attend this fair last year, making it a very successful recruiting and networking event for both companies and attendees.
A full table at the Career Fair entitles you to one six-foot table with a maximum of four representatives (a half table is maximum two reps). Both options include parking, free shuttle service from the venue to the parking and back, break-time snacks and refreshments, and access to post jobs on our entrepreneurship email newsletter, the BASES Digest, reaching over 5,000 people. You will also be given a complimentary copy of the Resume Booklet, which consists of an orderly collection of resumes of all Stanford students seeking jobs and internships.
When purchasing a table at the BASES Startup Career Fair you also have the option to register for the Startup 101 Career Fair simultaneously for a $50 discount on both fairs combined. The Startup 101 Career Fair is hosted with five other student groups and held in Tresidder Memorial Union on February 27th from 10am-4pm. If you would like to register separately for this fair and not the BASES Startup Career Fair please contact us at bases-external-relations-12-13@lists.stanford.edu for more information.
Shortly after registration you will receive a link to a survey to fill out with more information about your company and the types of students you are looking for, and closer to the date of the career fair you will receive an email with more information about the logistics of the day of the fair. We look forward to your participation in our upcoming career fair!
