This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Communicating with CC2541DK-RC in Linux (CentOS 7.0) without dongle

Other Parts Discussed in Thread: CC2541, CC2541DK-RC, CC2541DK-MINI

Hi All,

I am in process of designing a custom BLE remote control based on TI CC2541. Before designing the hardware, I bought two dev kits from TI,  CC2541DK-MINI and  CC2541DK-RC to evaluate the performance and give something to the software team until the custom remote control design is finished.

The (embedded) PC I am trying to control runs a Linux CentOS 7.0 and incorporates an Intel Bluetooth module which supports BLE, hence I don't use/need the USB dongle. I successfully could communicate with the  CC2541DK-MINI devkit using hcitools but it fails when I want to connect to the CC2541DK-RC.

I wonder if there is a simple way of communicating with the CC2541DK-RC. What I need to do is to capture events when a key is pressed on the remote control.

Thanks

  • How does it fail? What software is loaded on the RC? It is likely the HID sample project which means you'll need to use HID on the Linux side.
  • Hi Tim,


    Thanks for your reply.

    The RC has got it's default firmware which I reckon is the HID sample. I could successfully use/test that under Windows 8.

    In linux (I gave up CentOS and switched to Ubuntu 15.10) I tried these commands to connect and pair, but pairing fails:

    ali@ali-desktop:~$ bluetoothctl
    [NEW] Controller 34:13:E8:39:0E:67 ali-desktop [default]
    [bluetooth]# scan on
    Discovery started
    [CHG] Controller 34:13:E8:39:0E:67 Discovering: yes
    [NEW] Device 84:DD:20:F0:A1:C2 84-DD-20-F0-A1-C2
    [bluetooth]# scan off
    [CHG] Device 84:DD:20:F0:A1:C2 RSSI is nil
    [CHG] Controller 34:13:E8:39:0E:67 Discovering: no
    Discovery stopped
    [bluetooth]# default-agent
    No agent is registered
    [bluetooth]# agent on
    Agent registered
    [bluetooth]# pair 84:dd:a0:f0:a1:c2
    Device 84:dd:a0:f0:a1:c2 not available
    [bluetooth]#

    Also, I tried the following commands which failed as well:

    ali@ali-desktop:~$ sudo hidd -connect 84:dd:20:f0:a1:c2
    Can't get device information: Host is down

    What I need is just the commands which allow me using this remote as a keyboard in linux.

    Regards,

    Ali

  • Ali,

    If I understand this correctly, the same target application works in Windows but not in Linux. Correct?

    If that's the case, can send a sniff capture of your traffic? Is the device awake when you are trying to pair with it?
  • Tom,

    Yes, that's right. I can pair and use the remote in windows on the first go, but no success in Linux. I'm not sure about the Linux commands that I should follow though.

    So, I realised why the above commands did not work. I had to enter the MAC address with capital letters. Now it moves a bit further but still does not connect.

    The following shows how it pairs but does not ask pin code. You see when it connects then prompts: Failed to pair...:

    user@ubuntu:~$ bluetoothctl -a
    [NEW] Controller 34:13:E8:39:0E:67 ubuntu [default]
    [NEW] Device 08:ED:B9:EB:0E:F0 CHYMAPAL
    Agent registered
    [bluetooth]# power on
    Changing power on succeeded
    [bluetooth]# agent KeyboardOnly
    Agent is already registered
    [bluetooth]# default-agent
    Default agent request successful
    [bluetooth]# pairable on
    Changing pairable on succeeded
    [bluetooth]# scan on
    Discovery started
    [CHG] Controller 34:13:E8:39:0E:67 Discovering: yes
    [NEW] Device 70:73:CB:CB:0E:B8 70-73-CB-CB-0E-B8
    [NEW] Device 84:DD:20:F0:A1:C2 84-DD-20-F0-A1-C2
    [bluetooth]# pair 84:dd:20:f0:a1:c2
    Device 84:dd:20:f0:a1:c2 not available   

    [bluetooth]# pair 84:DD:20:F0:A1:C2
    Attempting to pair with 84:DD:20:F0:A1:C2
    [CHG] Device 84:DD:20:F0:A1:C2 Connected: yes
    [CHG] Device 84:DD:20:F0:A1:C2 UUIDs: 00001800-0000-1000-8000-00805f9b34fb
    [CHG] Device 84:DD:20:F0:A1:C2 UUIDs: 00001801-0000-1000-8000-00805f9b34fb
    [CHG] Device 84:DD:20:F0:A1:C2 UUIDs: 0000180a-0000-1000-8000-00805f9b34fb
    [CHG] Device 84:DD:20:F0:A1:C2 UUIDs: 0000180f-0000-1000-8000-00805f9b34fb
    [CHG] Device 84:DD:20:F0:A1:C2 UUIDs: 00001812-0000-1000-8000-00805f9b34fb
    [CHG] Device 84:DD:20:F0:A1:C2 UUIDs: 00001813-0000-1000-8000-00805f9b34fb
    [CHG] Device 84:DD:20:F0:A1:C2 Name: HID AdvRemote
    [CHG] Device 84:DD:20:F0:A1:C2 Alias: HID AdvRemote
    [CHG] Device 84:DD:20:F0:A1:C2 Modalias: bluetooth:v000Dp0000d0110
    Agent unregistered
    [DEL] Controller 34:13:E8:39:0E:67 ubuntu [default]
    Failed to pair: org.freedesktop.DBus.Error.NoReply
    [bluetooth]# scan on
    No default controller available
    [bluetooth]# default-agent
    No agent is registered
    [bluetooth]# agent on
    Agent registration enabled
    [bluetooth]# default-agent
    No agent is registered

     

    After this, neither the host controller nor the remote are accessible (see last lines above)

    Then I restarted my computer to see if I can reproduce this. This time it showed me that the remote is available but as soon I started scanning, again the host controller deleted...

    user@ubuntu:~$ bluetoothctl -a
    [NEW] Controller 34:13:E8:39:0E:67 ubuntu [default]
    [NEW] Device 84:DD:20:F0:A1:C2 HID AdvRemote
    Agent registered
    [bluetooth]# power on
    Changing power on succeeded
    [bluetooth]# agent on
    Agent is already registered
    [bluetooth]# default-agent
    Default agent request successful
    [bluetooth]# pairable on
    Changing pairable on succeeded
    [bluetooth]# scan on
    Discovery started
    [CHG] Controller 34:13:E8:39:0E:67 Discovering: yes
    [CHG] Device 84:DD:20:F0:A1:C2 RSSI: -39
    [CHG] Device 84:DD:20:F0:A1:C2 Connected: yes
    Agent unregistered
    [DEL] Controller 34:13:E8:39:0E:67 ubuntu [default]

    You asked two questions:

    "If that's the case, can send a sniff capture of your traffic?"   Would you please let me know how I can sniff capture the traffic?

    "Is the device awake when you are trying to pair with it?" Provided that it does not advertise unless I press a key, I reckon this means it is awake.

    Regards,

    Ali

     

     

  • The fact this works on windows makes me believe that the issue is probably on the BLE central side (Linux host/BLE host module/HID deamon)..

    Googling around "org.freedesktop.DBus.Error.NoReply" is some java exception.

    There are several sniffers around there, depending on the price range you are looking for.

    TI has a free sniffer available here: http://www.ti.com/tool/packet-sniffer

  • Hi Tim,

    The TI packet sniffer is for Windows not Linux. I used it few week ago though for debugging a KeyFob connection in windows (7, 8 and 10), it didn't work at all.

    It's been a couple of weeks I've been trying to get this remote control working in Linux, no success. So, I change my question now to: Has TI ever tested CC2541-DK-RC (HID AdvRemote) under a Linux platform so it acts as a keyboard? 

    If yes, then please let me know how?

    If no, then I need to figure out another solution for my application. 

    Best Regards,

    Ali

  • Hi Ali,

    currently, the desktop tools (sniffer, Btool, etc...) operate only on windows. HID reports should function independently across platforms. I HID example should work with windows, android (flavor of Linux), and ios applications. The issue you are seeing seems to be just related to Linux itself. Where you able to get past the java exception?
  • Hi Tom,

    No, unfortunately I could not resolve this yet. As you also mentioned, I reckon the problem is in Linux drivers. I used BlueZ which apparently is the only (or best?) way to communicate with the bluetooth devices. I am pretty sure the issue is with the pairing and it fails or is ignored somehow in the track.

    I have tried millions of  suggestions in the forums, but no success yet. The thing is all forums are based on generic Bluetooth keyboards (may not particularly BLE) and I am not sure if my problem is related to TI BT stack implementation or BlueZ or BLE or what :(

    It would be great if TI could test this in a flavor of Linux and publish a guide for that. I bet this could be really helpful for embedded designers who use Linux in their systems.

    Best Regards,

    Ali

  • Hi Tom,

    I'm in the same boat. My target is running Linux with BlueZ and fails to connect to the TI Adv remote controller. It would be great, if TI can provide a documentation which clearly explains how to make the remote controller work in Linux environments. Do you have a plan to release such doc?

    Here is little details of my issue.

    0. Setup

    (1) Linux kernel 3.4 and BlueZ 4.101
    (2) Linux kernel 3.4 and BlueZ 5.27

    1. "hcitool lescan" command gives the MAC of the adv. remote controller. A button on the remote controller should be pressed to make it searchable.

    # hcitool lescan
    LE Scan ...
    84:DD:20:F0:A2:5C (unknown)
    84:DD:20:F0:A2:5C HID AdvRemote

    2. I've tried to establish a connection with the help of "gatttool". A connection is made briefly and dropped immediately. A button should be pressed to make it connect.

    # gatttool -b 84:DD:20:F0:A2:5C -I
    [ ][84:DD:20:F0:A2:5C][LE]> connect
    [ ][84:DD:20:F0:A2:5C][LE]>

    3. The same test has been done for another BLE device(BLE serial device), and it works well.

    # hcitool lescan
    LE Scan ...
    00:15:83:00:3E:F6 (unknown)
    00:15:83:00:3E:F6 BT05

    # gatttool -b 00:15:83:00:3E:F6 -I
    [ ][00:15:83:00:3E:F6][LE]> connect
    [CON][00:15:83:00:3E:F6][LE]> primary
    [CON][00:15:83:00:3E:F6][LE]>
    attr handle: 0x0001, end grp handle: 0x000b uuid: 00001800-0000-1000-8000-00805f9b34fb
    attr handle: 0x000c, end grp handle: 0x000f uuid: 00001801-0000-1000-8000-00805f9b34fb
    attr handle: 0x0010, end grp handle: 0x0022 uuid: 0000180a-0000-1000-8000-00805f9b34fb
    attr handle: 0x0023, end grp handle: 0xffff uuid: 0000ffe0-0000-1000-8000-00805f9b34fb

    Regards,
    Justin
  • Ali & Justin,

    I think to get to the root to the problem on what's happening here we need a wireless sniffer capture between the controller and the advanced remote. Can one of you provided such a capture? The capture should show the connection taking place, but it may provide insights on what/who is causing the connection to drop.

  • Hi Tom and Justin,

    Unfortunately I am not able to run a sniffer due to lack of time and experience with the such programs. However, we've made a bit of progress with this:

    We switched back to CentOS (is it is eventually our target). We updated the BlueZ library to the latest version (v5.37) and we could pair the remote and it just worked! (See below)

    BUT, as soon as we restart the machine it won't boot. So, we reckon that's something to do with the BlueZ library and CentOs version we've got. Now, the ball is in the software team side to realise what the cause of problem is and how to solve it.

    Justin, could you update your BlueZ library and see if you can pair and if you face similar problem? This solution didn't work in Ubuntu.

    Here is how we managed to pair the remote:

    $ bluetoothctl -a
    [NEW] Controller 34:13:E8:39:0E:67 devel [default]

    Agent registered

    [bluetooth]# power on
    Changing power on succeeded

    [bluetooth]# default-agent
    Default agent request successful

    [bluetooth]# pairable on
    Changing pairable on succeeded

    [bluetooth]# scan on
    Discovery started

    [CHG] Controller 34:13:E8:39:0E:67 Discovering: yes
    [NEW] Device 84:DD:20:F0:A1:C2 84-DD-20-F0-A1-C2
    [bluetooth]# pair 84:DD:20:F0:A1:C2

    --asks for the passkey and then pair the device
    [bluetooth]# trust 84:DD:20:F0:A1:C2

    --trusted
    [bluetooth]# connect 84:DD:20:F0:A1:C2

    --connected
    [HID AdvRemote] 123421                <- Keys 1,2,3,4,2,1 are pressed
    [HID AdvRemote] quit