In the spirit of "OT: Too funny", I contacted a vendor about
a bug in one of their (likely ONLY!) products...
We have a device that is FXS on one end and BT on the other.
It acts as a bridge between a cellular (phone) network and
a wired terminal. The device is paired with a cell phone and
the FXS connected to premises wiring.
When it works, it allows existing devices to make use of the
cellular connection as if it was still POTS.
[I use this as an expedient to connect to my "automated
assistant" as we dropped land line service after the lineman
servicing the neighbor's connection managed to wedge *ours*
in the process. And, when confronted, replied, "Call in a
repair order" -- how? using my neighbor's phone?? Should
I be sure to tell them that I *witnessed* you breaking our
service???]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
This despite *it* knowing that it is no longer paired;
lift a wired handset and it provides a verbal warning
telling you, basically, "Your (wired) phones don't work.
I sure hope you aren't trying to call for an ambulance
or police protection!"
[Of course, you have to take action to *discover* this
condition; the device isn't smart enough to alert you
to the problem (hey, you've got control over a BELL
and a CID datastream; you can't ring the phone to
tell the occupants that their phones don't work??)
"Let's pitch the device to SENIORS as a convenience!
It doesn't have to be RELIABLE, does it?"]
One line reply from "Support" asks if phone has moved out of
BT distance (no, it's where it always has been for the past
~year).
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
But, have you also missed the part about your device NOT
allowing me to re-pair until I cycle power to *it*?
After a few emails, "update the firmware". Gee, how can
I tell what firmware is currently *in* the device? It
can audibly tell me that it isn't paired -- but can't tell
me what firmware is present?
And, DO YOU KNOW THAT THIS WAS A PREVIOUSLY REPORTED FAILURE MODE
THAT YOUR UPDATE WAS DESIGNED TO FIX? (Or, are you just burning up
my time trying to see if the problem is present in your latest
"bug-set"... er, "release"?
As I said in the previously referenced post:
"they don't even BOTHER to think about problems"
(sigh) Apparently there have been several similar products -- all
having failed in the market. I suspect this garag^H^H^H shop
will be closing their doors, soon, too.
That's what happens when engineers "design" products ("Gee,
we could...") instead of folks who actually *think* about the
application domain. It's also why folks have such hard times
writing drivers (cuz hardware can misbehave when you haven't
done anything to tickle it!)
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled. More than once have been on a road trip where
my phone's BT connection to the car (for music or nav) has dropped from
the car-side, an and the only fix is "get off at the nearest
rest-stop".
Granted, my car's a decade old (or a bit older); so maybe a newer car
would behave better.
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled.
More than once have been on a road trip where
my phone's BT connection to the car (for music or nav) has dropped from
the car-side, an and the only fix is "get off at the nearest
rest-stop".
Granted, my car's a decade old (or a bit older); so maybe a newer car
would behave better.
On 1/29/24 12:25, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled. More than once have been on a road trip where
my phone's BT connection to the car (for music or nav) has dropped from
the car-side, an and the only fix is "get off at the nearest
rest-stop".
Granted, my car's a decade old (or a bit older); so maybe a newer car
would behave better.
Don't count on it. Newer cars have more software and therefor
more bugs.
My car is only two years old and has a certain number of "issues"
that come and go from one drive to the next. None yet serious enough
to strand me, fortunately, but surely annoying!
I'd grown to expect better quality from Audi.
There are also many more potential interactions that likely have not
been foreseen. Unless you have really internalized the UX, you
will likely tend to think in terms of single, serialized actions
and not the range of potential scenarios that can arise.
On 1/29/24 12:25, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled. More than once have been on a road trip where
my phone's BT connection to the car (for music or nav) has dropped from
the car-side, an and the only fix is "get off at the nearest
rest-stop".
Granted, my car's a decade old (or a bit older); so maybe a newer car
would behave better.
Don't count on it. Newer cars have more software and therefor
more bugs.
On 1/29/2024 4:25 AM, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled.
really? The *car*? There is nothing that would *require* that
behavior -- except code written to only allow pairing once
in a power-on event.
On 1/29/2024 8:51 AM, Jeroen Belleman wrote:
On 1/29/24 12:25, Dan Purgert wrote:
I see this, increasingly, in UI designs. As if the designers
only thought about a single use task independent of everything
else that COULD happen, "asynchronously". You know, the devices
that force you to wait for the 5 second timeout on the display
prompt BEFORE you can proceed (don't you think I already KNOW
what it says and am ready to press the next button while it is
still thinking I *need* time to read the 4 words?)
[To be honest, this often requires a multithreaded solution
and folks STILL haven't adjusted to the idea of multitasking.
"Start timer. Display prompt. Wait for timer. Meanwhile,
*expect* user input as if timer's role didn't exist; cancel
timer on first user action and repaint display"]
My car is only two years old and has a certain number of "issues"
that come and go from one drive to the next. None yet serious enough
to strand me, fortunately, but surely annoying!
I love it when the entertainment system shows all of the text
fields as "???????". Really? What idiot thought that was
better than ""? (and, why is it EVER necessary to display as such)
I'd grown to expect better quality from Audi.
IME, most of the (driver visible) software is likely farmed out to
third party providers. The OEM likely doesn't have the skills/mindset
to know what issues are important in "engineer-speak".
SWMBO's vehicle has a backup camera that comes on when the car is placed
in reverse. But, the software is dog slow... all of the controls are ignored for a good 30 seconds after turning on the ignition! So, how
can it "notice" the transmission being place in reverse and adjusting
the main display to route live video to it? ANS: I suspect there
is a physical switch that directly connects the video feed to the
display so the view is available regardless of whether or not the
processor has managed to initialize itself!
Was there a specification ANYWHERE as to how quickly the system
should be responsive? Or, did someone "discover" this problem
later and cobble together a hardware fix (as changing "crt0.s"
would likely be a major heartache!)
On 2024-01-29, Don Y wrote:
On 1/29/2024 4:25 AM, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled.
really? The *car*? There is nothing that would *require* that
behavior -- except code written to only allow pairing once
in a power-on event.
I'm being a little tongue in cheek here, since he's comparing an
always-on device (this BT adapter thing) to his car (which is not "always-on"), and complaining he has to power-cycle the always-on one
from time to time.
What none of us know is "what's this time-to-time rate?" and more importantly, "how many times does something go wrong, and the device SUCCESSFULLY reconnects silently?"
On 1/29/2024 4:25 AM, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled.
really? The *car*? There is nothing that would *require* that
behavior -- except code written to only allow pairing once
in a power-on event.
[...]
Granted, my car's a decade old (or a bit older); so maybe a newer car
would behave better.
Regardless. If designing a bridge between the cellular network
(cell phone) and a wired network, you would assume keeping that
bridge operational IN ALL SITUATIONS (except being explicitly
told to break the connection) would be a primary design goal.
On 2024-01-29 20:39, Don Y wrote:
On 1/29/2024 8:51 AM, Jeroen Belleman wrote:
On 1/29/24 12:25, Dan Purgert wrote:
I see this, increasingly, in UI designs. As if the designers
only thought about a single use task independent of everything
else that COULD happen, "asynchronously". You know, the devices
that force you to wait for the 5 second timeout on the display
prompt BEFORE you can proceed (don't you think I already KNOW
what it says and am ready to press the next button while it is
still thinking I *need* time to read the 4 words?)
[To be honest, this often requires a multithreaded solution
and folks STILL haven't adjusted to the idea of multitasking.
"Start timer. Display prompt. Wait for timer. Meanwhile,
*expect* user input as if timer's role didn't exist; cancel
timer on first user action and repaint display"]
Many of these devices are single cpu, single core, and do not run any kind of multitasking operating system. The run a single program permanently.
To read the input while printing output the programmer has to output a letter,
then listen, in a loop. It can be done, but it is more code.
My car is only two years old and has a certain number of "issues"
that come and go from one drive to the next. None yet serious enough
to strand me, fortunately, but surely annoying!
I love it when the entertainment system shows all of the text
fields as "???????". Really? What idiot thought that was
better than ""? (and, why is it EVER necessary to display as such)
I'd grown to expect better quality from Audi.
IME, most of the (driver visible) software is likely farmed out to
third party providers. The OEM likely doesn't have the skills/mindset
to know what issues are important in "engineer-speak".
SWMBO's vehicle has a backup camera that comes on when the car is placed
in reverse. But, the software is dog slow... all of the controls are
ignored for a good 30 seconds after turning on the ignition! So, how
can it "notice" the transmission being place in reverse and adjusting
the main display to route live video to it? ANS: I suspect there
is a physical switch that directly connects the video feed to the
display so the view is available regardless of whether or not the
processor has managed to initialize itself!
I doubt there is a hardware switch. It is far easier and cheaper a software
switch. Mine responds faster than 30", and it is just a humble Opel. Display and firmware made by LG. It draws lines superimposed on the camera display that
move as I move the steering wheel, so there is CPU time involved.
Was there a specification ANYWHERE as to how quickly the system
should be responsive? Or, did someone "discover" this problem
later and cobble together a hardware fix (as changing "crt0.s"
would likely be a major heartache!)
It was considered acceptable. You have to let the engine warm up before attempting to move the car, anyway :-p
On 1/31/2024 6:12 AM, Carlos E.R. wrote:
On 2024-01-29 20:39, Don Y wrote:
On 1/29/2024 8:51 AM, Jeroen Belleman wrote:
On 1/29/24 12:25, Dan Purgert wrote:
I see this, increasingly, in UI designs. As if the designers
only thought about a single use task independent of everything
else that COULD happen, "asynchronously". You know, the devices
that force you to wait for the 5 second timeout on the display
prompt BEFORE you can proceed (don't you think I already KNOW
what it says and am ready to press the next button while it is
still thinking I *need* time to read the 4 words?)
[To be honest, this often requires a multithreaded solution
and folks STILL haven't adjusted to the idea of multitasking.
"Start timer. Display prompt. Wait for timer. Meanwhile,
*expect* user input as if timer's role didn't exist; cancel
timer on first user action and repaint display"]
Many of these devices are single cpu, single core, and do not run any
kind of multitasking operating system. The run a single program
permanently.
I'd find that hard to believe in the 21st century. I've been writing multithreaded code since ~1980 on dinky little 8-bit processors.
Even PICs (when they were GI)!
It's not the choice of implementation that sinks the design but the
way the designer has *modeled* the application. If you impose your serial thinking on the model, then you will have a serial implementation
where A happens before B, then C, etc.
E.g., somewhere, recently, I mentioned a dial-telephone that I've turned
into a clock (it was previously a dial-to-DTMF "head goof"). Lots of possibilities for races in how *it* approached it's goal (of telling
time and generating alarms). *But*, if you model the application in
a manner that mimics the user's EXPECTATIONS for interacting with a
REAL telephone (treat the agent IN the phone as a "caller" who can
act independently of you, the user), then the types of issues that
you have to handle become obvious:
- what happens if someone tries to call me JUST as I pick up the handset?
- what if someone tries to call me just AFTER I pick up the handset?
- what if someone calls while I am "on the phone"?
With this sort of model in mind, the designer's questions answer themselves. And, the expectations of the user are met without any
ambiguity or surprise.
To read the input while printing output the programmer has to output a
letter, then listen, in a loop. It can be done, but it is more code.
But, you can decompose it into multiple threads and have LESS
total code.
Did no one wonder "what if the device becomes un-paired?
DURING a call? While sitting idle?
Or (for vehicles), that the car AND DRIVER may want to do two or
more things simultaneously? (Can I turn on the windshield wipers
AND move the driver's seat simultaneously?)
SWMBO's vehicle has a backup camera that comes on when the car is placed >>> in reverse. But, the software is dog slow... all of the controls are
ignored for a good 30 seconds after turning on the ignition! So, how
can it "notice" the transmission being place in reverse and adjusting
the main display to route live video to it? ANS: I suspect there
is a physical switch that directly connects the video feed to the
display so the view is available regardless of whether or not the
processor has managed to initialize itself!
I doubt there is a hardware switch. It is far easier and cheaper a
software
The "right" solution is to process the video *in* software as you
have to be able to handle the different camera modes, superimposed
parking guides, etc.
But, if you can't get enough code up and running to see that I am
pressing the "show me the information display instead of the
navigation map", how much hope do you have for processing video?
switch. Mine responds faster than 30", and it is just a humble Opel.
Display and firmware made by LG. It draws lines superimposed on the
camera display that move as I move the steering wheel, so there is CPU
time involved.
Was there a specification ANYWHERE as to how quickly the system
should be responsive? Or, did someone "discover" this problem
later and cobble together a hardware fix (as changing "crt0.s"
would likely be a major heartache!)
It was considered acceptable. You have to let the engine warm up
before attempting to move the car, anyway :-p
Even if you just SHUT OFF the engine from a previous trip? :>
Likely no one ever deliberately thought about the time involved
BEFORE the design was complete. And, at that point, it would
be too hard to change. So, you RATIONALIZE that it isn't
a problem...
Assumptions are what leads to bad designs. Like assuming that Driver #2 will want to listen to whatever music source Driver #1 had selected when
they finished their most recent "trip".
Our stove has a "big knob" UI; one big knob to select from options
and values, press for ENTER. Great if there is only one task that
the stove can perform at a time.
But, what if you've got the first oven BAKING at 375F with 0:43 left
on its timer, the second BROILING on HIGH with 0:12 left on its
timer AND you want to set a general purpose timer for 3:00 but
the BROIL timer expires while you are setting that? Suddenly,
your general-purpose-timer-setting-activity has been preempted by
"tell the user the BROILER is done". What happened to the
value I was in the process of setting for that general purpose timer?
How long before I can get BACK to doing that? How much of that 3:00
will have elapsed before I've even managed to tell the stove
to start timing???
How should the user think of the stove's actions? Obviously, the
DESIGNER didn't think the stove could walk and chew gum...
On 2024-01-29 20:24, Don Y wrote:
On 1/29/2024 4:25 AM, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled.
really? The *car*? There is nothing that would *require* that
behavior -- except code written to only allow pairing once
in a power-on event.
My car can pair again to the current phone or to another easily, and it works.
But it fails randomly when Android Car Auto or whatever the current name is is
involved, with a Motorola wifi dongle. That's a piece of shit combo.
On 2024-01-29, Don Y wrote:
On 1/29/2024 4:25 AM, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled.
really? The *car*? There is nothing that would *require* that
behavior -- except code written to only allow pairing once
in a power-on event.
I'm being a little tongue in cheek here, since he's comparing an
always-on device (this BT adapter thing) to his car (which is not "always-on"), and complaining he has to power-cycle the always-on one
from time to time.
What none of us know is "what's this time-to-time rate?" and more importantly, "how many times does something go wrong, and the device SUCCESSFULLY reconnects silently?"
[...]
Granted, my car's a decade old (or a bit older); so maybe a newer car
would behave better.
Regardless. If designing a bridge between the cellular network
(cell phone) and a wired network, you would assume keeping that
bridge operational IN ALL SITUATIONS (except being explicitly
told to break the connection) would be a primary design goal.
Just like how my router never needs a reboot?
Or the modem?
Or the cable box?
Or the PC?
Or my cellphone?
If Don's thing takes 5 minutes to reboot (like my router); then with the following assumptions:
1. that we detect it needs the reboot as soon as it goes into its
failure state AND
2. I'm doing the math right ;)
that's a total of 20 minutes downtime per year, or 99.996% uptime.
99.0% uptime is 87.66 minutes, so even monthly reboots is >99% uptime.
To read the input while printing output the programmer has to output a
letter, then listen, in a loop. It can be done, but it is more code.
But, you can decompose it into multiple threads and have LESS
total code.
Did no one wonder "what if the device becomes un-paired?
DURING a call? While sitting idle?
Or (for vehicles), that the car AND DRIVER may want to do two or
more things simultaneously? (Can I turn on the windshield wipers
AND move the driver's seat simultaneously?)
In my car, that's a different processor than the "infotainment" display :-)
Responds instantly.
The "right" solution is to process the video *in* software as youSWMBO's vehicle has a backup camera that comes on when the car is placed >>>> in reverse. But, the software is dog slow... all of the controls are >>>> ignored for a good 30 seconds after turning on the ignition! So, how >>>> can it "notice" the transmission being place in reverse and adjusting
the main display to route live video to it? ANS: I suspect there
is a physical switch that directly connects the video feed to the
display so the view is available regardless of whether or not the
processor has managed to initialize itself!
I doubt there is a hardware switch. It is far easier and cheaper a software >>
have to be able to handle the different camera modes, superimposed
parking guides, etc.
But, if you can't get enough code up and running to see that I am
pressing the "show me the information display instead of the
navigation map", how much hope do you have for processing video?
Same as a TV set with different inputs. It can even have a different processor.
switch. Mine responds faster than 30", and it is just a humble Opel. Display
and firmware made by LG. It draws lines superimposed on the camera display >>> that move as I move the steering wheel, so there is CPU time involved.
Was there a specification ANYWHERE as to how quickly the system
should be responsive? Or, did someone "discover" this problem
later and cobble together a hardware fix (as changing "crt0.s"
would likely be a major heartache!)
It was considered acceptable. You have to let the engine warm up before
attempting to move the car, anyway :-p
Even if you just SHUT OFF the engine from a previous trip? :>
Mine starts up instantly in that situation. It takes maybe minutes before it actually powers off. I know because of the times I wanted to "reboot" it because of problems, I had to wait or it would open on the same menu.
Likely no one ever deliberately thought about the time involved
BEFORE the design was complete. And, at that point, it would
be too hard to change. So, you RATIONALIZE that it isn't
a problem...
I assume that the engineers designing it knew there was a time to boot.
Assumptions are what leads to bad designs. Like assuming that Driver #2
will want to listen to whatever music source Driver #1 had selected when
they finished their most recent "trip".
Our stove has a "big knob" UI; one big knob to select from options
and values, press for ENTER. Great if there is only one task that
the stove can perform at a time.
But, what if you've got the first oven BAKING at 375F with 0:43 left
on its timer, the second BROILING on HIGH with 0:12 left on its
timer AND you want to set a general purpose timer for 3:00 but
the BROIL timer expires while you are setting that? Suddenly,
your general-purpose-timer-setting-activity has been preempted by
"tell the user the BROILER is done". What happened to the
value I was in the process of setting for that general purpose timer?
How long before I can get BACK to doing that? How much of that 3:00
will have elapsed before I've even managed to tell the stove
to start timing???
How should the user think of the stove's actions? Obviously, the
DESIGNER didn't think the stove could walk and chew gum...
I think the designer did think of it, but the beans counter decided to simplify
number of knobs.
On 1/31/2024 10:56 AM, Carlos E.R. wrote:
To read the input while printing output the programmer has to output
a letter, then listen, in a loop. It can be done, but it is more code.
But, you can decompose it into multiple threads and have LESS
total code.
Did no one wonder "what if the device becomes un-paired?
DURING a call? While sitting idle?
Or (for vehicles), that the car AND DRIVER may want to do two or
more things simultaneously? (Can I turn on the windshield wipers
AND move the driver's seat simultaneously?)
In my car, that's a different processor than the "infotainment"
display :-)
Then there is a switch that allows THAT processor to have access to the display
that is normally used by the infotainment/navigation system (because you NORMALLY aren't using the BACKUP camera!) That "switch" can't rely on the software in the infotainment system being operational -- unless someone bastardized the implementation to put:
video_input := other_processor;
EARLY in the startup code.
Responds instantly.
SWMBO's vehicle has a backup camera that comes on when the car is
placed
in reverse. But, the software is dog slow... all of the controls are >>>>> ignored for a good 30 seconds after turning on the ignition! So, how >>>>> can it "notice" the transmission being place in reverse and adjusting >>>>> the main display to route live video to it? ANS: I suspect there >>>>> is a physical switch that directly connects the video feed to the
display so the view is available regardless of whether or not the
processor has managed to initialize itself!
I doubt there is a hardware switch. It is far easier and cheaper a
software
The "right" solution is to process the video *in* software as you
have to be able to handle the different camera modes, superimposed
parking guides, etc.
But, if you can't get enough code up and running to see that I am
pressing the "show me the information display instead of the
navigation map", how much hope do you have for processing video?
Same as a TV set with different inputs. It can even have a different
processor.
You still have to be able to recognize the user's (or environment's) desire to switch to a particular "input".
switch. Mine responds faster than 30", and it is just a humble Opel.
Display and firmware made by LG. It draws lines superimposed on the
camera display that move as I move the steering wheel, so there is
CPU time involved.
Was there a specification ANYWHERE as to how quickly the system
should be responsive? Or, did someone "discover" this problem
later and cobble together a hardware fix (as changing "crt0.s"
would likely be a major heartache!)
It was considered acceptable. You have to let the engine warm up
before attempting to move the car, anyway :-p
Even if you just SHUT OFF the engine from a previous trip? :>
Mine starts up instantly in that situation. It takes maybe minutes
before it actually powers off. I know because of the times I wanted to
"reboot" it because of problems, I had to wait or it would open on the
same menu.
Hers always starts up with the same splash screen (why would a
subcontractor
want to advertise their lousy implementation? hope other clients are equally naive??), legal disclaimer, etc. There is no way to effectively expedite the boot sequence.
Likely no one ever deliberately thought about the time involved
BEFORE the design was complete. And, at that point, it would
be too hard to change. So, you RATIONALIZE that it isn't
a problem...
I assume that the engineers designing it knew there was a time to boot.
Can you tell me how long it will take you for every subsystem
and object to initialize in a system that didn't EXPLICITLY
prioritize a fast startup? This harkens back to application
startup code that expedites throwing a splash screen up so
folks don't wonder why the "program" hasn't started, yet
(it HAS... but, it is busy doing stuff that doesn't make
marks on the screen!)
If you want something to boot quickly, you have to make deliberate
efforts in the design to ensure that you at least give the
appearance of doing so (more than just a quick splash screen).
In my current project, I save an image of the executing systemwhen
when I power a node down. So, I can bring the node back to that
state "immediately" when I need to power it back up (just
wait for the delays to transfer the image over the network).
Depending on how much memory an infotainment system requires
(to store the current state), it could be battery backed
(if low enough power and short enough time) and a simple
hash recomputed on restart to determine the integrity of
the image -- just RESUME instead of RESTART.
Assumptions are what leads to bad designs. Like assuming that Driver #2 1>>> will want to listen to whatever music source Driver #1 had selected
they finished their most recent "trip".
Our stove has a "big knob" UI; one big knob to select from options
and values, press for ENTER. Great if there is only one task that
the stove can perform at a time.
But, what if you've got the first oven BAKING at 375F with 0:43 left
on its timer, the second BROILING on HIGH with 0:12 left on its
timer AND you want to set a general purpose timer for 3:00 but
the BROIL timer expires while you are setting that? Suddenly,
your general-purpose-timer-setting-activity has been preempted by
"tell the user the BROILER is done". What happened to the
value I was in the process of setting for that general purpose timer?
How long before I can get BACK to doing that? How much of that 3:00
will have elapsed before I've even managed to tell the stove
to start timing???
How should the user think of the stove's actions? Obviously, the
DESIGNER didn't think the stove could walk and chew gum...
I think the designer did think of it, but the beans counter decided to
simplify number of knobs.
Then there should be some explanation (to the user) of what
is expected of the user WHEN (not if) that situation occurs.
Past experience (with other products/designs) leads me to
believe they just ignored this use case. E.g., when you
demo the implementation to "management", do you pose
all of these hypothetical cases to see how they like
your solution? Or, do you just focus on ONE user task
at a time:
"See, we use the big knob to select from BAKE, CONVECTION,
DEHYDRATE, BROIL, etc. Then, once we have selected a MODE,
we can use that same big knob to specify a TEMPERATURE.
And, once that is set, we can AGAIN use the big knob to
specify an optional cook time. And, again, what to do at
the expiration of that cook time (leave oven on, shut it
off, etc.)"
"Now, if we happen to be in the middle of specifying
the temperature and the timer for the OTHER oven expires,
we..."
If you think about how YOU would "solve" the UI problem,
you'd discover that the big knob is the problem. A legacy
oven would have different controls ALL PERPETUALLY ACCESSIBLE
that would avoid this issue. The big knob give you no way
of setting the FOCUS for the user's actions!
There are induction cooktops that are only capable of powering
two heating elements at a time. How do you convey that to the
user? Do you LET him use 4 "burners" but time-division multiplex
the "heat" applied? Will he get different perfomance in this
case than when only using *two* burners?
On 1/31/2024 6:16 AM, Carlos E.R. wrote:
On 2024-01-29 20:24, Don Y wrote:
On 1/29/2024 4:25 AM, Dan Purgert wrote:
On 2024-01-28, Don Y wrote:
[...]
Anyway, the device "un-pairs" periodically. And, when this
is discovered by the residents (me!), refuses to pair until
it is power cycled.
[...]
Let's assume you can't AUTOMATICALLY re-pair when you
rediscover the phone (gee, my car manages to do that!).
After it's power-cycled.
really? The *car*? There is nothing that would *require* that
behavior -- except code written to only allow pairing once
in a power-on event.
My car can pair again to the current phone or to another easily, and
it works.
I will have to test SWMBO's. I'll start it (so it sees "no phone" which
is a different use case than starting it with a phone present). Then,
drive
down the block (to ensure it is out of BT range for all of our devices).
Shut it down and restart it (in case it had a glimpse of our devices
while still garaged) and bring a phone into the car to see if it pairs.
Then, power OFF the phone and run some errands (to give it a chance to
"clear any cache" it may have had of the phone's presence) and turn the
phone back on as I return home.
Then, off and introduce another phone to see if it willingly discards the connection to the previous phone (it should do this as a different driver could have a different phone!)
E.g., I have other phones that I use solely as media players (no cell service)
that should pair when carried into the vehicle.
But it fails randomly when Android Car Auto or whatever the current
name is is involved, with a Motorola wifi dongle. That's a piece of
shit combo.
Is that because there are "multiple choices" available?
Or, do you think the devices are in direct conflict?
[I should see what happens if I use BT earbuds paired to the phone as I
bring it into the vehicle...]
My car can pair again to the current phone or to another easily, and it works.
I will have to test SWMBO's. I'll start it (so it sees "no phone" which
is a different use case than starting it with a phone present). Then, drive down the block (to ensure it is out of BT range for all of our devices).
Shut it down and restart it (in case it had a glimpse of our devices while still garaged) and bring a phone into the car to see if it pairs.
Then, power OFF the phone and run some errands (to give it a chance to
"clear any cache" it may have had of the phone's presence) and turn the
phone back on as I return home.
Then, off and introduce another phone to see if it willingly discards the connection to the previous phone (it should do this as a different driver could have a different phone!)
E.g., I have other phones that I use solely as media players (no cell service)
that should pair when carried into the vehicle.
On 2024-01-31 20:13, Don Y wrote:
On 1/31/2024 10:56 AM, Carlos E.R. wrote:
Then there is a switch that allows THAT processor to have access to the displayTo read the input while printing output the programmer has to output a >>>>> letter, then listen, in a loop. It can be done, but it is more code.
But, you can decompose it into multiple threads and have LESS
total code.
Did no one wonder "what if the device becomes un-paired?
DURING a call? While sitting idle?
Or (for vehicles), that the car AND DRIVER may want to do two or
more things simultaneously? (Can I turn on the windshield wipers
AND move the driver's seat simultaneously?)
In my car, that's a different processor than the "infotainment" display :-) >>
that is normally used by the infotainment/navigation system (because you
NORMALLY aren't using the BACKUP camera!) That "switch" can't rely on the >> software in the infotainment system being operational -- unless someone
bastardized the implementation to put:
No, that processor (in my car) uses a different display and different buttons.
video_input := other_processor;
EARLY in the startup code.
Responds instantly.
SWMBO's vehicle has a backup camera that comes on when the car is placed >>>>>> in reverse. But, the software is dog slow... all of the controls are >>>>>> ignored for a good 30 seconds after turning on the ignition! So, how >>>>>> can it "notice" the transmission being place in reverse and adjusting >>>>>> the main display to route live video to it? ANS: I suspect there >>>>>> is a physical switch that directly connects the video feed to the
display so the view is available regardless of whether or not the
processor has managed to initialize itself!
I doubt there is a hardware switch. It is far easier and cheaper a software
The "right" solution is to process the video *in* software as you
have to be able to handle the different camera modes, superimposed
parking guides, etc.
But, if you can't get enough code up and running to see that I am
pressing the "show me the information display instead of the
navigation map", how much hope do you have for processing video?
Same as a TV set with different inputs. It can even have a different processor.
You still have to be able to recognize the user's (or environment's) desire >> to switch to a particular "input".
Yes, but can be handled by different processors, switching the display to one or the other, similarly as does a TV with different inputs.
Likely no one ever deliberately thought about the time involved
BEFORE the design was complete. And, at that point, it would
be too hard to change. So, you RATIONALIZE that it isn't
a problem...
I assume that the engineers designing it knew there was a time to boot.
Can you tell me how long it will take you for every subsystem
and object to initialize in a system that didn't EXPLICITLY
prioritize a fast startup? This harkens back to application
startup code that expedites throwing a splash screen up so
folks don't wonder why the "program" hasn't started, yet
(it HAS... but, it is busy doing stuff that doesn't make
marks on the screen!)
If you want something to boot quickly, you have to make deliberate
efforts in the design to ensure that you at least give the
appearance of doing so (more than just a quick splash screen).
Of course.
How should the user think of the stove's actions? Obviously, the
DESIGNER didn't think the stove could walk and chew gum...
I think the designer did think of it, but the beans counter decided to
simplify number of knobs.
Then there should be some explanation (to the user) of what
is expected of the user WHEN (not if) that situation occurs.
Past experience (with other products/designs) leads me to
believe they just ignored this use case. E.g., when you
demo the implementation to "management", do you pose
all of these hypothetical cases to see how they like
your solution? Or, do you just focus on ONE user task
at a time:
"See, we use the big knob to select from BAKE, CONVECTION,
DEHYDRATE, BROIL, etc. Then, once we have selected a MODE,
we can use that same big knob to specify a TEMPERATURE.
And, once that is set, we can AGAIN use the big knob to
specify an optional cook time. And, again, what to do at
the expiration of that cook time (leave oven on, shut it
off, etc.)"
"Now, if we happen to be in the middle of specifying
the temperature and the timer for the OTHER oven expires,
we..."
If you think about how YOU would "solve" the UI problem,
you'd discover that the big knob is the problem. A legacy
oven would have different controls ALL PERPETUALLY ACCESSIBLE
that would avoid this issue. The big knob give you no way
of setting the FOCUS for the user's actions!
Of course.
There are induction cooktops that are only capable of powering
two heating elements at a time. How do you convey that to the
user? Do you LET him use 4 "burners" but time-division multiplex
the "heat" applied? Will he get different perfomance in this
case than when only using *two* burners?
The limitation can be a power limit.
Some cooktops instead configure a total watts limit.
My induction cooktop has only two burners, and one of them broke down recently.
Repairing it would be 250€; there are ranges cheaper than that.
But it fails randomly when Android Car Auto or whatever the current name is >>> is involved, with a Motorola wifi dongle. That's a piece of shit combo.
Is that because there are "multiple choices" available?
Or, do you think the devices are in direct conflict?
Direct software conflict. > The same hardware worked fine for a year with Android 12.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 300 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 86:33:26 |
| Calls: | 6,717 |
| Calls today: | 1 |
| Files: | 12,248 |
| Messages: | 5,358,389 |
| Posted today: | 1 |