I used principally PIC18F devices on the trains. The last iteration used CAN bus to the devices to minimize wiring and improve signal to noise on the rail cars. I ran the clock speed down to 4 MHz to minimize power requirements as well. The research cars had a Timken generator bearing that included a 12 pole tachometer signal to estimate the speed. Wheels are 36" diameter. At 18 pulses per second, I was making enough power to charge the battery and sustain booting the PC104 stack. Initially it was QNX based, but we added an observer/subscriber package that was dirt cheap for Linux and outrageously expensive for QNX. I ported all of the code to Linux from QNX. At the Linux level I had a serial interfaced GPS and serially interface CAN bus controller. An ethernet connected to "access points" that were operating a mesh network based on OLSR. There was also a 16-bit A2D that allowed sampling 100 KSPS against the accelerometer on the bearing adapter. That picked up signal from the cup, cone, cage and roller bearings. I did some local DSP to extract signals from each component. Tri-axial accelerometers were on the bolster at each end with signals in vertical, lateral and longitudinal planes to assess ride quality. I sampled those with PIC18F devices and sent results back on the CAN bus. There was a brake piston position sensor, handbrake actuator, anglecock actuator and cut-lever actuator. It was capable of closing angle-cock values, setting the handbrake and break the car free under complete remote control. All actuators were my designs and implemented with 18F PIC. Back at the PC104, I had a serial connection to a 1xRTT cellar modem to send data collected back to the server in Fairfax, VA. LAT/LON/timestamp/battery condition were transmitted at least hourly when idle and once per minute in motion. What do you do with that data? You tell the customer about 55 kinds of defects that are detectable and allow for maintenance scheduling at the customer shop instead of a breakdown "on the road". There were also temperature sensors on each bearing adaptor in place of the old "stink bombs" so a bearing burn off could be detect immediately instead of waiting for a track-side detector to spot it on 20 mile intervals.
That's the short synopsis. I published papers at the 10th International CAN Conference in Rome and IEEE/ASME conference in Pueblo, CO in early 2005. The whole project was canceled about 2 hours after Obama was inaugurated.
That was indeed an awesome project. It seems you had most of the kinds of stuff I've done all in a single system. It sure looks like that rail car system was a wonderful project. You put everything in there everything but the kitchen sink. Few people know that these things are "labors of love".
I used a PC104 project on a battery change balancer for Ma Bell. It is a delightful package. We went with VRTX on that project.
I know how you feel about project cancellation. I did a life safety system for the East Area Rocket Engine Test Facility in Huntsville for the NASA boys. We hooked to the countdown clock, and made an enormous field of sensors and actuators for doors, gates, railroad tracks, infrared sensors. We could detect cars, people, trains and control gate crossings, locks, sirens, horns, and gobs of warning lights. The network was carried on RS485, custom message protocol. The processor was a 68040 running on a multi-bus platform. Runtime was VRTX, developed under Idris, a UNIX clone that predated Linux. It even had sectionalized voice announcements. The labor union forced them to tear it all out so that a glob of signalmen and operators could keep their jobs. This was somewhere around 1984.
I remember one NASA guy told us, "If you ever hear that klaxon when you are down on a test stand, it means you are about to die.
I never saw a PIC die on the job. AVR devices were not nearly as rugged.