BL5340PA Series Long Range Bluetooth Module

We don't currently support changing the gain of the FEM to lower power with an API. This is not supported in the Nordic driver. The FEM has two calibrated gain settings - one that achieves 20 dBm output and one that achieves 10 dBm output (both with 0 dBm input). However, you can change the output power level as discussed in the following FAQ.

 Can I lower the TX Power on the BL5340 from the maximum set by the FW? (lairdconnect.com)

The power level can lowered at compile time by changing CONFIG_BT_CTLR_TX_PWR_ANTENNA from 20 to x. Power is split into two pieces (nrf53 + FEM).  Most of the granularity in power steps of the nRF53 is used obtain the output required for RF compliance. Therefore, the granularity of any further reductions in output power is limited.

For example, for TX Power = 12, this value is specified via CONFIG_BT_CTLR_TX_PWR_ANTENNA and the driver will try to get as close as it can.

The nRF5340 SoC output power has granularity of 0, -1, -2, -3, -4, -5, -6, -7, -8, -12, -16, -20, -40. However, 0 to -8 may already be used to achieve compliance for 20 dBm output at the antenna.

You will need to specify the antenna type and region in your board file or project configuration file. Based on those parameters, the FW will set the maximum allowable TX power for each channel and modulation.

 The default for the BL5340PA DVK is North America (FCC/IC), using an external antenna.

 Refer to the BL5340PA_manifest link below for details:

 LairdCP/bl5340pa_manifest: Manifest for the Ezurio fork of the nRF Connect SDK with support for the BL5340PA (github.com)
 

Yes, all BT modules include the needed LC filter components required for DC-DC Converter operation.

Lyra P and Lyra S modules include a 2.2uH inductor on VREGSW output and 4.7uF capacitor to ground.

The nRF528xx used on the BL65x modules use two voltage regulators, REG0 and REG1. In Normal Voltage mode only REG1 is enabled. In High Voltage mode both REG1 and REG0 are enabled. The BL65x modules include 10uH and 15nH inductors on DCC output and 1.0uF capacitor to ground on REG1. REG0 includes a 10uH inductor on DCCH output and 4.7uF cap to ground.

Note: The BL651 module uses the nRF52810 which uses a single voltage regulator. The BL651 includes 10uH and 15nH inductors on DCC output and 1.0uF capacitor to ground.

The nRF5340 used on the BL5340 and BL5340PA modules uses four voltage regulators, Main Voltage Regulator, Radio Voltage Regulator, High Voltage Regulator and a USB Regulator. In Normal Voltage mode the Main Voltage and Radio regulators are enabled while the High Voltage Regulator is disabled. In High Voltage mode the High Voltage regulator is enabled along with the Main Voltage and Radio regulators. The BL5340 module includes a 10uH inductor on the DCC outputs and 1uF capacitor to ground on the Main Voltage and Radio Voltage regulators. The High Voltage regulator includes a 10uH inductor on the DCCH output and 2.2uF capacitor to ground. The USB regulator uses an LDO only an no DC-DC filter components are needed.

As per section 3.7 of the BL5340/BL5340PA datasheets (links provided below) , these modules ship with no firmware loaded. Therefore, there is no Bootloader loaded to enable loading applications via UART and no support for FOTA (Firmware Over-the-Air) updates. It will be necessary to bring out the SWD interface on the PCB to enable programming the module with Nordic's nRF Connect SDK which uses the Zephyr RTOS platform. Once the Bootloader and/or FOTA firmware have been loaded to the module it should be possible to load future firmware updates via the UART or FOTA methods. See the Nordic DevZone for additional information on Bootloader and FOTA firmware options.

Datasheet - BL5340 Series
Datasheet - BL5340PA Series

The BL654PA module has not been certified in EU as regulatory restrictions limit TX Power spectral density to +10dBm/1 MHz. The same requirements are true for the BL5340PA, but this module will achieve regulatory approvals in the EU with TX Power set below +10dBm.

Operating a radio device in the 2.4GHz frequency band there apply certain regulatory requirements with regards to the maximum usable TX output power. It ultimately comes down to the RF power spectral density instead of a flat maximum TX power value.

ETSI EN 300 328 technically allows for 20dBm RF output power for equipment when Adaptive Frequency Hopping (AFH) and at least 15 channels are available. The only limitation is maximum 20 dBm for equipment meeting these requirements. However, the Nordic SoftDevice or nRF Connect SDK SoftDevice Controller does not provide a means for AFH. In this case the Power Spectral Density must be tested which limits the maximum radiated power to 10dBm/MHz.

While technically it would be possible to offer a module in the EU that can operate >10dBm, there are many hurdles in implementation that would increase development effort and cost.

With nRF Connect SDK v2.0.0 and later only VS Code is made available as an IDE as VS Code provides many features including both Command Line Interface (CLI) and Graphical User Interface (GUI) in one environment.

Prior to nRF Connect SDK, the 32.768KHz source in nRF5 SDK applications defaulted to using the external crystal oscillator. The BL65x DVK’s populate an external 32.768KHz crystal but it is not connected via open solder bridges. Therefore, either the solder bridges need to be shorted to make the external crystal connection or change the clock source to internal RC Oscillator via the sdk_config.h file.

With nRF Connect SDK the correct 32KHz clock source is selected depending on the EVK. For BL654 DVK examples are built using internal RC oscillator. On BL5340 DVK the external crystal oscillator is selected as the DVK does close the solder bridge pads.

If the 32KHz clock source needs to be changed an application can change accordingly in the prj.conf file of the project. The following direct dependencies need to be added to prj.conf to override the default clock configuration.

External Crystal Oscillator and accuracy selection:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_XTAL=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_50PPM=y

Internal RC Oscillator and accuracy selection:

CONFIG_CLOCK_CONTROL_NRF_K32SRC_RC=y

CONFIG_CLOCK_CONTROL_NRF_K32SRC_500PPM=y

Kconfig dependencies can be found:

https://developer.nordicsemi.com/nRF_Connect_SDK/doc/2.3.0/kconfig/index.html

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. 

The NFC track does not need to be routed with a controlled differential impedance. The NFC antenna is different from the BLE antenna as it's differential and not 50 Ohm (each track is 50 Ohm single ended). Also, the frequency is very low, so the exact impedance doesn't matter as much. The inductance in the antenna is what matters for the NFC antenna. Since the antenna is differential, it's better to use a two-pin connection instead of U.FL which is a single ended connection. 

The inductance of the antenna together with the NFC antenna tuning capacitors forms a resonant circuit that is tuned to the NFC frequency, 13.56 MHz. Any change in the connection wires to the antenna can be compensated with the tuning caps.
 

For VQ (voice quality) at 8-bit 24kbps with 3 retransmissions. 4 is possible. Limiting factor is CPU processing of LC3 encode. OTA (over-the-air) bandwidth has room for more channels if you consider an additional CPU for LC3 processing.

Note Ezurio maintains a partnership with Packetcraft for LE Audio SW Solution.

https://www.packetcraft.com/

Yes, every module can handle 4 channels. Additional modules may be used for additional channels. But there are RF interference concerns with the higher number of transmitters from additional modules. Possible to coordinate the modules so they do not interfere but may need to consider something more sophisticated to coordinate the devices to maximize the 2.4GHz spectrum.

Note Ezurio maintains a partnership with Packetcraft for LE Audio SW Solution.

https://www.packetcraft.com/
 

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.