Bluefruit-LE-Shield-FAQ

Page(s) en cours de traduction/élaboration. Page(s) under translation/construction

Puis-je dialoguer avec un périphérique 'Classic Bluetooth' avec un Bluefruit LE?

Non. Bluetooth Low Energy et Bluetooth 'Classic' sont deux parties d'une même noyau de spécification Bluetooth (Bluetooth Core Specification) -- définie et maintenue par le Bluetooth SIG -- mais sont des protocoles complètements différents fonctionnant avec des contraintes et des exigences différentes. Les deux protocoles ne peuvent pas dialoguer directement.

Mon module Bluefruit LE peut-il se connecter sur d'autres périphériques Bluefruit LE ?

Non, le firmware Bluefruit LE d'Adafruit est uniquement un périphérique et ne fonctionne pas en mode Central (comme un SmartPhone ou support BLE d'un laptop).

Si vous avez besoin du mode Central alors vous devriez vous pencher sur les nouveaux produits basés sur nRF52832 tel que l'Adafruit Feather nRF52 Bluefruit LE qui contient un firmware capable de fonctionner soit en mode Central ou soit en mode Périphérique.

Les produits à base de nRF518322 (comme celui utilisé dans ce guide) ne sont PAS capable de fonctionner en mode Centrale parce qu'il n'est pas supporté par le firmware qu'il utilise. Il n'est pas possible de faire une mise-à-jour en toute sécurité sans utiliser un matériel spécial.

Pourquoi aucun de mes changements ne persiste lorsque lorsque j'utilise un croquis d'exemple ?

La plupart des croquis effectuent une réinitialisation d'usine (FACTORY RESET) pour être certain que le module Bluefruit LE soit dans un état connu avant d'exécuter le croquis de démo.

C'est utile pour assurer le bon fonctionnement d'un croquis mais a comme effet de board d'effacer toutes les données personnalisées de la NVM pour y remettre le paramétrage d'usine à chaque fois que le croquis est redémarré (ou Arduino réinisitalisé, ce qui redémarre le croquis).

Pour désactiver la réinitialisation d'usine, ouvrez le croquis de démo et trouvez la ligne qui initialise le flag/drapeau FACTORYRESET_ENABLE et fixer la valeur à '0' (cela empêchera la réinitialisation d'usine au démarrage du croquis).

Si vous ne voyez pas le flag/drapeau 'FACTORYRESET_ENABLE' dans le fichier .ino c'est que vous avez probablement une ancienne version de la bibliothèque. Vous pourriez avoir besoin de faire une mise-à-jour de la bibliothèque via le gestionnaire de bibliothèque Arduino.

Ai-je besoin de CTS et RTS sur mon module UART Bluefruit LE ?

Utiliser CTS et RTS n'est strictement nécessaire lorsque l'on utilise une connexion série matérielle (HW serial) mais elle devrait être utilisé lors d'une connexion série logicielle (SW serial) pour réguler le flux de donnée et éviter de perdre des octets. Il est également recommandé d'utiliser CTS et RTS si vous avez beaucoup de données à transférer.

La raison derrière le besoin des signaux CTS et RTS c'est que le block UART du nRF51822 n'est pas très robuste. Les toutes premières versions du composant avaient un FIFO extrêmement petit, ce qui signifie que le périphérique UART était rapidement submergé.

Utiliser CTS et RTS améliore significativement la fiabilité de la connexion UART puisque ces deux broches indiquent au périphérique distant qu'il faut attendre que la mémoire tampon soit traitée.

Pour activer le support CTS et RTS, il faut ouvrir le fichier BluefruitConfig.h et assigner les broches appropriées aux macros dédiées à ces fonctions (elles sont fixées à -1 si elles ne sont pas utilisées).

Activer ces deux broches devrait résoudre les problèmes de fiabilité que vous pourriez rencontrer avec les grandes commandes, ou les transmissions de nombreuses commandes d'affilé.

How can I update to the latest Bluefruit LE Firmware?

Page(s) en cours de traduction/élaboration. Page(s) under translation/construction

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.

Which firmware version supports 'xxx'?

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.

Does my Bluefruit LE device support ANCS?

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.

== My Bluefruit LE device is stuck in DFU mode ... what can I do?

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.

On Android:

• 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

On iOS:

• 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!

on Adafruit_nRF51822_Flasher:

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.

How do I reflash my Bluefruit LE module over SWD?

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.

Adafruit_nF51822_Flasher

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.

Can I access BETA firmware releases?

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!

Activer les Releases BETA pour 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

Why can't I see my Bluefruit LE device after upgrading to Android 6.0?

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.

What is the theoretical speed limit for BLE?

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
• Nexus 4
  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.

Can my Bluefruit board detect other Bluefruit boards or Central devices?

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.

How can I determine the distance between my Bluefruit module and my phone in m/ft?

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.

How far away from my phone can I have my Bluefruit LE module?

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.

How many GATT services and characteristics can I create?

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

Is it possible to modify or disable the built in GATT services and characteristics (DIS, DFU, etc.)?

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.

How can I use BlueZ and gatttool with Bluefruit modules?

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.

<syntaxhighlight lang="bash">

1. Initialise the USB dongle

$ sudo hciconfig hci0 up

1. Scan for the UART BLE device

$ sudo hcitool lescan

 D6:4E:06:4F:72:86 UART

1. 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
 

1. 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

1. 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

1. 6e400002 (handle 0x000b) = TX characteristic
2. 6e400003 (handle 0x000d) = RX characteristic

1. Optional (but maybe helpful) ... scan for CCCD entries

 [D6:4E:06:4F:72:86][LE]> char-read-uuid 2902
 handle: 0x000e 	 value: 00 00 
 

1. Enable notifications on the RX characteristic (CCCD handle = 0x000e)
2. 0100 = get notifications
3. 0200 = get indications
4. 0300 = get notifications + indications
5. 0000 = disable notifications + indications

 [D6:4E:06:4F:72:86][LE]> char-write-req 0x000e 0100
 Characteristic value was written successfully

1. Just to make sure it was updated

 [D6:4E:06:4F:72:86][LE]> char-read-hnd 0x000e
 Characteristic value/descriptor: 01 00 
 

1. Writing "test" in the Serial Monitor of the Arduino sketch should
2. cause this output not that notifications are enabled:

 Notification handle = 0x000d value: 74 65 73 74 

1. Write something to the TX characteristic (handle = 0x000b)
2. 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

1. To send multiple bytes

 [D6:4E:06:4F:72:86][LE]> char-write-cmd 0x000B 707172737475
 

1. If you are running the callbackEcho sketch and notifications
2. are enabled you should get this response after the above cmd:

 Notification handle = 0x000d value: 70 71 72 73 74 75 

---

1. 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

1. This should give us the following output as data is written on the Uno,
2. 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 </bash>

Can I use the IRQ pin to wake my MCU up from sleep when BLE UART data is available?

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.

---

Basé sur "Bluefruit LE Shield" d'Adafruit Industries, écrit par Kevin Townsend - Traduit en Français par shop.mchobby.be CC-BY-SA pour la traduction
Toute copie doit contenir ce crédit, lien vers cette page et la section "crédit de traduction".

Based on "Bluefruit LE Shield" from Adafruit Industries, written by Kevin Townsend - Translated to French by shop.mchobby.be CC-BY-SA for the translation
Copies must includes this credit, link to this page and the section "crédit de traduction" (translation credit).

Traduit avec l'autorisation d'AdaFruit Industries - Translated with the permission from Adafruit Industries - www.adafruit.com