Re: Arduino current sensing (in car)
Often, it allows them to differentiate among current (as well as future!) "models" in their lineup. What's most annoying is when an upscale model differs solely from a "basic" model because of a "hidden" internal setting!
There are nonrecurring (development) costs associated with each feature you implement. Plus, potential recurring (manufacturing) costs -- additional knobs, buttons, extra pages in a manual, etc.. And, the "commitment" they must now make to supporting that functionality going forward ("design maintenance").
But, there is also some value to not offering extra functionality as it keeps the user interface (cognitive loading) simpler. You don't have to provide a way to differentiate among several different features in a single interface AND task the user with remembering those subtleties!
E.g., the Unisite's "high level" user interface is provided via a user-provided glass TTY (typ ANSI 3.64). The Unisite, itself, has just two buttons on it: power (obvious) and a button that basically swaps RxD with TxD in the serial port connector on the rear of the instrument. So:
Other devices with serial ports would typically leave the user wondering what cable to use (wired as DCE or DTE?), baud rate, stop pits, parity, etc. And, do nothing to solve this problem FOR the user ("Hmmm... that cable didn't work. Let's try a different one -- and hope that none of the other settings are the reason for the cable not working!)
Of course, they COULD have exposed all of these settings to the user in the guise of "more flexibility/capability" (what happens if I want to talk to the device using EBCDIC?). Thankfully, they didn't let the engineer(s) make that decision! (who invariably opt for more knobs and settings)
Similarly, the electric wheelchair I'm tinkering with has a serial port supported by the controller (it's actually labeled on the PCB). Why not document how that interface works so I can tinker with the controller's "buried" configuration settings?
Originally posted by stj
View Post
There are nonrecurring (development) costs associated with each feature you implement. Plus, potential recurring (manufacturing) costs -- additional knobs, buttons, extra pages in a manual, etc.. And, the "commitment" they must now make to supporting that functionality going forward ("design maintenance").
But, there is also some value to not offering extra functionality as it keeps the user interface (cognitive loading) simpler. You don't have to provide a way to differentiate among several different features in a single interface AND task the user with remembering those subtleties!
E.g., the Unisite's "high level" user interface is provided via a user-provided glass TTY (typ ANSI 3.64). The Unisite, itself, has just two buttons on it: power (obvious) and a button that basically swaps RxD with TxD in the serial port connector on the rear of the instrument. So:
- plug in cable
- tap space bar (so Unisite can determine proper parameters for the serial port)
- if no reply, push button to swap RxD&TxD and repeat
Other devices with serial ports would typically leave the user wondering what cable to use (wired as DCE or DTE?), baud rate, stop pits, parity, etc. And, do nothing to solve this problem FOR the user ("Hmmm... that cable didn't work. Let's try a different one -- and hope that none of the other settings are the reason for the cable not working!)
Of course, they COULD have exposed all of these settings to the user in the guise of "more flexibility/capability" (what happens if I want to talk to the device using EBCDIC?). Thankfully, they didn't let the engineer(s) make that decision! (who invariably opt for more knobs and settings)
Similarly, the electric wheelchair I'm tinkering with has a serial port supported by the controller (it's actually labeled on the PCB). Why not document how that interface works so I can tinker with the controller's "buried" configuration settings?
Comment