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!)

On Sun, 28 Jan 2024 13:52:57 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>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!)

Hard power cycling fixes all sorts of broken gadgets.

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.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

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.

Jeroen Belleman

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 will have to try powering off the phone and powering on
another phone -- with the car still in operation -- to see
if it automatically finds the new device. I should also
see what happens if TWO phones are eligible to be paired...)

> 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".

I've not encountered that. In fact, I've often been "surprised"
for the car to be indicating a paired phone when I've not made
a deliberate attempt to carry one *into* the car (the idea of
carrying a phone is anathema to me!).

"Oh, I must have left the phone in here. I wonder where it is
hiding??"

> 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.

What value being able to pick up a handset in another room
if you can't rely on it being functionally connected to the
cellular network? ("Do not RELY on this as it likely
won't work when you need it!")

On 1/29/2024 8:51 AM, Jeroen Belleman wrote:
> 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.

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.

Why is the radio tuned to a station that isn't among my presets?

Why is the navigation system telling me that my destination is
8 miles away -- and, 400 ft? (And, I can actually *see* it a
few hundred feet down the road!)

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 1/29/2024 12:39 PM, Don Y wrote:
> 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.

As a simple example:

I have an alarm clock that is implemented in an old rotary-dial
"desk phone".

Pick up the handset and it announces the time/date.

With the handset off-hook, you can set an alarm time
(and other options) which will cause the phone to ring
at the specified criteria.

"Answering" the ringing phone acknowledges the alarm
(and can either reset it or invoke a sleep-timer).

[You still need to be able to FINALLY cancel the sleep timer.]

What if an alarm comes due while you are off-hook? Should
it be deferred, pending your actions (e.g., you may be in the
process of erasing the setting!)

What if you want to "program" the clock just as an alarm is
coming due? (i.e., both examples of races... how do you
resolve them in the user's mind?) Do you have to have the handset
up to your ear to understand what the phone/clock thinks about
reality?

On 2024-01-29, Jeroen Belleman wrote:
> 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.

Oh, definitely! I meant it more as just an admission of understanding
that it's "old hardware" in the car.

As far as I can tell; the car I have is the first model year to
have done away with the "and it comes with this special mp3
player-of-the-era connector!".

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

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.

--
Cheers, Carlos.

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

--
Cheers, Carlos.

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.

--
|_|O|_|
|_|_|O| Github: https://github.com/dpurgert
|O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860

On 2024-01-31 15:38, Dan Purgert wrote:
> 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?"

I have this:

car---BT --> phone
\ \--USB--BT+Wifi Dongle --> Phone with Android Auto.

The two BT systems collide after the upgrade to Android 13, but both are
needed (Android Car Auto uses the car BT for authorization, then it
attempts the USB+BT+WiFi connection). Currently when the connection
fails, I have to unplug the BT+Wifi Dongle (an M1 from Motorola), then
fiddle with the BT tap on the phone (also a Motorola) in order to make
sure the phone connects to the car BT, and then plug in the dongle and
wait for its connection as well.

Weeks ago I had to stop, exit and lock the car, and reboot the phone, in
order to the the thing to connect again and work. Something like 7 minutes.

It has been like a month of pain in the ass. Now it is working better,
but I never know when starting the car if it is going to work or not.

While I'm driving I see the car BT disconnect and reconnect randomly
from the phone.

--
Cheers, Carlos.

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?)

>>> 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

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-31 18:37, Don Y wrote:
> 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?)

In my car, that's a different processor than the "infotainment" display :-)

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.

>
>> 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.

--
Cheers, Carlos.

On 1/31/2024 7:38 AM, Dan Purgert wrote:
> 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.

How long should a device INTENDED TO BE ALWAYS ON run before "needing"
to be power cycled? Please explain the basis for any figures
you provide so we can extend it to how often *any* bug can manifest...

> 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?"

What can "go wrong"? Is the Apple phone more likely to misbehave or
the (garage-shop) bridge adapter? Note that the cordless phone
system runs 24/7/365 despite having processors in their base unit
and each handset. As does the processor in my furnace, microwave
oven, freezer, ...

It has never been "disconnected" (that we could "detect"), previously.

When you pick up a wired handset (because you want to use the telephone
service) and the *device* tells you: "Warning. The phone is disconnected"
you have to wonder:
- why?
- when?
- how?
and why IT hasn't done anything to remedy that situation -- even if
*all* it could do was RING the phone and deliver that prompt when
*it* detected that it was no longer connected.

