Support
All support resources for our products. Here you can find answers to frequently asked questions, discuss with other users, recover a lost license code or file a support request.
Forum closed
This forum was closed and turned into an archive effective April 21, 2018. It is no longer possible to create new topics or reply to existing topics.

Thanks everyone for all the great questions and contributions over the years.

Please use the Contact form to get in touch.

Remote Buddy Forum

Overview 

AuthorThread
User

20.12.2007 19:25:02
Re: Re: Remote Buddy does not cause packet loss

This posting is older than 6 months and can contain outdated information.
Version 1.0 Preview X did only one BT inquiry at startup. Once that BT 
inquiry did time out, it did not place new inquiries and you could not 
pair a Bluetooth remote after that. From what I remember of the 
Darwiin code, it uses that very same scheme.

As requested by many users, later versions and including v1.1, v1.7, 
v1.8, .. continously searches for known BT remotes. Having to 
continously search for its Bluetooth devices is something other apps 
targeting BT devices made specifically for computers don't have to do. 
The Wii Remote and the Sony BD Remote were not designed as normal 
computer input devices. If they shall be made work with a Mac, they 
have to be actively searched for.

As Bluetooth and WLAN do not have anything to do with one another on a 
driver or protocol level and Remote Buddy's use of TCP/IP and 
IOBluetooth is several layers and the kernel/userspace barrier away 
from the actual drivers (and one another), plus the Bluetooth APIs are 
very simple and straightforward (no voodoo or magic flags involved or 
available here at all), I don't see how Remote Buddy could be the 
cause of any WLAN/BT interferences. As a matter of fact, only this one 
way is available to communicate with Bluetooth devices on OS X.

Sure, Remote Buddy uses the official Bluetooth APIs, and sure, if 
there's a problem with the Bluetooth drivers when doing connects and 
inquiries (== searches) to Bluetooth devices, it'll trigger these 
problems. But they are not rooted in or within the scope of influence 
of Remote Buddy's use of the Bluetooth stack. And Remote Buddy's use 
of the Bluetooth stack in turn is the only thing that I have control 
over.

If there was a problem *I* could fix, I'd be more than happy to do it, 
even if that would mean that I have to go to great lengths to achieve 
the goal. For the built-in Apple IR receiver I've already gone very 
far multiple times in reaction to changes on Apple's side, but it was 
and is doable, as it can all be done with the use of stable, supported 
standard APIs.

The Bluetooth stack of OS X is different. Unless I'd try to replace 
the entire Bluetooth stack (with the majority of it being completely 
undocumented), I have no chance to work around or fix problems in it. 
It's not modular and the - decisive - kernel part is completely 
undocumented.

If I say that the problem can only be located within Apple's drivers 
or a physical problem, I don't say this because I'm unwilling to 
acknowledge or fix a problem, but because all I know about the problem 
does - by employing nothing but logic and excluding possibilities one 
by one - only permit this conclusion.

My research on the problem did also show that it is around for even 
longer than Remote Buddy is. Here's this finding from Apple Discussions:

-- quote -- 
After messing around for many hours (actually days) I figured out that 
I have the itermittent network problem (wireless) when I enable 
bluetooth, if I turn bluetooth off the network works fine (with any 
combination of both Apple and Logitech keyboards and Mouse). I just 
got off the phone with tech support, they suggested I take the unit 
back for service because I probably have a failing bluetooth module. 
Before doing that I decided to move the mini to the same room as the 
access point and turn bluetooth on, absolutely no problems at all. I'm 
not taking it in for repair just yet. I think it's a performance issue 
and not a component failure.

I also have an iBook and it doesn't have any wireless problems at all 
even with bluetooth running 
-- quote --

It's dated 6th March 2006. That's a couple of months before even the 
first line of Remote Buddy's code saw the light of day. There's also 
this - in reply to above posting:

-- quote -- 
I saw on an Intel iMac thread that someone had been told by Apple tech 
support that Bluetooth and Airport would interfere with each other on 
channel 6. I had been having problems with my Bluetooth mouse & 
Airport bandwidth on my Mac mini Core Duo, and the channel selection 
was set to Automatic.

[..]

Yep, I have this too. My duo is connected via 2 airport expresses in 
WDS mode. I also have a bluetooth keyboard and mouse

Hooked up my new duo and observed horrible wireless performance 
(intermittent connectivity and throughput). Powerbook in same location 
operates without issue using same bluetooth keyboard/mouse. Was on 
channel 1 with intermittent network performance. Went to channel 11, 
and network intermitentcy went away; however, network throughput is 
not as high as Powerbook. 
-- quote --

Source of all quotes: 
http://discussions.apple.com/thread.jspa?threadID=387407

This issue has also been in the news already (=> f.ex. http://www.macobserver.com/article/2006/03/15.15.shtml 
), but like other issues that exist to date (=> i.e. the numerous 
AirPort issues), the news sites forget about it after an initial spike 
of attention (they don't want to bore their readers with "no news on 
this topic" or "issue still unfixed - nothing to see here, really" 
articles, I guess).

I guess I'll implement an option to limit the time after launch within 
which Remote Buddy seeks for Bluetooth remotes, but that's really as 
much as I can do.

This post is my last one on this forum thread. All I can do from this 
point on is to repeat myself.

Best regards, 
Felix Schwarz 

Thread-display::