Ezurio did provide breakout boards for our older BL600(EOL) modules but we do not produce breakout boards for any of our current range of Bluetooth modules as of 2024.

This includes all BL65x, BL53xx, BL54xxx, BTxxx, Vela and Lyra modules.

We do provide development kits for all of our module offerings. To learn more, visit any product page on ezurio.com. 

These instructions are intended for Linux or Macintosh OS. They may work using WSL, Cigwin, or other bash style terminals in Windows although this is untested. 

It may be desired to communicate with a device attached to the USB-SWD without terminal emulation, I.E. Picocom, Screen, Putty.  This can be useful for writing bash scripts, or if you're using Zephyr's "west flash" and would like a quick way to check your output. 

1. Verify you have the program "stty" available using the command "which stty", if this does not return a value you will need to install it.  Fortunately "stty" generally comes standard with Linux and MacOS.  
2. Identify your serial device.  This can be done using the command "dmesg -w" then connecting the USB-SWD.  You will see output like this (In Linux).

3. (Optional) Assign the device name to a variable, for example "DEVICE=/dev/ttyACM0".
4. Configure "stty" to talk with the device "stty -F $DEVICE 115200 -echo -echoe -echok"
5. To see output from the device execute "cat $DEVICE &".  This will send serial communication from the device to Linux's standard output.  The "&" is to run this program in the background.
6. Now press the reset button on the USB-SWD, you should see the output from your device.  In this example the Zephyr "Hello World" example has been flashed to a BT510. 

7. (Optional) if you would like to send commands back to the device you can use "echo" or add an argument to your shell, "foo() { echo -n -e "$1\r" > $DEVICE; }".  Now commands can be issued directly from the command line, for example "foo "my_command"" will send the string "my_command" to the device. 

For example in SmartBasic Interactive mode

ati 4

10    4    01 EFA44957769F
00

BLE devices can have multiple mac addresses and if the mac address begins 01 as above it signifies it is a random static address which is assigned during manufacture. While its random nature means its not unique the number of possible random static addresses is 2^(48-2)-2 a very large number so it is very unlikely you will ever see a duplicate, let alone in the same place at the same time.

Other MAC address types include

• 00 IEEE assigned public address, the same as used by BT classic devices
• 01 Random static, generated at manufacture
• 02 Random private resolvable with IRK. resolvable by other devices already known
• 03 Random private non resolvable

To address privacy concerns, there are four types of Bluetooth addresses in a BLE device which can change as often as required. For example, an iPhone regularly changes its BLE Bluetooth address and it always exposes only its resolvable random address. This feature is known as LE privacy. It allows the Bluetooth address within advertising packets to be replaced with a random value that can change at different time intervals. Malicious devices are not able to track your device as it actually looks like a series of different devices. To manage this, the usual six-octet Bluetooth address is qualified on-air by a single bit which qualifies the Bluetooth address as public or random: ▪ Public – The format is as defined by the IEEE organisation. ▪ Random – The format can be up to three types and this qualification is done using the upper two bits of the most significant byte of the random Bluetooth address.

On Ezurio SmartBasic module, the address type can be set using the function BleSetAddressTypeEx(). On the other hand, Sysinfo$(4) can be used to retrieve the Bluetooth address if it is public or random static. Due to LE privacy 1.2, if the address type is random resolvable or random non-resolvable, it cannot be retrieved by the application layer since it is fully controlled by the baseband layer.

Note: The Bluetooth address portion in smartBASIC is always in big endian format. If you sniff on-air packets, the same six packets appear in little endian format, hence reverse order – and you do not see seven bytes, but a bit in the packet somewhere which specifies it to be public or random.

According to the Nordic DevZone there are mainly two potential issues leading to a short on one of the SWD signals:

• ESD issue, likely when connecting an SWD programmer to the SWD signals.
• Connecting an SWD programmer while the target board is not connected to supply voltage.

