Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #26162 > unrolled thread

Cloud? IoT? How to start

Back to article view | Back to comp.arch.embedded

Contents

  Cloud? IoT? How to start pozz <pozzugno@gmail.com> - 2017-03-23 12:04 +0100
    Re: Cloud? IoT? How to start Randy Day <randy.day@sasktel.netx> - 2017-03-23 07:41 -0600
    Re: Cloud? IoT? How to start Paul <paul@pcserviceselectronics.co.uk> - 2017-03-24 12:04 +0000
      Re: Cloud? IoT? How to start rickman <gnuarm@gmail.com> - 2017-03-25 15:35 -0400
        Re: Cloud? IoT? How to start Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-25 20:10 +0000
        Re: Cloud? IoT? How to start Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:23 -0500
        Re: Cloud? IoT? How to start Grant Edwards <invalid@invalid.invalid> - 2017-03-25 20:28 +0000
      Re: Cloud? IoT? How to start upsidedown@downunder.com - 2017-03-25 22:20 +0200
        Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-25 19:34 -0700
        Re: Cloud? IoT? How to start Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-26 07:49 +0100
          Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-26 01:20 -0700
            Re: Cloud? IoT? How to start Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-26 09:17 +0100
              Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-26 02:47 -0700
                Re: Cloud? IoT? How to start Paul <paul@pcserviceselectronics.co.uk> - 2017-03-26 12:46 +0100
                  Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-26 11:31 -0700
                    Re: Cloud? IoT? How to start Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-26 21:29 +0100
                      Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-26 16:08 -0700
          Re: Cloud? IoT? How to start pozz <pozzugno@gmail.com> - 2017-03-27 09:21 +0200
    Re: Cloud? IoT? How to start Grant Edwards <invalid@invalid.invalid> - 2017-03-24 14:41 +0000
      Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-24 11:29 -0700
        Re: Cloud? IoT? How to start George Neuner <gneuner2@comcast.net> - 2017-03-24 23:03 -0400
          Re: Cloud? IoT? How to start "tim..." <tims_new_home@yahoo.com> - 2017-03-25 09:16 +0000
          Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-25 10:39 -0700
            Re: Cloud? IoT? How to start George Neuner <gneuner2@comcast.net> - 2017-03-26 05:31 -0400
              Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-26 03:36 -0700
              Re: Cloud? IoT? How to start Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-27 00:22 +0000
                Re: Cloud? IoT? How to start Tom Gardner <spamjunk@blueyonder.co.uk> - 2017-03-27 16:53 +0100
                  Re: Cloud? IoT? How to start Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-27 18:45 +0000
                    Re: Cloud? IoT? How to start Robert Wessel <robertwessel2@yahoo.com> - 2017-03-27 15:21 -0500
                      Re: Cloud? IoT? How to start Simon Clubley <clubley@remove_me.eisner.decus.org-Earth.UFP> - 2017-03-28 17:59 +0000
                        Re: Cloud? IoT? How to start Robert Wessel <robertwessel2@yahoo.com> - 2017-03-28 15:01 -0500
                        Re: Cloud? IoT? How to start rickman <gnuarm@gmail.com> - 2017-03-31 00:09 -0400
                          Re: Cloud? IoT? How to start Anssi Saari <as@sci.fi> - 2017-04-05 11:58 +0300
        Re: Cloud? IoT? How to start Les Cargill <lcargill99@comcast.com> - 2017-03-25 12:55 -0500
          Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-25 11:01 -0700
            Re: Cloud? IoT? How to start Les Cargill <lcargill99@comcast.com> - 2017-03-25 15:25 -0500
              Re: Cloud? IoT? How to start Don Y <blockedofcourse@foo.invalid> - 2017-03-25 19:36 -0700
    Re: Cloud? IoT? How to start Theo Markettos <theom+news@chiark.greenend.org.uk> - 2017-03-24 18:29 +0000
    Re: Cloud? IoT? How to start "Robert Lacoste" <see-alciom-dot-com@none.com> - 2017-03-29 13:33 +0200