Clearly, it is operational -- at least partially so! And, CLAIMS to
"Auto reconnect: When your cell phones are within range"
So, how is it "confused"? And, how does cycling ITS power correct
the situation (if it wasn't an internal problem in the device?)

>>> [...]
>>> 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?

Router: 117 Days 7 Hours 31 Minutes 20 Seconds
(the batteries in the UPS for this machine -- and the router
plus modem -- have died years ago and I've not considered
them important enough to spend $100 on their replacement)

My "network services" box: 1134 days
(which, I bet, is the day I built it's latest kernel! It's
UPS is still operational and can power the appliance for
the better part of a *day*)

> Or the modem?

I can't talk to my radio as it belongs to my ISP

> Or the cable box?

None

> Or the PC?

Running or sleeping, continuously (reboot is too time consuming
for the various HBAs -- SCSI, SAS -- to poll their buses and NICs
to attempt PXE boot)

Does waking from hibernation count as a reboot?

> Or my cellphone?

Never powered OFF let alone rebooted!

> 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.

What's the uptime for your telephone service? Electric? Water?

A phone is a UTILITY. It is expected to be available.
And, definitely not FAIL SILENTLY!

I've walked up to the phone three times in the past week and
found no dialtone ("Warning..."). What are the chances that
I've managed to catch it between "automatic reboots" (which
we know it doesn't do)?

If I had a "pressing need" to make a phone call and was relying
on the advertised convenience of being able to have a phone
"nearby" without having to carry a cell phone around the house,
would I have been disappointed? At risk?

Let's pretend magic elves did something to break the connection.
How does that excuse the device NOT pairing (despite being
operational enough to recognize that I've gone off-hook AND
been able to generate a spoken prompt) when commanded to do so?

No, this is a design defect. And, the "support" folks glossing over
the "won't repair when commanded" issue to focus on the "why did it
UN-PAIR" question is dishonest.

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...]

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 system
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
>> 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.

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 2024-01-31 20:13, Don Y wrote:
> 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:

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.

>
>>>> 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).

Of course.

> In my current project, I save an image of the executing system
> 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
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.
>
> 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!

On 2024-01-31 19:49, Don Y wrote:
> 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?

Direct software conflict.
The same hardware worked fine for a year with Android 12.

>
> [I should see what happens if I use BT earbuds paired to the phone as I
> bring it into the vehicle...]
>
>

--
Cheers, Carlos.

On 1/31/2024 11:49 AM, Don Y wrote:
>> 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.

I tried this with a set of three phones. All initially off so the car didn't
know they were present until AFTER the car had been started.

Any ONE phone will pair with the car, when powered on. And, will re-pair
with the car (while car is still running) if powered off and back on
(or, BT turned off -- airplane mode -- and back on) -- regardless of
which phone had most recently paired with the car.

Turning on a second phone while the car is paired, has the second
phone ignored (I'm unsure if that is the intuitive behavior... a car
full of family, each with their own phones? Perhaps the car should
be forced to stick with *one*??).

Turning the first/paired phone off does not cause the "next" phone
to be found. I am unsure of the intuitive behavior in that case, either.

But, clearly, a phone/car that has unpaired can repair without
manual intervention from the user.

On 1/31/2024 12:37 PM, Carlos E.R. wrote:
> On 2024-01-31 20:13, Don Y wrote:
>> 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:
>
> No, that processor (in my car) uses a different display and different buttons.

I can only assume that the same processor is processing the video from
the camera as doing the navigation and infotainment. The display
in question (there are three in the car) is used for multiple purposes
(when interacting with your cell phone, handling navigation, interacting
with the media player, displaying car status (fuel economy, etc.) or
configuring "settings" -- for all of the above).

>>      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.

Regardless of the number of processors/video sources, each PROCESS needs to be
aware of whether or not it "has the user's attention" (i.e., control of the
display). E.g., I can't call up the navigation system while the car is in
reverse (even if stationary). Nor can the media player override the display
when I'm reviewing settings.

(But, the navigation system can split the screen at any time to indicate
your approach to a waypoint)

>>>> 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.

This tends not to be something that folks consider when developing
applications. And, depending on the technologies used (e.g., OOPS),
may be difficult to address after-the-fact. I.e., all of the objects
would need to be instantiated in that interval.

>>>> 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.

Do the stakeholders even know what *focus* is?

>> 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.

I think the "two burners" may be a consequence of whatever electronics
are necessary to DRIVE the two (of 4 or 5) coils. realistically, how
many people use every stovetop burner concurrently -- and, at maximum
power/drive? (anything less than maximum would lend itself to
time division multiplexing). How do you tell the user that the
stove can't meet his requirements, "at this time"?

[I wonder if the controls are smart enough to even "balance" the
load for bang-bang controls!?]

> 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.

While we tend to *use* the cooktop more than the oven, *my* concerns have
always been with the oven (or ovenS, in our case) as anything that takes
a LONG time (baking) represents a bigger annoyance if less than ideal.

[But, SWMBO fell in love with the stove so we voted -- *it* won, 60-40!]

On 1/31/2024 12:39 PM, Carlos E.R. wrote:

>>> 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.

Where is the "Car Auto" software running (as that seems to
be what you suspect)?

Why can't that device connect to the BT hosted by that same
adapter?