Please make sure proper ESD precautions are taken into account (ESD wrist-strap, ESD base/mat) as well as make sure to first connect the supply voltage and then the SWD programmer.

While it's possible to open/write/close files from SmartBASIC Interactive Mode (AT+FOW, FWR, FCL) to e.g., enter configuration information for a SmartBASIC application, there is no AT command available to display the content of a file from the flash file system.

A workaround would be adding another SmartBASIC application to a device which can be started in Interactive Mode (AT+RUN or just the name) and opens the (config) file and prints the content to the console. Below is an example application.

Yes, you need to qualify/list any product that uses BT SIG intellectual property, even if you do not use the logo or require interoperability with other BT devices. see here for more details. Qualify Your Product | Bluetooth® Technology Website

 

The smartBASIC language provides functions for setting a specific set of channels to be used for BLE advertising/scanning or a BLE connection.

• BleChannelMap(chanMap$) enables or disables data channel usage when in a connection.
• BleAdvSetCreate(nSetId, nAdvProperties, nPriSecPhy, nFilterPolicy, peerAddr$, chanMask$) can set BLE advert channels.
• BleScanStartEx(scanTimeoutMs, nPriPhyScan, chanMask$, nFilterHandle) can set channels used for BLE scanning.

The channel map/mask has to be entered as a 5 byte long string for each of the functions and due to the little-endian architecture of the underlying ARM core its composition can be confusing. The below example will show the actual assignment of channel within that string. Furthermore the meaning of a set bit differs among the above functions.

• BleChannelMap() -> a set bit means channel is enabled!
• BleAdvSetCreate() and BleScanStartEx() -> a set bit means channel is disabled!

Now let's “visualize” the channel mapping into the five byte string:

channel number:

00000000|11111100|22221111|33222222|xxx33333
76543210|54321098|32109876|10987654|xxx65432
\byte 0/ \byte 1/ \byte 2/ \byte 3/ \byte 4/

So for enabling e.g., channels 9+10 only you would set the yellow bits:

00000000|11111100|22221111|33222222|xxx33333
76543210|54321098|32109876|10987654|xxx65432
\byte 0/ \byte 1/ \byte 2/ \byte 3/ \byte 4/
 0x00     0x06     0x00     0x00     0x00

giving “0006000000” as string.

For disabling channel only 35, i.e. active channels are 0-34 and 36, it would be:

00000000|11111100|22221111|33222222|xxx33333
76543210|54321098|32109876|10987654|xxx65432
\byte 0/ \byte 1/ \byte 2/ \byte 3/ \byte 4/
  0xFF     0xFF     0xFF     0xFF     0x17

giving “FFFFFFFF17” as string.

Further detail is given in the smartBASIC Extension Guides in the documentation section of the product page for each BLE module at Bluetooth Module Portfolio.

Unfortunately, we do not have an example of a Windows Bluetooth Low Energy application. If you require assistance with developing a Windows Bluetooth Low Energy application please contact one of our Sales Experts and let them know you are interested in a Design Services engagement and we will be happy to discuss your application requirements and provide a quote.

The actual TX rate is influenced by the PDU and MTU sizes along with the Connection Intervals and Slave Latency.

The maximum number of characteristics is not a limitation in smartBASIC but a limitation in the underlying Nordic SoftDevice SDK. The SoftDevice has a maximum RAM allowance of 64KB, adding more characteristics will increase RAM usage and depending on other configuration, will determine how many characteristics can be supported within the 64KB allowed RAM space.

The maximum number of characteristics supported in smartBASIC is roughly 24. This is a product of the combination of the total RAM allowance of 64K for SoftDevice, GATT Table configuration as well as the GATT Table size as is specified in Configuration Key 204 (refer to BL654 smartBASIC Extension Guide). The default GATT table size is 1792 bytes (Config 204)) which will allow for roughly 11 characteristics.

