October 2006 - Bluetooth-dev

Capturing events from Bluetooth USB Dongle
by apparao 26 Oct '06

26 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Hello All, Regards, Apparao M. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… What are the APIs available on Mac OS X for capturing events from Bluetooth USB Dongle. This email sent to site_archiver(a)lists.apple.com

1 0

PAN/NAP
by Olof Backing 24 Oct '06

24 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Regards, Olof -- Tutus Data AB Phone: +46-8-70-995 98 99 Svärdvägen 11 Fax: +46-8-551 102 39 SE-182 33 DANDERYD Sweden _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… Hi! Are there any PAN/NAP support/extensions available out there? Or have anyone made any efforts to develop/port something? I saw a small note on the list back in '05, but no further discussions followed. I have plans to look at Bluez (from Linux) since I use it for a Linux based project at work. This - on the other hand - is a strict hobby/private initiative. This email sent to site_archiver(a)lists.apple.com

1 0

Re: IOBluetoothDeviceRegisterForDisconnectNotification
by Joseph Kelly 23 Oct '06

23 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Joe On Oct 23, 2006, at 11:30 AM, Christian Martin wrote: Hi Joe, Anyway... I will try to dig in a bit more... Thx Christian Christian, Joe On Oct 20, 2006, at 7:53 AM, Christian Martin wrote: Hi Joseph, Thx for your rapid answer. Thx. Christian Martin B.Sc. Math/Computer From: Joseph Kelly <joeman(a)mac.com> To: Christian Martin <cmartin64x(a)hotmail.com> Subject: Re: IOBluetoothDeviceRegisterForDisconnectNotification Date: Thu, 19 Oct 2006 13:57:21 -0700 Joe K. On Oct 19, 2006, at 12:57 PM, Christian Martin wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… To quote the Apple engineer who answered this same question for me last year: "IOBluetoothUI is not thread safe. It uses both IOBluetooth and AppKit of which neither are thread safe. Your best bet is to use the main thread as your Bluetooth thread and enqueue any Bluetooth operations to be performed on it. Not ideal, but it should work for you." I found that I could do some operations on a non-main thread, but I would get intermittent failures -- async writes wouldn't complete etc. I implemented a fancy command queue with all kinds of neat locking mechanisms to allow the main thread to perform all my bluetooth, and it worked perfectly. If you're not writing a well behaved Cocoa application, you've got a bit of work to do. Check on the Java lists to see if anyone has implemented a Bluetooth solution... Is there any way you can send messages to the main thread of your Java app? If you can, that's a place to start. I appreciate you took some time to answer my question(s). I am not an experienced programmer on OS X so I tend to go ahead with the best of my knowledge. I am currently able to start a java application, load a JNI which contains the appropriate calls to triger a device search. The only way I can get a list of all the devices is to set a separate thread (inside the JNI in C) which has the series of calls for a device search and, at the end, I make a call to the runloop. By doing so, the callback fctns are called and I can get the list of devices available. Obviously, the thread never dies since it is caught in the runloop. I can say it works !... but can I claim it is thread safe ??? This is where I am lost. You state : "...thread restriction I claim is indeed true for the C apis ..." . I do not know where I can get a clear answer on this... I guess I am pushing it a bit too much in doing something that stands out of realm of reasonable path to follow ! It's not impossible. First I would verify that the thread restriction I claim is indeed true for the C apis (I've been using the ObjectiveC api). This would probably involve getting the bluetooth working first by calling your C functions (that you're wrapping in JNI) in a purely C environment using main and non-main threads -- query, connect, open channel, send/receive, close channel, disconnect. Second, if you find that it doesn't work except on the main thread, you might investigate whether you can set up the main thread before you run the jvm. I would be fairly certain (your mileage may vary ;-) that once you enter the jvm that it sits in a runloop and fields window manager events. You could add a bunch of sources to the main thread's runloop, and your jni functions could post requests to the main thread by triggering those sources, which would then carry out the bluetooth operation on the main thread. Etc. If you plan on talking to one device at a time, this should be fairly straightforward. For simultaneous devices, you might have to implement a command queue of some kind. I'm CC'ing this back to the list in hopes that someone more knowledgeable about Bluetooth, Java, threading, etc. than I will chime in... I am currently working on a Java Application which would need some call into the api of bluetooth. So, I did a JNI to wrap it up. Now, according to what you are saying JAVA/JNI/Bluetooth is not possible ! Please let me know if there is an avenue that I am missing... I am seriously stuck here. The Apple Bluetooth implementation is not thread safe. In order for it to work correctly, you must make all calls from the main thread. IOBluetoothDeviceRegisterForDisconnectNotification _________________________________________________________________ Say hello to the next generation of Search. Live Search – try it now. http://www.live.com/?mkt=en-ca _________________________________________________________________ Ready for the world's first international mobile film festival celebrating the creative potential of today's youth? Check out Mobile Jam Fest for your a chance to WIN $10,000! www.mobilejamfest.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: IOBluetoothDeviceRegisterForDisconnectNotification
by Christian Martin 23 Oct '06

23 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Hi Joe, Anyway... I will try to dig in a bit more... Thx Christian Christian, Joe On Oct 20, 2006, at 7:53 AM, Christian Martin wrote: Hi Joseph, Thx for your rapid answer. Thx. Christian Martin B.Sc. Math/Computer From: Joseph Kelly <joeman(a)mac.com> To: Christian Martin <cmartin64x(a)hotmail.com> Subject: Re: IOBluetoothDeviceRegisterForDisconnectNotification Date: Thu, 19 Oct 2006 13:57:21 -0700 Joe K. On Oct 19, 2006, at 12:57 PM, Christian Martin wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… I appreciate you took some time to answer my question(s). I am not an experienced programmer on OS X so I tend to go ahead with the best of my knowledge. I am currently able to start a java application, load a JNI which contains the appropriate calls to triger a device search. The only way I can get a list of all the devices is to set a separate thread (inside the JNI in C) which has the series of calls for a device search and, at the end, I make a call to the runloop. By doing so, the callback fctns are called and I can get the list of devices available. Obviously, the thread never dies since it is caught in the runloop. I can say it works !... but can I claim it is thread safe ??? This is where I am lost. You state : "...thread restriction I claim is indeed true for the C apis ..." . I do not know where I can get a clear answer on this... I guess I am pushing it a bit too much in doing something that stands out of realm of reasonable path to follow ! It's not impossible. First I would verify that the thread restriction I claim is indeed true for the C apis (I've been using the ObjectiveC api). This would probably involve getting the bluetooth working first by calling your C functions (that you're wrapping in JNI) in a purely C environment using main and non-main threads -- query, connect, open channel, send/receive, close channel, disconnect. Second, if you find that it doesn't work except on the main thread, you might investigate whether you can set up the main thread before you run the jvm. I would be fairly certain (your mileage may vary ;-) that once you enter the jvm that it sits in a runloop and fields window manager events. You could add a bunch of sources to the main thread's runloop, and your jni functions could post requests to the main thread by triggering those sources, which would then carry out the bluetooth operation on the main thread. Etc. If you plan on talking to one device at a time, this should be fairly straightforward. For simultaneous devices, you might have to implement a command queue of some kind. I'm CC'ing this back to the list in hopes that someone more knowledgeable about Bluetooth, Java, threading, etc. than I will chime in... I am currently working on a Java Application which would need some call into the api of bluetooth. So, I did a JNI to wrap it up. Now, according to what you are saying JAVA/JNI/Bluetooth is not possible ! Please let me know if there is an avenue that I am missing... I am seriously stuck here. The Apple Bluetooth implementation is not thread safe. In order for it to work correctly, you must make all calls from the main thread. IOBluetoothDeviceRegisterForDisconnectNotification _________________________________________________________________ Say hello to the next generation of Search. Live Search try it now. http://www.live.com/?mkt=en-ca _________________________________________________________________ Ready for the world's first international mobile film festival celebrating the creative potential of today's youth? Check out Mobile Jam Fest for your a chance to WIN $10,000! www.mobilejamfest.com This email sent to site_archiver(a)lists.apple.com

1 0

Kernel Panics
by Sebastian Krauß 22 Oct '06

22 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Hello list, A panic log sent to me by a user looks like this: Somewhat helpless... Sebastian _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… one of my apps seems to be causing Kernel Panics at the moment the remote client connects to the Mac. It uses a custom service, the code is partially altered code from the RFCommServerSample; the code for incoming connections looks like this: -(void) newRFCOMMChannelOpened:(IOBluetoothUserNotification *) inNotification channel:(IOBluetoothRFCOMMChannel *)newChannel { if ((newChannel)&&[newChannel isIncoming]&&([newChannel getChannelID]==serverChannelID)) { if ([newChannel setDelegate:self]==kIOReturnSuccess) { RFCOMMChannel = newChannel; [RFCOMMChannel retain]; [self stopProvidingServices]; [connectionTarget performSelector:handleRemoteConnectionSelector]; } else { RFCOMMChannel = NULL; } } } Unresolved kernel trap(cpu 0): 0x700 - Program DAR=0x000000000891D000 PC=0x00000000026E3B40 Latest crash info for cpu 0: Exception state (sv=0x385B3500) PC=0x026E3B40; MSR=0x00089030; DAR=0x0891D000; DSISR=0x42000000; LR=0x002FA2C0; R1=0x21EEB8E0; XCP=0x0000001C (0x700 - Program) Backtrace: 0x00000000 0x00614E48 0x0060D0E4 0x0060D694 0x00611B68 0x00611274 0x00603654 0x005FE828 0x0060A550 0x005FE770 0x005EF158 0x005EB81C 0x005EB7B0 0x005EAF64 0x006182BC 0x00618714 0x0003C884 0x000A9314 Kernel loadable modules in backtrace (with dependencies): com.apple.iokit.IOBluetoothFamily(1.7.8f2)@0x5e5000 Proceeding back via exception chain: Exception state (sv=0x385B3500) previously dumped as "Latest" state. skipping... Exception state (sv=0x391BFC80) PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown) Kernel version: Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC panic(cpu 0 caller 0xFFFF0007): 0x700 - Program Latest stack backtrace for cpu 0: Backtrace: 0x00095138 0x00095650 0x00026898 0x000A7E04 0x000AB780 Proceeding back via exception chain: Exception state (sv=0x385B3500) PC=0x026E3B40; MSR=0x00089030; DAR=0x0891D000; DSISR=0x42000000; LR=0x002FA2C0; R1=0x21EEB8E0; XCP=0x0000001C (0x700 - Program) Backtrace: 0x00000000 0x00614E48 0x0060D0E4 0x0060D694 0x00611B68 0x00611274 0x00603654 0x005FE828 0x0060A550 0x005FE770 0x005EF158 0x005EB81C 0x005EB7B0 0x005EAF64 0x006182BC 0x00618714 0x0003C884 0x000A9314 Kernel loadable modules in backtrace (with dependencies): com.apple.iokit.IOBluetoothFamily(1.7.8f2)@0x5e5000 Exception state (sv=0x391BFC80) PC=0x00000000; MSR=0x0000D030; DAR=0x00000000; DSISR=0x00000000; LR=0x00000000; R1=0x00000000; XCP=0x00000000 (Unknown) Kernel version: Darwin Kernel Version 8.8.0: Fri Sep 8 17:18:57 PDT 2006; root:xnu-792.12.6.obj~1/RELEASE_PPC Does anybody have an idea what's going wrong here? Besides the fact that an application running with normal user privileges shouldn't ever be able to cause a Kernel Panic. This email sent to site_archiver(a)lists.apple.com

