Nokia set-top box: example of *dreadful* embedded design

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
I don't know quite why it is that set-top boxes are so poorly designed as a
breed. I've had cable units, satellite units, and (now) freeview
(terrestrial digital) set-top boxes - almost without exception [1], they've
been flaky as hell.

I have a Nokia Mediamaster 221T freeview unit which is an extreme example.
It's always been flaky, but since upgrading the firmware recently, it's
become virtually unusable - it's been known to freeze (requiring a full
power cycle) 4 or 5 times within 5 minutes. I've had discussions with Nokia
about it via email, culminating in a phone conversation with a "support
agent" just now - she tells me I live in a poor signal area (which is kinda
true), and that a poor signal can cause the unit to freeze - a statement
which I take as a stunning admission of failure on the part of the Nokia
designers.

[1] One exception: my daughter bought a no-name freeview box for £30 or so
from a local dealer, expecting little from it - and it's been superb. It's
not frozen once, and the picture is fine (theoretically poor signal
notwithstanding). I bought the Nokia unit for about £130 (over a year ago,
sadly) because I thought Nokia knew what they were doing. Hah.

I can't think of any other product where poor signal could be used as an
excuse for system freezes. What *is* going on? Presumably the RTOS is using
up all its cycles trying to derive a clean signal, to the extent that the
unit crashes. How can this possibly be justified?

Steve
(an ex-loyal Nokia customer)
http://www.fivetrees.com



Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

Reduced parts and bad design partitioning.

Quoted text here. Click to load it

I have seen ADSL routers gow AWOL from the network because they are having
problems with the ADSL line. Example of which was one ISP forgot to tell
me that they use VC encapsulation not LLC, so the unit goes busy sorting
out the line. Eventually reconfigure the unit and it works continuously.

Quoted text here. Click to load it

Basically some companies have the attitude "It can ALL be done in software"
and by that they mean ONE CPU doing all the work, so they have reduced
parts count and cost. Don't even get me on the poor software design for
upgrading firmware in some network devices, that cannot cope with
saving config onto PC and restoring config after upgrade. The number that
don't have default values for NEW features and ONLY update the configurtion
items that exist in the old version is unbelievable.

A classic case of this was a router that on firmware upgrade added the
ability to set router time from a PC or manually after the firmware upgrade,
but obviously when restoring a configuration assumed it was from a same
version of firmware so time values all became UNDEFINED!!! Poor software
checks and methods, which to my mind is typical of bad desktop application
programmers doing embedded work with an embedded version of the desktop OS.

Quoted text here. Click to load it

--
Paul Carpenter          | snipped-for-privacy@pcserviceselectronics.co.uk
<http://www.pcserviceselectronics.co.uk/ PC Services
We've slightly trimmed the long signature. Click to see the full one.
Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it
OS.

Agreed - that's absolutely my take too.

<sigh>

Steve
http://www.fivetrees.com



Re: Nokia set-top box: example of *dreadful* embedded design
On Thu, 20 Jan 2005 12:12:36 -0000, the renowned "Steve at fivetrees"

Quoted text here. Click to load it

Part of the downside of upgradable firmware too. If it had to be made
with mask ROMs with a 10 week lead time and a $xxxK minimum order
they'd be more likely to make it (more) right.


Best regards,
Spehro Pefhany
--
"it's the network..."                          "The Journey is the reward"
snipped-for-privacy@interlog.com             Info for manufacturers: http://www.trexon.com
We've slightly trimmed the long signature. Click to see the full one.
Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

Ditto.  But then where would we be without clients?

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
We've slightly trimmed the long signature. Click to see the full one.
Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

We have a freeview box (mitsubishi?  somthing like that) which is OK unless
you leave the TV guide on top of it, because that blocks the top ventilation
holes and the whole thing overheats and dies until it's been left unplugged
from the mains for five minutes or so.  Actually, it's worse than that,
because if you leave the remote control on it and only partially block
the holes, it still overheats.  Even in normal operation the case is
quite warm to the touch, and it stays warm when it's in standby.

What's with that?  I wonder how many people have taken them back "broken"?  
They sit on top of the TV, where else do people keep the remote control
and TV guide?  Duh.  (well, ours are generally in the middle of the
floor, or under a chair, or down the back of the sofa, because we have
kids).

--
Trevor Barton

Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

Wow - an example where having kids _improves_ the reliability of
a consumer appliance ? :)
-jg


Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

Wow ... that was quite a leap. It *must* be the RTOS ;-)

