Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

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.

How to access bluetooth low energy devices from Windows 7

Other Parts Discussed in Thread: CC2540, CC2541

Microsoft has added support for the bluetooth low energy stack to Windows 8, and they have provided a bunch of API's which seem to enable applications to access bluetooth low energy devices. In particular, they have add the BluetoothGATT API's. These include BluetoothGATTGetCharacteristics() and BluetoothGATTGetCharacteristicValue() for example. So in principle, I can write a Windows 8 application to access data from my BLE peripheral device.

Apparently, Microsoft has not ported the BluetoothGATT API's to Windows 7, and there is no clear indication that they intend to do so. So how do I write a Windows 7 application that accesses data from my BLE peripheral device?

TI has application code that runs on Windows 7 and which talks to BLE devices. Is TI willing to make this available to developers? Can we redistribute the Windows 7 drivers that come with the USB BLE radio dongles that come with the CC2540 Mini Development Kit?

When we release our custom BLE peripheral device, it is critical that we provide end users with a way to communicate with the device from a Windows 7 computer.

  • Hello,

    We have something called the BLE Device Monitor.

    Could this be a starting point for you?

    LPRF Rocks the World

  • Yes, I have been using the BLE Device Monitor.

    That program works on Windows 7 with the CC2540 USB dongle. Can we redistribute our version of the CC2540 USB dongle? Is the dongle a reference design that we can copy and can we get source code for the firmware for the dongle? I notice that the dongle uses the Microsoft driver usbser.sys and presents itself to the system as a virtual COM port. That is not an ideal solution but we might be able to live with that.

  • The firmware for the CC2540 USB dongle is distributed together with the BLE-stack release (1.3). All the source code is also included there. The name of the Iar project is TestHostAll (this application also runs on CC2540 EM and CC2541EM). 

  • I cannot find anything called TestHostAll. There is a project called HostTestApp. Is that for the USB dongle?

    I was also wondering if we could get source code for the BLE Device Monitor from TI?

  • Hi Elliot,

    The firmware you are looking for are (dependent on hardware platform):

    •  CC2540_USBdongle_HostTestRelease_All.hex (CC2540 USB Dongle)
    • CC2541_SmartRF_HostTestRelease_All.hex (CC2541EM)
    • CC2540_SmartRF_HostTestRelease_All.hex (CC2540EM)

    available at ..\BLE-CC254x-1.3\Accessories\HexFiles.

    The project source HostTestApp which you refer to correctly.

    Best Regards

  • Is source code for the BLE Monitor app available?

  • The source code for the Windows BLE Device Monitor is for internal use only, and there is currently no plan to make it public.

  • Hallo Jomar,

    I have tested the Sensor Tag Kit with the  BLE Device Monitor, and found some things that will good if you can fix it.

    • On the left side of the tool there is the log output, unfortunately is it not possible to increase the size of the output, it is required to scroll every time to see the full output. It's just for convenience.
    • For the GATT options settings there seems to be a wrong handling of what you can set in the input window. Setting wrong values, e.g. max < min or supervisor time < max/min leads to crash of the BLE Device Monitor. It would be good if there is a reset button for this settings, I had to change this settings at the end via the registry entries. I assume due that you use QT, the values are written to the registry.

    You already mentioned it that the BLE Device Monitor will not be "released", but I might be worth if you can put them for downloading it and if some one has time it can do some fixing/extending the feature set. For legal reasons you can exclude any warranty, etc...

    Thanks in advance

    Nedi

  • Hi Nedi,

    First of all, your feedback is highly appreciated. The two things you mentioned are easy to fix. With the GATT settings, I guess you mean GAP settings, the connection interval? It is perfectly 'legal' to use inconsistent values, but the there will be an error response (I'm surprised it crashes the whole application). That, said we could easily add a sanity check and a 'Restore defaults' button.

    As for releasing the source code: if there is high demand for it we might consider to do it, but at the moment we prefer to keep it in-house.

    NB! You are right, we are using Qt.

  • I would second the motion, regarding providing "source code", at least to TI clients planning on using the BLE chip sets. Fast time to market is critical, and leveraging the TI firmware with  Window7 application source code (ala BTool) would be a beneficial for TI selling chips, and clients creating products with TI chips.

  • Of course you should provide source code for the application. You did so for IOS.

    Nothing like having the other side of the pipeline to see the whole picture.

    We will be Testing these devices as part of our Mfg-ing process before we ship. We use Windows PCs for all of our Mfg/Test applications. Having a kick start is always a reason to select one vendor over another.

  • We would also tremendously benefit from access to the source code BLE device monitor. We will not be looking for support.

    Access to Windows code will speed up our development since using Windows we can add custom code on the tag and  test with Windows. Once tested, port changes to iOS and Android. Without control on Windows side, making changes to the tag are very-2 time consuming.

    Please consider releasing the source code (without support from TI). Looking forward to TI's feedback on this issue.

  • Agreed. Having the source would provide a great reference.

  • We would also appreciate some form of Win7 source that we could pattern our own BLE applications after. I agree we don't need support or warranty. Your help will let us start buying CC2540's much sooner.......

  • Where are we with the source code discussion?  We also need the source code (for Windows 7 support) for the TI part to be a viable option for us.    Also the ability to log the values would be greatly appreciated.

    Thomas.

  • Hi all,
    I hereby add one vote for the importance of providing source code to run on windows. And given the current consumers pool windows 7 is not to be ignored and is a primary target.
    I don't understand how TI and others skipped around this, everyone is currently focusing on the network within the person's reach, all around the smart phone, but for an Internet of Things, it is not a smartphone that is going to collect data from all the smart things at home 24/7.
    Tiny servers running windows are quick and very popular platforms, they solve all the unnecessary burden of embedded development.

    Wassim