1 0

Re: IOBluetoothDeviceRegisterForDisconnectNotification
by Joseph Kelly 20 Oct '06

20 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Christian, Joe On Oct 20, 2006, at 7:53 AM, Christian Martin wrote: Hi Joseph, Thx for your rapid answer. Thx. Christian Martin B.Sc. Math/Computer From: Joseph Kelly <joeman(a)mac.com> To: Christian Martin <cmartin64x(a)hotmail.com> Subject: Re: IOBluetoothDeviceRegisterForDisconnectNotification Date: Thu, 19 Oct 2006 13:57:21 -0700 Joe K. On Oct 19, 2006, at 12:57 PM, Christian Martin wrote: _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… It's not impossible. First I would verify that the thread restriction I claim is indeed true for the C apis (I've been using the ObjectiveC api). This would probably involve getting the bluetooth working first by calling your C functions (that you're wrapping in JNI) in a purely C environment using main and non-main threads -- query, connect, open channel, send/receive, close channel, disconnect. Second, if you find that it doesn't work except on the main thread, you might investigate whether you can set up the main thread before you run the jvm. I would be fairly certain (your mileage may vary ;-) that once you enter the jvm that it sits in a runloop and fields window manager events. You could add a bunch of sources to the main thread's runloop, and your jni functions could post requests to the main thread by triggering those sources, which would then carry out the bluetooth operation on the main thread. Etc. If you plan on talking to one device at a time, this should be fairly straightforward. For simultaneous devices, you might have to implement a command queue of some kind. I'm CC'ing this back to the list in hopes that someone more knowledgeable about Bluetooth, Java, threading, etc. than I will chime in... I am currently working on a Java Application which would need some call into the api of bluetooth. So, I did a JNI to wrap it up. Now, according to what you are saying JAVA/JNI/Bluetooth is not possible ! Please let me know if there is an avenue that I am missing... I am seriously stuck here. The Apple Bluetooth implementation is not thread safe. In order for it to work correctly, you must make all calls from the main thread. IOBluetoothDeviceRegisterForDisconnectNotification _________________________________________________________________ Say hello to the next generation of Search. Live Search – try it now. http://www.live.com/?mkt=en-ca This email sent to site_archiver(a)lists.apple.com

1 0

IOBluetoothDeviceRegisterForDisconnectNotification
by Christian Martin 19 Oct '06

19 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Hi, Any sample on that or code... This is poorly documented... When I turn off my bluetooth device... I do not seem to trigger anything ? Any lead ? Thx C Martin _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… I like to have some mecanisms that would handle a lost device / out of range / turn off... I taught that IOBluetoothDeviceRegisterForDisconnectNotification would do the job... I currently create a thread with the call IOBluetoothDeviceRegisterForDisconnectNotification and then call RunApplicationEventLoop(); _________________________________________________________________ Ready for the world's first international mobile film festival celebrating the creative potential of today's youth? Check out Mobile Jam Fest for your a chance to WIN $10,000! www.mobilejamfest.com This email sent to site_archiver(a)lists.apple.com

1 0

Re: Service Searches
by Alexander Traud 18 Oct '06

18 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com User-agent: Microsoft-Entourage/9.0.6.8320 >> the device is specifying the attribute list as {0100, 0004} for the >> ServiceSearchAttributeRequest >> [...] >> the response for only one service [is] being returned when the production >> device requests the service search. > as it does work on Windows I would test other devices having several SPPs against your problem-device, too. Having no 0x0001 in the service search is quite unusual and might be the actual problem on your problem-device. Otherwise, if possible, use a private UUID instead of the quite generic SPP one. Nevertheless, you can file a bug report at Apple. However, than I am not sure, who will be faster, your problem-device manufacturer or Apple. https://bugreport.apple.com/ PS: Comcast is quite tricky when it comes to e-mail. For example, I am not able to send you a private message. _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Fwd: Service Searches
by Ron Wagner 18 Oct '06

18 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… This email sent to site_archiver(a)lists.apple.com

1 0

Re: OBEXAddCountHeader
by Sebastian Krauß 18 Oct '06

18 Oct '06

site_archiver(a)lists.apple.com Delivered-To: bluetooth-dev(a)lists.apple.com Wow, great news! Thank you so much. >From here on, I'll make it on my own. ;) Am 18.10.2006 um 19:07 schrieb Ralf Menssen: Documentation is here: status = [mFileTransferService sendFile:@"Testfile"]; you should provide 2 delegate functions: and 2. (example): Ralf Menssen nova media _______________________________________________ Do not post admin requests to the list. They will be ignored. Bluetooth-dev mailing list (Bluetooth-dev(a)lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/bluetooth-dev/site_archiver%40lists.… Sebastian Krauß schrieb: OK, just had a look at the documentation. Looks good. -- But... in my app, I stuck close to Apple's sample code at /Developer/Examples/Bluetooth/OBEXSample which let me show progress since my eventSelector got called every time I can write new data. Will I still be able to do that when I use those APIs which -- in comparison, at least -- are more high level? Sebastian PS: Sorry for not having replied to the other mails; I somehow only received a few of the answers and discovered the other mails in the web archive. No, OBEX File Transfer is an alternative Bluetooth service. You use it instead of OBEX Object Push. It provides you with some basic file system functions like copy files, get directory contents of the device, create new folders, delete files, etc. You connect once and stay connected until you close the connection. In your main menu bar you should find that Bluetooth symbol with some functions to browse a Bluetooth device. This uses OBEX File Transfer. http://developer.apple.com/documentation/DeviceDrivers/Reference/ IOBluetooth/OBEXFileTransferServices/Classes/ OBEXFileTransferServices/CompositePage.html And a while ago there was sample code for an OBEX File Transfer application, don't know where it has gone... Yes, FileTransfer uses similar mechanisms. When copying a file from the Mac to the device using 1. - (void) fileTransferServicesSendFileComplete: (OBEXFileTransferServices*)inServices error:(OBEXError)inError - (void) fileTransferServicesSendFileProgress: (OBEXFileTransferServices*)inServices transferProgress:(NSDictionary*)inProgressDescription; { NSNumber *dataTransfered = [inProgressDescription objectForKey: (NSString *)kFTSProgressBytesTransferredKey]; [_notifier showProgress:[dataTransfered intValue]]; /* Dictionary contains: kFTSProgressBytesTotalKey = 3880895; kFTSProgressBytesTransferredKey = 65529; kFTSProgressEstimatedTimeKey = 51.3941650390625; kFTSProgressPercentageKey = 1.688502; kFTSProgressTimeElapsedKey = 0; kFTSProgressTransferRateKey = 72.4974; */ } This email sent to site_archiver(a)lists.apple.com

1 0