Surely it *is* a poorly designed system.

Having had some exposure to the CATV business, I have
to say that given:

o all of the requirements to prevent "content" from
   being "stolen",

o a hodgepodge of non-standard and standard protocols,

o a large number of closed source third party libraries,

o large teams of embedded software developers working
   on a "feature rich" product, and

o the usual "ship-it-tomorrow" management style of a
   highly competitive market

I am neither surprised nor impressed ;-)

--
Michael N. Moran           (h) 770 516 7918
5009 Old Field Ct.         (c) 678 521 5460
We've slightly trimmed the long signature. Click to see the full one.
Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

Having designed (and tested) a few in my time, I've got plenty of excuses
;-)

Three parts to STB software (OK, 4 then) ...

Drivers - Generally the best parts of the software (if written by
professionals!). Fast, efficient, they work.

Middleware - Mostly utter garbage. No, really. Which means that the
application layer is in trouble before it even starts ...

App layer - Often poorly written by college grads being paid sixpence per
hour. Usually then hacked by more senior engineers to get around the faults
in the middleware. Doomed to failure. Not to worry, we can upgrade with an
off-air download if anyone complains ...

Not forgetting the good old bootloader - This is the bit everyone hates to
write or maintain - No fame, no glory. Often just a hacked set of drivers
done by the most junior member of the team. And boy, does it show.

Quoted text here. Click to load it

Hehe. Good job you haven't got a Pace DTVA - That's a barrel of laughs.
Not. The EPG has been broken since September. Runs out of memory gathering
SI and crashes. Great. Who tested this particular crock one asks?

Never mind, at least these guys don't design aircraft ...

Al.

Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

Thanks for the insight. It is as I feared ;).

Quoted text here. Click to load it

Heh ;). It would appear that Nokia don't have a mechanism for handling such
complaints. I've certainly tried, and given up in disgust.

Quoted text here. Click to load it

Many thanks for pointing me at the bright side ;).

Steve
http://www.fivetrees.com



Re: Nokia set-top box: example of *dreadful* embedded design

having my share of experience in doing this type of thing...

Quoted text here. Click to load it

actually, this is the hard part.  companies like ST (when asked, say
they only make hardware, not software; or if asked on a different day,
only make software, not hardware) put out "demo" code for their chips
which is a large package of software.  these code drops, aside from
being #ifdef'd for years and years to support every chip ever made
and every errata ever encountered, are usable in general for okay
performance.  until you hit that corner case.  and then it's game over.

most of the really solid STBs and IRDs i've seen rewrite the entire
chipset code from the ground up.  problems also lie with conexant chips,
for example, that have special DSP-like or reprogrammable codec-cell
structures that you have to load a "firmware" into.  i saw one project
languish in the fun of instability for a long time before one chip
company said, "oh, hold on, we compiled that for the wrong configuration!"
when the new release arrived, all was well.

so, drivers you take with a grain of salt.  especially if you're
foolesh enough to believe the "reference" code provided by the
chipset vendor.  and of course, that "we have 6 weeks to make this
work" factor creeps in here.  because the code that ran just fine
on the 4744 should just need a tweak or two to run on the 4754, right?

Quoted text here. Click to load it

this is the part i see most often written by those with the least
experience, where the senior developers spend their time trying to
understand why that function takes 50 arguments but only received
40 and the compiler didn't complain... or why i can pass a string to
an int and not get a warning/error...

Quoted text here. Click to load it

heh.  don't forget those handy utilities that they write to convert
from one code type to another, never document, and promptly leave for
some other job... leaving the main team with fragile support tools
that are poorly understood.
 
Quoted text here. Click to load it

this can be the most fun.  it's also the part where you spend all your
time on the phone with the hardware part makers finding out that "oh,
chip R1-AB/D-V7 has this special bug, you need to do <xyz> to work
around it.  and no, it's not in the errata.  sorry."

-j

Re: Nokia set-top box: example of *dreadful* embedded design
Quoted text here. Click to load it

Unless they are written by *professionals*. Chipset manufacturers haven't
got a clue. I used to make a very decent living from writing drivers that
actually worked! ;-)

Quoted text here. Click to load it

Your idea of 'fun' is slightly displaced from mine ;-)

Quoted text here. Click to load it

Ah. A kindred spirit!

I gave up on dealing with this sh1t a few years ago. I'm too old and wise
to deal with the same mistakes on every contract that I do these days ;-)

Nice reply Josh - I'm glad I'm not alone!

Al.

Site Timeline