Re: Connection to Panasonic module Pan1322 fails
Re: Connection to Panasonic module Pan1322 fails
- Subject: Re: Connection to Panasonic module Pan1322 fails
- From: Moritz Gmelin <email@hidden>
- Date: Fri, 15 May 2015 14:52:53 +0200
Hi,
I just found out that this same problem also applies when trying to connect to a BTSPP (or Obex) socket on a Samsung Galaxy Tab (or Galaxy S4). It does however work when I connect to a BTSPP service on a Windows 7 machine using the Microsoft Bluetooth stack.
I am very sure that this did work using our software (the avetanaBluetooth Library) with MacOS < X.10.
So the situation is that the same software that used to work with any BT counterpart before MacOS X.10, now only works with a limited number of counterparts.
Does anyone have an idea about what could have happened?
Thanks
Moritz
> Am 20.04.2015 um 08:46 schrieb Moritz Gmelin <email@hidden>:
>
> Hi,
>
> yes the Thread that is doing the bluetooth stuff is within a RunLoop. And as I said, it does work with all other devices I’ve had in hands so far.
>
> I have done one log of a failed connection attempt and one of a successfull connection from within the BlueChat application (yes, I’ve changed the UUID to BTSPP, which I don’t even use since I’m directly connecting to channel 1 without even doing an SDP inquiry.
>
> Why do I see an SDP search before the real connection even when I did not request one?
>
> The difference I see between the 2 logs is that in the successful log, the connection to PSM 3 is done much earlier (before the SDP reqeust) than in the unsuccessful log. Who is doing this request and can I skip that?
>
> Thanks
>
> Moritz
>
> <logs.zip>
>> Am 17.04.2015 um 13:50 schrieb Moritz Gmelin <email@hidden>:
>>
>>
>> Hi,
>>
>> yes the Thread that is doing the bluetooth stuff is within a RunLoop. And as I said, it does work with all other devices I’ve had in hands so far.
>>
>> I have done one log of a failed connection attempt and one of a successfull connection from within the BlueChat application (yes, I’ve changed the UUID to BTSPP, which I don’t even use since I’m directly connecting to channel 1 without even doing an SDP inquiry.
>>
>> Why do I see an SDP search before the real connection even when I did not request one?
>>
>> The difference I see between the 2 logs is that in the successful log, the connection to PSM 3 is done much earlier (before the SDP reqeust) than in the unsuccessful log. Who is doing this request and can I skip that?
>>
>> Thanks
>>
>> Moritz
>>
>> <BT12Fail.pklg><BT12Success.pklg>
>>
>>
>>> Am 16.04.2015 um 19:33 schrieb Alexander Traud <email@hidden>:
>>>
>>>> Any clues where I could start searching?
>>>
>>> In the Xcode Hardware I/O Tools <https://developer.apple.com/downloads/>,
>>> you find the Apple PacketLogger which is very handy for Bluetooth Classic.
>>>
>>> Are you sure the RFComm channel is still 1? ConnectToServer extracts the
>>> channel ID via the Service-Discovery Profile (SDP) and an UUID. By the way,
>>> this opens a Bluetooth Baseband connection as well. But you saw that, I
>>> guess, because gExampleChatServiceClassUUID is a private UUID, not the one
>>> for the Serial-Port Profile (SSP) you are looking for. Mhm.
>>>
>>>
>>> _______________________________________________
>>> Do not post admin requests to the list. They will be ignored.
>>> Bluetooth-dev mailing list (email@hidden)
>>> Help/Unsubscribe/Update your Subscription:
>>>
>>> This email sent to email@hidden
>>
>>
>
> _______________________________________________
> Do not post admin requests to the list. They will be ignored.
> Bluetooth-dev mailing list (email@hidden)
> Help/Unsubscribe/Update your Subscription:
>
> This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Bluetooth-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden