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.

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

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. 

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.

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.

When a peer device writes to a characteristic, you'll get a BLE_GATTS_EVT_WRITE event.

It is currently not an option to remove it as it is mandated in the Bluetooth spec, at table 12.2 chapter 12 Vol 3 Part C Bluetooth v4.2

When you scan for advertisements you get the peripherals MAC address as part of the function return for BleScanGetAdvReport(). You are able to use this value to decide which adverts to listen to and which to discard. To do this you will need to filter it similarly to the smartBASIC app show below where the first byte of the MAC is "000C".

We recommend using de-ionized water. Additionally, we recommend avoiding any sonic vibration, heat, and pressure washing as well as any other soaps/chemicals.

Is it possible to use nRF51 sniffer to sniff BLE extension packet? It can use the nRF51 sniffer to see the MTU packet exchange (the iPhone will show the maximum packet length in this message) but any data packets with a length greater than 23 bytes after this will appear as garbage because the nRF51 hardware cannot handle the larger packet sizes

You can use the SPRINT function to convert your hex to decimal. Please review page 69 of the smartBASIC Core Manual for a description of how to use the SPRINT function. As an example, to convert 0004D2 to its decimal value of 1234, your code would look like this: DIM a, s$ : a=0x0004D2 SPRINT #s$,INTEGER.D'a print s$

No driver needs to be loaded onto the the Raspberry Pi as it already has an FTDI driver in the Raspbian Linux OS. Insert your BL620-US into a USB slot on your Raspberry Pi and enter the ls /dev/tty* command in a terminal session to see all of the available device names. Identify a device called "ttyACM0" and confirm this is the BL620 by removing the BL620-US and then doing the ls /dev/tty* command again to ensure the "ttyACM0" device is no longer in the list. To access the BL620-US simply open the device in the exact same way as you would for a Serial Port, "COM4" for example .

 A connection to a module in UwTerminal is not required to XCompile a smartBASIC app.   To XCompile without a UwTerminal connection:   Copy the relevant version of Xcomplier to the folder that contains your smartBASIC application. The XCompiler will be located in the firmware download folder found on your specific products product page. It is important you use the XCompiler file from the firmware version you are using on the module the app will be running on. In this example our xcompiler is called  xcomp_bl652_1234_5678.exe and your smartBASIC app is called  LairdRocks.sb   Next, open a command prompt window in that folder and issue the command: xcomp_bl652_1234_5678.exe   LairdRocks.sb You will see a file called LairdRocks.uwc being created which is what gets downloaded to the module when using UwTerminal.    

If your data is arriving in the form of a hex string, you first need a routine to extract the characters you wish to convert to decimal. In this example, we will be converting 6 bits that arrive in a string from hex to decimal. These bits will be characters 57-62 in our 56 byte data package. For that, we'll need: StrSubCommand$ = MID$(StrCommand$, 57, 6) You then need to reverse the string, there is no function that does this in smartBASIC, but you can do this programmatically using a FOR loop, a pseudocode example would be as follows:  StrReversedSubCommand$ = "" FOR i=STRLEN(StrSubCommand$) DOWNTO 1     StrReversedSubCommand$ = StrReversedSubCommand$ + MID$(StrSubCommand$, i, 1) NEXT  We then want to convert this string hex into a decimal (i.e. from "0004D2" to "1234"), and for that we'll need a some code and the use of the StrHex2Bin smartBASIC function as follows:-  DecimalValue = StrHex2Bin$(StrReversedSubCommand$, 0)*65536 + StrHex2Bin$(StrReversedSubCommand$, 2)*256 + StrHex2Bin$(StrReversedSubCommand$, 4)

The BL620-US dongle has a Segger J-Link chip on board; when you connect the dongle to your computer, it searches for the relevant driver which can be obtained from https://www.segger.com/downloads/jlink/. You will need the serial number printed on the underside of your dongle next to the text SEGGER # to be able to download the driver from the Segger website. Please reference the BL620 Quick Start Guide for additional information about installing the dongle. As of the writing of this document the J-Link Drivers could be located here.

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.