Page 2 of 2 — ← Prev page 1 [2]

#26236

On Fri, 24 Mar 2017 11:29:59 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>Does your automobile *need* a radio?  heater?  etc.?

Many cars *do* need the radio ... to perform ignition key/fob code
verification.  Pull the stereo in the new car and see if it still
starts 8-).

For many autos, an after-market stereo upgrade has to leave the old
unit connected, powered, and buried in the dash because removing it
disables the vehicle.

George

[toc] | [prev] | [next] | [standalone]

#26242

"George Neuner" <gneuner2@comcast.net> wrote in message 
news:gpmbdc57jg7fb5h8l4t83794ldit2jg450@4ax.com...
> On Fri, 24 Mar 2017 11:29:59 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>>Does your automobile *need* a radio?  heater?  etc.?
>
> Many cars *do* need the radio ... to perform ignition key/fob code
> verification.  Pull the stereo in the new car and see if it still
> starts 8-).

you know of a new car that has a stereo that will pull out?

tim

 

[toc] | [prev] | [next] | [standalone]

#26247

On 3/24/2017 8:03 PM, George Neuner wrote:
> On Fri, 24 Mar 2017 11:29:59 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> Does your automobile *need* a radio?  heater?  etc.?
>
> Many cars *do* need the radio ... to perform ignition key/fob code
> verification.  Pull the stereo in the new car and see if it still
> starts 8-).

I'm not sure *where* the hardware and software functionality for
the fob-related features resides (haven't purchased a workshop manual,
yet; I've been forbidden from tinkering with it until the warranty
expires!  :> ).

I know there are near-field sensors in each of the driver/passenger
doors (approximately) as it will only unlock the corresponding door
if *a* fob is sensed in its proximity (I think 37 inches?) as the handle
is touched.  I assume the same driver-side fob-sensor is used to enable
the ignition.  I.e., with both of us in the front seat, roughly equidistant
from the START button and each carrying a fob, it recognizes which of us
is actually *in* the driver's seat and selects that driver's profile
(seat position, mirror settings, GPS/phone/stereo settings, etc.)

Likewise, rear hatch won't raise unless a fob similarly detected, there.

"Remote" function will work over reasonably long distances (a block
or so?).

And, "dead battery fallback" only operates within an inch or two of
the START button.

Don't know if the Sirius "upgrade" is a hardware upgrade, software
upgrade or just a bit that enables a feature.  Of course, AM/FM
require a real radio.

GPS obviously does, as well.  As does the "concierge" service (or
whatever it is called). And, the BT link to the phone.  Hard to imagine
*all* of those using a shared set of hardware.

(E.g., I'd imagine there's more than just an "antenna" in each door
sensor; easier to ship a packet of digital data to something that
decides whether or not to unlock the doors)

> For many autos, an after-market stereo upgrade has to leave the old
> unit connected, powered, and buried in the dash because removing it
> disables the vehicle.

On earlier vintage of this model, the radio/stereo could be *replaced*.
Lots of online docs about locating the "code" to enable the radio's
functionality (anti-theft).  You'd think that if it disabled the car
from starting, the questions would be ""I removed my stereo and now
my car won't start..."

[toc] | [prev] | [next] | [standalone]

#26275

On Sat, 25 Mar 2017 10:39:50 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 3/24/2017 8:03 PM, George Neuner wrote:
>> On Fri, 24 Mar 2017 11:29:59 -0700, Don Y
>> <blockedofcourse@foo.invalid> wrote:
>>
>>> Does your automobile *need* a radio?  heater?  etc.?
>>
>> Many cars *do* need the radio ... to perform ignition key/fob code
>> verification.  Pull the stereo in the new car and see if it still
>> starts 8-).
>
>I'm not sure *where* the hardware and software functionality for
>the fob-related features resides (haven't purchased a workshop manual,
>yet; I've been forbidden from tinkering with it until the warranty
>expires!  :> ).

