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

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)

formatting link

Reply to
Steve at fivetrees
Loading thread data ...

Reduced parts and bad design partitioning.

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.

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.

--
Paul Carpenter          | paul@pcserviceselectronics.co.uk
    PC Services
 Click to see the full signature
Reply to
Paul Carpenter

OS.

Agreed - that's absolutely my take too.

Steve

formatting link

Reply to
Steve at fivetrees

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
Reply to
Trevor Barton

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"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
 Click to see the full signature
Reply to
Spehro Pefhany

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
 Click to see the full signature
Reply to
Michael N. Moran

"Steve at fivetrees" wrote

Ditto. But then where would we be without clients?

--
Nicholas O. Lindan, Cleveland, Ohio
Consulting Engineer:  Electronics; Informatics; Photonics.
 Click to see the full signature
Reply to
Nicholas O. Lindan

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

-jg

Reply to
Jim Granville

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.

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.

Reply to
Al

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

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

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

Steve

formatting link

Reply to
Steve at fivetrees

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

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?

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

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.

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 to work around it. and no, it's not in the errata. sorry."

-j

Reply to
Josh Fryman

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

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

Ah. A kindred spirit!

I gave up on dealing with this s*1t 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.

Reply to
Al

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.