Posted on 02/23/2023 1:00:08 PM PST by rxsid
Just one of the many things they do.
"There's a thin veneer of hyper-competent professionals who keep the lights on and the water drinkable. Replace them with the incompetent and the water turns brown and the lights go out."
Having been a part of that thin veneer, this I know is a profound bit of truth.
Woah. The Substack writer did some jackassin’. Now he needs to fish.
What are the “proper safety protocols” that had they been in place, could have averted the derailment?
We don’t know because he never states.
Just jackassin’.
Look at an SDS and the personal exposure level (PEL) (Section 8)...I wouldn't want to live down wind of that uncontrolled burn.
Hazardous Substance Fact Sheet
When did you build that system?
“There are sensors on the inboard and outboard bearing adaptors at each wheel.”
Interesting post. A sensor on each wheel adds up to a lot of sensors on a train! I saw on the news tonight that there are sensors in the track that can pick up an overheated bearing as the train goes them. Guess trains are loaded up with electronics like everything else.
[see the “everything” above? Immediately after I typed that word, this very smart text box inserted the “else”. Annoying.]
I vaguely remember when sleeve bearings were replaced with tapered roller bearings. Is that what put Timken on the map? I remember guys walking alongside a stopped train looking for hotboxes and oiling the bearings.
It takes 3000 ppm for a human to detect the odor of vinyl chloride.
A Citizen’s Guide to Incineration
That was an open pit, uncontrolled burn.
Even the soil from around the pit will have to be dug out
and incinerated as well for there to be a proper clean up.
The air is just part of it. There is also the dead fish and rainbow water.
“The bearings on my cars were Timken”
You’re saying you used the wireless telephone network to send the data from your car?
What’s the main reason that type of bearing fails?
A guy I knew worked at HP on their FFT spectrum analyzer. He told me all sorts of things those instruments were used for. One was to analyze the vibrations on the Golden Gate Bridge.
My colleague traveled to the FRA facility in Pueblo, CO with a digital recorder. He went through every train at the facility with an accelerometer on the bearing adapter. At the end of the effort, he had developed DSP algorithms that could detect 55 different defects in the bearings from the vibration signature. It was his algorithms that I applied to the 100,000 samples per second for 20 seconds each day. My contribution was getting a 4 Mhz CPU with a Diamond Systems 16-bit A to D to grab those samples, then run my implementation of his Matlab routine (mine in C) to extract the data. I did the hardware/software/system design/implementation. Timken built the special generator bearing. Wilcoxon Research (Meggitt) did the the PC board fab and specialized sensors...accelerometer 100 SPS at +/- 80 g, tri-accelerometers and temperature sensors. The specialized cutlever, handbrake, auto-coupler, auto-anglecock devices were done by Sharma Associates in Countryside, IL. I use a Kyocera M2 module to achieve the 1XRTT CDMA network. A Garmin serial GPS provided timing and position. I had 802.11b wireless bridges to support the ad hoc network executed with OLSR software. The NDDS libraries were executed over the OLSR mesh network.
The 2005-2008 cars had my new CANopen hardware to control the temperature sensors, tri-axial accelerometers, handbrake, anglecock and cutlevers. I pushed the clock speed down to 4 MHz on the CAN microcontrollers to optimize power consumption and improve noise immunity on the CAN bus connecting all of the controllers back to the box with the PC104 Linux. Suffice to say, it was a very capable hardware package. I would build it differently with the advances in hardware that have occurred since 2010. Still, the system functionality was the right set of operations. It would have prevented the Ohio accident with immediate notification to the locomotive instead of depending on hotbox detectors and reports to be transmitted to the locomotive.
BTW, the type of DSP I was doing for this project leverages one of my key skillsets in taking Matlab DSP code and making it run blazing fast using C++ and FFTW libraries. My PhD colleagues cook up algorithms that are correct, but do not execute fast enough. My C++ DSP code is small and fast. Matlab may have caught up since 2010. I released my licensed copy to another engineer in the shop when I left that project. Embedded DSP is pretty standard practice today. Many microcontrollers have specialized hardware to do the sampling and execute the DSP algorithms. Again, that is a key reason I would implement differently at this point in time vs the technology available in 2005.
” making it run blazing fast using C++”
Interesting. I imagine that use of a newer, perhaps faster FFTW library increased performance, but not merely the transition to C++.
Indeed a lot has changed in the embedded system world since 2010. I’m using the MBED/Keil development environment now and my particular piece of hardware (MBED LPC1768) is already obsolete. The Keil source code editor is awesome! GITHUB is the industry standard but nebulously documented.
I'm going to satisfy my interest in DSP by doing more with Software Defined Radio. There are good python libraries with lots of filters and demodulators available in the libraries. I'm mostly interested in efficient data communications from that perspective.
Disclaimer: Opinions posted on Free Republic are those of the individual posters and do not necessarily represent the opinion of Free Republic or its management. All materials posted herein are protected by copyright law and the exemption for fair use of copyrighted works.