May 2004 - Bluetooth-dev - lists.apple.com

re: Limit to number of incoming channels?
by luc bergevin 06 May '04

06 May '04

hi, I'm not sure about the Apple implementation of Bluetooth, but at the baseband level of the protocol stack, the hardware divise the timeline into slots. These slots are grouped by packets of 6, which may be use differently depending of the quality of service. One normal use is: --- link 1 sends --- link 1 receives --- link 2 sends --- link 2 receives --- link 3 sends --- link 3 receives If Apple's implementation uses only one link for all the rfcomm channels, then there should be as much channels as you want, with a lower quality for a bigger number of channels. But if the implementation creates one link for each channel, then you are blocked at 3 channels. And the hardware may reserve one link for his own needs, which would block you at 2 channels. I hope it helps. luc bergevin, student. Okay, After redesigning my app to run a separate process for each BT device, I have a new problem. As each process starts, it attempts to set up and add a service. It then registers for incoming connections. Once connection is complete, the main process launches another sub-process which repeats the procedure. My first process launches and sets up channel 1. A device connects on channel 1. A new process is started which sets up channel 2. A device connects on channel 2. A new process is started which stes up channel 4. (What happened to channel 3?) I try to connect a third device, but to no avail. No notification ever gets called. The device can't connect. If I disconnect one of the first 2 devices, then the third device will successfully connect in on channel 4. So I'm wondering, is there a limit to the number of incoming channels I can set up? I was able to connect more than 2 incoming devices with my old, single process design. But that design only set up 1 channel. ...Thanx... ...Eric... _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Limit to number of incoming channels?
by Crichlow, Eric 05 May '04

05 May '04

Okay, After redesigning my app to run a separate process for each BT device, I have a new problem. As each process starts, it attempts to set up and add a service. It then registers for incoming connections. Once connection is complete, the main process launches another sub-process which repeats the procedure. My first process launches and sets up channel 1. A device connects on channel 1. A new process is started which sets up channel 2. A device connects on channel 2. A new process is started which stes up channel 4. (What happened to channel 3?) I try to connect a third device, but to no avail. No notification ever gets called. The device can't connect. If I disconnect one of the first 2 devices, then the third device will successfully connect in on channel 4. So I'm wondering, is there a limit to the number of incoming channels I can set up? I was able to connect more than 2 incoming devices with my old, single process design. But that design only set up 1 channel. ...Thanx... ...Eric... _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: IOBluetoothRFCOMMChannel and NSThread
by Yann Bizeul 04 May '04

04 May '04

> all UI calls need to be made on the main thread (this is an Appkit > restriction) and all Bluetooth calls need to be made on a single > thread. So This pretty much means that if you need to use Bluetooth > and UI on a thread, all the calls need to be made on the main thread. > Using the asyncronous APIs you will avoid blocking the UI for lengthy > operations (like connections). Ok, understood. One point left in the dark is why could I not call [ IOBluetoothDevice pairedDevice ] in my BT thread ? (Sometimes it returns an empty array, or just one device...). Is this call kind of AppKit one so I have to use it into the AppKit thread ? > Also I would like to point out that trying to connect every 10 > seconds is a very bad idea. The connection require the connecting > device to cover the 2.4Ghz band to find the counterpart which means > that you will disrupt AirPort networks. In general this is not that > bad because it does not happen that often (only when you connect) and > 802.11 can recover by re-sending its packets, but if you try to > connect every 10 seconds you give very little room for the AirPort > network to recover. If you really need to "keep trying" I would > suggest attempts between 30 seconds to one minute (the longer the > interval, the better). Understood too :-) I'll change it to 30s, I don't think users need immediate reconnection, I just have to find discrete visual way to show when bluetooth recovers. Thanks to you and others who help me -- Yann Bizeul - yann at tynsoe.org http://projects.tynsoe.org/ [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: IOBluetoothRFCOMMChannel and NSThread
by Marco Pontil 03 May '04

03 May '04

Yann, all UI calls need to be made on the main thread (this is an Appkit restriction) and all Bluetooth calls need to be made on a single thread. So This pretty much means that if you need to use Bluetooth and UI on a thread, all the calls need to be made on the main thread. Using the asyncronous APIs you will avoid blocking the UI for lengthy operations (like connections). Also I would like to point out that trying to connect every 10 seconds is a very bad idea. The connection require the connecting device to cover the 2.4Ghz band to find the counterpart which means that you will disrupt AirPort networks. In general this is not that bad because it does not happen that often (only when you connect) and 802.11 can recover by re-sending its packets, but if you try to connect every 10 seconds you give very little room for the AirPort network to recover. If you really need to "keep trying" I would suggest attempts between 30 seconds to one minute (the longer the interval, the better). ... Marco On May 3, 2004, at 1:42 PM, Yann Bizeul wrote: Thanks for the answer. In fact I started to establish a thread responsible of all bluetooth stuffs. Worked not so bad but it seem some bluetooth operations stick other ones. For example, while I'm trying to connect every 10s to a device, If I try to get pairedDevices to display preferences, this method returns nothing. Is there a rule for those stuffs ? I'm doing all bluetooth calls in the same thread. Right now I'm trying to use IOBluetoothUI to get a device in the prefs, but the windowController stays white, hangs the app, and display nothing. Is there a difference between using AppKit thread or a custom one ? Any idea ? Thank you ! Le 3 mai 04, ` 19:05, Marco Pontil a icrit : Hello Yann, The problem is that the Bluetooth Stack is not designed to run on multiple threads. The first thread that makes a call in the stack is also the only thread that will receive events (and new data is an event) from the stack. Since your problem seems to be the connection blocking I would suggest to use the asyncronous API to open the connection. In this way the caller will not block and once the open connection is completed will be notified of the results (success or failure). ... Marco On May 2, 2004, at 2:04 AM, Yann Bizeul wrote: -- Yann Bizeul - yann at tynsoe.org http://projects.tynsoe.org/ _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: IOBluetoothRFCOMMChannel and NSThread
by Eric Brown 03 May '04