If using the AT Interface application the maximum number of characteristics is set to 24 by default. The default configuration can be found in $autorun$.AT.interface.BL654._.sb file:

 //This defines the maximum number of characteristics we can manage

#define MAX_CHARACTERISTICS 24

As mentioned previously this is the max number of characteristics that can be supported but Out of Box the GATT table size is 1792 bytes resulting in roughly 11 characteristics.

Laird does not provide a Windows utility for scanning and connecting to BLE devices. We are also not aware of any existing third party apps to do this either. Android and iOS are the best options for scanning for and connecting to BLE radios. 

There are several functions within an application that can increase current consumption above the measurement indicated in the Datasheet for standby doze, low power mode.

• Timers
• GPIOs held in an asserted state
• LEDs
• Nested functions - which keep the module from entering the standby doze state
• UART (when open)

Bluetooth Low Energy uses Services as opposed to the set of standardized profiles that exists for Classic Bluetooth. While some Bluetooth Low Energy services have been standardized by the Bluetooth SIG, the development of custom services is allowed to meet custom application requirements.
 
Because Bluetooth Low Energy uses a completely different protocol than Classic Bluetooth and supports custom services, Bluetooth Low Energy devices cannot connect to a computer through the typical Bluetooth configuration of a computer. Therefore, connecting to a PC requires writing and running a Bluetooth Low Energy Central Role/Client application to collect the data sent from the Bluetooth Low Energy peripheral modules. Application development for PCs and Mobile devices is outside the scope of our support. Alternatively, a BL654 USB dongle could be used as a BLE Central Role device, to collect the BLE data and pass it to the PC over a COM Port. However, you would still need an application to view and process the data received over that COM Port.
 
We generally recommend customers who are new to Bluetooth Low Energy obtain a copy of Getting Started with Bluetooth Low Energy to help them understand the Bluetooth Low Energy protocol and the GATT table. There are also many resources available online which explain this. 

When Bluetooth Low Energy was first introduced and we launched our BL6xx product line (predecessors to the BL65x series) we produced the BL600 and BL620 smartBASIC Application Walkthrough document, which provides an overview of how Bluetooth Low Energy works and how a GATT table is constructed. 

If you are having issues using the Online Xcompilers it could be related to security settings in your system which may be blocking access to the Online Xcompilers. If you are not able to resolve this it is possible to Xcompile locally by following the steps below:

