29 917
modifications
Modifications
Sauter à la navigation
Sauter à la recherche
Ligne 96 :
Ligne 96 : − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Bluefruit-LE-Shield-FAQ (voir la source)
Version du 30 juillet 2017 à 15:30
, 30 juillet 2017 à 15:30→Does my Bluefruit LE device support ANCS?
on '''Adafruit_nRF51822_Flasher''':
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.
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 [[Bluefruit-LE-Shield-Software-resources|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 [https://www.adafruit.com/search?q=J-Link 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 [https://github.com/adafruit/Adafruit_Adalink 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 [https://www.adafruit.com/products/2548 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 [https://github.com/adafruit/Adafruit_BluefruitLE_Firmware 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 [https://github.com/adafruit/Adafruit_BluefruitLE_Firmware/blob/master/releases.xml 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 [https://github.com/adafruit/Adafruit_BluefruitLE_Firmware/tree/master/sniffer/1.0.1 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 [https://github.com/adafruit/Adafruit_nRF51822_Flasher Adafruit_nRF51822_Flasher] repo.
== an 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 [http://developer.android.com/about/versions/marshmallow/android-6.0-changes.html#behavior-hardware-id 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 [https://code.google.com/p/android/issues/detail?id=190372&q=GPS&colspec=ID%20Type%20Status%20Owner%20Summary%20Stars 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'''<br />6 packets * 20 bytes * 1/0.030 s = 4 kB/s = 32 kbps
* '''iPhone 5/6 + IOS 8.2/8.3'''<br />3 packets * 20 bytes * 1/0.030 s = 2 kB/s = 16 kbps
* '''iPhone 5/6 + IOS 8.x with nRF8001'''<br />1 packet * 20 bytes * 1/0.030 s = 0.67 kB/s = 5.3 kbps
* '''Nexus 4'''<br />4 packets * 20 bytes * 1/0.0075 s = 10.6 kB/s = 84 kbps
* '''Nordic Master Emulator Firmware (MEFW) with nRF51822 0.9.0'''<br />1 packet * 20 bytes * 1/0.0075 = 2.67 kB/s = 21.33 kbps
* ''' Nordic Master Emulator Firmware (MEFW) with nRF51822 0.11.0'''<br />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 [https://devzone.nordicsemi.com/blogs/1046/what-to-keep-in-mind-when-developing-your-ble-andr/ 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 {{fname|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 [https://www.bluetooth.com/specifications/gatt/viewer?attributeXmlFile=org.bluetooth.service.device_information.xml 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">
# 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 </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.
{{Bluefruit-LE-Shield-TRAILER}}
{{Bluefruit-LE-Shield-TRAILER}}