Problems using My Ooma? Ideas on how we can make it better? You’ve come to the right place.
#110166 by Telo_BK
Tue May 21, 2013 9:43 pm
Thanks for taking your valuable time, parity_bit, to explain Bluetooth and bug reports.

I didn't say an "ordinary" rep issued a bug report. It went to Engineering, and evidently they determined it was a bug.

Bluetooth headsets are worn by humans (this is the "person" in "Personal Area Network (PAN)"). Humans move around (sometimes out of range due to distance or obstacles). That's the practical reality of how Bluetooth operates. Properly implemented Bluetooth compatible devices are designed and programmed to take that into account. Otherwise Bluetooth wouldn't be so widely deployed. When that happens (and it happens a lot), Telo re-sequences the ordinal numbers of the headsets. Instead they should tie that ordinal number to the Headset's built-in MAC address (which is fixed per-headset, and for practical purposes, unique), assigning it when each headset is paired. Then the prefix will never change. Hence- Ooma made the bug report.

I hope that clarifies it and puts to rest the troubling notion that Ooma's engineers are toiling to fix a non-existent bug- or worse- are snowing their customers into believing they're going to fix this. "Pairs with", and "works with" are not the same. "It worked in the lab", or "there are lots of bugs..." aren't satisfying to customers who expect (or even need) the product they bought on a risk-free trial to "do what it says". The product has been on the market since 2010. I'd never get away with letting something like this get out of the lab (nor would I want-to).
#111418 by parity_bit
Sun Jun 30, 2013 6:23 am
I'm ecstatic that you have faith in the process. I hope that works out for you.
Whether it was an ordinary rep, or an "engineering" one amounts to a moot point because as you point out, the product has been on the market since 2010. I hope you maintain your optimism in spite of what I am going to write, but, they're likely not taking your "bug" seriously. They could have invented completely new technologies in the same, or less amount of time.

But thankfully, they don't have to. The Telo, and likely the Hub before it is built upon proven technologies--namely Gnu/Linux and certain other open-source initiatives. This makes Ooma's job quite a bit easier as the source code for any GPL based solutions are by definition, mandatory to include. So if a company that is part of the Bluetooth SIG releases something to the Linux community to tinker with and it's under GPL then Ooma has a good portion of their work already done for them. This is partially the same with proprietary vendors as SDKs and toolkits exist in that arena.

Rest assured they knew about that "bug" a considerable time before they issued you the honor of thinking you had actually started the ball rolling. Like you've no doubt experienced in your own job, or at least you alluded to that, products have to undergo extensive testing. The beta process certainly discovered what you say before you said it to the "engineering" arm.

What you said relating to Bluetooth and Personal Area Networks is misleading.
PAN's are also called PicoNets and have scarce little to do with your concept of people predictive programs. Contrary to what you'd have people understand, I doubt very much there is any predictive technology built into Bluetooth for analyzing the patterns of people's movement and compensating for that. Instead PicoNets and PANs are called such as a contrast to LANs in which networks contain magnitudes more members than 8 (host + 7 clients) and span much larger distances. PicoNets are by definition very small, and their broadcast range is small as well. The broadcast output is strictly defined and monitored (during the licensing process) by the FCC and other regulatory bodies in the US and elsewhere. Don't think for a minute that if you are on the edge of the network's boundaries and the device is maxed out in terms of broadcasting power that it will increase power output by another factor.
Likewise if the device's signal is blocked by your refridgerator, and is already at maximum output, it is not going to use this predictive technology you attribute to Personal Area Networks relating to Bluetooth to either reroute your signal or boost output. What it will do is lose signal and re-initiate the handshake once you are in range. Not much for intelligence in the way you envisioned it, but it's what we have. If what you speak of in theory is any more than a concept, I would highly recommend patenting such technology.

In the meantime, I hope your quest for anything other than a snow-day goes well.


Telo_BK wrote:Thanks for taking your valuable time, parity_bit, to explain Bluetooth and bug reports.

I didn't say an "ordinary" rep issued a bug report. It went to Engineering, and evidently they determined it was a bug.

Bluetooth headsets are worn by humans (this is the "person" in "Personal Area Network (PAN)"). Humans move around (sometimes out of range due to distance or obstacles). That's the practical reality of how Bluetooth operates. Properly implemented Bluetooth compatible devices are designed and programmed to take that into account. Otherwise Bluetooth wouldn't be so widely deployed. When that happens (and it happens a lot), Telo re-sequences the ordinal numbers of the headsets. Instead they should tie that ordinal number to the Headset's built-in MAC address (which is fixed per-headset, and for practical purposes, unique), assigning it when each headset is paired. Then the prefix will never change. Hence- Ooma made the bug report.

I hope that clarifies it and puts to rest the troubling notion that Ooma's engineers are toiling to fix a non-existent bug- or worse- are snowing their customers into believing they're going to fix this. "Pairs with", and "works with" are not the same. "It worked in the lab", or "there are lots of bugs..." aren't satisfying to customers who expect (or even need) the product they bought on a risk-free trial to "do what it says". The product has been on the market since 2010. I'd never get away with letting something like this get out of the lab (nor would I want-to).

Who is online

Users browsing this forum: Google [Bot] and 6 guests