1. Disable (uncheck) the Online XCompilers on the Config Tab in UwTerminalX as shown below:
2. Locate the Xcomp_mmmmm_xxxx_xxxx.exe file in the firmware zip folder (downloaded from module's Product Page) for the version of firmware loaded to the module.
   Note: the Xcomp version MUST match the firmware version loaded to the module or the application will not compile.
   mmmmm = module
   xxxx_xxxx =Xcomp version
3. Copy or Move the Xcomp_mmmmm_xxxx_xxxx.exe to the same folder the smartBASIC application is stored in as shown below:

You should now be able to Xcompile the application using UwTerminalX by right-clicking in the terminal and selecting one of the Xcompile options :

• Xcompile
• Xcompile+Load
• Xcompile+Load+Run

Select the application from the folder where the Xcomp file is located. UwTerminalX will now look for the local Xcompiler in the application folder.

Yes, any programmer/debugger that supports the SWD 2-wire interface and the Cortex M4F processor should work with the Nordic-based modules. You can find information about the memory map in the nRF5xxxx Product Specification under the Memory and NVMC sections.

In general, cleaning the populated modules is strongly discouraged. Residuals under the module cannot be easily removed with any cleaning process. 

• Cleaning with water can lead to capillary effects where water is absorbed into the gap between the host board and the module. The combination of soldering flux residuals and encapsulated water could lead to short circuits between neighboring pads. Water could also damage any stickers or labels.
• Cleaning with alcohol or a similar organic solvent will likely flood soldering flux residuals into the RF shield, which is not accessible for post-washing inspection. The solvent could also damage any stickers or labels.
• Ultrasonic cleaning could damage the module permanently.

However, if water washing is required you will need to use deionized water. We do not recommend chemical cleaning and cannot guarantee it will not damage the modules. If you MUST clean PCB with chemicals it is recommended that you test on one board and then confirm the module still works after the process, prior to adding it to production, while understanding the above affects washing the populated PCBs can have on the module.

The Bluetooth Low Energy (BLE) concept of “Custom Services and Profiles” means that a developer can customize their product and applications so they are proprietary. In addition, BLE was not originally intended for streaming serial data, rather it was meant to send small packets of sensor data periodically. The BT SIG has not officially adopted a Serial Port service/profile as with Classic BT, so any implementation of VSP or other serial data service or profile will be proprietary to the manufacturer of the silicon or module you are using.

Ezurio has provided VSP for our customers that want to use BLE for simple cable replacement as long as their application data rate does not exceed 10kbps. Ezurio has also defined the VSP Profile which defines how the Peripheral device (BL600) will communicate with the Central device (smartphone/tablet/PC/MAC).

In order to communicate between the BL600 running VSP and a PC (or other Central role device), the PC will need to have an application running on it that recognizes and communicates with the VSP Service on the BL600. For example, a Windows 7 PC does not support BT4.0 / BT4.1 so you would need a BT4.0 USB dongle that incorporates the full BT4.0 stack on the dongle and an application that runs on Windows 7 and fulfills the requirements of a Central role device for Ezurio’s VSP Profile.

Information regarding Ezurio's VSP Profile can be found in the smartBASIC User Guide, which explains what is required when developing a Central Role VSP application.

No, our firmware is not open source.

It is possible to flash the BL600 DVK to bare metal and remove the smart­­BASIC firmware. However, you must provide firmware to support the board’s functionality and Laird is unable to provide support for this. You must go directly to Nordic for such services. Laird only supports Laird firmware and applications written in smart­­BASIC.

If you decide to write your own application or firmware, you must register with Nordic to receive their tools and SDK. All on-going support, in that case, would also need to come from Nordic. Once Laird’s smartBASIC image is erased, we are no longer able to provide support for the module.

For full firmware upgrade instructions, please refer to one of the following firmware upgrade application notes:

Development Kit Firmware Upgrade Guide

Upgrading BL600 Firmware over UART

Please note that a common error is failing to prepare the board to the required settings.  Before a firmware upgrade, you should ensure the positions of the three power switches at the bottom-left of the board are set correctly:

SW4 must be set to "USB"

SW5 must be set to "3V3"

SW6 must be set to "3V3 / 1V8"

The whitelist is automatically populated. When the whitelist filter is enabled, the whitelist is populated from the bonding manager database.

As of firmware v1.2.55.3, smartBASIC may control PWM and FREQUENCY output on up to two GPIO pins. These are implemented using the BL600’s on-board timers, GPIOTE, and PPI channels.

The BL600 license key is a unique number assigned to each BL600 module. It is tied to the random MAC address which Nordic etches into the silicon of the Nordic chip. Laird’s firmware takes that random number and matches it with the license that we program at production time.

If the license key does not match or it does not exist, the firmware operates with reduced transmit power (~4 dBm) and the autorun program in the BL600 flash memory will not run.

For these reasons, it is extremely important that you restore the BL600’s license key after you upgrade the module firmware.

Yes, BL600 smartBASIC programs can be loaded over the air by booting into VSP mode. Please refer to the Virtual Serial Port Service section of the smartBASIC  BL600 extensions document which can be found at this link.

Note the behaviour if a $autorun$ program exists, which may require you to include the ERASEFILESYTEM function in your smartBASIC program to erase any existing $autorun$ program prior to loading a new smartBASIC program.

The 256K of flash is shared by the following components:

1) The BLE software stack from Nordic Semiconductor

