No. Bluetooth Low Energy and 'Classic' Bluetooth are both part of the same Bluetooth Core Specification -- defined and maintained by the Bluetooth SIG -- but they are completely different protocols operating with different physical constraints and requirements. The two protocols can't talk to each other directly.
No, the Bluefruit LE firmware from Adafruit is currently peripheral only, and doesn't run in Central mode, which would cause the module to behave similar to your mobile phone or BLE enabled laptop.
If you required Central support, you should look at the newer nRF52832 or nRF52840 based products like the Adafruit Feather nRF52840 which contains a SoftDevice which is capable of running in either Central or Peripheral mode. The nRF518322 based products (such as the one used in this learning guide) are not capable of running in Central mode because it isn't supported by the SoftDevice they use, and it isn't possible to update the SoftDevice safely without special hardware.
There are several possible explanations here, but the first thing to try is to:
- Disconnect and close the Bluefruit LE Connect app if it's open
- Disable BLE on your mobile device
- Restart your Bluefruit sketch and HW
- Turn BLE back on again (on the mobile device)
- Open the Bluefruit LE Connect mobile app again and try to connect again
If problems persist, try performing a Factory Reset of your device (see the appropriate learning guide for details on how to do this since it varies from one board to another).
In order to ensure that the Bluefruit LE modules are in a known state for the Adafruit demo sketches, most of them perform a factory reset at the start of the sketch.
This is useful to ensure that the sketch functions properly, but has the side effect of erasing any custom user data in NVM and setting everything back to factory defaults every time your board comes out of reset and the sketch runs.
To disable factory reset, open the demo sketch and find the FACTORYRESET_ENABLE flag and set this to '0', which will prevent the factory reset from happening at startup.
If you don't see the 'FACTORYRESET_ENABLE' flag in your .ino sketch file, you probably have an older version of the sketches and may need to update to the latest version via the Arduino library manager.
Using CTS and RTS isn't strictly necessary when using HW serial, but they should both be used with SW serial, or any time that a lot of data is being transmitted.
The reason behind the need for CTS and RTS is that the UART block on the nRF51822 isn't very robust, and early versions of the chip had an extremely small FIFO meaning that the UART peripheral was quickly overwhelmed.
Using CTS and RTS significantly improves the reliability of the UART connection since these two pins tell the device on the other end when they need to wait while the existing buffered data is processed.
To enable CTS and RTS support, go into the BluefruitConfig.h file in your sketch folder and simply assign an appropriate pin to the macros dedicated to those functions (they may be set to -1 if they aren't currently being used).
Enabling both of these pins should solve any data reliability issues you are having with large commands, or when transmitting a number of commands in a row.
The easiest way to keep your Bluefruit LE modules up to date is with our Bluefruit LE Connect app for Android or Bluefruit LE Connect for iOS. Both of these apps include a firmware update feature that allows you to automatically download the latest firmware and flash your Bluefruit LE device in as safe and painless a manner as possible. You can also roll back to older versions of the Bluefruit LE firmware using these apps if you need to do some testing on a previous version.
We regularly release Bluefruit LE firmware images with bug fixes and new features. Each AT command in this learning guide lists the minimum firmware version required to use that command, but for a higher level overview of the changes from one firmware version to the next, consult the firmware history page.
ANCS is on the roadmap for us (most likely in the 0.7.x release family), but we don't currently support it since there are some unusual edge cases when implementing it as a service.
If your device is stuck in DFU mode for some reason and the firmware was corrupted, you have several options.
First, try a factory reset by holding down the DFU button for about 10 seconds until the CONN LED starts flashing, then release the DFU button to perform a factory reset.
If this doesn't work, you may need to reflash your firmware starting from DFU mode, which can be done in one of the following ways:
Bluefruit LE Connect (Android)
- Place the module in DFU mode (constant LED blinky)
- Open Bluefruit LE Connect
- Connect to the 'DfuTarg' device
- Once connected, you will see a screen with some basic device information. Click the '...' in the top-right corner and select Firmware Updates
- Click the Use Custom Firmware button
- Select the appropriate .hex and .init files (copied from the Bluefruit LE Firmware repo) ... for the BLEFRIEND32 firmware version 0.6.7, this would be:
- Hex File: blefriend32_s110_xxac_0_6_7_150917_blefriend32.hex
- Init File: blefriend32_s110_xxac_0_6_7_150917_blefriend32_init.dat
- Click Start Update
Unfortunately, the iOS app doesn't yet support custom firmware updates from DFU mode yet, but we will get this into the next release.
Nordic nRF Toolbox
You can also use Nordic's nRF Toolbox application to update the firmware using the OTA bootloader.
- Open nRF Toolbox (using the latest version)
- Click the DFU icon
- Click the Select File button
- Select Application from the radio button list, then click OK
- Find the appropriate .hex file (ex. 'blefriend32_s110_xxac_0_6_7_150917_blefriend32.hex')
- When asked about the 'Init packet', indicate Yes, and select the appropriate *_init.dat file (for example: 'blefriend32_s110_xxac_0_6_7_150917_blefriend32_init.dat').
- Click the Select Device button at the bottom of the main screen and find the DfuTarg device, clicking on it
- Click the Upload button, which should now be enabled on the home screen
- This will begin the DFU update process which should cause the firmware to be updated or restored on your Bluefruit LE module
- Create a .zip file containing the .hex file and init.dat file that you will use for the firmware update. For example:
- Rename 'blefriend32_s110_xxac_0_6_7_150917_blefriend32.hex' to application.hex
- Rename 'blefriend32_s110_xxac_0_6_7_150917_blefriend32_init.dat' to application.dat
- Upload the .zip file containing the application.hex and application.dat files to your iPhone using uTunes, as described here
- Open the nRF Toolbox app (using the latest version)
- Click the DFU icon
- Click the Select File text label
- Switch to User Files to see the .zip file you uploaded above
- Select the .zip file (ex. blefriend32_065.zip)
- On the main screen select Select File Type
- Select application
- On the main screen select SELECT DEVICE
- Select DfuTarg
- Click the Upload button which should now be enabled
- This will begin the DFU process and your Bluefruit LE module will reset when the update is complete
- If you get the normal 2 or 3 pulse blinky pattern, the update worked!
As a last resort, if you have access to a Raspberry Pi, a Segger J-Link or a STLink/V2, you can also try manually reflashing the entire device, as described in the FAQ above, with further details on the Software Resources page.
Reflashing Bluefruit LE modules over SWD (ex. switching to the sniffer firmware and back) is at your own risk and can lead to a bricked device, and we can't offer any support for this operation! You're on your own here, and there are unfortunately 1,000,000 things that can go wrong, which is why we offer two separate Bluefruit LE Friend boards -- the sniffer and the normal Bluefruit LE Friend board with the non-sniffer firmware, which provides a bootloader with fail safe features that prevents you from ever bricking boards via OTA updates.
AdaLink (SWD/JTAG Debugger Wrapper)
Transitioning between the two board types (sniffer and Bluefruit LE module) is unfortunately not a risk-free operation, and requires external hardware, software and know-how to get right, which is why it isn't covered by our support team.
That said ... if you're determined to go down that lonely road, and you have a Segger J-Link (which is what we use internally for production and development), or have already erased your Bluefruit LE device, you should have a look at AdaLink, which is the tool we use internally to flash the four files required to restore a Bluefruit LE module. (Note: recent version of AdaLink also support the cheaper STLink/V2, though the J-Link is generally more robust if you are going to purchase a debugger for long term use.)
The mandatory Intel Hex files are available in the Bluefruit LE Firmware repo. You will need to flash:
- An appropriate bootloader image
- An appropriate SoftDevice image
- The Bluefruit LE firmware image
- The matching signature file containing a CRC check so that the bootloader accepts the firmware image above (located in the same folder as the firmware image)
The appropriate files are generally listed in the version control .xml file in the firmware repository.
If you are trying to flash the sniffer firmware (at your own risk!), you only need to flash a single .hex file, which you can find here. The sniffer doesn't require a SoftDevice image, and doesn't use the fail-safe bootloader -- which is why changing is a one way and risky operation if you don't have a supported SWD debugger.
We also have an internal python tool available that sits one level higher than AdaLink (referenced above), and makes it easier to flash specific versions of the official firmware to a Bluefruit LE module. For details, see the Adafruit_nRF51822_Flasher repo.
The latest versions of the Bluefruit LE Connect applications for iOS and Android allow you to optionally update your Bluefruit LE modules with pre-release or BETA firmware.
This functionality is primarilly provided as a debug and testing mechanism for support issues in the forum, and should only be used when trying to identify and resolve specific issues with your modules!
Enabling BETA Releases on iOS
- Make sure you have at least version 1.7.1 of Bluefruit LE Connect
- Go to the Settings page
- Scroll to the bottom of the Settings page until you find Bluefruit LE
- Click on the Bluefruit LE icon and enable the Show beta releases switch
- You should be able to see any BETA releases available in the firmware repo now when you use Bluefruit LE Connect
Enabling BETA Releases on Android
- Make sure you have the latest version of Bluefruit LE Connect
- Open the Bluefruit LE Connect application
- Click the "..." icon in the top-right corner of the app's home screen
- Select Settings
- Scroll down to the Software Updates section and enable Show beta releases
- You should be able to see any BETA releases available in the firmware repo now when you use Bluefruit LE Connect
In Android 6.0 there were some important security changes that affect Bluetooth Low Energy devices. If location services are unavailable (meaning the GPS is turned off) you won't be able to see Bluetooth Low Energy devices advertising either. See this issue for details.
Be sure to enable location services on your Android 6.0 device when using Bluefruit LE Connect or other Bluetooth Low Energy applications with your Bluefruit LE modules.
This depends on a variety of factors, and is determined by the capabilities of the central device (the mobile phone, etc.) as much as the peripheral.
Taking the HW limits on the nR51822 into account (max 6 packets per connection interval, and a minimum connection interval of 7.5ms) you end up with the following theoretical limits on various mobile operating systems:
iPhone 5/6 + IOS 8.0/8.1
6 packets * 20 bytes * 1/0.030 s = 4 kB/s = 32 kbps
iPhone 5/6 + IOS 8.2/8.3
3 packets * 20 bytes * 1/0.030 s = 2 kB/s = 16 kbps
iPhone 5/6 + IOS 8.x with nRF8001
1 packet * 20 bytes * 1/0.030 s = 0.67 kB/s = 5.3 kbps
4 packets * 20 bytes * 1/0.0075 s = 10.6 kB/s = 84 kbps
Nordic Master Emulator Firmware (MEFW) with nRF51822 0.9.0
1 packet * 20 bytes * 1/0.0075 = 2.67 kB/s = 21.33 kbps
Nordic Master Emulator Firmware (MEFW) with nRF51822 0.11.0
6 packets * 20 bytes * 1/0.0075 = 16 kB/s = 128 kbps
There are also some limits imposed by the Bluefruit LE firmware, but we are actively working to significantly improve the throughput in the upcoming 0.7.0 release, which will be available Q2 2016. The above figures are useful as a theoretical maximum to decide if BLE is appropriate for you project or not.
UPDATE: For more specific details on the limitations of various Android versions and phones, see this helpful post from Nordic Semiconductors.
No. All of our Bluefruit LE modules currently operate in peripheral mode, which means they can only advertise their own existence via the advertising payload. The central device (usually your phone or laptop) is responsible for listening for these advertising packets, starting the connection process, and inititating any transactions between the devices. There is no way for a Bluefruit module to detect other Bluefruit modules or central devices in range, they can only send their own advertising data out and wait for a connection request to come in.
The short answer is: you can't.
RF devices normally measure signal strength using RSSI, which stands for Received Signal Strength Indicator, which is measured in dBm. The closer the devices are the strong the RSSI value generally is (-90dBm is much weaker than -60dBm, for example), but there is no reliable relationship between RSSI values in dBm and distance in the real world. If there is a wall between devices, RSSI will fall. If there is a lot of interference on the same 2.4GHz band, RSSI will fall. Depending on the device, if you simply change the antenna orientation, RSSI will fall. You can read the RSSI value between two connected devices with the
AT+BLEGETRSSI command, but there are no meaningful and repeatable conclusions that can be drawn from this value about distance other than perhaps 'farther' or 'closer' in a very loose sense of the terms.
This depends on a number of factors beyond the module itself such as antenna orientation, the antenna design on the phone, transmit power on the sending node, competing traffic in the same 2.4GHz bandwidth, obstacles between end points, etc.
It could be as low as a couple meters up to about 10 meters line of sight, but generally Bluetooth Low Energy is designed for very short range and will work best in the 5-6 meter or less range for reliable communication, assuming normal Bluefruit firmware settings.
For firmware 0.7.0 and higher, the following limitations are present:
- Maximum number of services: 10
- Maximum number of characteristics: 30
- Maximum buffer size for each characteristic: 32 bytes
- Maximum number of CCCDs: 16
No, unfortunately you can't. We rely on the Device Information Service (DIS) contents to know which firmware and bootloader version you are running, and wouldn't be able to provide firmware updates without being able to trust this information, which i why it's both mandatory and read only.
Similarly, the DFU service is mandatory to maintain over the air updates and disabling it would create more problems that it's presence would cause.
BlueZ has a bit of a learning curve associated with it, but you can find some notes below on one option to send and receive data using the BLE UART Service built into all of our Bluefruit LE modules and boards.
These commands may change with different versions of BlueZ. Version 5.21 was used below.
# Initialise the USB dongle $ sudo hciconfig hci0 up # Scan for the UART BLE device $ sudo hcitool lescan D6:4E:06:4F:72:86 UART # Start gatttool, pointing to the UART device found above $ sudo gatttool -b D6:4E:06:4F:72:86 -I -t random --sec-level=high [D6:4E:06:4F:72:86][LE]> connect Attempting to connect to D6:4E:06:4F:72:86 Connection successful # Scan for primary GATT Services [D6:4E:06:4F:72:86][LE]> primary attr handle: 0x0001, end grp handle: 0x0007 uuid: 00001800-0000-1000-8000-00805f9b34fb attr handle: 0x0008, end grp handle: 0x0008 uuid: 00001801-0000-1000-8000-00805f9b34fb attr handle: 0x0009, end grp handle: 0x000e uuid: 6e400001-b5a3-f393-e0a9-e50e24dcca9e attr handle: 0x000f, end grp handle: 0xffff uuid: 0000180a-0000-1000-8000-00805f9b34fb # Get the handles for the entries in the UART service (handle 0x0009) [D6:4E:06:4F:72:86][LE]> char-desc handle: 0x0001, uuid: 00002800-0000-1000-8000-00805f9b34fb handle: 0x0002, uuid: 00002803-0000-1000-8000-00805f9b34fb handle: 0x0003, uuid: 00002a00-0000-1000-8000-00805f9b34fb handle: 0x0004, uuid: 00002803-0000-1000-8000-00805f9b34fb handle: 0x0005, uuid: 00002a01-0000-1000-8000-00805f9b34fb handle: 0x0006, uuid: 00002803-0000-1000-8000-00805f9b34fb handle: 0x0007, uuid: 00002a04-0000-1000-8000-00805f9b34fb handle: 0x0008, uuid: 00002800-0000-1000-8000-00805f9b34fb handle: 0x0009, uuid: 00002800-0000-1000-8000-00805f9b34fb handle: 0x000a, uuid: 00002803-0000-1000-8000-00805f9b34fb handle: 0x000b, uuid: 6e400002-b5a3-f393-e0a9-e50e24dcca9e handle: 0x000c, uuid: 00002803-0000-1000-8000-00805f9b34fb handle: 0x000d, uuid: 6e400003-b5a3-f393-e0a9-e50e24dcca9e handle: 0x000e, uuid: 00002902-0000-1000-8000-00805f9b34fb handle: 0x000f, uuid: 00002800-0000-1000-8000-00805f9b34fb handle: 0x0010, uuid: 00002803-0000-1000-8000-00805f9b34fb handle: 0x0011, uuid: 00002a27-0000-1000-8000-00805f9b34fb # 6e400002 (handle 0x000b) = TX characteristic # 6e400003 (handle 0x000d) = RX characteristic # Optional (but maybe helpful) ... scan for CCCD entries [D6:4E:06:4F:72:86][LE]> char-read-uuid 2902 handle: 0x000e value: 00 00 # Enable notifications on the RX characteristic (CCCD handle = 0x000e) # 0100 = get notifications # 0200 = get indications # 0300 = get notifications + indications # 0000 = disable notifications + indications [D6:4E:06:4F:72:86][LE]> char-write-req 0x000e 0100 Characteristic value was written successfully # Just to make sure it was updated [D6:4E:06:4F:72:86][LE]> char-read-hnd 0x000e Characteristic value/descriptor: 01 00 # Writing "test" in the Serial Monitor of the Arduino sketch should # cause this output not that notifications are enabled: Notification handle = 0x000d value: 74 65 73 74 # Write something to the TX characteristic (handle = 0x000b) # This should cause E F G H to appear in the Serial Monitor [D6:4E:06:4F:72:86][LE]> char-write-cmd 0x000b 45 [D6:4E:06:4F:72:86][LE]> char-write-cmd 0x000b 46 [D6:4E:06:4F:72:86][LE]> char-write-cmd 0x000b 47 [D6:4E:06:4F:72:86][LE]> char-write-cmd 0x000b 48 # To send multiple bytes [D6:4E:06:4F:72:86][LE]> char-write-cmd 0x000B 707172737475 # If you are running the callbackEcho sketch and notifications # are enabled you should get this response after the above cmd: Notification handle = 0x000d value: 70 71 72 73 74 75 -------------- # If you just want to enable constant listening, enter the following command from the CLI: $ sudo gatttool -b D6:4E:06:4F:72:86 -t random --char-write-req -a 0x000e -n 0100 --listen # This should give us the following output as data is written on the Uno, # though we can't send anything back: Characteristic value was written successfully Notification handle = 0x000d value: 74 65 73 74 Notification handle = 0x000d value: 6d 6f 72 65 20 74 65 73 74
No, on SPI-based boards the IRQ pin is used to indicate that an SDEP response is available to an SDEP command. For example, when you sent the `AT+BLEUARTRX` command as an SDEP message, the Bluefruit firmware running on the nRF51822 will parse the message, prepare an SDEP response, and trigger the IRQ pin to tell the MCU that the response is ready. This is completely independant from the BLE UART service, which doesn't have interrupt capability at present.