On Thursday 19 July 2007 8:23:50 pm Dave Bour wrote: > Its funny/tragic that bt and wifi don't seem to get along yet like you, > both work perfectly on my laptop (802.11g). I've been looking at replacing > my blackberry with the relatively new htc p4000 (non-branded 6800) and > again, they've got the same feedback already about stutter on the bt when > using wifi as they share the antenna
Are you saying you *are* getting stutter, or that people are reporting it? You need both your wifi chipset and your BT chipset to have a couple of signaling lines which indicate when they want to use the radio, and then arbitration logic to determine who wins if they both want to. Without that, or with it unconnected/misconfigured *will* get stutter due to band contention. It may be unimplemented due to lack of availability in the chosen chipset, cost, marketing or idiocy; my bet's on the latter. > For me, the limits on the blackberry > (no sip client, no media player) are driving my push to get rid of this > 7130 for something better. As we were talking earlier today (I was the guy > in the orange/white shirt at lunch), lots of these technologies have > potential, but they just always seem to miss on the delivery. It's the tragedy of technology. You get people with great ideas but who can't implement it, or they get crippled by business decisions, terrible laws written by technophobes, time constraints and fear of having their "great idea" stolen and the system subsequently being locked down to protect their investment. To me, it's all "blah, blah, blah..." excuses. Yes, you need to get your product out to start making a buck so you can cover your development expenses and gain marketshare, but that doesn't explain the opening up of the system, publishing of the internal file formats and generally the ability to screw with the system you paid good money for. Let's face it: the number of people who actually *could* play with their systems in such a way as to threaten any business plan or product lineup disappear into the statistical "noise" of their intended market. The evil haxors get in anyway, so they're of no use as an excuse, although with horrible laws like the DMCA and the up-and-coming Canadian equivalent, at least they can sic the police on those types, and those guys are always good for a soundbite about how horrible the big bad Internet is and why we need more laws to protect poor little businesses who can't be arsed to actually compete on merit. > The Aastra > implementation is no different. Cellular type deployment but no dynamic > power management. No load balancing algorithms. A few other gripes too but > we'll see what happens. Isn't technology wonderful. Aggh! I honestly do not understand this "no load balancing" issue -- it's impossible to load balance how it was being suggested today. If you have two RFPs, A and B, and each can handle 8 active calls, and A is at 6/8 and B is at 0/8, and you have a phone P who sees both at relatively equal link quality levels, what advantage do you have of making P register with B instead of A? None! Remember that they phones will bounce back and forth as needed (although using a transfer timeslot pair in the process). If another phone, Q, comes into the network and it looks to link up, it's a VERY arbitrary thing to say that it will likely find A before B, and therefore a phone which sees both A and B the same relative link quality should choose the lessor-loaded one. If P moves and it hands off to A, you're using one of the "transfer" channels, and not one of the main conversation ones. If you have a site where that *is* a real, honest-to-goodness issue, put A and B at the front entrance and C somewhere inside. This technology is *cheap* compared to what else is out there. Skinnying up on the RFPs is like skinnying up on the server memory; sure cost is everything... until you can't get the work done! I dunno; to me it's totally, completely arbitrary. Load balancing them gives no apparent benefit that I can see, and the only thing I can really see a nice use for is if A is already at capacity *and* is transferring media for two additional channels (i.e. it's at spectrum capacity), then I don't see why it wouldn't do a SIP REINVITE to hand off the media. They're marketing the lack of REINVITE as a feature, but I think that feature's of rather dubious value. SIP REINVITES are pretty seamless in and of themselves, and having the additional proxy traffic between RFPs seems a waste. You're right though, the inability to turn DOWN the transmit power (or have it AUTOMATICALLY adjust like a cell phone/tower) seems to be a shortcoming, as that could potentially have significant power savings as well. That may be part of the DECT standard though; I'm not sure. SNMP for ALL radio data will be very helpful, as will TFTP for provisioning, phone books and other configurable items. And let's PRAY there are a set of decent OFFICE ringtones for these things! -A. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