iOS devices will not pair with BLE devices unless one of the device's characteristics specifies that encryption is required. Apps need to provide their own UI for the user to discover and select the BLE peripheral they want to work with, this is because the app knows what service(s) are required for the app while iOS Bluetooth settings does not. Even when pairing of BLE devices is performed it is still initiated through the app. Bluetooth settings is used to "forget" the device (remove the stored encryption keys). However, it seems that iOS does list BLE devices when they advertise some of the BT SIG adopted services such as the Heart Rate service. By advertising this service you can get your device visible in the Bluetooth Settings page..

The BL600 does not support parity on the UART, it only supports 8-N-1.

The responsibility for providing the QDID for a host system is with the provider of the stack that is used on that system. If for instance the host system uses a module that requires the Bluetooth stack to run on that system (e.g. Lairds Sterling-LWB in a Linux platform) the QDID must be provided by the stack vendor who's stack is running on that Linux platform. Challenges might occur when an open-source, community based stack is used. If a module with integrated stack us used (e.g. Lairds BL652) the QDID is provided by the module vendor.  

smartBASIC does not have a forward declare ability in the general sense of the term but you are able to declare a function in a .sblib file and then call that function in another .sb file as long as you #include the .sblib file the function is stored in. Many of our smartBASIC modules sample apps use this functionality for easier programming between product lines. You can see an example of this in the "htss.health.thermometer.sensor.custom.sb" file in the Library Import section of the code.

When a variable is declared, smartBASIC only reserves space in memory for that variable. If you need it initialized to zero you will need to explicitly set it to 0. Also, should you need a variable to persist past a functions runtime, it must be declared globally.

No event should have priority over another. The events are handled in a first in first out methodology so whatever event triggers first, the firmware will handle it and then move to the next event in the queue.

While the BL600 and BL652 both have similar functionality and work with smartBASIC, the process for entering Direct Test Mode (DTM) is totally different.  Ezurio customers requiring the capability to enter DTM for the purposes of certification should contact support or their Territorial Sales Manager to request the required file(s) and procedure(s).

The factors to confirm when checking the soldering job on Bluetooth modules are solder stencil aperture size, solder stencil thickness, solder ball size, solder type, and the MSL guidelines. If the parts have been left out for too long then the modules should be baked to remove any moisture prior to soldering. If there are any failures, we highly recommend providing an x-ray of the module.

If using UWTerminalX, click on the config tab and press the error codes button. You can now look up the meaning of any error code. If using an older version of UWTerminal just highlight an error code, right-click it, then select ?Lookup Selected ErrorCode?. We strongly recommend downloading the latest version of UWTerminalX from https://github.com/LairdCP/UwTerminalX/releases which provides many improvements over the older UWTerminal.

We only recommend reflowing our modules once as it can damage the module and void the warranty.

Ezurio provides 3D files (STEP) files for most but not all of it's modules.  Based on the nature of the information in the files, in most cases Laird requires a login to access these files as well as layout files and software/firmware downloads.  As such, for most modules, the 3D files are found under the Software Downloads tab of the product page.  The page offers a credentials request link for customers who need credentials.  In most cases, the credentials are provided via return email within about 10 minutes. Please contact support if you have any additional questions or have any issues accessing our downloads.

Your URL may be too long. We are limited to 31 bytes, including flags, etc in a beacon. If your URL exceeds this length it will not be populated in the advert or scan. We recommend shortening your websites URL with a URL shortening service such as https://bitly.com/ or https://goo.gl/ and using the unique URL generated from this site for your beacon.

We highly do not recommend conformal coating the radio module. If you plan on encapsulating the radio module in a potting compound or conformal coating, you must assure that the compound in liquid or solid form does not enter under the shield where there are sensitive RF components. Some of the capacitive and inductance values are as low (pF and nH) and could be sensitive to contacting materials such as potting compounds. There are potting compounds and conformal coatings which have very good dielectric constants and are suitable for 2.4 GHz potting applications, however, when you apply any of these, they were not accounted for in the circuit design and might reduce performance of the device (or all together cause it not to function).  You should run tests on their particular potting compound and evaluate radio's performance and range.  Also, it's worth mentioning that applying any compound, conformal coating or potting directly to the module WILL void the warranty. If your application requires 100% sealing of the radio module, there is a way to do this very successfully without impacting the module performance. Simply place the module on your PCB. Place a plastic cover over the module (like a hat), make the cover large enough to cover the whole module. Apply glue around the bottom perimeter of the cover where it sits on the PCB. This allows the module to function in free air-space while there is a complete seal around it. This information is only for reference and we recommend you should conduct your own testing with your prototype of your end application to find the best suitable fit for your design.  