2) Laird’s smartBASIC engine

3) File system to store users smartBASIC Application and data files.

4) Non-volatile data store for user to do as they please, see NvRecordSet(), NvRecordGet()

5) The trusted device database which contains thinks line LTK,IRK,CSRK etc

Item (3) is currently 32k bytes.

Item (4) is 4k bytes (but given headers etc, actual effective user data space is about 75% of that).

In our experience, the largest smartBASIC application we have seen is about 20K.

If item (4) is not big enough, Laird recommends that an external I2C or SPI based serial EEPROM be included in the customer design. In this case, you could have about 256kbytes and smartBASIC provides high level API to read/write from I2C or SPI ports. You will not need to write any low level drivers and sample code can be supplied on request.

The BL600 firmware upgrade prodedure is documented in the following application notes, depending on whether you are upgrading via the UART or with the JTAG.

Upgrade over JTAG

Upgrade over UART

A MALLOC_FAIL can occur for 2 reasons.

1. There is no more space in RAM
2. The heap is fragmented*

The latter can be resolved by calling reset() which will reset the module and defragment the heap. If there is enough contiguous memory freed up by the defragmentation, the issue is then resolved.

For the former, you will have to reconsider the use and scope of the variables and structures in your smartBASIC application.

*http://en.wikipedia.org/wiki/Fragmentation_(computing)

Yes. Ezurio encourages all customers to utilize the smartBASIC implementation on-board every BL600 module for ease of use and fastest time to market. Our experts will assist customers on a case-by-case basis to support the Nordic SDK. Please note in these instances software and firmware technical support will need to be provided by Nordic, rather than Ezurio.

Please contact support for further information.

Yes, the Laird Toolkit app contains the BPM, HRM, Proximity, HTM, Serial, OTA, and Batch apps in one easy download.

Any available source code for Laird's Andriod and iOS applications can be found on the BL600 product page under the "Software Downloads" tab.

No. This is not possible because you cannot hide ADV prior to a connection and you can only advertise with ADV_IND (connectable undirected advertising event) before a connection is made. Once connected, you can advertise with ADV_DIRECT_IND (connectable directed advertising event).

Yes, the Laird Toolkit app contains the BPM, HRM, Proximity, HTM, Serial, OTA, and Batch apps in one easy download.

To purchase the BL600 and DVK-BL600, you may contact sales directly or visit one of Laird’s distributors.

The documentation tab of the BL600 page provides the product brief, hardware integration guide, schematics, firmware updates, 3D models, quick start guides, and a collection of application notes for specific topics. It also provides the smart BASIC application library, BL600 utilities, and training videos.

Firmware, schematics and more are part of the Bluetooth Secure Download Center, available for Laird customers. You must register for access. When you have access, visit the BL600 product page and log into the software tab.

Note:  Please remember to FIRST note the module license key, as you will have to restore the license key after the upgrade.

There exist three solutions:

Using the offline XCompiler

• Copy the relvant version of XCompiler (found in the firmware zip file for your relevant firmware version) to the folder that contains your smartBASIC application.
• Say, your XCompiler is called xcomp_bl652_1234_5678.exe and your smartBASIC app is called  jenniferRocks.sb. Then open a command prompt window in that folder and issue the command xcomp_bl652_1234_5678.exe   jenniferRocks.sb and if there are no errors you will see a file called jenniferRocks.uwc being created which is what gets downloaded to the module by UwTerminal.
• In the file name xcomp_bl652_1234_5678.exe The ?bl652? comes from the AT I 0 response and the ?1234_5678? comes from the AT I 13 response

Using the online XCompiler

