Is selective braking pressure worth it when the thing decides to either apply 0% pressure or 100% pressure at an inopportune moment?
Selective braking pressure is worth it, yes. At least, if you believe in physics. Google for "mu slip curve". A locked wheel does not stop your vehicle sooner than a wheel that's being controlled to brake at the peak of the mu slip curve. This is what ABS does.
"...when the thing decides to either apply 0% pressure or 100% pressure at an inopportune moment?"
And why exactly would it decide to do this?
With this type of thinking I bet you're shaking in your shoes when you step on a commercial airliner. Do you think the pilot is actually up there there making minute corrections during a 15 hour flight to New Zealand? When the plane lands, do you think he's got some way to tell if he's locked up the landing gear, dragging the tires across the runway?
Can the existing network infrastructure handle the additional bandwidth that would be demanded, if significant, by VoIP?
How exactly does all of this work? It seems like the existing analog infrastructure would remain in place. After all, asking everyone to replace their existing handsets isn't going to happen anytime soon. Now the phone company will A/D my speech, then send it out directing it to another server local to the number that I dialed, which will D/A my speech and reproduce it for the ear of a person in another home?
If the above is true, it seems that it would make sense for some additional offering from the phone company that would eliminate the A/D portion of the communication and the phone line to your house would become a broadband connection. Make the handset perform the Voice-->IP conversion with embedded software, and I can ditch my dial-up ISP...
The more complicated an electronic system becomes, the less likely it will last for a long time.
And I generally agree with both of them, but I also think that you are seriously underestimating the lifetime of electronic circuits.
17 years is a rather small amount of time. Many passenger aircraft are still operating on a daily basis that have 20+ year old elecronics.
How far back does fuel injection date? I believe that Mercedes-Benz pioneered the art, sometime back in the late 60s or early 70s. I'd be willing to bet that these first electronic systems are still functioning just fine. My '82 280ZX had electronic fuel injection (I believe that it was a Bosch system) and it still functions perfectly. (I gave the car to my younger brother)
I doubt that you've upgraded from your PC-AT simply because you were concerned that it would blow up or catch fire. You've upgraded because you wanted to benefit from several years of innovation. And I'd bet that you'll do so again.
My point is that it makes no sense to discuss how old, mechanical techology is superior because of it's simplicity. I think it's quite clear that electronics increase system complexity and make repair more complex. However, computers and electronics make possible feats that are entirely IMPOSSIBLE to practically implement mechanically.
In modern vehicles, the warning lamps are not hardwired. They are controlled by the embedded software in the instrument panel (IP). If the IP has not received a message from the ABS module within, say, 1 second, it will turn on EVERY brake-related lamp immediately (red "BRAKE" lamp, yellow "ABS" lamp, traction/stability control warning lamp, etc.)
Even in older vehicles that had hard-wired lamps, the lamp was grounded through the ABS controller. In this way, if the ABS micro ever went down, the lamp would illuminate by default.
There is no comparison between desktop computers which have millions of different possible configurations of input/output devices and storage mediums and protocols, and an embedded system such as a driver's seat module or a climate -control module, that performs a pre-determined (and thus EMBEDDED) function, while listening to the exact same sensorics in EVERY VEHICLE.
I can shut down my Windows machine and install a new sound card or completely replace the RAM, and likely it will re-boot and attempt to figure out what I've done. It may or may not re-configure everything correctly. Your car will not be happy with similar changes because all of this code doesn't exist. If a wheel speed sensor doesn't look electrically identical to the sensor that the system was designed for, the ABS module will set a DTC, disable ABS function, and throw a warning lamp.
Linux is remarkably stable because the user is responsible for configuring everything. Don't want support for sound cards other than what's installed in your box? Don't compile or load those modules. Don't need USB support? Re-compile the kernel and don't include it. You can make all the choices.
By the way, the supplier responsible for the module writes their own software.
I am a vehicle development engineer working on automotive embedded systems.
One time driving, everything went crazy on the dash...engine slowed, all problems lights on. I drove it into the dealership close by to show them. Turned the key off. Turned it back on...like no problem every occured.
Why didn't you have the dealership check for trouble codes?
The trouble with such a highly computerized car...I feel, is that once you get electrical demons in there...they are almost impossible to get rid of. Their diagnostic stuff could never catch the problems.
This is why almost every module stores a diagnostic trouble code (DTC) to help the service tech pinpoint the problem. At exactly the moment that the module detected an "electrical demon", it should store a DTC such as "Front Left Wheel Speed Sensor Airgap". This one, for example, indicates that during the last 14 or so milliseconds, the sensor did not interrupt the processor -- when previously the module calculated a speed of 100 kph based on this sensor's interrupts.
I'm a definite believe in a more 'mechanical' car....much more dependable and easier to maintain IMHO.
IMHO this is not an appropriate post on a technology-based forum. Your '86 Porsche still benefits from fuel injection, which is computer-controlled. And your enthusiasm about 10 mpg amazes me.
The technology under the hood of my 350Z enables it's normally aspirated 3.5L V6 to put out around 290 hp! This technology, namely variable valve timing and direct ignition, would not be possible without a computer orchestrating everything. (And I'm guessing that it will perform as well as your '86 Porsche, while giving me a highway fuel economy of 26 mpg)
My box runs WinME, with a software by Adaptec called GoBack. This "technology" silently keeps track of every modification to my disk, will let me revert the entire drive (or individual files) to some state in the past.
At every boot I'm allowed to press a key in order to enter the interface and revert my drive. I have used this about twice to fix some stupid "Jeez, I wonder if these two versions of the same program can co-exist?" things I've f'ed up.
Slick. The documentation for this program claims that it only uses system idle time, but I'm wondering if it isn't causing my disk an undue pounding. During idle times it can be heard writing and it annoys me.
At any rate, it works great, but doesn't do what the author of the article suggests, and that is to allow him access to his home directory from other machines. (i.e., when he mentions that a bash shell on another box is completely unmodified it pisses him off)
GM would not tolerate the publication of a person identified as a GM employee enjoying a cruise in his Ford Mustang--if that employee was a willing participant in the activity.
Perhaps automakers are just a very bad example here. I'm not sure about your Coke/Pepsi statements, but definitely automakers could really care less what their employees drive.
These lines are blurred further by the fact that Ford has controlling interest in several former competitors: Mazda, Volvo, Land Rover, Aston Martin, and Jaguar, for example.
Ford routinely purchases several market-competitive vehicles for comparison before they launch a new product.
I work in vehicle development in the area of stability control systems. Each automaker has their own name for such systems, but you may have heard of VDC, ESP, or DSC. The above essentially do the same thing -- monitor a driver's input through a steering wheel angle sensor, and watch the vehicle behavior thorough a number of sensors. When the vehicle does something contrary to what the driver's intention is, the system can selectively apply one of the four brakes to help the driver regain control of the vehicle. These systems are not new -- Mercedes first introduced such a system around '96. In Europe every car has such a system. Here in the States, auotmakers are just starting to introduce such systems as optional on a number of vehicles.
Recently our company has begun writing several of the sensor signals into unused areas of the EEPROM when we detect certain types of component failures. This helps to troubleshoot what area of the failure detection strategy code might be too sensitive. (To avoid those "I had a warning lamp on this morning and when I drove to lunch it was gone." experiences)
I am certain that the the airbag module supplier has this functionality implemented for similar reasons, especially since new "multiple stage" airbags are beginning to be used. The article calls it an Event Data Recorder which most definitely was not the intent of recording such data.
The stability control system has the ability to record 10-20 more interesting pieces of data such as throttle position, yaw rate, steering angle, lateral and longitudinal acceleration, four individual wheel speeds, master cylinder hydraulic pressure, etc. But why should it? The auto industry fights vigorously for every single cent (even fractional cents) in the cost of each component. Unless the OEM specifically requests such functionality, the supplier (my company) won't just add it in for fun.
We only have enough unused space in our EEPROM for a few signals at the exact point in time that the failure occurred, and would have no reason to increase this capacity unless our customer (the OEM) requested it and was willing to pay for it. This type of "snapshot" is only to improve the robustness of the product in the long term.
Misuse of this data is really the issue, not the fact that it is being written.
We're already there. High-end vehicles since the early '90s all communicate using some sort of network protocol. Now on the lowest end vehicles you'll find multiplexing in use. For late model vehicles, CAN is becoming the most popular. (I work in vehicle development for a supplier of electronic brake systems such as ABS)
Our ABS module reports vehicle speed (and actually four individual wheel speeds) that allow the 4WD system controller to do its job. Diconnect the ABS module and you also lose "automatic" 4WD capability. In some vehicles the spedometer will also drop to zero. The brake pedal switch is also interpreted by ABS it's status is reported on the CAN bus.
For traction control, we look at the actual engine torque, throttle position, gear position, etc. reported by the engine controller. To reduce engine torque we simply request a reduction via the CAN bus.
I think what is important here is the fact that if VDO suddenly wants to produce "smart brake lights" that increase intensity depending on driver brake effort, they can now simply drop their software into our ECU (as the brake module is best equipped to handle this function).
I was not aware (until reading this thread) that the Mac OS X has already included BT support...! Admittedly that after I got my BT phone I bought the Tungsten just to play... Suddenly I thought of all sorts of possibilities!
Another problem: Very few phones include BT. Nokia includes it on two phones available right now... One is older and rather large, the second is IMO ugly with a strange round keypad and a camera for around $500. Ericsson has a couple of offerings and Siemens I think has one or two. All are at the higher-end and more expensive.
Keep in mind that once you've done the connection with your T68, the device should be trusted and you should only need to keep Bluetooth turned "on" (it doesn't need to be discoverable anymore) and you can easily talk with that trusted device. This is how I can pull my Tungsten out of my pocket, select a friend from the address book and tap "SMS". Compose a message and hit send. It automatically finds the phone and sends the message as the phone and the Palm are both in the trusted devices list.
Off-topic: The T68 text entering method I think you're referring to is called "T9". I also have a Siemens mobile (minus Bluetooth:) that has this entry method. Try this:
To switch from T9 to multitap, try holding down the '*' or '#' key, and you should see a menu that allows you to get into and out of T9 quickly.
Another tip: To easily enter numbers in multitap mode, press and hold the number and it will bypass all other available letters and jump straight to the digit.
Best regards,
--Bill
Re:Bluetooth has different purpose, nature, etc.
on
The Death of Bluetooth?
·
· Score: 2, Interesting
I'd have to disagree with a couple of your points:
Bluetooth setup requires 30-40 steps.
Check out the Palm Tungsten|T, Ericsson T39 (a two year old phone), or Ericsson T68. To get my Tungsten|T to talk to my T39, setup was quite easy. As soon as the two devices are near each other, they easily "discover" each other. Then simply tell the two to connect. You supply a few digit code on the Tungsten (say 123), and then phone will require you to echo those digits ONCE. Those devices are now trusted and further setup is not necessary.
I write SMS messages to anyone in my Palm's address book and send them to other's cellphones with my Palm while the BT phone is in my pocket. Really slick.
Bluetooth doesn't benefit from more widespread deployment.
Imagine walking into your favorite pub and browsing the brew list on your cellphone or PDA before the server gets to you... Or reviewing the specials at your leisure?
Bluetooth requires many devices to be minimally useful.
Always wanted to browse the web from my bathroom. Requires two devices: My internet-connected home computer with a $30 Bluetooth dongle and my Tungsten|T with a browser installed.
Also find interesting utility during meetings: A simple glance at my colleague at the other end of the conference room and we both pick up our Tungstens. An instant later we're using Palm's "Blueboard", a shared drawing application where we can both doodle on the screen in real-time. Palm's "Bluechat" allows chatting between the two devices as well. Since his device is already "trusted", connection is as simply as tapping "Accept" when my Palm wakes up and tells me that someone wants to "draw with me". Most of the time I have to turn the device off and put it down as I can't stifle my laughter for too long...
But back to the article... As many have already said, Frankston seems to miss the point of BT completely. 802.11b is great to keep my laptop talking to shared drives and a Lotus Notes server while in our office building, but seems like overkill for the small bandwidth of SMS messaging from Palm-->Phone or doodling back and forth between two small, low-powered devices.
Slashdot Mirror
Nope.
Is selective braking pressure worth it when the thing decides to either apply 0% pressure or 100% pressure at an inopportune moment?
Selective braking pressure is worth it, yes. At least, if you believe in physics. Google for "mu slip curve". A locked wheel does not stop your vehicle sooner than a wheel that's being controlled to brake at the peak of the mu slip curve. This is what ABS does.
"...when the thing decides to either apply 0% pressure or 100% pressure at an inopportune moment?"
And why exactly would it decide to do this?
With this type of thinking I bet you're shaking in your shoes when you step on a commercial airliner. Do you think the pilot is actually up there there making minute corrections during a 15 hour flight to New Zealand? When the plane lands, do you think he's got some way to tell if he's locked up the landing gear, dragging the tires across the runway?
Can the existing network infrastructure handle the additional bandwidth that would be demanded, if significant, by VoIP?
How exactly does all of this work? It seems like the existing analog infrastructure would remain in place. After all, asking everyone to replace their existing handsets isn't going to happen anytime soon. Now the phone company will A/D my speech, then send it out directing it to another server local to the number that I dialed, which will D/A my speech and reproduce it for the ear of a person in another home?
If the above is true, it seems that it would make sense for some additional offering from the phone company that would eliminate the A/D portion of the communication and the phone line to your house would become a broadband connection. Make the handset perform the Voice-->IP conversion with embedded software, and I can ditch my dial-up ISP...
It's possible for a driver to modulate brake pressure on the front left wheel?
Is it possible for the driver to sense the air/fuel ratio of the running engine, and adjust the amount of fuel injected into the cylinder?
Can you do this?
cgenman: I agree with you. My post was a response to parent "State of Software Sucks" by Anonymous Coward.
As electronics age, they become less reliable.
The more complicated an electronic system becomes, the less likely it will last for a long time.
And I generally agree with both of them, but I also think that you are seriously underestimating the lifetime of electronic circuits.
17 years is a rather small amount of time. Many passenger aircraft are still operating on a daily basis that have 20+ year old elecronics.
How far back does fuel injection date? I believe that Mercedes-Benz pioneered the art, sometime back in the late 60s or early 70s. I'd be willing to bet that these first electronic systems are still functioning just fine. My '82 280ZX had electronic fuel injection (I believe that it was a Bosch system) and it still functions perfectly. (I gave the car to my younger brother)
I doubt that you've upgraded from your PC-AT simply because you were concerned that it would blow up or catch fire. You've upgraded because you wanted to benefit from several years of innovation. And I'd bet that you'll do so again.
My point is that it makes no sense to discuss how old, mechanical techology is superior because of it's simplicity. I think it's quite clear that electronics increase system complexity and make repair more complex. However, computers and electronics make possible feats that are entirely IMPOSSIBLE to practically implement mechanically.
In modern vehicles, the warning lamps are not hardwired. They are controlled by the embedded software in the instrument panel (IP). If the IP has not received a message from the ABS module within, say, 1 second, it will turn on EVERY brake-related lamp immediately (red "BRAKE" lamp, yellow "ABS" lamp, traction/stability control warning lamp, etc.)
Even in older vehicles that had hard-wired lamps, the lamp was grounded through the ABS controller. In this way, if the ABS micro ever went down, the lamp would illuminate by default.
There is no comparison between desktop computers which have millions of different possible configurations of input/output devices and storage mediums and protocols, and an embedded system such as a driver's seat module or a climate -control module, that performs a pre-determined (and thus EMBEDDED) function, while listening to the exact same sensorics in EVERY VEHICLE.
I can shut down my Windows machine and install a new sound card or completely replace the RAM, and likely it will re-boot and attempt to figure out what I've done. It may or may not re-configure everything correctly. Your car will not be happy with similar changes because all of this code doesn't exist. If a wheel speed sensor doesn't look electrically identical to the sensor that the system was designed for, the ABS module will set a DTC, disable ABS function, and throw a warning lamp.
Linux is remarkably stable because the user is responsible for configuring everything. Don't want support for sound cards other than what's installed in your box? Don't compile or load those modules. Don't need USB support? Re-compile the kernel and don't include it. You can make all the choices.
By the way, the supplier responsible for the module writes their own software.
I am a vehicle development engineer working on automotive embedded systems.
Why didn't you have the dealership check for trouble codes?
The trouble with such a highly computerized car...I feel, is that once you get electrical demons in there...they are almost impossible to get rid of. Their diagnostic stuff could never catch the problems.
This is why almost every module stores a diagnostic trouble code (DTC) to help the service tech pinpoint the problem. At exactly the moment that the module detected an "electrical demon", it should store a DTC such as "Front Left Wheel Speed Sensor Airgap". This one, for example, indicates that during the last 14 or so milliseconds, the sensor did not interrupt the processor -- when previously the module calculated a speed of 100 kph based on this sensor's interrupts.
I'm a definite believe in a more 'mechanical' car....much more dependable and easier to maintain IMHO.
IMHO this is not an appropriate post on a technology-based forum. Your '86 Porsche still benefits from fuel injection, which is computer-controlled. And your enthusiasm about 10 mpg amazes me.
The technology under the hood of my 350Z enables it's normally aspirated 3.5L V6 to put out around 290 hp! This technology, namely variable valve timing and direct ignition, would not be possible without a computer orchestrating everything. (And I'm guessing that it will perform as well as your '86 Porsche, while giving me a highway fuel economy of 26 mpg)
My box runs WinME, with a software by Adaptec called GoBack. This "technology" silently keeps track of every modification to my disk, will let me revert the entire drive (or individual files) to some state in the past.
At every boot I'm allowed to press a key in order to enter the interface and revert my drive. I have used this about twice to fix some stupid "Jeez, I wonder if these two versions of the same program can co-exist?" things I've f'ed up.
Slick. The documentation for this program claims that it only uses system idle time, but I'm wondering if it isn't causing my disk an undue pounding. During idle times it can be heard writing and it annoys me.
At any rate, it works great, but doesn't do what the author of the article suggests, and that is to allow him access to his home directory from other machines. (i.e., when he mentions that a bash shell on another box is completely unmodified it pisses him off)
Perhaps automakers are just a very bad example here. I'm not sure about your Coke/Pepsi statements, but definitely automakers could really care less what their employees drive.
These lines are blurred further by the fact that Ford has controlling interest in several former competitors: Mazda, Volvo, Land Rover, Aston Martin, and Jaguar, for example.
Ford routinely purchases several market-competitive vehicles for comparison before they launch a new product.
Recently our company has begun writing several of the sensor signals into unused areas of the EEPROM when we detect certain types of component failures. This helps to troubleshoot what area of the failure detection strategy code might be too sensitive. (To avoid those "I had a warning lamp on this morning and when I drove to lunch it was gone." experiences)
I am certain that the the airbag module supplier has this functionality implemented for similar reasons, especially since new "multiple stage" airbags are beginning to be used. The article calls it an Event Data Recorder which most definitely was not the intent of recording such data.
The stability control system has the ability to record 10-20 more interesting pieces of data such as throttle position, yaw rate, steering angle, lateral and longitudinal acceleration, four individual wheel speeds, master cylinder hydraulic pressure, etc. But why should it? The auto industry fights vigorously for every single cent (even fractional cents) in the cost of each component. Unless the OEM specifically requests such functionality, the supplier (my company) won't just add it in for fun.
We only have enough unused space in our EEPROM for a few signals at the exact point in time that the failure occurred, and would have no reason to increase this capacity unless our customer (the OEM) requested it and was willing to pay for it. This type of "snapshot" is only to improve the robustness of the product in the long term.
Misuse of this data is really the issue, not the fact that it is being written.
Kind of like ... Sony manufactures MP3 players, but they are also a recording giant?
A 420MB drive from 1994. Originally used to run OS/2, and then Windows 95... Now it's works great as a porn drive.
Our ABS module reports vehicle speed (and actually four individual wheel speeds) that allow the 4WD system controller to do its job. Diconnect the ABS module and you also lose "automatic" 4WD capability. In some vehicles the spedometer will also drop to zero. The brake pedal switch is also interpreted by ABS it's status is reported on the CAN bus.
For traction control, we look at the actual engine torque, throttle position, gear position, etc. reported by the engine controller. To reduce engine torque we simply request a reduction via the CAN bus.
I think what is important here is the fact that if VDO suddenly wants to produce "smart brake lights" that increase intensity depending on driver brake effort, they can now simply drop their software into our ECU (as the brake module is best equipped to handle this function).
Another problem: Very few phones include BT. Nokia includes it on two phones available right now ... One is older and rather large, the second is IMO ugly with a strange round keypad and a camera for around $500. Ericsson has a couple of offerings and Siemens I think has one or two. All are at the higher-end and more expensive.
Keep in mind that once you've done the connection with your T68, the device should be trusted and you should only need to keep Bluetooth turned "on" (it doesn't need to be discoverable anymore) and you can easily talk with that trusted device. This is how I can pull my Tungsten out of my pocket, select a friend from the address book and tap "SMS". Compose a message and hit send. It automatically finds the phone and sends the message as the phone and the Palm are both in the trusted devices list.
Off-topic: The T68 text entering method I think you're referring to is called "T9". I also have a Siemens mobile (minus Bluetooth :) that has this entry method. Try this:
To switch from T9 to multitap, try holding down the '*' or '#' key, and you should see a menu that allows you to get into and out of T9 quickly.
Another tip: To easily enter numbers in multitap mode, press and hold the number and it will bypass all other available letters and jump straight to the digit.
Best regards,
--Bill
Bluetooth setup requires 30-40 steps.
Check out the Palm Tungsten|T, Ericsson T39 (a two year old phone), or Ericsson T68. To get my Tungsten|T to talk to my T39, setup was quite easy. As soon as the two devices are near each other, they easily "discover" each other. Then simply tell the two to connect. You supply a few digit code on the Tungsten (say 123), and then phone will require you to echo those digits ONCE. Those devices are now trusted and further setup is not necessary.
I write SMS messages to anyone in my Palm's address book and send them to other's cellphones with my Palm while the BT phone is in my pocket. Really slick.
Bluetooth doesn't benefit from more widespread deployment.
Imagine walking into your favorite pub and browsing the brew list on your cellphone or PDA before the server gets to you... Or reviewing the specials at your leisure?
Bluetooth requires many devices to be minimally useful.
Always wanted to browse the web from my bathroom. Requires two devices: My internet-connected home computer with a $30 Bluetooth dongle and my Tungsten|T with a browser installed.
Also find interesting utility during meetings: A simple glance at my colleague at the other end of the conference room and we both pick up our Tungstens. An instant later we're using Palm's "Blueboard", a shared drawing application where we can both doodle on the screen in real-time. Palm's "Bluechat" allows chatting between the two devices as well. Since his device is already "trusted", connection is as simply as tapping "Accept" when my Palm wakes up and tells me that someone wants to "draw with me". Most of the time I have to turn the device off and put it down as I can't stifle my laughter for too long...
But back to the article... As many have already said, Frankston seems to miss the point of BT completely. 802.11b is great to keep my laptop talking to shared drives and a Lotus Notes server while in our office building, but seems like overkill for the small bandwidth of SMS messaging from Palm-->Phone or doodling back and forth between two small, low-powered devices.
--Bill