The most common reason for this error is that the host platform running UWTerminalX cannot establish a connection via the internet for the repository to access the correct/matching Xcomp (cross-compiler) file. UWTerminalX avoids the issues encountered by users of UWTerminal where errors would be encountered when the matching Xcomp file was not found locally. UWTerminalX has access to all Xcomp versions and can therefore compile any smart BASIC script regardless of firmware version and without requiring user action. Ensure that the host is connected to the internet and is not blocked from accessing the correct Xcomp file or that the file is stored locally. There is a check box on the Configuration tab of the utility that allows you to select Compile Online or Compile Locally. Local copies of the Xcomp file should be stored in the same folder as the .sb script, the same folder as the UWTerminalX utility, or in a sub-folder of either.

Yes it is possible that Laird's BLE modules could be utilized in a end device that is certified as"Intrinsically Safe". We do not currently have any end customers doing this with all of Laird's BT/BLE modules, some of our BT/BLE modules have been successfully certified by our customers. As a valuable point of information, Intrinsically Safe certifications are detailed and extensive, requiring NDA restricted information on our modules which we can support based on the commercial opportunity. The detailed analysis and testing of the end production solution is the responsibility of the end customer working with their certified test house. 

UwTerminalX uses online cross-compiling to compile smart BASIC code. This error is displayed when an internet connection is not present. Connecting to the internet should resolve this issue. If an internet connection is not possible, navigate to the Config tab in UwTerminalX and uncheck the Online XCompile box found in the lower right corner. You will need to compile your smart BASIC code locally with the cross compiler that is found in the firmware download folder which is available on the product pages under the Software Downloads tab of the Laird Connectivity website. The Xcomp file must located in the same folder as your smart BASIC code to allow for proper cross compiling.

Ezurio provides layout files PADS and PADS ASCII formats. The ASCII files will import to Altium (and Protel varients) as well as Cadence (Orcad and Allegro) CAD packages. As far as we know, there is no way to import to Eagle CAD. Please be sure to use the .asc file for PCB and the .txt file for the schematic when importing to Altium. Ezurio uses ORCAD for schematics (Gerbers). 

The recommended cleanser is "hydrocarbon cleaning oil", which can be used to clean the RF shield and PCB. We do not recommend the use of alcohol as it doesn't work as well and could leave residue on the boards.  

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.

Once the uart is closed, the RX pin is not controlled by the smartBasic application. The firmware can no longer detects the UART break until the UART is opened.

Besides what mentioned in core manual, yuo should check if the uart is already before calling uartclose. You should also check if there is any remaining data in the uart tx buffer.  

When you do "read" right after "write" at the same address, it is possible you might need to add a "delay" in between. You should check the chip datasheet to determine the min. delay value.

FRM_PLATFORM_MISMATCH - what does error mean? You are trying to loading firmware to non-matching platform, Please make sure you had downloaded the right firmware from our website.

When a Gatt client writes a Gatt server, the server will give a write response. When a server notifies a GATT client, the client does not give an ack. That's why "write" is always slower than "notify" when it comes to throughput measurement. 

There are three factors affecting BLE throughput: Connection intervals - This is how often the radios talk. The min value varies from 7.5 ms to 50 ms depending on the hardware and stack. Number of packets per interval - It can be as many as six packets per interval. It depends on the stack and hardware. Packet payload - 20 bytes is typical.

No. 1Mbit is just the modulation frequency for BLE packets.    

No. The APIs are in read / write operation, and will append the op bit to the 8 bit address.