03 May '04

On May 3, 2004, at 1:42 PM, Yann Bizeul wrote: > Thanks for the answer. > > In fact I started to establish a thread responsible of all bluetooth=20 > stuffs. Worked not so bad but it seem some bluetooth operations > stick=20 > other ones. > For example, while I'm trying to connect every 10s to a device, If I=20 > try to get pairedDevices to display preferences, this method returns=20 > nothing. > > Is there a rule for those stuffs ? I'm doing all bluetooth calls in > the=20= > > same thread. > > Right now I'm trying to use IOBluetoothUI to get a device in the > prefs,=20= > > but the windowController stays white, hangs the app, and display=20 > nothing. > > Is there a difference between using AppKit thread or a custom one ? > > Any idea ? > > Thank you ! > > There are really two issues with threads and the Bluetooth frameworks: 1 - The Bluetooth libraries are not thread safe, so all calls must come from the same thread. Because of the asynchronous nature of some of the APIs and internal mechanisms, the first thread to call into the frameworks must run a run loop and will be the one that all asynchronous callbacks are delivered on. As a consequence, it is the only one that should be making calls into the Bluetooth APIs. 2 - The UI functions are based on AppKit. All UI calls must be done on the main thread. As a result, all other Bluetooth calls in a Bluetooth UI application must be made on the main thread. - Eric [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: IOBluetoothRFCOMMChannel and NSThread
by Yann Bizeul 03 May '04

03 May '04

Thanks for the answer. In fact I started to establish a thread responsible of all bluetooth=20 stuffs. Worked not so bad but it seem some bluetooth operations stick=20 other ones. For example, while I'm trying to connect every 10s to a device, If I=20 try to get pairedDevices to display preferences, this method returns=20 nothing. Is there a rule for those stuffs ? I'm doing all bluetooth calls in the=20= same thread. Right now I'm trying to use IOBluetoothUI to get a device in the prefs,=20= but the windowController stays white, hangs the app, and display=20 nothing. Is there a difference between using AppKit thread or a custom one ? Any idea ? Thank you ! Le 3 mai 04, =E0 19:05, Marco Pontil a =E9crit : > Hello Yann, > > The problem is that the Bluetooth Stack is not designed to run = on=20 > multiple threads. The first thread that makes a call in the stack is=20= > also the only thread that will receive events (and new data is an=20 > event) from the stack. > > Since your problem seems to be the connection blocking I would=20= > suggest to use the asyncronous API to open the connection. In this way=20= > the caller will not block and once the open connection is completed=20 > will be notified of the results (success or failure). > > ... Marco > > On May 2, 2004, at 2:04 AM, Yann Bizeul wrote: --=20 Yann Bizeul - yann at tynsoe.org http://projects.tynsoe.org/ [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

Re: IOBluetoothRFCOMMChannel and NSThread
by Marco Pontil 03 May '04

03 May '04

Hello Yann, The problem is that the Bluetooth Stack is not designed to run on multiple threads. The first thread that makes a call in the stack is also the only thread that will receive events (and new data is an event) from the stack. Since your problem seems to be the connection blocking I would suggest to use the asyncronous API to open the connection. In this way the caller will not block and once the open connection is completed will be notified of the results (success or failure). ... Marco On May 2, 2004, at 2:04 AM, Yann Bizeul wrote: Hello List, I used to open a RFCOMM channel without using threads with no problems. But this is blocking sometimes when the device is not reachable. So I wanted to open the connection in a Thread. The problem is that I do no longer receive any data from the device, I set the delete of IOBluetoothRFCOMMChannel to self, but my - (void)rfcommChannelData:(IOBluetoothRFCOMMChannel*)rfcommChannel data:(void *)dataPointer length:(size_t)dataLength; Is never called. Can somebody explain why using thread could change something ? Thanks -- Yann Bizeul - yann at tynsoe.org http://projects.tynsoe.org/ [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored. _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0

IOBluetoothRFCOMMChannel and NSThread
by Yann Bizeul 02 May '04

02 May '04

Hello List, I used to open a RFCOMM channel without using threads with no problems. But this is blocking sometimes when the device is not reachable. So I wanted to open the connection in a Thread. The problem is that I do no longer receive any data from the device, I set the delete of IOBluetoothRFCOMMChannel to self, but my - (void)rfcommChannelData:(IOBluetoothRFCOMMChannel*)rfcommChannel data:(void *)dataPointer length:(size_t)dataLength; Is never called. Can somebody explain why using thread could change something ? Thanks -- Yann Bizeul - yann at tynsoe.org http://projects.tynsoe.org/ [demime 0.98b removed an attachment of type application/pkcs7-signature which had a name of smime.p7s] _______________________________________________ bluetooth-dev mailing list | bluetooth-dev(a)lists.apple.com Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/bluetooth-dev Do not post admin requests to the list. They will be ignored.

1 0