Nothing per se to do with "wireless" fobs.  

Many vehicles that have coded ignition *keys* cannot be started if
their radio is damaged or removed.  Most auto manufacturers now have
some kind of ignition lockout system - but some of them place the
circuitry in the stereo system.  GM and Honda in particular are well
known for this, but they aren't the only ones.

George

[toc] | [prev] | [next] | [standalone]

#26278

On 3/26/2017 2:31 AM, George Neuner wrote:
> On Sat, 25 Mar 2017 10:39:50 -0700, Don Y
> <blockedofcourse@foo.invalid> wrote:
>
>> On 3/24/2017 8:03 PM, George Neuner wrote:
>>> On Fri, 24 Mar 2017 11:29:59 -0700, Don Y
>>> <blockedofcourse@foo.invalid> wrote:
>>>
>>>> Does your automobile *need* a radio?  heater?  etc.?
>>>
>>> Many cars *do* need the radio ... to perform ignition key/fob code
>>> verification.  Pull the stereo in the new car and see if it still
>>> starts 8-).
>>
>> I'm not sure *where* the hardware and software functionality for
>> the fob-related features resides (haven't purchased a workshop manual,
>> yet; I've been forbidden from tinkering with it until the warranty
>> expires!  :> ).
>
> Nothing per se to do with "wireless" fobs.
>
> Many vehicles that have coded ignition *keys* cannot be started if
> their radio is damaged or removed.  Most auto manufacturers now have
> some kind of ignition lockout system - but some of them place the
> circuitry in the stereo system.  GM and Honda in particular are well
> known for this, but they aren't the only ones.

Then you'd expect the radio replacement/service procedure (including
replacing a blown radio fuse) to indicate that the car won't start
with a blown radio fuse, right?  (as that would be comparable to
removing the radio).

I see no google hits pertaining to radios, their fuses or "trouble starting".

[toc] | [prev] | [next] | [standalone]

#26296

On 2017-03-26, George Neuner <gneuner2@comcast.net> wrote:
>
> Many vehicles that have coded ignition *keys* cannot be started if
> their radio is damaged or removed.  Most auto manufacturers now have
> some kind of ignition lockout system - but some of them place the
> circuitry in the stereo system.  GM and Honda in particular are well
> known for this, but they aren't the only ones.
>

And what on earth happens if you need to get to the hospital in a
hurry or if there's an accident out in the middle of nowhere that
leaves the vehicle (sort of) drivable but damages the radio ?

Perhaps everyone should switch to driving a Lada or in the US,
whatever the el-cheapo car is/was (Yugo?). :-) On the plus side, you
wouldn't have to worry about remote hacking of your vehicle. :-)

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[toc] | [prev] | [next] | [standalone]

#26309

On 27/03/17 01:22, Simon Clubley wrote:
> On 2017-03-26, George Neuner <gneuner2@comcast.net> wrote:
>>
>> Many vehicles that have coded ignition *keys* cannot be started if
>> their radio is damaged or removed.  Most auto manufacturers now have
>> some kind of ignition lockout system - but some of them place the
>> circuitry in the stereo system.  GM and Honda in particular are well
>> known for this, but they aren't the only ones.
>>
>
> And what on earth happens if you need to get to the hospital in a
> hurry or if there's an accident out in the middle of nowhere that
> leaves the vehicle (sort of) drivable but damages the radio ?

http://www.telegraph.co.uk/technology/2017/01/16/tesla-driver-stranded-desert-smartphone-app-failure/

[toc] | [prev] | [next] | [standalone]

#26316