In order to pull the Device Name of the BL600 from the Ad Element you could use either the BleGetADByTag () function or the BleAdvRptAppendAD () function. For example to place the local name into a scan report use: rc=BleAdvRptAppendAD(scnRpt$,0x09,DeviceName$) The 0x09 argument is the "Data Type Value" of the Generic Access Profile Reference the Bluetooth SIG for the nTag argument values: https://www.bluetooth.org/en-us/specification/assigned-numbers/generic-… ) Descriptions of the data types can be found in the "Supplement to the Bluetooth Core" Specification which can be downloaded from the Bluetooth SIG link below: https://www.bluetooth.org/DocMan/handlers/DownloadDoc.ashx?doc_id=302735 An example of a script using the BleGetADByTag function is the adscan.advert.display.sb Sample App which is available from the GitHub - Laird BL620 Sample Apps folder: https://github.com/LairdCP/BL620-Applications/blob/master/adscan.advert… Notice how this script extracts each of the AD types and then prints the results to the UART In particular this part of the code pulls the data in 0x08 or 0x09 data types from the Ad Element. //Advert not seen before - get device name ? ? rc = BLEGETADBYTAG(advData$, 8, TmpStr$)?? ? ? if (rc == 0) then ? ? //Name found at index 0x08 ? ? PRINT TmpStr$;"

" ? ? else ? ? //Name not found at index 0x08, check 0x09 ? ? rc = BLEGETADBYTAG(advData$, 9, TmpStr$) ? ? if (rc == 0) then ? ? //Name found at index 0x09 ? ? PRINT TmpStr$;"

" ? ? else ? ? //Name not found ? ? PRINT "[Device Name Not Found]

" ? ? endif ? ? endif

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.

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

If you call the smartBASIC function "SysInfo$ and set it to 4, it will print out the Bluetooth address of the module. If you set that function to 14, it will show the random public address unique to this module. It may be the same value as the above 4 value unless AT+MAC was used to set an IEEE mac address. However, the output from SysInfo$ is in hex with delimiters. With that in mind, the terminal interprets it as an ASCII character. Before printing, you would need de-hexize the string with the function ?strhexize$(s$)?. Please note that you will need to define ?s$?. This is described below: dim s$ : s$ = sysInfo$(4) PRINT strhexize$(s$) PRINT "

SysInfo$(4) = ";SysInfo$(4) // address of module PRINT "

SysInfo$(14) = ";SysInfo$(14) // public random address PRINT "

SysInfo$(0) = ";SysInfo$(0)

The default baud rate cannot be permanently changed on smartBASIC modules as any changes made to the baud rate do not persist through a power cycle. However, you can create a 2 line smartBASIC script that will change the baud rate. This script can be set to autorun every time the module is booted. Once the script has run the module will drop back into interactive mode with the new baud rate you specified in your application. The two lines are as follows UartClose() UartOpen(YOUR_BAUD_HERE) This file should be named using our autorun naming convention of $autorun$.your.file.name.sb and your module should be set up to be in autorun mode.

While we have not implemented specific Watchdog functions in smartBASIC, a work-around can be achieved by having external circuitry that if not ticked causes the external circuit to reset the module. You could program a timer in smartBASIC that toggles a GPIO, so that it resets a timer in an external circuit preventing it from expiring and resetting the module. If smartBASIC falls over for any reason, then the external circuit never gets ticked and therefore goes ahead and reset the module. However, that workaround depends on the external circuitry you wish to implement for your application.

Peripheral device(e.g. BL600) needs to allow bonding by using BleSecMngrBondReq(1). Central device(e.g.BL620) can implement BLePair(conHndl, 1) to enable pairing with bonding forced upon established connection.

The name of the .sb file is allowed to contain up to 23 characters.

Include the following code in the smartBASIC script: '//****************************************************************************** '// Function and Subroutine definitions '//****************************************************************************** '//debug Subroutine Sub DbgAssertRC(byval tag as integer) ? if rc != 0 then ? ? print "

Failed with "; integer.h' rc;" at tag "; tag ? endif endsub '//User will insert 'DbgAsserRC()' in code to assist when error(s) may occur.

'//****************************************************************************** '// Library Import '//****************************************************************************** '// Insert path of the smartBasic library (file extension: '.sblib') in this section. '// For library in same folder as the script ex: '// #include "advert.report.manager.sblib" '// For library in a different folder ex: '// #include "lib\cli.health.thermometer.custom.sblib" '// Once the library is set, user should be able to call functions and subroutines from this library to their new sB script. '//******************************************************************************