• Lairds online XCompiler is available at http://uwterminalx.no-ip.org/
• You can upload a SmartBASIC source code file and when successfully compiled, the browser will automatically download the compiled .uwc file.
• Note that compiling with the online XCompiler is limted to a single source code file (#include statements are not supported)

Using the Online XCompiler Tool

• The Online XCompiler Tool is a frontend for our online XCompiler and supports multiple source code files through #include statements. You can select a source code file and the tool automatically compiles it and stores the .uwc locally.

Yes, you can have GND on bottom (or inner layer if the Host PCB is more than a 2 layer board) and top but please be aware that you must connect the two GNDs together by via (regularly placed). Also, solid (meaning less cuts in GND plane due vias going from top to bottom thus cutting area of the GND plane) continuous GND plane is good for EMC as return currents have smaller loop area (lower inductance). 

DIM rc, s$, dn$ DIM ad$:ad$="\01\02\03\04" DIM prAddr$:prAddr$="" DIM advRpt$, scnRpt$ rc = BleScanRptInit(advRpt$) dn$ = BleGetDeviceName$() print "BleGetDeviceName$() : ";dn$ //Add device name to scan Report rc = BleAdvRptAppendAD(s$, 0x09, dn$) rc = BleAdvRptAppendAD(advRpt$,0x31,ad$) print "rc for BleAdvRptAppendAD : ";rc;"

" rc = BleAdvRptsCommit(advRpt$,scnRpt$)  print "rc for BleAdvRptsCommit(advRpt$,scnRpt$) : ";rc;"

" print "

Free space in advert report: ";BleAdvRptGetSpace(advRpt$);" bytes." print "

Free space in scan report: ";BleAdvRptGetSpace(scnRpt$);" bytes." rc = BleAdvertStart(2,prAddr$, 100, 0,0)  

The BT900, BL620, and BL600 all support 128 bit encryption. The radio handles this automatically when you have an encrypted connection. The AesEncrypt function in smarBASIC utilizes 128 bit encryption. For more information regarding this function, please feel free to reference the following smartBASIC Core Guide.

Please run the AT I 4 command in UwTerminal to retrieve the MAC address of the affected module and contact support asking for a license key to be generated and be sure to include the MAC address that you retrieved. You must include the MAC address for our software to generate a new license key.

I am using a BL600 Bluetooth module in my device and I was wondering if there is any way to upgrade the BL600 over BLE? Do you have open protocol to update firmware over BLE? Or maybe you have your own mobile application for upgrading?

Due to memory limitations the firmware (FW) updates cannot be loaded to the BL600 Over-the-Air (OTA) via BLE. Virtual Serial Port (vSP) only provides a serial connection, which streams the information one single bit at time. Additionally, the vSP buffers, located in the RAM only allocate 256 bytes for Rx buffer and 256 for the Tx buffer, which is not sufficient for transferring the firmware update, for subsequent processing of the upgrade on the module. Only smartBASIC applications can be loaded to the module OTA. Therefore, due to the memory limitations, it is not possible to load FW updates OTA. This would require having enough memory on the module for two copies of the FW, which the BL600 does not have. All firmware upgrades must be performed via a JTAG or UART connection as per the attached documents: BL600 Firmware Upgrade over JTAG

BL600-07, which has the latest chip (Nordic HW Variant: nRF51822-QFAA-H0) and firmware (Firmware v1.8.88.0), that the DCDC is not enabled by default. Note: in older modules -06 and older, the DCDC is always forced OFF because Nordic advised us that there was a hardware level issue which got fixed in the latest chip which we deploy in the -07 To enable DCDC the smartBASIC application should have the following line: BleConfigDcDc( 1 ) It is safe to have this line even in older modules because based on the variant at runtime I will force to OFF if it is an older chip.

The following code will run on BL600 and direct advert to BL620 with specific MAC address: dim rc,addr$ addr$ = "\02\D4\F4\6F\CA\C8\E7" ?? ?? ?? //address of specific BL620 rc = BleAdvertStart(1,addr$,100,0,0) WaitEvent I tried direct advert with a smartphone instead of the BL620 but was unsuccessful, this is most likely because the MAC on smartphone changes.

Changing the advertised device name is accomplished using three different functions prior to calling the BleAdvertStart () function.

First, the BleGapSvcInit () function is used to change the device name from the default, Laird [BL600 | BT900], to the desired device name.
Next, the BleAdvRptInit () funtion must be called to create and initialize the advert report with the new device name.
Finally, the BleAdvRptsCommit () function must be called to commit the changes.

Below is an example of a simplified smartBASIC app which changes the default device name to "My Device":
 

//******************************************************************************
// Ezurio
// Rikki Horrigan
//******************************************************************************

//******************************************************************************
//Definitions
//******************************************************************************

//******************************************************************************
//Global Variable Definitions
//******************************************************************************
dim rc     //result code
dim nameWritable
dim nAppearance
dim nMinConnInterval
dim nMaxConnInterval
dim nSupervisionTout
dim nSlaveLatency

//******************************************************************************
// Initialize Global Variable
//******************************************************************************
nameWritable = 0 //The device name will not be writable by peer.
nAppearance = 1091 //Device will apear as Walking sensor on hip (org.bluetooth.characteristic.gap.appearance.)
nMinConnInterval = 500000 // must be smaller than nMaxConnInterval.
nMaxConnInterval = 1000000 //must be larger than nMinConnInterval
nSupervisionTout = 4000000 //Range is between 100000 to 32000000 microseconds (rounded to the nearest 10000 microseconds)
nSlaveLatency = 0 //value must be smaller than (nSupervisionTimeout/nMaxConnInterval)-1

//******************************************************************************
//Functions & Subroutines
//******************************************************************************

//ERROR HANDLER
SUB assertRC(rc, line)
  IF rc != 0 THEN
    PRINT "\nError on line ";line;", code: ";INTEGER.H'rc
  ENDIF
ENDSUB

// Change Device Name

FUNCTION OnStartup()
print "Default Device Name: "; BleGetDeviceName$ ();"\n"
dim deviceName$ //declare variable for DEVICENAME
deviceName$= "My Device" //Set new DEVICENAME
rc = BleGapSvcInit (deviceName$, nameWritable, nAppearance, nMinConnInterval, nMaxConnInterval, nSupervisionTout, nSlaveLatency )
print "\n New Device Name: "; BleGetDeviceName$ (); "\n"

//Create and Initializing the Advert Report (not advertised until BLEADVRPTSCOMMIT is called)
dim adRpt$ //advert report
adRpt$ = ""
rc = BleAdvRptInit(adRpt$, 2, 0, 16)

//Commit the advert report
dim scRpt$ //scan report
scRpt$ = ""
rc = BleAdvRptsCommit(adRpt$,scRpt$)

//Start Advertising
dim addr$
addr$ = ""
rc = BleAdvertStart(0,addr$,100,0,0)

ENDFUNC 1 // Remain in WAITEVENT
//******************************************************************************
//Handler Definitions
//******************************************************************************

//******************************************************************************
//OnEvent Statements
//******************************************************************************

//******************************************************************************
//Equivalent to Main() in C
//******************************************************************************
rc = OnStartup()

Waitevent

The Bx600 Breakout Boards are intended for peripheral mode, BL600 firmware, only. The latest BL600 1.8.88.0 firmware supports UART Bootloader and all future firmware upgrades are done via UART. Unfortunately, BL620 firmware does NOT support UART Bootloader because the version of the Nordic softdevice used in the BL620 firmware doesn't support it. Therefore, BL620 firmware can only be loaded with a JLink. The Bx600 boards do not have a JTAG interface and are therefore designed for peripheral mode (BL600) only. For the central role side we recommend either the  BL620-US USB Dongle or the DVK-BL600.  The DVK-BL600 has a JTAG interface which supports switching between the BL600 and BL620 firmware, as well as the following additional hardware: a temperature sensor, voltage measurement circuit, programmable LED array and push button switches.

The BT900 and BL600 documents refer to the UwTerminal utility which was the primary utility when these documents were written. This utility is still available in the firmware zip files when they are downloaded from the BT900 Product Page or BL600 Product Page .

However, UwTerminalX is the new improved version of UwTerminal offering additional features not available in predecessor UwTerminal. We recommend working with UwTerminalX as it will support all the features mentioned in the BT900 documentation and offer the additional features, such as access to online Xcompilers.

The latest release of UwTerminalX can be downloaded from our GitHub Repository: UwTerminalX/releases


 

smartBASIC is a programming language developed for our BT900 and BL6xx modules to simplify the code required for programming them. It is not used for developing Android or iOS device applications. BLE applications for Android and iOS devices would need to written in code specific to the Android or iOS platform.

Our, Laird Toolkit Application available for iOS and Android is currently in the process of being updated for Android and iOS to work with newer OS platforms.
Once it is complete we expect to make the source code available, to customers working with our smartBASIC modules, for reference when developing Apps for these platforms.
As of the writing of this FAQ the current version of the Laird Toolkit is still available on the App store for iOS and Google Play for Android, however, it may not work with newer versions of iOS or Android until the updates have been made.
Google Play Store
Apple Store

An alternate resource, the Nordic nRF Toolbox is also available from the iOS App Store and Google Play. The source code for this application is available from Nordic's Website.
nRf Toolbox
Android
iOS

Our Bluetooth 5.0 smartBASIC modules (BL652, BL653, BL654) have the capability of supporting LE Secure Connections Pairing as well as encryption. LE Secure Connection is an enhanced security feature introduced in Bluetooth v4.2. It uses a Federal Information Processing Standards (FIPS) compliant algorithm called Elliptic Curve Diffie Hellman (ECDH) for key generation. 
 
LE Secure Connections, supports four association models: 

• Just Works
• Numeric Comparison (Only for LE Secure Connections)
• Passkey Entry
• Out of Band (OOB)

Additional information about LE Secure Connections and the models can be found here: www.bluetooth.com.
 

Our Bluetooth 4.0 smartBASIC modules (BT900 /BL600 /BL620) support Simple Secure Pairing and Encryption 
Additional information about Simple Secure Pairing can be found here:
ezurio.com/resources/newsroom/secure-ble-pairing-iot
ezurio.com/resources/white-papers/ble-and-lairds-bl6x0-series-bt900-modules-guide-security-and-privacy
 
We recommend reviewing the Pairing, Bonding and Security Manager functions in the BL6xx/BT900 smartBASIC Extensions User Guides. The full security of the Bluetooth/Bluetooth Low Energy connection will depend largely on how the smartBASIC application is written, and what the input/output capabilities are of the devices that are connecting. If either device will not have any input/output capabilities then pairing will have to default to Just Works, which is the least secure pairing method. However there are additional layers of security that can be added to increase protection from hacking when the Just Works pairing model is used.

With Bluetooth Low Energy, to further secure the connection, it is recommended that the metadata for the characteristic attributes are configured for Encryption with man-in-the-middle protection for characteristic value access. This will prevent anyone from accessing data on the module without proper encryption keys. (See BleAttrMetadataEx in the BL6xx/BT900 smartBASIC Extensions User Guides.) Additionally, when using Just Works pairing, or any time additional security is required, we recommend adding a challenge/response question to the application layer, with a timer, which expects the connecting device to respond to the challenge question in a specified period of time after a connection has occurred. If the correct response is not received within that time period the application would force a disconnection. Finally, whisper mode pairing can be used during the pairing process as an additional layer of security. This is accomplished by reducing the Tx power while pairing using BleTxPwrWhilePairing as per the BL6xx/BT900 smartBASIC Extensions User Guide, which will reduce the radius which a hacker would need to breach in order to capture or spoof the encryption procedure.