Design Con 2015

Disappointing DECT: Don't overlook the networking effect

-October 04, 2013

As some of you may recall from a year-ago post, I'm using an RCA-branded dual-line DECT phone system. Downstairs in the office is the 25250RE1 base station:



fed by two VoiP sources, an Ooma Hub:



and a Google Voice-serviced Obihia Technology adapter:



Upstairs are two base station-mated 25055RE1 accessory handsets, one in the kitchen and the other in my bedroom:



As I'd previously written, I initially experienced destructive interference from my dual-band 802.11n router when it was too close to the 25250REI, resulting in poor voice quality as perceived by whomever was trying to listen to me. I fixed that by moving them a few feet apart. And although all of the handsets now work fine when I'm in the house, I'm still not able to reliably converse with anyone while I'm out on the deck and using the remote handset based the kitchen. This is the case even though the intervening span between handset and cradle is less than 10 feet and consists (aside from air) of a single wall and a single window.

Given that RCA's DECT system employs the 1.9 GHz band (thanks again for the tip, aptos, I checked), I would have expected much longer usable range. Maybe the wall employs attenuating chicken wire construction. Maybe the handset cradle's broadcast and reception pattern isn't omnidirectional. Or maybe the cradle is experiencing destructive interference from the 2.4 GHz (802.11g) print server sitting less than a foot away from it. I'll save further debug and diagnosis for a future post. This time, my intent is to discuss a functional shortcoming of a non-spectral nature.

The other day, I finally got around to programming a few regularly dialed phone numbers and associated names into the system. My initial assumption was that, once I punched the data into the memory of one of the handsets, it would promptly and automatically propagate to the directories of the other mated handsets as well. But this capability doesn't seem to be supported by the 25250RE1/25055RE1 combination; I had to tediously manually program the other two handsets with the exact same multiple data suite. And I don't understand why any of this was necessary.

I get why such a feature would be optional. The programmed phone number-and-name set used in the kitchen, for example, might be different than the one needed in the home office, the living room, and the adults' and kids' bedrooms. But I've got to believe that plenty of situations also exist where a matching directory for each handset in a DECT system would be necessary, especially in the business settings in which the 25250RE1/25055RE1 combo was intended to be used. And as such, particularly given that ongoing communication between the remote handsets and the base station already exists and the inclusion of this added capability therefore wouldn't seemingly be complicated or costly, I don't know why RCA didn't provide it.

Were this solely a DECT complaint and differentiation prospect, I probably wouldn't have bothered writing about it. What (miniscule) percentage of the readership of this blog designs DECT equipment, after all? But plenty of you more generally design gear that is interconnected. Off the top of my head, for example, I think of the fact that I can pause a movie I'm viewing on Netflix or another service via one of my Roku boxes, move to another Roku-tethered display, and continue watching from where I previously left off. Or that a calendar, contact, task, browser bookmark, password or file change that I make on one of my devices is rapidly and seamlessly replicated on my other computers, smartphones and tablets, thanks to Xmarks, Dropbox, 1Password and Google's various services.

Granted, these particular cases involve a cloud-based server intermediary. But isn't the DECT base station conceptually similar to a server nexus? And granted, we're talking about high-volume but scant-profit-margin consumer electronics gear; features that substantially add to the product cost without producing a sufficiently commensurate return-on-investment are verboten. But I can't believe (please inform me to the contrary if necessary, readers) that including this added capability would have burdened RCA's equipment with much (if any) additional expense. And it would have saved me a tangible amount of time and hassle. So I'd encourage RCA and other DECT manufacturers to consider it next time. And I'd more generally encourage those of you making networked gear to look for similar interconnection-enhancement opportunities in your future products.

Also see:

Loading comments...

Write a Comment

To comment please Log In

FEATURED RESOURCES