The BL6x0 has very fine pitched pads and if too much or not enough solder paste is applied, this can cause an issue. Stencil thickness and number of passes used to apply the solder paste using the stencil should be controlled. In our own manufacturing process we have found that a 5 mil stencil with a single pass of solder paste is the best process to use.

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 smart BASIC app which changes the default device name to "My Device": //****************************************************************************** // Laird Technologies // Rikki Horrigan //****************************************************************************** //****************************************************************************** //Definitions //****************************************************************************** //****************************************************************************** //Global Variable Definitions //****************************************************************************** dim rc ? ? //result code dim nameWritable dim nAppearance dim nMinConnInterval dim nMaxConnInterval dim nSupervisionTout dim nSlaveLatency //****************************************************************************** // Initialisse 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 "

Error on line ";line;", code: ";INTEGER.H'rc ? ENDIF ENDSUB // Change Device Name FUNCTION OnStartup() print "Default Device Name: "; BleGetDeviceName$ ();"

" dim deviceName$ //declare variable for DEVICENAME deviceName$= "My Device" //Set new DEVICENAME rc = BleGapSvcInit (deviceName$, nameWritable, nAppearance, nMinConnInterval, nMaxConnInterval, nSupervisionTout, nSlaveLatency ) print "

New Device Name: "; BleGetDeviceName$ (); "

" //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

Laird's BLE devices running smartBASIC will run programs written with a .sB file extension which must first be compiled with Laird's UWTerminal or UWTerminal X and the correct cross-compiler which will generate the program with a .uwc file extension.

While it is theoretically possible to send the update to the uC and then from the uC via UART to the BT900/BL6xx, in practice this operation has proved very difficult to perform successfully. Customers who have attempted this have found adding a UART header connection to connect a host directly updating to be the more easily implemented solution.

No. OTA is based on the BL600/BT900 built-in VSP function, and it will only work on Peripheral devices. VSP requires a Central role connect to it. It cannot actively connect to other another BLE devices.

Once an application is compiled, it will generate a file with "uwc" as the extension. User can load the file to the modules (BL600/BL620/BT900) with AT commands over the UART, or over the air for modules (BL600/BT900).

No, the BT900 must run smartBASIC and while the device's programming can be controlled from a separate microController, smartBASIC must be run on the BT900 to at least control the I/O's.

On Android, nRF Connect is a very useful and powerful generic BLE tool that lets you observe adverts, connect to devices and exchange data with a GATT server. 

For iOS, BLExplr provide similar functionality to MCP but is not free. It is also possible to use Wireshark in conjunction with a BL600/620 dev board or BL620-US running special sniffer firmware to provide over the air (OTA) sniffing functionality. Please contact support  for more information on setting up a BLE sniffer.

No the autorun pin (SIO_28) is not exposed on the BL620-US and it is assumed there will be a host capable of sending a command to run a smartbasic program on the BL620-US.

A GATT Server is a device which stores attribute data locally and provides data access methods to a remote GATT Client paired via BLE. A GATT Client is a device which accesses data on a remote GATT Server, paired via BLE, using read, write, notify, or indicate operations. Once two devices are paired each device can act as both a GATT Server and a GATT Client.

Indications and Notifications are a way for a GATT Client to subscribe to data provided by a GATT Server. A Notification is an unacknowledged message or update while an Indication is an acknowledged message or update. These Notifications and Indications are sent any time the relevant data in the GATT table on the GATT Server is updated. (You must "subscribe" to the data that you would like to be Notified or Indicated of) In a way Indications and Notifications are much like TCP and UDP packets. TCP requires that when data is sent, the receiver acknowledges that the data has been received by sending back an ACKnowledgement packet. UDP just sends off data without any concern whether it is actually confirmed to be received or not. In this sense Indications are akin to TCP and Notifications are akin to UDP.

Bonding is pairing AND saving of the Long Term Key(LTK) for a later connection where as pairing will not save a LTK for future connections.

Due to limitation of stack and ram, BL600/BL620/BT900 allows maximum of 20 bytes for data to be sent at a time. It is up to the app developer to ensure that the data goes out in max chunks of 20 bytes.