On 2017-03-27, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
> On 27/03/17 01:22, Simon Clubley wrote:
>> On 2017-03-26, George Neuner <gneuner2@comcast.net> wrote:
>>>
>>> Many vehicles that have coded ignition *keys* cannot be started if
>>> their radio is damaged or removed.  Most auto manufacturers now have
>>> some kind of ignition lockout system - but some of them place the
>>> circuitry in the stereo system.  GM and Honda in particular are well
>>> known for this, but they aren't the only ones.
>>>
>>
>> And what on earth happens if you need to get to the hospital in a
>> hurry or if there's an accident out in the middle of nowhere that
>> leaves the vehicle (sort of) drivable but damages the radio ?
>
> http://www.telegraph.co.uk/technology/2017/01/16/tesla-driver-stranded-desert-smartphone-app-failure/
>

Unbelievable. :-(

That's a failure on so many levels, starting with Tesla for designing
such a fragile system without any obvious backups and ending with the
driver who never thought of this.

In fairness to the driver however, depending on how it was explained
to him, he may never have fully realised the implications of not having
connectivity to the remote servers until he found out the hard way.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[toc] | [prev] | [next] | [standalone]

#26318

On Mon, 27 Mar 2017 18:45:09 -0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2017-03-27, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>> On 27/03/17 01:22, Simon Clubley wrote:
>>> On 2017-03-26, George Neuner <gneuner2@comcast.net> wrote:
>>>>
>>>> Many vehicles that have coded ignition *keys* cannot be started if
>>>> their radio is damaged or removed.  Most auto manufacturers now have
>>>> some kind of ignition lockout system - but some of them place the
>>>> circuitry in the stereo system.  GM and Honda in particular are well
>>>> known for this, but they aren't the only ones.
>>>>
>>>
>>> And what on earth happens if you need to get to the hospital in a
>>> hurry or if there's an accident out in the middle of nowhere that
>>> leaves the vehicle (sort of) drivable but damages the radio ?
>>
>> http://www.telegraph.co.uk/technology/2017/01/16/tesla-driver-stranded-desert-smartphone-app-failure/
>>
>
>Unbelievable. :-(
>
>That's a failure on so many levels, starting with Tesla for designing
>such a fragile system without any obvious backups and ending with the
>driver who never thought of this.


But this *was* the backup system.  The primary system was the key fob.
This let you drive you car in most cases even if you forgot to
actually take you car keys with you.

It's not so easy a problem to fix either - they used network
connectivity to check if your phone was still valid to unlock your
car.  If they didn't (say the phone would also authenticate to the car
in pure Bluetooth mode), someone could just steal your phone, turn off
WiFi and the 3G/4G connection, and go nick your Tesla (of course
that's not any different than actually stealing your car keys, except
that grabbing a cell phone is practically much easier, since they're
so often out in the open, while keys tend to spend most of their time
in pockets and such).  Which is not to say there aren't ways to fix
this, but none are completely straight-forward.

This is also a simple and straight-forward extension of a preceding
technology, which just makes that problem worse (it's just like what
we've already been doing, but with this little bit added).  For
example, OnStar's long standing ability to unlock your car for you
(you've bean able to call them if you locked the keys in the car since
1996).  Being able to do that from a phone app is a pretty trivial
enhancement, and being able to also *start* the car remotely is
another trivial enhancement (remote start by itself dates back
decades).  Nor are either of those are uncommon - my Nissan will do
both - although I've never then tried to get into my car and drive
away without my key fob.  I'll have to try that sometime, although I
suspect it would work - I *know* you can drive the car without the fob
after getting it unlocked and started in the conventional manner (it
does beep at you and display "no key" if you do).  Which then lead to
similar failure mode.  For example, what if you left your keys on the
sunroof (certainly close enough to make the door and starter sensors
happy), unlocked the car, started it, and then drove off into Death
Valley, stopping (and turning off the car) half way across to admire
the scenery.  Again, you'd be stuck (assuming the keys had actually
blown off the roof).

Tesla's failure was in not realizing that a backup system might become
the primary system, because users are creative like that.  That error
has bitten many designers - "we don't have to actually monitor X,
because the emergency limit sensor will shut it down when it goes too
far", "we don't have to handle the gun safely, the safety is on", "I
don't have to check the coolant level every day, because the backup
cooling system will kick in if the primary system runs low", "I can
take safety #1 and #2 off, because safety #3 is still there".

[toc] | [prev] | [next] | [standalone]

#26326

On 2017-03-27, Robert Wessel <robertwessel2@yahoo.com> wrote:
> On Mon, 27 Mar 2017 18:45:09 -0000 (UTC), Simon Clubley
><clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>
>>On 2017-03-27, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>>>
>>> http://www.telegraph.co.uk/technology/2017/01/16/tesla-driver-stranded-desert-smartphone-app-failure/
>>>
>>
>>Unbelievable. :-(
>>
>>That's a failure on so many levels, starting with Tesla for designing
>>such a fragile system without any obvious backups and ending with the
>>driver who never thought of this.
>
>
> But this *was* the backup system.  The primary system was the key fob.
> This let you drive you car in most cases even if you forgot to
> actually take you car keys with you.
>

Oh, I see, thanks. I wonder if the driver knew that a usable signal was
required for his mobile phone and I wonder if Tesla made that explicit
in their manuals and user training. (Not everyone would think to ask
these types of questions unprompted.)

>
> Tesla's failure was in not realizing that a backup system might become
> the primary system, because users are creative like that.  That error
> has bitten many designers - "we don't have to actually monitor X,
> because the emergency limit sensor will shut it down when it goes too
> far", "we don't have to handle the gun safely, the safety is on", "I
> don't have to check the coolant level every day, because the backup
> cooling system will kick in if the primary system runs low", "I can
> take safety #1 and #2 off, because safety #3 is still there".

Perhaps it might be better if we all just went back to using physical
keys instead. :-)

Thanks for taking the time to do the above writeup.

Simon.

-- 
Simon Clubley, clubley@remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world

[toc] | [prev] | [next] | [standalone]

#26328

On Tue, 28 Mar 2017 17:59:28 -0000 (UTC), Simon Clubley
<clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:

>On 2017-03-27, Robert Wessel <robertwessel2@yahoo.com> wrote:
>> On Mon, 27 Mar 2017 18:45:09 -0000 (UTC), Simon Clubley
>><clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>>On 2017-03-27, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>>>>
>>>> http://www.telegraph.co.uk/technology/2017/01/16/tesla-driver-stranded-desert-smartphone-app-failure/
>>>>
>>>
>>>Unbelievable. :-(
>>>
>>>That's a failure on so many levels, starting with Tesla for designing
>>>such a fragile system without any obvious backups and ending with the
>>>driver who never thought of this.
>>
>>
>> But this *was* the backup system.  The primary system was the key fob.
>> This let you drive you car in most cases even if you forgot to
>> actually take you car keys with you.
>>
>
>Oh, I see, thanks. I wonder if the driver knew that a usable signal was
>required for his mobile phone and I wonder if Tesla made that explicit
>in their manuals and user training. (Not everyone would think to ask
>these types of questions unprompted.)


That's a good question, I have no idea how explicit Tesla's training
was/is.  I suspect they emphasize that point more now, though...

I also suspect it was not really a failure mode in the forefront of
Tesla's engineer's minds.  Sure, "it won't work if there's no phone
service" is obvious, but getting from there to "what if a user starts
the car with their phone and then drives someplace without phone
service and shuts it down" goes a couple of steps past the problem
they were trying to solve.  Of course it *is* their responsibility to
think about that sort of thing.  So I'd assume it was mentioned, but
not really emphasized.  IOW "this won't work if you don't have phone
service" was probably mentioned, or at least implied, but "don't use
this to start your car and then drive off into the desert" was not,
and the user didn't make that connection either.

As I mentioned, Nissan has most of the same features (although I'm not
sure it has everything you need to create this particular problem),
and they certainly didn't go out of their way to even emphasize that
unlocking or starting my car from my phone wouldn't work if I didn't
have phone service.  It might well have been in the fine print in the
click through license agreement, but how often do those actually get
read.

I suspect it'll be less than effective in any event - when was the
last time you could get a user to pay attention to a lecture on how
the primary system works, much less the peculiarities of the backup
system...  I still can't convince my mom that she can actually unlock
all the doors by double tapping the button on her key fob.  She
insists on just opening the driver's door, then hunting* for a while
for the door unlock button on the driver's door armrest.  Usually
while I'm standing in the rain on the passenger side.


*I once got a call a couple of days after one of those events that
none of the windows worked anymore (the driver's window might still
have, I don't remember).  She had hit the window lock in the process
of hunting for the door unlock...


>> Tesla's failure was in not realizing that a backup system might become
>> the primary system, because users are creative like that.  That error
>> has bitten many designers - "we don't have to actually monitor X,
>> because the emergency limit sensor will shut it down when it goes too
>> far", "we don't have to handle the gun safely, the safety is on", "I
>> don't have to check the coolant level every day, because the backup
>> cooling system will kick in if the primary system runs low", "I can
>> take safety #1 and #2 off, because safety #3 is still there".
>
>Perhaps it might be better if we all just went back to using physical
>keys instead. :-)


The traditional approach, where the key was physically locked into the
ignition certainly had the advantage that you couldn't drive the car
anywhere without taking the ignition key with you!

But that was only the ignition key.  GM, for example, was (in)famous
for decades for having different* door and ignition keys.  So if you
had some way to *lock* the door without the door key (and that was
possible with at least some cars - sometimes via the
hold-up-the-latch-while-closing-the-door trick), you could have lost
the door key after unlocking the door, and then driven off with the
ignition key, and then gotten yourself locked out of the car, despite
having the ignition key.  Of course most users just kept both keys on
the same keychain, which usually prevented that problem.

Most people, myself included, would be loathe to give up keyless entry
just because it introduces a few new (rare) failure modes.  It is darn
convenient.


*They built steering columns and doors in different plants, and it
took them decades to figure out how to coordinate those assemblies so
the same key was configured for both.

Most people, myself included, would be loathe to give up keyless entry
just because it introduces a few new (rare) failure modes.  It is darn
convinient.


*They built steering columns and doors in different plants, and it
took them decades to figure out how to coordinate those assemblies so
the same key was configured for both.

[toc] | [prev] | [next] | [standalone]

#26354

On 3/28/2017 1:59 PM, Simon Clubley wrote:
> On 2017-03-27, Robert Wessel <robertwessel2@yahoo.com> wrote:
>> On Mon, 27 Mar 2017 18:45:09 -0000 (UTC), Simon Clubley
>> <clubley@remove_me.eisner.decus.org-Earth.UFP> wrote:
>>
>>> On 2017-03-27, Tom Gardner <spamjunk@blueyonder.co.uk> wrote:
>>>>
>>>> http://www.telegraph.co.uk/technology/2017/01/16/tesla-driver-stranded-desert-smartphone-app-failure/
>>>>
>>>
>>> Unbelievable. :-(
>>>
>>> That's a failure on so many levels, starting with Tesla for designing
>>> such a fragile system without any obvious backups and ending with the
>>> driver who never thought of this.
>>
>>
>> But this *was* the backup system.  The primary system was the key fob.
>> This let you drive you car in most cases even if you forgot to
>> actually take you car keys with you.
>>
>
> Oh, I see, thanks. I wonder if the driver knew that a usable signal was
> required for his mobile phone and I wonder if Tesla made that explicit
> in their manuals and user training. (Not everyone would think to ask
> these types of questions unprompted.)

Trust me, people don't have a clue about cell coverage not extending 
across every corner of the globe.  I kayak and many people bring their 
cell phones to use the GPS.  Trouble is they don't work out of range of 
a tower.  My hand held GPS continues to work as long as I have a 
battery.  They also don't understand a cell phone is a poor emergency 
distress signal for the same reason.  If you need to use it you are 
likely too far from a cell tower.

-- 

Rick C

[toc] | [prev] | [next] | [standalone]

#26361

rickman <gnuarm@gmail.com> writes:

> Trust me, people don't have a clue about cell coverage not extending
> across every corner of the globe.  I kayak and many people bring their
> cell phones to use the GPS.  Trouble is they don't work out of range
> of a tower.

Weird. Even Google Maps these days has an offline mode (and can navigate
offline too.) Of course, they'd need to download offline maps for the
area they want beforehand and at least in my experience Goog's maps
aren't that useful anywhere outside a road... But other apps provide
maps for that too.

[toc] | [prev] | [next] | [standalone]

#26248

Don Y wrote:
> On 3/24/2017 7:41 AM, Grant Edwards wrote:
>> On 2017-03-23, pozz <pozzugno@gmail.com> wrote:
>>
>>> I'd like to start learning the modern paradigm of IoT and Cloud.
>>
>> IoT:
>>
>> Take a bunch of small devices with no need for internet access.
>> Add
>
> IoT doesn't require access to The Internet.  Remember, *an* internet
> just refers to them being able to talk (i.e., to each other).
>


It's generally clearer to refer to "an inTRAnet".

> As to whether they *need* that ability... that depends on the
> functionality you want to give them.  Does your automobile *need* a
> radio?  heater? etc.?
>

IoT is largely "control things with your phone". That doesn't
necessarily mean using the larger Internet but it's semi-implied that
it does. Somewhere around the third person who uses it will expect
that.

<snip>
>>> My first impression is that they are "empty words" without a
>>> precise meaning: you can fill the "word" as you want.
>
>

Yep.

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#26249

On 3/25/2017 10:55 AM, Les Cargill wrote:
> Don Y wrote:
>> On 3/24/2017 7:41 AM, Grant Edwards wrote:
>>> On 2017-03-23, pozz <pozzugno@gmail.com> wrote:
>>>
>>>> I'd like to start learning the modern paradigm of IoT and Cloud.
>>>
>>> IoT:
>>>
>>> Take a bunch of small devices with no need for internet access.
>>> Add
>>
>> IoT doesn't require access to The Internet.  Remember, *an* internet
>> just refers to them being able to talk (i.e., to each other).
>
> It's generally clearer to refer to "an inTRAnet".

The Internet is AN internet.  What you call an intranet is likewise.
Would you say IoT was an acronym for Intranet-of-Things?  *And*
Internet-of-Things?  (i.e., the important aspect is that the devices
are internetworked, not that they can talk to The Internet.

>> As to whether they *need* that ability... that depends on the
>> functionality you want to give them.  Does your automobile *need* a
>> radio?  heater? etc.?
>
> IoT is largely "control things with your phone". That doesn't
> necessarily mean using the larger Internet but it's semi-implied that
> it does. Somewhere around the third person who uses it will expect
> that.

No, that's just how it is currently marketed.  How do you "control"
your refrigerator with your phone?  It may, however, monitor what
you've placed in and removed from it.  Or, let you visually examine
its contents without opening the door.  But, none of that requires
The Internet.  Or, a phone.

I pretty much have more IoT kit, here, than most homes in the
country.  Yet, I don't rely on The Internet for *any* of it!
(OTOH, I can access and control most of it using a voice channel
via the PSTN)

> <snip>
>>>> My first impression is that they are "empty words" without a
>>>> precise meaning: you can fill the "word" as you want.
>
> Yep.

[toc] | [prev] | [next] | [standalone]

#26264

Don Y wrote:
> On 3/25/2017 10:55 AM, Les Cargill wrote:
>> Don Y wrote:
>>> On 3/24/2017 7:41 AM, Grant Edwards wrote:
>>>> On 2017-03-23, pozz <pozzugno@gmail.com> wrote:
>>>>
>>>>> I'd like to start learning the modern paradigm of IoT and Cloud.
>>>>
>>>> IoT:
>>>>
>>>> Take a bunch of small devices with no need for internet access.
>>>> Add
>>>
>>> IoT doesn't require access to The Internet.  Remember, *an* internet
>>> just refers to them being able to talk (i.e., to each other).
>>
>> It's generally clearer to refer to "an inTRAnet".
>
> The Internet is AN internet.  What you call an intranet is likewise.

Look, I'm just trying to get terminology that is inherently
clearer. You can call it food if you want to. :)

An inTRAnet can often lack a backhaul to the larger world. Since
that fits what you described...

<snip>

-- 
Les Cargill

[toc] | [prev] | [next] | [standalone]

#26269

On 3/25/2017 1:25 PM, Les Cargill wrote:
> Don Y wrote:
>> On 3/25/2017 10:55 AM, Les Cargill wrote:
>>> Don Y wrote:
>>>> On 3/24/2017 7:41 AM, Grant Edwards wrote:
>>>>> On 2017-03-23, pozz <pozzugno@gmail.com> wrote:
>>>>>
>>>>>> I'd like to start learning the modern paradigm of IoT and Cloud.
>>>>>
>>>>> IoT:
>>>>>
>>>>> Take a bunch of small devices with no need for internet access.
>>>>> Add
>>>>
>>>> IoT doesn't require access to The Internet.  Remember, *an* internet
>>>> just refers to them being able to talk (i.e., to each other).
>>>
>>> It's generally clearer to refer to "an inTRAnet".
>>
>> The Internet is AN internet.  What you call an intranet is likewise.
>
> Look, I'm just trying to get terminology that is inherently
> clearer. You can call it food if you want to. :)

Adding yet another term to finely resolve between different types
of IoT installations doesn't really make things any clearer.
     "Will you be wwanting to connect these devices to The Internet,
     Mr Smith?  I need to know if you want IoT devices or iOt devices..."

> An inTRAnet can often lack a backhaul to the larger world. Since
> that fits what you described...

[toc] | [prev] | [next] | [standalone]

#26220

pozz <pozzugno@gmail.com> wrote:
> I'd like to start learning the modern paradigm of IoT and Cloud.  My 
> first impression is that they are "empty words" without a precise 
> meaning: you can fill the "word" as you want.

Is this 'learn' as in 'understand how all the layers work' or 'learn' as in
'pick tool X and learn its API'?

In the former case I suggest installing a VM system, eg Xen, KVM, HyperV or
ESXi, and then spinning up some VMs on that.  Then, proceed to play with
some of the containerisation and high availability tools on top of your
VM(s).

All of this is hidden behind APIs like AWS and App Engine.  You can pick
those up by jumping in at their API level, but it helps to understand what
is going on underneath them.  In particular, the API is typically
vendor-specific - fine if you don't mind being tied to that vendor, less
good if you want to pick the right tool for each job.

If this is a product, maybe picking a platform is the way to go to make
progress fast - but you should expect to throw the initial version away as
you learn what the platform does and doesn't allow you to do.

For the specific case of IoT, the field is still developing; that means
there are no 'obvious' front runners as far as services go - it also means
that anyone you pick has a risk they shutter the project when they go bust
or move onto the next thing.  That's why there's something to be said for
building your own - if you have the skills.  Of course, your customers are
still at risk that /you/ go bust.

Theo

[toc] | [prev] | [next] | [standalone]

#26335

"pozz"  wrote in message news:ob09tq$qj2$1@dont-email.me... 
>I'd like to start learning the modern paradigm of IoT and Cloud.  My 
>first impression is that they are "empty words" without a precise 
>meaning: you can fill the "word" as you want.

"IoT" has actually be defined by the ITU in Recommendation ITU-T Y.2060
See https://www.itu.int/rec/T-REC-Y.2060-201206-I

Friendly,
Robert Lacoste
www.alciom.com

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | comp.arch.embedded

csiph-web