PAN1026A problem pair with older computers

I am using a PAN1026A with SDK in Bluetooth Classic SPP with simple secure pairing. With newer computer we have no problem pairing. With older computers >= 2 years when the computer scans for Bluetooth devices the PAN1026A will appear multiple times as unknown device. What is causing this issue. We are using the latest SDK in bare metal mode. 

10replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • What operating systems are running on the old and new computers? Are they the same?

    Are you using dual-mode operation, ie. Bluetooth Classic and Bluetooth Low Energy simultaneously?

    If multiple devices are shown: is the pairing successful with one of the entries?

    Like
  • Both computers are running windows 10. I am only using Bluetooth Classic do I have to disable the BLE side of the module? The new computer I can pair and using Real Term terminal program send messages back and forth. The old computer I can pair but have problems using Real Term terminal program I cannot send messages see multiple Unknown device in Blue tooth settings show devices. 

    Like
  • Dennis Essenmacher does this answer your question?

    Like
  • The old computer I can pair but have problems using Real Term terminal program I cannot send messages see multiple Unknown device in Blue tooth settings show devices.

    By observing your application on the PAN1026A-based device you can verify how and if a connection is established between that computer and your device.

    You confirmed that pairing works so that shows that the basic connectivity is working.

    Do you use the same Bluetooth adapter on both of these computers or are these notebooks with built-in adapters? If so, are they different?

    It is possible that on these computers different Bluetooth stacks are operating and that because of this the virtual COM ports are behaving differently.

    If you establish a connection once and do the pairing, then a set of virtual COM ports will be created for that connection. I cannot explain why other Bluetooth devices are shown or where they are coming from.

    Usually opening a virtual COM port in a terminal application will trigger the connection to be established. So if you go through all the (virtual) COM ports on your device, opening one of them should lead to the Bluetooth connection getting created.

    If not, then I am afraid there is a setup and/or configuration problem on your old computer's Bluetooth subsystem, which is out of scope for PAN1026A to fix, I'm afraid.

    Like
  • Michael Hunold unfortunately the PAN1026a replaces a Blue Radios module that works. The reason to go to the PAN1026A is to cut cost. 

    Like
  • Please confirm: The same "old" computer works when using it against the Blue Radios Bluetooth module, but does not work when using it against the PAN1026A module?

    Like
  • I tried the board with Blue Radios module it works. I think the problem is handling of the link key. The computer send the following command:

    TCU MNG CONNECTION STATUS EVENT   link key
    ya_RxData[846] uint8 0x20 (Hex) 
    ya_RxData[847] uint8 0x0 (Hex) 
    ya_RxData[848] uint8 0x0 (Hex) 
    ya_RxData[849] uint8 0xe1 (Hex) 
    ya_RxData[850] uint8 0x47 (Hex) 
    ya_RxData[851] uint8 0x19 (Hex) 
    ya_RxData[852] uint8 0x0 (Hex) 
    ya_RxData[853] uint8 0x0 (Hex) 
    ya_RxData[854] uint8 0x2 (Hex) 
    ya_RxData[855] uint8 0xd5 (Hex) 
    ya_RxData[856] uint8 0x5b (Hex) 
    ya_RxData[857] uint8 0xcc (Hex) 
    ya_RxData[858] uint8 0x71 (Hex) 
    ya_RxData[859] uint8 0x0 (Hex) 
    ya_RxData[860] uint8 0x3 (Hex) 
    ya_RxData[861] uint8 0x46 (Hex) 
    ya_RxData[862] uint8 0xdd (Hex) 
    ya_RxData[863] uint8 0xcd (Hex) 
    ya_RxData[864] uint8 0x65 (Hex) 
    ya_RxData[865] uint8 0x44 (Hex) 
    ya_RxData[866] uint8 0x36 (Hex) 
    ya_RxData[867] uint8 0x47 (Hex) 
    ya_RxData[868] uint8 0xd0 (Hex) 
    ya_RxData[869] uint8 0xae (Hex) 
    ya_RxData[870] uint8 0xd7 (Hex) 
    ya_RxData[871] uint8 0x32 (Hex) 
    ya_RxData[872] uint8 0xc8 (Hex) 
    ya_RxData[873] uint8 0x9b (Hex) 
    ya_RxData[874] uint8 0x2 (Hex) 
    ya_RxData[875] uint8 0xea (Hex) 
    ya_RxData[876] uint8 0x6d (Hex) 
    ya_RxData[877] uint8 0x4 (Hex)
     

    Like
  • I think the problem is handling of the link key.

    The reception of the link key looks ok.

    The status code is 0x00 (= "Successful") and the Connection Status is 0x03 (= "Link Key") so with this event the link key is transmitted.

    The Link Key Type is 0x04, which means "Unauthenticated Combination Key". This means that the "Just Works" simple pairing method was used. Here, no pin code or additional key press was used to make sure that the remote device you are pairing against is really the device that is under your control.

    Until here everything looks ok, but the key handling still may be the problem.

    Since you are using the Bluetooth SDK you need to properly implement the key store API. The key store API is used automatically by the Bluetooth SDK to store and retrieve link keys.

    key_store_bt_store_link_key() is called whenever such a connection status event with a link key is retrieved and  key_store_bt_retrieve_link_key() is used when a SPP connection is established. If a link key is present from a previous connection then it must be used to establish the next connection.

    If this is not done correctly, then the remote device may terminate the connection and not try to establish a using this link key again.

    So please carefully check the link key handling with regard to the key store API again.

    As a last resort you could create a complete debug log of all TCU requests, responses and events and attach it as a file to this issue.

    It is sufficient if all TCU messages are printed in the form 0x020 0x00 0x00 0xe1 0x47 0x19 0x00 ...

    Like
  • Does the PAN1026a have EEPROM? If not does the board have to provide an EEPROM for storage of link keys?

    Like
  • PAN1026A has an on-module EEPROM.

    The main purpose is the storage of the public Bluetooth Device Address, which is read when the device boots up.

    The rest of the EEPROM is free for application use.

    The Toshiba Bluetooth SDK forwards all link key handling (store, retrieve, delete) to the application layer via the so-called "key store API". The application must implement the key store API for Bluetooth Classic and/or the key store API for Bluetooth LE.

    If your host controller has an easily accessible non-volatile storage then you can implement the key store API on top of that.

    Alternatively, the Bluetooth SDK comes with a sample implementation of the key store APIs that will use the on-module EEPROM for storage instead.

    Please check the Bluetooth SDK developer's guide from the Toshiba Bluetooth SDK for details, for example chapter 7.4.7. Key Storage Subsystem Callbacks.

    Like
Like Follow
  • 1 yr agoLast active
  • 10Replies
  • 71Views
  • 2 Following