P ROTEUS -III REFERENCE MANUAL 2611011024000 V ERSION 0.
Revision history Manual version FW version HW version 0.11 1.0 1.1 Notes • Initial release Date November 2019 ? For firmware history see chapter Firmware history Proteus-III reference manual version 0.11 www.we-online.
Abbreviations and abstract Abbreviation Name Description Bluetooth® conform MAC address of the module used on the RF-interface. BTMAC CS Checksum ® Byte wise XOR combination of the preceding fields. BLE Bluetooth Low Energy According to Bluetooth® specification. BT Bluetooth® According to Bluetooth® specification. DSSS Direct sequence spread spectrum Technique to spread a message on the radio DTM Direct test mode Mode to test Bluetooth® specific RF settings.
Contents 1 Introduction 1.1 Operational description 1.1.1 Key features . . 1.1.2 Connectivity . . 1.2 Block diagram . . . . . . 1.3 Ordering information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Electrical specifications 2.1 Recommended operating conditions 2.2 Absolute maximum ratings . . . . . . 2.3 Power consumption . . . . . . . . . . 2.3.1 Static . . . . . . . . . . . . . 2.3.2 Dynamic . . . . . . . . . . . 2.4 Radio characteristics . . . . . . . . . 2.
7 The command interface 7.1 Scan for other modules in range . . . . . . . . . . . . . . 7.1.1 CMD_SCANSTART_REQ . . . . . . . . . . . . . 7.1.2 CMD_SCANSTOP_REQ . . . . . . . . . . . . . . 7.1.3 CMD_GETDEVICES_REQ . . . . . . . . . . . . . 7.1.3.1 Example 1 . . . . . . . . . . . . . . . . . . . . 7.1.4 CMD_RSSI_IND . . . . . . . . . . . . . . . . . . 7.1.5 CMD_BEACON_RSP . . . . . . . . . . . . . . . . 7.2 Setup connections . . . . . . . . . . . . . . . . . . . . . . 7.2.1 CMD_CONNECT_REQ . . . . . . . . .
7.6 7.7 7.8 7.9 Run the Bluetooth test modes . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.1 CMD_DTMSTART_REQ . . . . . . . . . . . . . . . . . . . . . . . . 7.6.2 CMD_DTM_REQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.6.2.1 Example: Transmission, 16 times 0x0F, channel 0 . . . . . . . 7.6.2.2 Example: Receiver, channel 0 . . . . . . . . . . . . . . . . . . . 7.6.2.3 Example: Transmission, carrier test, channel 0 . . . . . . . . . 7.6.2.4 Example: Set TX power to -4 dBm . . . . .
8.5 8.6 8.7 8.8 8.9 8.10 8.11 8.12 8.13 8.14 8.15 8.16 8.17 8.18 8.19 8.20 8.21 FS_SerialNumber: Read the serial number of the module . . . . . . . . . 8.5.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . RF_DeviceName: Modify the device name . . . . . . . . . . . . . . . . . . 8.6.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8.6.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
.22 8.23 8.24 8.25 8.26 8.27 8.21.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . DIS_ManufacturerName: Configure the manufacturer name 8.22.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . 8.22.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . DIS_ModelNumber: Configure the model number . . . . . . 8.23.1 Example 1 . . . . . . . . . . . . . . . . . . . . . . . 8.23.2 Example 2 . . . . . . . . . . . . . . . . . . . . . . . DIS_SerialNumber: Configure the serial number . . .
14.2 Firmware update using the Proteus-III OTA bootloader . . . . . . . . . . . . 174 14.2.1 Firmware update steps using the Nordic nRF Toolbox app . . . . . 176 15 Firmware history 178 16 Design in guide 16.1 Advice for schematic and layout . . . . . . . . . . . . . . . . . . . . . . . . 16.2 Dimensioning of the micro strip antenna line . . . . . . . . . . . . . . . . . 16.3 Antenna solutions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16.3.1 Wire antenna . . . . . . . . . . . . . . .
22.4 22.5 22.6 22.7 22.8 Exemption clause . . . . . . . . . . . . . . . . FCC Compliance Statement . . . . . . . . . . IC Compliance Statement . . . . . . . . . . . FCC and IC requirements to OEM integrators 22.7.1 Pre-certified antennas . . . . . . . . ARIB Declaration of conformity . . . . . . . . 22.8.1 Label . . . . . . . . . . . . . . . . . . 22.8.2 Certified antennas . . . . . . . . . . 23 Important notes 23.1 General customer responsibility . . . . . . . . 23.
1 Introduction 1.1 Operational description The Proteus-III module is a radio sub module/device for wireless communication between devices such as control systems, remote controls, sensors etc. . On the basis of Bluetooth® Low Energy 5.0 it offers a fast and secure data transmission of data packages between two or more parties (point to point topology). A serial interface (UART) is available for communication with the host system.
High throughput mode: The Proteus-III contains the so called "High throughput mode" that allows to send up to 4 data packets per connection interval. This increases significantly the throughput. This mode and its usage is described in Proteus-III - Application Note 4". All BLE roles supported: The integrated BLE stack supports all BLE roles. Depending on the current state of operation the Proteus-III firmware automatically switches its role to execute the user’s instructions.
1.2 Block diagram Figure 1: Block diagram of the module 1.3 Ordering information WE order code Description 2611011024000 Proteus-III Bluetooth® Smart Module, Tape & Reel 2611011024009 Development Kit including 3×Proteus-III 2611019224001 Bluetooth® Smart Evaluation Board with Proteus-III Table 1: Ordering information Proteus-III reference manual version 0.11 www.we-online.
2 Electrical specifications As not otherwise stated measured on the evaluation board Proteus-III-EV with T=25°C, VDDS=3V, f=2.44GHz, internal DC-DC converter in use. 2.1 Recommended operating conditions Description Min. Typ. Max. Unit Ambient temperature -40 25 85 °C Supply voltage (VDDS) 1.8 3 3.6 V 60 ms Supply rise time (0V to ≥ 1.
2.3 Power consumption 2.3.1 Static Continuous test mode Min. Typ. Max. Unit TX current consumption at +8 dBm 16.41 mA TX current consumption at 0 dBm 6.41 mA 1 RX current consumption 6.25 mA Sleep (system off mode) 0.4 µA TX current consumption at +8 dBm 18.92 mA TX current consumption at 0 dBm RX current consumption 8 2 7.
Figure 2: Radio transmitting @ 8 dBm output power, 1 Mbps BLE mode, Clock = HFXO, Regulator = DC/DC (typical values) 2.3.2 Dynamic Besides the static TX, RX, idle and sleep current the average current is of interest. Here an example for a typical behavior of a peripheral device in advertising mode (see Figure 3). Currents and state durations are dependent on the configuration of the module. In this state the module transmits the advertising packets on the 3 advertising channels.
Figure 3: Current consumption calculation in advertising mode with 40ms advertising interval with 8 dBm output power, UART disabled 2.4 Radio characteristics 50Ω conducted measurements from nRF52 data sheet Proteus-III reference manual version 0.11 www.we-online.
Description Min. Output power -40 Max. Unit +8 dBm -951 Input sensitivity (≤ 37 Bytes, BER=1E-3) RSSI accuracy valid range (±2dB) Typ. dBm -90 -20 dBm Enable TX or RX delay 140 µs Enable TX or RX delay (fast mode) 40 µs Disable TX delay 6 µs Disable RX delay 0 µs Table 5: Radio parameters 2.5 Pin characteristics Measurements from nRF52 data sheet Description Min. Input high voltage Typ. Max. Unit 0.7 ×VCC VCC V Input low voltage VSS 0.3 ×VCC V Current at VSS+0.
ANT 1 RF 18 GND SWDCLK SWDIO /CTS /RESET /RTS URXD B3 8 13 B6 BOOT VDD GND WAKE_UP B1 marked pins are RESERVED 3 Pinout UTXD 12 9 LED_2 LED_1 BUSY MODE_1 Figure 4: Pinout (top view) Proteus-III reference manual version 0.11 www.we-online.
No µC Pin Designation I/O 1 ANT Input RF connection to PCB antenna (see section 4.2) 2 RF Output 50Ω RF connection to external antenna or onboard antenna via ANT (see section 4.2) 3 GND Supply Ground 4 6 7 Input Serial wire clock (SWD Interface). Uses internal pull down resistor. Do not connect if not needed. SWDIO Input Serial wire input/output (SWD Interface). Uses internal pull up resistor. Do not connect if not needed. /RESET Input Reset pin. A low signal resets the module.
No 16 17 µC Pin P0.12 P0.03 18 Designation I/O Description Input /CTS signal, if flow control is enabled. Using internal pull down1 , otherwise. Do not connect if not needed. WAKE_UP Input Wake-up will allow leaving the system-off mode or re-enabling the UART. Uses internal pull up resistor1 . Do not connect if not needed. GND Supply Ground /CTS B1 P0.09/NFC12 B1 GPIO Pin for remote GPIO access. Do not connect, if not needed. B2 P0.10/NFC22 B2 GPIO Pin for remote GPIO access.
4 Quick start 4.1 Minimal pin connections 4 /RESET 1 VDD VDD ANT 3 RF UTXD 2 Host Controller URXD 7 RTS/CTS Proteus -III 5 WAKE_UP/BOOT/MODE_1 8 1 GND SWDIO/SWDCLK 6 BUSY/LED_1/LED_2 Figure 5: Minimal pin connections The above image shows the steps to be performed to integrate the Proteus-III into a custom end device. 1. Supply voltage and ground First of all, connect the VDD and GND pins to supply the radio module with power. 2.
• Connect the MODE_1 pin to the host controller to switch between command and peripheral only mode. 6. (Optional) Status indication Connect the BUSY, LED_1 and LED_2 pins to the host controller to allow easy indication of the status. 7. (Optional) UART flow control Connect the /RTS and /CTS pins to the host controller in case the UART flow control shall be used. This is mandatory for fast UART baud rates. 8.
4.3 Power up After powering the module the /RESET pin shall be hold for another ∆t of 1ms after the VDD is stable to ensure a safe start-up. The module will send a CMD_GETSTATE_CNF to indicate "ready for operation" after the /RESET pin was released. Applying a reset (e.g. a host temporarily pulling the /RESET pin down for at least 1ms and releasing it again) after the VCC is stable will also be sufficient. Figure 6: Power up Proteus-III reference manual version 0.11 www.we-online.
4.4 Quickstart example This section describes how to quick start the data transmission between two Proteus-III modules. The goal is to setup a connection between module A and module B, transmit some data and close the connection again. In this section, all packet data from or to the modules is given in hexadecimal notation. For quick testing, a pair of Proteus-III-EV is recommended. Connect the two devices (modules, EV-boards or USB dongles) to a PC.
Connection setup and first data transmission 1. Power-up the modules and make their UARTs accessible by the host(s) (115200 Baud, 8n1). After the power-up or after reset the following sequence is sent from the module. Info Module A Module B ⇐ Response CMD_GETSTATE_CNF: Module A started in ACTION_IDLE mode. 02 41 02 00 01 01 41 ⇐ Response CMD_GETSTATE_CNF: Module B started in ACTION_IDLE mode. 02 41 02 00 01 01 41 2. Request the FS_BTMAC of both modules.
Info Module A Module B ⇒ Request CMD_CONNECT_REQ with FS_BTMAC of module B 02 06 06 00 11 00 00 DA 18 00 D1 ⇐ Response CMD_CONNECT_CNF: Request understood, try to connect now 02 46 01 00 00 45 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 02 86 07 00 00 11 00 00 DA 18 00 50 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x55 0x00 0x00 0xDA 0x18 0x00 ⇐ Indication CMD
Info Module A ⇒ Request CMD_DATA_REQ: Send "EFGH" to module B 02 04 04 00 45 46 47 48 0E ⇐ Response CMD_DATA_CNF: Request received, send data now 02 44 01 00 00 47 ⇐ Indication CMD_DATA_IND: Received string "EFGH" from FS_BTMAC 0x55 0x00 0x00 0xDA 0x18 0x00 with RSSI of 0xC1 (-63dBm) ⇐ Response CMD_TXCOMPLETE_RSP: Data transmitted successfully Module B 02 84 0B 00 55 00 00 DA 18 00 C1 45 46 47 48 D7 02 C4 01 00 00 C7 6.
5 Functional description The Proteus-III module acts as a slave and can be fully controlled by an external host that implements the command interface. The configuration as well as the operation of the module can be managed by predefined commands that are sent as telegrams over the UART interface of the module. The Proteus-III can operate in different states.
ACTION_DTM ACTION_SCANNING The module is in direct test mode. The module scans for other advertising Proteus modules in range. Permitted commands: CMD_RESET_REQ, CMD_GETSTATE_REQ, CMD_SCANSTOP_REQ, CMD_GET_REQ, CMD_UARTDISABLE_REQ Permitted commands: CMD_DTM_REQ, CMD_RESET_REQ, CMD_GETSTATE_REQ ACTION_IDLE ACTION_SLEEP The module advertises and waits for incoming connection indications. If no connection will be established, it goes to sleep.
5.1 State indication using the LED pins The pins LED_1 and LED_2 of the Proteus-III can be used to determine the module state. The states described in Figure 7 result in the following pin behavior. The pins on the ProteusIII are active high.
5.3 Identification of a Proteus-III device on the radio The Proteus-III can be identified on the radio interface by its FS_BTMAC. This FS_BTMAC is a Bluetooth® -conform MAC address, which is part of the data package sent during advertising in ACTION_IDLE mode. A FS_BTMAC has the size of 6 Bytes. In ACTION_SCANNING state a module listens to the data packets of all advertising modules in range and stores their FS_BTMAC to an internal data base.
will inform their host by a CMD_DISCONNECT_IND message that the connection is no longer open. If one module is no longer within range, the CMD_DISCONNECT_IND message is triggered by a timeout. For an example on setting up an unsecured connection, see chapter 4.4. See also the Proteus-III application note 1 "advanced user guide" to get detailed information about the connection setup with foreign devices. 5.4.
Info Module A Module B ⇒ Request CMD_GET_REQ with settings index 4 02 10 01 00 04 17 ⇐ Response CMD_GET_CNF: FS_BTMAC of module A is 0x55 0x00 0x00 0xDA 0x18 0x00 02 50 07 00 00 55 00 00 DA 18 00 C2 ⇒ Request CMD_GET_REQ with settings index 4 02 10 01 00 04 17 ⇐ Response CMD_GET_CNF: FS_BTMAC of module B is 0x11 0x00 0x00 0xDA 0x18 0x00 02 50 07 00 00 11 00 00 DA 18 00 86 3. Configure the parameter RF_SecFlags to use "Just Works" pairing method for BT security.
Info Module A Module B ⇒ Request CMD_CONNECT_REQ with FS_BTMAC of module B 02 06 06 00 11 00 00 DA 18 00 D1 ⇐ Response CMD_CONNECT_CNF: Request understood, try to connect now 02 46 01 00 00 45 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 02 86 07 00 00 11 00 00 DA 18 00 50 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x55 0x00 0x00 0xDA 0x18 0x00 ⇐ Indication CMD
Info Module A Module B ⇒ Request CMD_DATA_REQ: Send "ABCD" to module A 02 04 04 00 41 42 43 44 06 ⇐ Response CMD_DATA_CNF: Request received, send data now 02 44 01 00 00 47 ⇐ Indication CMD_DATA_IND: Received string "ABCD" from FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 with RSSI of 0xCA (-54dBm) 02 84 0B 00 11 00 00 DA 18 00 CA 41 42 43 44 90 ⇐ Response CMD_TXCOMPLETE_RSP: Data transmitted successfully 02 C4 01 00 00 C7 6. Reply with "EFGH" to module B.
the central device requests its host to enter the correct pass key (see CMD_PASSKEY_IND). In this case the pass key of the peripheral has to be entered on central side using the CMD_PASSKEY_REQ command. If the entered pass key is correct, the channel will be opened for data transmission. Otherwise, the connection will be rejected. Example: Secured connection with security method "StaticPasskey" 1. Power-up the modules and make their UARTs accessible by the host(s) (115200 Baud, 8n1).
Info Module A Module B ⇒ Request CMD_CONNECT_REQ with FS_BTMAC of module B 02 06 06 00 11 00 00 DA 18 00 D1 ⇐ Response CMD_CONNECT_CNF: Request understood, try to connect now 02 46 01 00 00 45 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 02 86 07 00 00 11 00 00 DA 18 00 50 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x55 0x00 0x00 0xDA 0x18 0x00 02 86 07 00 00
Info Module A Module B ⇒ Request CMD_DATA_REQ: Send "ABCD" to module A 02 04 04 00 41 42 43 44 06 ⇐ Response CMD_DATA_CNF: Request received, send data now 02 44 01 00 00 47 ⇐ Indication CMD_DATA_IND: Received string "ABCD" from FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 with RSSI of 0xCA (-54dBm) 02 84 0B 00 11 00 00 DA 18 00 CA 41 42 43 44 90 ⇐ Response CMD_TXCOMPLETE_RSP: Data transmitted successfully 02 C4 01 00 00 C7 6. Reply with "EFGH" to module B.
a connection is initiated. When using this method, the peripheral device outputs the new generated pass key (see CMD_DISPLAY_PASSKEY_IND) when a connection setup has been initiated. At the same time the central device requests its host to enter this pass key (see CMD_PASSKEY_IND). In this case the pass key of the peripheral has to be entered on central side using the CMD_PASSKEY_REQ command. If the entered pass key is correct, the channel will be opened for data transmission.
Info Module A Module B ⇒Perform CMD_SET_REQ with settings index 12 and value 0x05 on module A 02 11 02 00 0C 05 18 ⇐ Response CMD_SET_CNF (Module will restart to adopt the new value) 02 51 01 00 00 52 ⇐ Response CMD_GETSTATE_CNF 02 41 02 00 01 01 41 ⇒Perform CMD_SET_REQ with settings index 12 and value 0x05 on module B 02 11 02 00 0C 05 18 ⇐ Response CMD_SET_CNF (Module will restart to adopt the new value) 02 51 01 00 00 52 ⇐ Response CMD_GETSTATE_CNF 02 41 02 00 01 01 41 4.
Info Module A Module B ⇒ Request CMD_CONNECT_REQ with FS_BTMAC of module B 02 06 06 00 11 00 00 DA 18 00 D1 ⇐ Response CMD_CONNECT_CNF: Request understood, try to connect now 02 46 01 00 00 45 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 02 86 07 00 00 11 00 00 DA 18 00 50 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x55 0x00 0x00 0xDA 0x18 0x00 02 86 07 00 00
Info Module A Module B ⇒ Request CMD_DATA_REQ: Send "ABCD" to module A 02 04 04 00 41 42 43 44 06 ⇐ Response CMD_DATA_CNF: Request received, send data now 02 44 01 00 00 47 ⇐ Indication CMD_DATA_IND: Received string "ABCD" from FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 with RSSI of 0xCA (-54dBm) 02 84 0B 00 11 00 00 DA 18 00 CA 41 42 43 44 90 ⇐ Response CMD_TXCOMPLETE_RSP: Data transmitted successfully 02 C4 01 00 00 C7 6. Reply with "EFGH" to module B.
connection) when a connection is initiated. When using this method, the peripheral and central device output the new generated pass key (see CMD_DISPLAY_PASSKEY_IND) when a connection setup has been initiated. Both, the central and peripheral device request their hosts to confirm that both keys coincide (see CMD_NUMERIC_COMP_REQ). If both devices confirmed the key, the channel will be opened for data transmission. Otherwise, the connection will be rejected.
Info Module A Module B ⇒Perform CMD_SET_REQ with settings index 12 and value 0x04 on module A 02 11 02 00 0C 04 19 ⇐ Response CMD_SET_CNF (Module will restart to adopt the new value) 02 51 01 00 00 52 ⇐ Response CMD_GETSTATE_CNF 02 41 02 00 01 01 41 ⇒Perform CMD_SET_REQ with settings index 12 and value 0x04 on module B 02 11 02 00 0C 04 19 ⇐ Response CMD_SET_CNF (Module will restart to adopt the new value) 02 51 01 00 00 52 ⇐ Response CMD_GETSTATE_CNF 02 41 02 00 01 01 41 4.
Info Module A Module B ⇒ Request CMD_CONNECT_REQ with FS_BTMAC of module B 02 06 06 00 11 00 00 DA 18 00 D1 ⇐ Response CMD_CONNECT_CNF: Request understood, try to connect now 02 46 01 00 00 45 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 02 86 07 00 00 11 00 00 DA 18 00 50 ⇐ Indication CMD_CONNECT_IND: Physical connection established successfully to module with FS_BTMAC 0x55 0x00 0x00 0xDA 0x18 0x00 ⇐ Indication CMD
The RSSI values will be different in your tests. Info Module A Module B ⇒ Request CMD_DATA_REQ: Send "ABCD" to module A 02 04 04 00 41 42 43 44 06 ⇐ Response CMD_DATA_CNF: Request received, send data now 02 44 01 00 00 47 ⇐ Indication CMD_DATA_IND: Received string "ABCD" from FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 with RSSI of 0xCA (-54dBm) 02 84 0B 00 11 00 00 DA 18 00 CA 41 42 43 44 90 ⇐ Response CMD_TXCOMPLETE_RSP: Data transmitted successfully 02 C4 01 00 00 C7 6.
5.4.1.5 Bonding The SECFLAGS_BONDING_ENABLE flag in the RF_SecFlags user setting allows enabling the bonding feature. This feature stores the keys that are exchanged during the pairing phase in a connection setup. With this, subsequent connections to bonded devices can be established without renegotiation. The commands CMD_GETBONDS_REQ and CMD_DELETEBONDS_REQ allow to display and remove certain or all entries of the list of bonded devices.
Info Module A Module B ⇒Perform CMD_SET_REQ with settings index 12 and value 0x0A (Just works with SECFLAGS_BONDING_ENABLE flag set) on module A 02 11 02 00 0C 0A 17 ⇐ Response CMD_SET_CNF (Module will restart to adopt the new value) 02 51 01 00 00 52 ⇐ Response CMD_GETSTATE_CNF 02 41 02 00 01 01 41 ⇒Perform CMD_SET_REQ with settings index 12 and value 0x0A (Just works with SECFLAGS_BONDING_ENABLE flag set) on module B 02 11 02 00 0C 0A 17 ⇐ Response CMD_SET_CNF (Module will restart to adopt the
5. Now module A closes the connection, so both modules will get a disconnect indication. Info Module A ⇒ Request CMD_DISCONNECT_REQ: Disconnect 02 07 00 00 05 ⇐ Response CMD_DISCONNECT_CNF: Request received, disconnect now 02 47 01 00 00 44 ⇐ Indication CMD_DISCONNECT_IND: Connection closed 02 87 01 00 16 92 Module B ⇐ Indication CMD_DISCONNECT_IND: Connection closed 02 87 01 00 13 97 6. Connect module A to module B a second time.
5.5 Unidirectional connectionless data transmission using Beacons Besides the connection-based type of data transmission described in the previous section, there exists a second method that uses so called Beacons. In this case, a limited amount of user data can be placed in the BLE scan response packet, which is broadcasted frequently without acknowledgement and without security.
Info Module A Module B ⇐ Reset both modules using /RESET pin, CMD_GETSTATE_CNF 02 41 02 00 01 01 41 02 41 02 00 01 01 41 ⇒ Configure RF_BeaconFlags using CMD_SET_REQ to "beacon rx enabled, no filter" 02 11 02 00 0E 01 1E ⇐ CMD_SET_CNF from module B 02 51 01 00 00 52 ⇐ Module B reset such that the change in the user setting takes effect (CMD_GETSTATE_CNF) 02 41 02 00 01 01 41 ⇒ Activate scanning on module B 02 09 00 00 0B ⇐ Response CMD_SCANSTART_CNF 02 49 01 00 00 4A ⇒ CMD_SETBEACON_REQ, con
5.7 Configure the module for low power consumption Depending on the application environment of the Proteus-III, the goal is to find the optimal trade-off between the module’s performance and its power consumption. Therefore, the main settings and operation modes that affect the current consumption are listed below: • CMD_SLEEP_REQ: This command puts the module into ACTION_SLEEP mode, where it consumes the lowest current (<1µA). In this case, both the UART and the BLE interface are shut down.
Conformance tests of the nRF52 with the DTM application are carried out by dedicated test equipment. To get access to the test functions the CMD_DTMSTART_REQ shall be used first. This command restarts the module in direct test mode. A CMD_GETSTATE_CNF message confirms that the DTM has been started successfully. Now the CMD_DTM_REQ can be used to start and stop the test functions. After a test has been started, it has to be stopped before a next test can be run.
Info Module A Module B ⇒ Request CMD_DTM_REQ to start the reception test on module B with channel 0 02 1E 04 00 01 00 00 00 19 ⇐ Response CMD_DTM_CNF: Started test successfully 02 5E 03 00 00 00 00 5F • Stop both tests again.
5.10 Connection setup using LE Coded phy Due to backward compatibility reasons the Bluetooth® Low Energy standard expects to setup a Bluetooth® connection in the 1 MBit legacy mode and then to update the connection to long range mode, if requested. Thus, at connection setup time the distance between the two BLE devices must be within the standard range. To avoid this situation, the Proteus-III allows to setup a connection directly in long range mode.
Info Module A Module B ⇒Perform CMD_SET_REQ with settings index 28 and value 0x02 (Long range connection mode) on module A 02 11 03 00 1C 02 00 0E ⇐ Response CMD_SET_CNF (Module will restart to adopt the new value) 02 51 01 00 00 52 ⇐ Response CMD_GETSTATE_CNF 02 41 02 00 01 01 41 ⇒Perform CMD_SET_REQ with settings index 28 and value 0x02 (Long range connection mode) on module B 02 11 03 00 1C 02 00 0E ⇐ Response CMD_SET_CNF (Module will restart to adopt the new value) 02 51 01 00 00 52 ⇐ Respo
Info Module A Module B ⇒ Request CMD_DATA_REQ: Send "ABCD" to module A 02 04 04 00 41 42 43 44 06 ⇐ Response CMD_DATA_CNF: Request received, send data now 02 44 01 00 00 47 ⇐ Indication CMD_DATA_IND: Received string "ABCD" from FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00 with RSSI of 0xCA (-54dBm) 02 84 0B 00 11 00 00 DA 18 00 CA 41 42 43 44 90 ⇐ Response CMD_TXCOMPLETE_RSP: Data transmitted successfully 02 C4 01 00 00 C7 6. Reply with "EFGH" to module B.
6 Host connection 6.1 Serial interface: UART The configuration in factory state of the UART is 115200 Baud without flow control and with data format of 8 data Bits, no parity and 1 stop Bit ("8n1"). The baud rate and flow control of the UART can be configured by means of the UserSetting UART_ConfigIndex. The data format is fixed to 8n1. The output of characters on the serial interface runs with secondary priority.
7 The command interface The module acts as a slave and can be fully controlled by an external host. The configuration as well as the operation of the module can be managed by predefined commands that are sent as telegrams over the UART interface of the module. The commands of the command interface can be divided into 3 groups: • Requests: The host requests the module to trigger any action, e.g. in case of the request CMD_RESET_REQ the host asks the module to perform a reset.
7.1 Scan for other modules in range 7.1.1 CMD_SCANSTART_REQ This command starts the scan operation to find other Proteus-III in range. All found devices that fit the Proteus-III specification (i.e. devices that support AMBER SPP service UUID) are saved in an internal data base. Before outputting the data base content using the command CMD_GETDEVICES_REQ, the scan has to be stopped using CMD_SCANSTOP_REQ.
7.1.3 CMD_GETDEVICES_REQ This command returns the information about the devices found during the last scan operation. #Devices determines the number of devices that have been detected. The corresponding information will be output one after the other in the field behind #Devices in the CMD_GETDEVICES_CNF response. The RSSI and TXPower values are transmitted in the two’s complement notation.
If TXPower = 0x80, there is no value available. If Device name length = 0, then there is no device name available. 7.1.3.1 Example 1 Request for the FS_BTMAC of the devices found during the last scan.
complement notation. The accuracy is ±2dB when inside the RSSI range of -90 to -20 dBm. The value of the parameter TX power is read from the content of the received advertise packet. Format: Start signal Command Length BTMAC RSSI TX Power CS 0x02 0x8B 2 Bytes 6 Byte 1 Byte 1 Byte 1 Byte 7.1.5 CMD_BEACON_RSP This telegram indicates the reception of an advertising packet.
7.2 Setup connections 7.2.1 CMD_CONNECT_REQ This command tries to setup a connection to the Proteus-III, which is identified by the FS_ BTMAC used in the command. After the module prints a CMD_CONNECT_CNF to confirm that the request was received, the indication message CMD_CONNECT_IND follows which determines whether the connection request was accepted by the other device. In case of enabled security features (see the setting RF_SecFlags) a CMD_SECURITY_IND is output in addition.
Start signal Command Length Status BTMAC CS 0x02 0x88 0x07 0x00 1 Byte 6 Bytes 1 Byte Status: 0x00: Encrypted link to previously bonded device established 0x01: Bonding successful, encrypted link established 0x02: No bonding, pairing successful, encrypted link established 7.2.4 CMD_CHANNELOPEN_RSP This command is printed on the UART as soon as connection setup and service discovery has been completed successfully. Now data can be transmitted using the CMD_DATA_REQ.
7.2.6 CMD_DISCONNECT_IND This telegram indicates that the connection has shut down successfully. This indication message is the result of a disconnection request (CMD_DISCONNECT_REQ).
7.2.8 CMD_PHYUPDATE_IND This command indicates that there was an attempt to update the PHY of the existing connection. If the PHY update was successful, the command includes the new PHY for receiving and transmitting direction, as well as the BTMAC of the device connected to. This command is the result of the CMD_PHYUPDATE_REQ.
7.2.10 CMD_PASSKEY_IND Depending on the security settings of the peripheral, a passkey has to be entered on the central side to authenticate the central device. When such a pass key authentication request is received on the central side this CMD_PASSKEY_IND message is send to the host. In this case, the passkey has to be entered using the CMD_PASSKEY_REQ to successfully finish the connection procedure.
0x00: The keys displayed on the central and peripheral device coincide, thus connection setup can be continued 0x01: The keys displayed on the central and peripheral device do not coincide, thus connection setup shall the canceled Response (CMD_NUMERIC_COMP_CNF): Start signal Command | 0x40 Length Status CS 0x02 0x64 0x01 0x00 1 Byte 1 Byte Status: 0x00: Answer accepted 0xFF: Operation not permitted 7.2.13 CMD_GETBONDS_REQ This command requests the MAC addresses of all bonded devices.
Start signal Command Length CS 0x02 0x0F 0x00 0x00 0x0D Response: Start signal 0x02 Command | 0x40 Length Status 0x12 0x00 0x4F #Devices Payload CS 0x02 0x00 0x00 0x82 0x5C 0xA7 0xE2 0x87 0xD0 0x01 0x00 0x01 0x00 0x00 0xDA 0x18 0x00 0x53 0x00 Two devices have been bonded before: • Device 1 (Bond_ID 0x0000) with FS_BTMAC 0x82 0x5C 0xA7 0xE2 0x87 0xD0 • Device 2 (Bond_ID 0x0001) with FS_BTMAC 0x01 0x00 0x00 0xDA 0x18 0x00 7.2.
Start signal Command | 0x40 Length Status CS 0x02 0x4E 0x01 0x00 0x00 0x4D Successfully removed all bonding information. 7.2.14.2 Example 2 Request to remove the bonding of the device corresponding to Bond_ID 0. Start signal Command Length Bond_ID CS 0x02 0x0E 0x02 0x00 0x00 0x00 0x0E Response: Start signal Command | 0x40 Length Status CS 0x02 0x4E 0x01 0x00 0x00 0x4D Successfully removed the bonding information. Proteus-III reference manual version 0.11 www.we-online.
7.3 Transmit and receive data 7.3.1 CMD_DATA_REQ This command provides the simple data transfer between two connected modules. Transmission takes place to the previously connected device(s). This command is suitable for transmission for a point-to-point connection. The number of payload data Bytes is negotiated during the connection phase. It can be maximal 243 Bytes, but at least 19 Bytes. When the data is processed by the module a CMD_DATA_CNF is output by the UART.
7.3.3 CMD_DATA_IND This telegram indicates the reception of data sent by the previously connected device. This indication message is the result of a data request (CMD_DATA_REQ) sent to the associated device within a connection. The CMD_DATA_IND returns the FS_BTMAC of the sending device, the RSSI value of the received data packet and the data received via the RF-interface, which can be found in the payload. The RSSI value is printed in two’s complement notation.
Start signal Command Length BTMAC RSSI Payload CS 0x02 0x8C 2 Bytes 6 Bytes 1 Byte (Length - 7) Bytes 1 Byte Proteus-III reference manual version 0.11 www.we-online.
7.4 Configuring the module and modifying the device settings It is strongly recommended to have identical settings on all devices, which have to open a connection with each other or are to be used in Beacon mode. The module’s parameters are stored in flash, but have a local copy in RAM. The flash parameters can be modified by the CMD_SET_REQ, read by the CMD_GET_REQ and retain their content even when resetting the module. 7.4.
Start signal Command Length Settings index Parameter CS 0x02 0x11 2 Bytes 1 Byte (Length - 1) Bytes 1 Byte Response (CMD_SET_CNF): Start signal Command | 0x40 Length Status CS 0x02 0x51 0x01 0x00 1 Byte 1 Byte Status: 0x00: Request received, settings set successfully 0x01: Operation failed due to invalid parameter 0x04: Serious error, when writing flash. Try to factory reset or re-flash the device 0x05: Supply voltage to low. Please apply correct supply voltage, reset and retry.
7.4.2 CMD_GET_REQ This command can be used to query individual setting parameters in flash. The respective parameters are accessed by means of the corresponding settings index, which can be found in Table 20. Parameters of 2 or more Bytes have to be transferred with the LSB first unless noted differently in the corresponding description. Read access to the memory area outside the setting is blocked.
7.5 Manage the device state 7.5.1 CMD_GETSTATE_REQ This command returns the current state of the module. Please refer to chapter 5 for details on the states of the module.
Start signal Command Length CS 0x02 0x01 0x00 0x00 0x03 Response: Start signal Command | 0x40 Length Module role Module actions More info CS 0x02 0x41 0x08 0x00 0x02 0x03 0x11 0x00 0x00 0xDA 0x18 0x00 0x99 The module is connected to another module with FS_BTMAC 0x11 0x00 0x00 0xDA 0x18 0x00. 7.5.2 CMD_RESET_REQ This command triggers a software reset of the module.
Start signal Command | 0x40 Length Status CS 0x02 0x42 0x01 0x00 1 Byte 1 Byte Status: 0x00: Request received, will go to sleep now 0x01: Operation failed 0xFF: Operation not permitted Please note that the WAKE_UP pin has a second function. If the module is not in ACTION_SLEEP mode and the UART was disabled using the CMD_UARTDISABLE_REQ, the UART can be re-enabled by applying falling edge, holding the line low for at least 10ms before applying a rising edge and holding it high for at least 10ms.
Start signal Command | 0x40 Length Status CS 0x02 0x5C 0x01 0x00 1 Byte 1 Byte Status: 0x00: Request received, will perform factory reset now 0x01: Operation failed 0xFF: Operation not permitted To save the parameters in the flash memory of the module, the particular memory segment must first be flushed entirely and then restored from RAM. If a reset occurs during this procedure (e.g. due to supply voltage fluctuations), the entire memory area may be destroyed.
0x00: Request received, will disable UART now 0x01: Operation failed 0xFF: Operation not permitted We insistently recommend disabling the UART using this command only, if it is foreseeable that there will be no UART communication for several seconds! Use cases could be during advertising phase to wait for connecting BLE devices or when broadcasting data via Beacons. Disabling the UART peripheral of the module results in a reduction of current consumption of about 550µA.
Please note that you can only exit the bootloader mode by performing a hardware reset using the respective pin. The bootloader mode will also be enabled if the firmware image is marked "invalid" or if the BOOT pin logic level (set by the host) is set to start the bootloader during start-up of the module.
7.6 Run the Bluetooth test modes The test modes "DTM" as specified by the Bluetooth® SIG are defined in the Bluetooth® Core specification. 7.6.1 CMD_DTMSTART_REQ This command restarts the module in direct test mode (DTM). When starting in DTM mode, a CMD_GETSTATE_CNF message follows which indicates that the test mode has been enabled successfully. Now the CMD_DTM_REQ can be used to start and stop various test modes.
Vendor option Vendor command Payload 0x00: Reset DTM 0x00 0x00 New phy 1. 0x01: 1MBit 0x02: Set phy 2. 0x02: 2MBit 0x00 3. 0x03: S8 LE Coded 4.
Start signal Command | 0x40 Length Status Result CS 0x02 0x5E 2 Bytes 1 Byte 0-2 Bytes 1 Byte Status: 0x00: Request received 0x01: Operation failed 0x03: Busy 0xFF: Operation not permitted Result: 0x0000: Test success 0x0001: Test failed 0x8000 + n: Received n packets during RX test See also the example in chapter 5.8. 7.6.2.1 Example: Transmission, 16 times 0x0F, channel 0 Start the transmission test on channel 0 (2402 MHz).
Start signal Command 0x02 0x1E Command Length code 0x04 0x00 Channel / Vendor option Length / Vendor command Payload CS 0x00 0x00 0x01 0x1A 0x03 Response: Start signal Command | 0x40 Length Status Result CS 0x02 0x5E 0x03 0x00 0x00 0x80 0x00 0xDF Test stopped successfully and received 0 packets. 7.6.2.
7.6.2.3 Example: Transmission, carrier test, channel 0 Start the carrier test on channel 0 (2402MHz). We need to use a vendor specific command: Start signal Command Length Command code Channel / Vendor option Length / Vendor command Payload CS 0x02 0x1E 0x04 0x00 0x02 0x00 0x00 0x03 0x19 Response: Start signal Command | 0x40 Length Status Result CS 0x02 0x5E 0x03 0x00 0x00 0x00 0x00 0x5F See the previous example to stop the test again. 7.6.2.
Start signal Command | 0x40 Length Status Result CS 0x02 0x5E 0x03 0x00 0x00 0x00 0x00 0x5F Proteus-III reference manual version 0.11 www.we-online.
7.7 Switching GPIOs by remote control This chapter contains the commands to use the GPIO feature of the Proteus-III. Please refer to chapter 11 for a detailed description. 7.7.1 CMD_GPIO_LOCAL_WRITECONFIG_REQ This command configures the free GPIOs of the radio module. This is necessary to allow local and remote GPIO control. As the configuration is stored in flash, it is retained after restarting the device. The flash memory used to store these settings has a limited count of write cycles.
0x02: GPIO works as output Value: • if Function is input: 0x00: GPIO has no pull resistor 0x01: GPIO has pull down resistor 0x02: GPIO has pull up resistor • if Function is output: 0x00: GPIO is output low 0x01: GPIO is output high CMD_GPIO_LOCAL_WRITECONFIG_CNF block structure Each Block has the following format: Length GPIO_ID Status 0x02 1 Byte 1 Byte Length: Length of the subsequent bytes in this block GPIO_ID: ID of the GPIO, see chapter 11.1 Status: 0x00: Success 0x01: Failed 7.7.1.
7.7.2 CMD_GPIO_LOCAL_READCONFIG_REQ This command reads the current configuration of the free GPIOs of the radio module. Format: Start signal Command Length CS 0x02 0x2B 0x00 0x00 0x29 Response (CMD_GPIO_LOCAL_READCONFIG_CNF): Start signal Command | 0x40 Length Status Block1 0x02 0x6B 2 Bytes 1 Byte x Bytes ...
7.7.2.1 Example: Read the current GPIO configuration Read the current configuration: Start signal Command Length CS 0x02 0x2B 0x00 0x00 0x29 Response: Start signal 0x02 Command | 0x40 0x6B Length 0x15 0x00 Status 0x00 CS Blocks 0x03 0x01 0x02 0x01 0x03 0x02 0x02 0x01 0x02 0x03 0x00 0x02 0x04 0x00 0x02 0x05 0x00 0x02 0x06 0x00 0x7B The GPIOs with GPIO_ID 0x01 and 0x02 are output high. The remaining GPIOs with GPIO_ID 0x03,0x04,0x05 and 0x06 are not configured.
7.7.3 CMD_GPIO_REMOTE_WRITECONFIG_REQ This command configures the free GPIOs of the connected remote device. This is necessary to allow remote GPIO control. As the configuration is stored in flash, it is retained after restarting the device. This command can be run successfully only if the remote device is connected via BLE. The flash memory used to store these settings has a limited count of write cycles.
• if Function is input: 0x00: GPIO has no pull resistor 0x01: GPIO has pull down resistor 0x02: GPIO has pull up resistor • if Function is output: 0x00: GPIO is output low 0x01: GPIO is output high CMD_GPIO_REMOTE_WRITECONFIG_CNF block structure Each Block has the following format: Length GPIO_ID Status 0x02 1 Byte 1 Byte Length: Length of the subsequent bytes in this block GPIO_ID: ID of the GPIO, see chapter 11.
7.7.4 CMD_GPIO_REMOTE_READCONFIG_REQ This command reads the current configuration of the free GPIOs of the connected remote device. Format: Start signal Command Length CS 0x02 0x2C 0x00 0x00 0x2E Response (CMD_GPIO_REMOTE_READCONFIG_CNF): Start signal Command | 0x40 Length Status Block1 0x02 0x6C 2 Bytes 1 Byte x Bytes ...
7.7.4.1 Example: Read the current GPIO configuration of the connected remote device Read the current GPIO configuration of the connected remote device: Start signal Command Length CS 0x02 0x2C 0x00 0x00 0x2E Response: Start signal 0x02 Command | 0x40 0x6C Length 0x15 0x00 Status 0x00 CS Blocks 0x03 0x01 0x02 0x01 0x03 0x02 0x02 0x01 0x02 0x03 0x00 0x02 0x04 0x00 0x02 0x05 0x00 0x02 0x06 0x00 0x7C The GPIOs with GPIO_ID 0x01 and 0x02 are output high.
7.7.5 CMD_GPIO_REMOTE_WRITE_REQ This command writes the free GPIOs of the remote device. This command can be only run successfully if the respective pins of the remote device have been configured as output pins before and the remote device is connected via BLE. Format: Start signal Command Length Block1 0x02 0x29 2 Bytes x Bytes ... Blockn CS x Bytes 1 Byte Response (CMD_GPIO_REMOTE_WRITE_CNF): Start signal Command | 0x40 Length Status Block1 0x02 0x69 2 Bytes 1 Byte x Bytes ...
GPIO_ID: ID of the GPIO, see chapter 11.1 Status: 0x00: Success 0x01: Failed 7.7.5.1 Example: Set a remote output GPIO to low Set the output GPIO (GPIO_ID 0x01) of the connected remote device to low: Start signal Command Length Block1 CS 0x02 0x29 0x03 0x00 0x02 0x01 0x00 0x2B Response: Start signal Command | 0x40 Length Status Block1 CS 0x02 0x69 0x04 0x00 0x00 0x02 0x01 0x00 0x6C Successfully set GPIO with GPIO_ID 0x01 to low. Proteus-III reference manual version 0.11 www.we-online.
7.7.6 CMD_GPIO_REMOTE_READ_REQ This command reads the free GPIOs of the remote device. This command can be only run successfully if the respective pins of the remote device have been configured as output or input pins before and the remote device is connected via BLE. Format: Start signal Command Length Block1 0x02 0x2A 2 Bytes x Bytes ... Blockn CS x Bytes 1 Byte Response (CMD_GPIO_REMOTE_READ_CNF): Start signal Command | 0x40 Length Status Block1 0x02 0x6A 2 Bytes 1 Byte x Bytes ...
7.7.6.1 Example: Read the values of remote GPIOs Read the value of the GPIOs with GPIO_ID 0x01 and 0x02 of the connected remote device: Start signal Command Length Block1 CS 0x02 0x2A 0x03 0x00 0x02 0x01 0x02 0x2A Response: Start signal Command | 0x40 Length Status Block1 Block2 CS 0x02 0x6A 0x07 0x00 0x00 0x02 0x01 0x00 0x02 0x02 0x01 0x6D Successfully read the values of the remote GPIOs with GPIO_ID 0x01 (GPIO is low) and 0x02 (GPIO is high).
7.7.7 CMD_GPIO_LOCAL_WRITE_REQ This command writes the free GPIOs of the local device. This command can be only run successfully if the respective pins of the local device have been configured as output pins before. Format: Start signal Command Length Block1 0x02 0x26 2 Bytes x Bytes ... Blockn CS x Bytes 1 Byte Response (CMD_GPIO_LOCAL_WRITE_CNF): Start signal Command | 0x40 Length Status Block1 0x02 0x66 2 Bytes 1 Byte x Bytes ...
GPIO_ID: ID of the GPIO, see chapter 11.1 Status: 0x00: Success 0x01: Failed 7.7.7.1 Example: Set a local output GPIO to low Set the output GPIO (GPIO_ID 0x01) of the local device to low: Start signal Command Length Block1 CS 0x02 0x26 0x03 0x00 0x02 0x01 0x00 0x24 Response: Start signal Command | 0x40 Length Status Block1 CS 0x02 0x66 0x04 0x00 0x00 0x02 0x01 0x00 0x63 Successfully set GPIO with GPIO_ID 0x01 to low. Proteus-III reference manual version 0.11 www.we-online.
7.7.8 CMD_GPIO_LOCAL_READ_REQ This command reads the free GPIOs of the local device. This command can be only run successfully if the respective pins of the local device have been configured as output or input pins before. Format: Start signal Command Length Block1 0x02 0x27 2 Bytes x Bytes ... Blockn CS x Bytes 1 Byte Response (CMD_GPIO_LOCAL_READ_CNF): Start signal Command | 0x40 Length Status Block1 0x02 0x67 2 Bytes 1 Byte x Bytes ...
7.7.8.1 Example: Read the values of local GPIOs Read the value of the GPIOs with GPIO_ID 0x01 and 0x02 of the local device: Start signal Command Length Block1 CS 0x02 0x27 0x03 0x00 0x02 0x01 0x02 0x27 Response: Start signal Command | 0x40 Length Status Block1 Block2 CS 0x02 0x67 0x07 0x00 0x00 0x02 0x01 0x00 0x02 0x02 0x01 0x60 Successfully read the values of the local GPIOs with GPIO_ID 0x01 (GPIO is low) and 0x02 (GPIO is high). Proteus-III reference manual version 0.11 www.
7.7.9 CMD_GPIO_REMOTE_WRITECONFIG_IND This command indicates that the remote device has written the free GPIOs of the radio module. Please note that only the GPIOs are part of this message, that have been configured successfully. Failed attempts of GPIO configurations will not be indicated by this message. Format: Start signal Command Length Block1 0x02 0xA8 2 Bytes x Bytes ... Blockn CS x Bytes 1 Byte The Block structure is as defined in CMD_GPIO_REMOTE_WRITECONFIG_REQ block structure. 7.7.9.
7.7.10 CMD_GPIO_REMOTE_WRITE_IND This command indicates that the remote device has written the free GPIOs of the radio module. Please note that only the GPIOs are part of this message, that have been updated successfully. Failed attempts of GPIO updates will not be indicated by this message. Format: Start signal Command Length Block1 0x02 0xA9 2 Bytes x Bytes ... Blockn CS x Bytes 1 Byte The Block structure is as defined in CMD_GPIO_LOCAL_READ_CNF block structure. 7.7.10.
7.7.11 CMD_GPIO_LOCAL_WRITE_IND This command indicates that the GPIOs of the remote device have been written by its local host. Please note that only the GPIOs are part of this message, that have been updated successfully. Failed attempts of GPIO updates will not be indicated by this message. Format: Start signal Command Length Block1 0x02 0xA6 2 Bytes x Bytes ... Blockn CS x Bytes 1 Byte The Block is of structure as defined in CMD_GPIO_LOCAL_READ_CNF block structure . 7.7.11.
7.8 Other messages 7.8.1 CMD_ERROR_IND This indication is shown when the module entered an error state. Format: Start signal Command Length Status CS 0x02 0xA2 0x01 0x00 1 Byte 1 Byte Status: 0x01: UART_COMMUNICATION_ERROR The UART had a buffer overflow. Thus, UART TX and RX was aborted and UART has restarted. Please restart module if UART is still malfunctioning. Proteus-III reference manual version 0.11 www.we-online.
7.9 Message overview Start signal CMD Message name Short description Chapter 0x02 0x00 CMD_RESET_REQ Reset the module 7.5.2 0x02 0x01 CMD_GETSTATE_REQ Request the current module state 7.5.1 0x02 0x02 CMD_SLEEP_REQ Go to sleep 7.5.3 0x02 0x04 CMD_DATA_REQ Send data to the connected device 7.3.1 0x02 0x06 CMD_CONNECT_REQ Setup a connection with another device 7.2.1 0x02 0x07 CMD_DISCONNECT_REQ Close the connection 7.2.5 0x02 0x09 CMD_SCANSTART_REQ Start scan 7.1.
Start signal CMD Message name Short description 0x02 0x25 CMD_GPIO_LOCAL_WRITECONFIG_ REQ Configure the free GPIOs for remote control 7.7.1 0x02 0x26 CMD_GPIO_LOCAL_WRITE_REQ Set the output value of a output GPIO of the current device 7.7.7 0x02 0x27 CMD_GPIO_LOCAL_READ_REQ Read the value of a GPIO of the current device 7.7.8 0x02 0x28 CMD_GPIO_REMOTE_WRITECONFIG_ REQ Configure the free GPIOs of the remote device for remote control 7.7.
Start signal CMD Message name Short description 0x02 0x40 CMD_RESET_CNF Reset request received 7.5.2 0x02 0x41 CMD_GETSTATE_CNF Return the current module state 7.5.1 0x02 0x42 CMD_SLEEP_CNF Sleep request received 7.5.3 0x02 0x44 CMD_DATA_CNF Data transmission request received 7.3.1 0x02 0x46 CMD_CONNECT_CNF Connection setup request received 7.2.1 0x02 0x47 CMD_DISCONNECT_CNF Disconnection request received 7.2.5 0x02 0x49 CMD_SCANSTART_CNF Scan started 7.1.
Start signal CMD Message name Short description 0x02 0x6B Returns the GPIO configuration 7.7.2 0x02 0x6C CMD_GPIO_LOCAL_READCONFIG_CNF CMD_GPIO_REMOTE_READCONFIG_ CNF Returns the GPIO configuration of the connected remote device 7.7.4 Chapter Table 13: Message overview: Confirmations 2 Start signal CMD Message name Short description 0x02 0x82 CMD_SLEEP_IND State will be changed to ACTION_SLEEP 7.5.4 0x02 0x84 CMD_DATA_IND Data has been received 7.3.
8 UserSettings - Module configuration values The settings described in this chapter are stored permanently in the module’s flash memory. Depending on their corresponding permissions, their current values can be read out by the CMD_GET_REQ command or modified by the CMD_SET_REQ command. To do so the corresponding settings index is used, which can be found in the primary table of each setting description. The validity of the specified parameters is not verified.
Packet variant Package Flash size RAM size QFN QFN73 1024 kB 256 kB WLCSP WLCSP 1024 kB 256 kB Table 15: nRF52840 IC revision overview 8.1.1 Example 1 Request the device info of the module using CMD_GET_REQ with settings index 15 Start signal Command Length Settings index CS 0x02 0x10 0x01 0x00 0x0F 0x1C Response CMD_GET_CNF: Successfully read out the device info (with Byte order changed to MSB first): OS version = 0x00B6 (Softdevice S140 6.1.
8.2 FS_FWVersion: Read the firmware version Settings index Designation Permissible values Default value Permissions Number of Bytes 1 FS_FWVersion - - read 3 This setting contains the firmware version of the module. 8.2.
8.3 FS_MAC: Read the MAC address Settings index Designation Permissible values Default value Permissions Number of Bytes 3 FS_MAC - - read 8 This setting contains the unique MAC address of the module. 8.3.
8.4 FS_BTMAC: Read the BLE conform MAC address Settings index Designation Permissible values Default value Permissions Number of Bytes 4 FS_BTMAC - - read 6 This setting contains the BLE conform MAC address of the module. The FS_BTMAC is introduced and used to find the respective device on the RF-interface. It consists of the company ID 0x0018DA followed by the FS_SerialNumber of the module. Please note that LSB is transmitted first in all commands. 8.4.
8.5 FS_SerialNumber: Read the serial number of the module Settings index Designation Permissible values Default value Permissions Number of Bytes 16 FS_SerialNumber - - read 3 This setting contains the serial number of the module. 8.5.1 Example 1 Request the serial number of the module using CMD_GET_REQ with settings index 16 Start signal Command Length Settings index CS 0x02 0x10 0x01 0x00 0x10 0x03 Response CMD_GET_CNF: Successfully read out the serial number, it is 0.0.
8.6 RF_DeviceName: Modify the device name Settings index Designation Permissible values Default value Permissions Number of Bytes 2 RF_DeviceName See description "Proteus-III" read/write 1-32 This parameter is using MSB first notation. This parameter determines the name of the module, which is used in the advertising packets as well as in the Generic Access Profile (GAP).
Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x06 0x00 0x00 0x41 0x32 0x37 0x32 0x31 0x13 Proteus-III reference manual version 0.11 www.we-online.
8.7 RF_StaticPasskey: Modify the static passkey Settings index Designation Permissible values Default value Permissions Number of Bytes 18 RF_StaticPasskey See description "123123" read/write 6 This setting determines the static pass key of the peripheral device used for authentication. If the static pass key security mode is enabled by the peripheral, this key must be entered in the central device.
8.8 RF_SecFlags: Modify the security settings Settings index Designation Permissible values Default value Permissions Number of Bytes 12 RF_SecFlags See description 0 read/write 1 This 8-Bit field configures security settings of the module. Chapter 5.4 contains further information about secure connections. When connecting from a Proteus-III to another Proteus-III, be sure that the same security mode is used.
Bit no. Description Security mode configuration. Depending on its value, different modes are chosen when setting up a secure connection. In firmware version 2.1.0 and newer the peripheral decides which is the minimum security level to access its data. Data is transmitted without authentication and 0x0 No security encryption. 0x2 Just works level 1.2 Each time a connection is established, new random keys are exchanged in advance to use them for data encryption. This mode uses the "just works" method.
Start signal Command | 0x40 Length Status CS 0x02 0x51 0x01 0x00 0x00 0x52 8.8.2 Example 2 Request the security flags of the module using CMD_GET_REQ with settings index 12 Start signal Command Length Settings index CS 0x02 0x10 0x01 0x00 0x0C 0x1F Response CMD_GET_CNF: Successfully read out the value 2, which means that the just works pairing mode is enabled.
8.9 RF_SecFlagsPerOnly: Modify the security settings (Peripheral only mode) Settings index Designation Permissible values Default value Permissions Number of Bytes 44 RF_SecFlagsPerOnly See description 11 read/write 1 This user setting determines the security setting of the peripheral only mode. Please refer to the setting RF_SecFlags for more details. Since the security modes "Lesc pass key" and "Lesc numeric comparison" output the LESC key on the UART, it is essential to use the command mode.
8.10 RF_ScanFlags: Modify the scan behavior Settings index Designation Permissible values 13 RF_ScanFlags See description Default value Permissions Number of Bytes 0 read/write 1 This 8-Bit field configures the scan behavior of the module. To use multiple settings, add the Bit numbers and choose the result as value for RF_ScanFlags. Bit no. 0 15 : 1 Description If this Bit is set, an active scan is performed when using CMD_SCANSTART_REQ.
Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x02 0x00 0x00 0x00 0x50 Proteus-III reference manual version 0.11 www.we-online.
8.11 RF_BeaconFlags: Interprete the advertising data Settings index 14 Designation Permissible values Default value Permissions Number of Bytes RF_BeaconFlags See description 0 read/write 1 This field configures the reception of Beacons. Value Description 0x01 Receive all Beacons from Proteus-III devices in range. Each received packet is interpreted and output by the UART via a CMD_BEACON_IND message.
Start signal Command Length Settings index Parameter CS 0x02 0x11 0x02 0x00 0x0E 0x04 0x1B Response CMD_SET_CNF: Successfully modified the setting. Start signal Command | 0x40 Length Status CS 0x02 0x51 0x01 0x00 0x00 0x52 8.11.
8.12 RF_AdvertisingTimeout: Modify the advertising timeout Settings index 7 Designation Permissible values Default value Permissions Number of Bytes RF_AdvertisingTimeout 0 (infinite), 1 - 650 0 read/write 2 This parameter defines the time in seconds after which the advertising of the module stops. If no peer connects before this timeout, advertising stops and the module goes to system-off mode. If the RF_AdvertisingTimeout is set to 0, the module advertises infinitely.
8.13 RF_AdvertisingFlags: Configure the advertising packet Settings index Designation Permissible values Default value Permissions Number of Bytes 29 RF_AdvertisingFlags 0,1 0 read/write 1 The user setting RF_AdvertisingFlags specifies the content of the advertising packet. Bit no.
Start signal Command Length Settings index CS 0x02 0x10 0x01 0x00 0x1D 0x0E Response CMD_GET_CNF: Successfully read out the value 0x00. Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x02 0x00 0x00 0x00 0x50 Proteus-III reference manual version 0.11 www.we-online.
8.14 RF_ScanFactor: Modify the scan factor Settings index 10 Designation Permissible values Default value Permissions Number of Bytes RF_ScanFactor 1 - 10 2 read/write 1 This parameter defines the factor between the scan window and the scan interval. See RF_ScanTiming for more information.
8.15 RF_ScanTiming: Modify the scan timing Settings index 9 Designation Permissible values Default value Permissions Number of Bytes RF_ScanTiming 0 - 11 1 read/write 1 The RF_ScanTiming enables the possibility to configure the timing behavior of the module’s RF interface during advertising and scanning state. Using this parameter several predefined configurations can be chosen, which include timing parameters, such as the frequency of advertising packets and the length of a scan window.
Please ensure that all members of a network support the same advertising and scan timing parameters. To ensure that the module is allowed to send a sufficient amount of advertising packets, please also check the RF_AdvertisingTimeout parameter. 8.15.1 Example 1 Set the scan timing parameter to 0x00 using CMD_SET_REQwith settings index 9. Start signal Command Length Settings index Parameter CS 0x02 0x11 0x02 0x00 0x09 0x00 0x18 Response CMD_SET_CNF: Successfully modified the setting.
8.16 RF_ConnectionTiming: Modify the connection timing Settings index Designation Permissible values Default value Permissions Number of Bytes 8 RF_ConnectionTiming 0-8 2 read/write 1 The RF_ConnectionTiming enables the possibility to configure the timing behavior of the module’s RF interface during an established connection.
connection interval is used. If now another BLE device (e.g. a smart phone) connects as central to a Proteus-III module (peripheral) and the connection interval settings do not coincide, the ProteusIII requests the smart phone to accept its settings after 5s. If the cell phone does not accept the settings, it will be requested a further 3 times with a delay of 10s. If the peripheral’s settings request have been rejected in all cases the connection will be shut down.
Start signal Command Length Settings index CS 0x02 0x10 0x01 0x00 0x08 0x1B Response CMD_GET_CNF: Successfully read out the value 1. Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x02 0x00 0x00 0x01 0x51 Proteus-III reference manual version 0.11 www.we-online.
8.17 RF_TXPower: Modify the output power Settings index 17 Designation Permissible values Default value Permissions Number of Bytes RF_TXPower See description 8 read/write 1 This setting determines the output power in dBm of the module. The value has to be entered in hexadecimal and as two’s complement. The permissible values are listed in the following table.
Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x02 0x00 0x00 0x04 0x54 Proteus-III reference manual version 0.11 www.we-online.
8.
Start signal 0x02 Command | 0x40 0x50 Length 0x11 0x00 Proteus-III reference manual version 0.11 www.we-online.
8.19 RF_Appearance: Configure the appearance of the device Settings index 25 Designation Permissible values Default value Permissions Number of Bytes RF_Appearance 0-65535 0 read/write 2 The user setting RF_Appearance specifies the appearance of the Bluetooth® devices. It’s a 2 Bytes field defined by the Bluetooth® SIG. Please check the Bluetooth® Core Specification:Core Specification Supplement, Part A, section 1.12 for permissible values. 8.19.
8.20 UART_ConfigIndex: Modify the UART speed Settings index 11 Designation Permissible values Default value Permissions Number of Bytes UART_ConfigIndex See description 22 read/write 1 This parameter defines the baud rate used by the module’s UART. The permissible values are listed in the following table. If flow control is enabled the pins /RTS and /CTS are used.
UART_ConfigIndex 33 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 89 91 93 95 97 Rate [Baud] Real rate [Baud] Flow control Parity 1000000 1000000 yes none 1200 1205 no even 1200 1205 yes even 2400 2396 no even 2400 2396 yes even 4800 4808 no even 4800 4808 yes even 9600 9598 no even 9600 9598 yes even 14400 14414 no even 14400 14414 yes even 19200 19208 no even 19200 19208 yes even 28800 28829 no even 28800 28829 yes e
Please note that due to the HF-activity of the chip, single Bytes on the UART can get lost, when using a very fast UART data rate. In case of corrupted UART communication the module cannot interpret the sent request and thus does not return a confirmation. 8.20.
8.21 CFG_Flags: Configure the module Settings index Designation Permissible values Default value Permissions Number of Bytes 28 CFG_Flags See description 0 read/write 2 The user setting CFG_Flags specifies various module features. Bit no. Name Description 0 High-throughput mode Set this Bit to 1 to enable the high-throughput mode. 1 Long range connection mode Set this Bit to 1 to enable the mode using the LE Coded mode during connection setup. 2 GPIO remote config.
Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x03 0x00 0x00 0x00 0x00 0x51 Proteus-III reference manual version 0.11 www.we-online.
8.22 DIS_ManufacturerName: Configure the manufacturer name Settings index 20 Designation Permissible values Default value Permissions Number of Bytes DIS_ManufacturerName See description "Default" read/write 1-64 The user setting DIS_ManufacturerName specifies the content of the manufacturer name field of the Device Information Service.
Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x08 0x00 0x00 0x44 0x65 0x66 0x61 0x75 0x6C 0x74 0x11 Proteus-III reference manual version 0.11 www.we-online.
8.23 DIS_ModelNumber: Configure the model number Settings index Designation Permissible values 21 DIS_ModelNumber See description Default value Permissions Number of Bytes "Default" read/write 1-64 The user setting DIS_ModelNumber specifies the content of the model number field of the Device Information Service. The permissible characters are in the range of 0x20 - 0x7E which are special characters (see ASCII table), alphabetic characters (a-z and A-Z), numbers (0-9) and whitespace.
8.24 DIS_SerialNumber: Configure the serial number Settings index 22 Designation Permissible values Default value Permissions Number of Bytes DIS_SerialNumber See description "Default" read/write 1-64 The user setting DIS_SerialNumber specifies the content of the serial number field of the Device Information Service. The permissible characters are in the range of 0x20 - 0x7E which are special characters (see ASCII table), alphabetic characters (a-z and A-Z), numbers (0-9) and whitespace.
8.25 DIS_HWVersion: Configure the HW version Settings index 23 Designation Permissible values Default value Permissions Number of Bytes DIS_HWVersion See description "Default" read/write 1-16 The user setting DIS_HWVersion specifies the content of the hardware version field of the Device Information Service. The permissible characters are in the range of 0x20 - 0x7E which are special characters (see ASCII table), alphabetic characters (a-z and A-Z), numbers (0-9) and whitespace.
8.26 DIS_SWVersion: Configure the SW version Settings index 24 Designation Permissible values Default value Permissions Number of Bytes DIS_SWVersion See description "Default" read/write 1-16 The user setting DIS_SWVersion specifies the content of the software version field of the Device Information Service. The permissible characters are in the range of 0x20 - 0x7E which are special characters (see ASCII table), alphabetic characters (a-z and A-Z), numbers (0-9) and whitespace.
8.27 DIS_Flags: Configure the device information service Settings index 19 Designation Permissible values Default value Permissions Number of Bytes DIS_Flags 0-255 0 read/write 1 The user setting DIS_Flags specifies the content of the Device Information Service. To add a specific field, like DIS_ModelNumber to the Device Information Service, the corresponding Bit has to be set in the DIS_Flags. Bit no.
Start signal Command | 0x40 Length Status Parameter CS 0x02 0x50 0x02 0x00 0x00 0x00 0x50 Proteus-III reference manual version 0.11 www.we-online.
Settings index Permissible Default values value Number Permissions of Bytes Designation Summary 1 FS_FWVersion Version of the firmware - - read 3 2 RF_DeviceName Name of the module See description "A2721" read / write 1-32 3 FS_MAC MAC address of the module - - read 6 4 FS_BTMAC BLE conform MAC address of the module - - read 6 7 RF_ AdvertisingTimeout Time [s] after advertising stops.
Settings index Permissible Default values value Number Permissions of Bytes Designation Summary 18 RF_StaticPasskey 6 digit pass key See description "123123" read / write 6 19 DIS_Flags Flags for the DIS 0 - 255 0 read / write 1 20 DIS_ ManufacturerName Manufacturer name field of the DIS See description "Default" read / write 1-64 21 DIS_ModelNumber Model number field of the DIS See description "Default" read / write 1-64 22 DIS_SerialNumber Serial number field of the DIS
9 Timing parameters 9.1 Reset and sleep After power-up, resetting the module or waking the module from sleep a CMD_GETSTATE_CNF is sent to the serial interface as soon as the module is ready for operation. Description Typ. Unit Ready after reset/sleep 77 ms 9.2 BLE timing parameters The timing parameters for sending advertising packets or scanning are determined by the user settings RF_ScanTiming, RF_ScanFactor and RF_AdvertisingTimeout.
Knowing the connection interval and the number of messages that will be sent, the time necessary to setup a connection can be estimated by multiplying the number of messages with the connection interval. In case the Device Information Service is enabled, the number of messages and thus the time consumption of the connection setup may be increased. 9.4 Connection based data transmission After setting up a connection, data can be transmitted using the CMD_DATA_REQ.
10 Peripheral only mode The Proteus-III implements a new feature that allows the easy integration of the Proteus-III BLE module to an already existing host. The peripheral only mode offers a plug and play installation without previous configuration of the Proteus-III. It is tailored for easy communication with mobile BLE devices like smart phones.
10.3 How to use the peripheral only mode The peripheral only mode is enabled, when a high signal is present on the MODE_1 pin during device start-up or reset. No configuration of the module is needed for this operating mode. The module shall be set to factory settings if reconfigured before so it uses the default user settings. In this case, the UART uses 115200 Baud 8n1 and static passkey pairing is used as authentication method. If a configuration of the module is still needed (e.g.
• The pin BUSY can be used as a kind of flow control for the data transmission during the peripheral only mode. By default the pin level is LOW. As soon as the 20ms timeout was detected or too much data was received via UART, the pin switches to HIGH and data transmission starts via BLE. The pin switches LOW again, as soon as BLE data transmission has finished and the transmission of new data is feasible again. In case the pin is HIGH, no more data is accepted on the UART.
11 Remote GPIO control The Proteus-III allows to control free GPIOs via remote access. Chapter 7.7 contains the description of the necessary commands. To use the remote GPIO control feature of the Proteus-III, the GPIOs of interest must be configured first. This can be done in two ways. Either by the local host (see figure 9), when the radio module is in idle mode (not connected via BLE), or via the connected remote device (see figure 10).
CMD_GPIO_LOCAL_WRITECONFIG_REQ Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_LOCAL_WRITECONFIG_CNF Module 2 Host 2 Figure 9: Configure the local GPIOs via local host Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_REMOTE_WRITECONFIG_IND CMD_GPIO_REMOTE_WRITECONFIG_REQ CMD_GPIO_REMOTE_WRITECONFIG_CNF CMD_GPIO_REMOTE_WRITECONFIG_REQ Module 2 Host 2 CMD_GPIO_REMOTE_WRITECONFIG_CNF Figure 10: Configure the local GPIOs via remote device host Proteus-III reference manual version 0.11 www.we-online.
CMD_GPIO_LOCAL_READCONFIG_REQ Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_LOCAL_READCONFIG_CNF Module 2 Host 2 Figure 11: Read the configuration of the local GPIOs via local host Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_REMOTE_READCONFIG_REQ CMD_GPIO_REMOTE_READCONFIG_CNF CMD_GPIO_REMOTE_READCONFIG_REQ Module 2 Host 2 CMD_GPIO_REMOTE_READCONFIG_CNF Figure 12: Read the configuration of the local GPIOs via remote device host Proteus-III reference manual version 0.11 www.we-online.
CMD_GPIO_LOCAL_WRITE_REQ Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_LOCAL_WRITE_CNF CMD_GPIO_LOCAL_WRITE_IND Module 2 Host 2 CMD_GPIO_LOCAL_WRITE_IND Figure 13: Set the output value of a GPIO via host controller CMD_GPIO_LOCAL_READ_REQ Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_LOCAL_READ_CNF Module 2 Host 2 Figure 14: Read the input value of a GPIO via host controller Proteus-III reference manual version 0.11 www.we-online.
Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_REMOTE_WRITE_IND CMD_GPIO_REMOTE_WRITE_REQ CMD_GPIO_REMOTE_WRITE_CNF CMD_GPIO_REMOTE_WRITE_REQ Module 2 Host 2 CMD_GPIO_REMOTE_WRITE_CNF Figure 15: Set the output value of a GPIO via remote device Module 1 Host 1 GPIO UART Radio 1 0 CMD_GPIO_REMOTE_READ_REQ CMD_GPIO_REMOTE_READ_CNF CMD_GPIO_REMOTE_READ_REQ Module 2 Host 2 CMD_GPIO_REMOTE_READ_CNF Figure 16: Read the input value of a GPIO via remote device Proteus-III reference manual version
Not marked pins are RESERVED 11.1 Supported GPIO_IDs for remote and local control The following GPIOs of the Proteus-III are supported for remote and local access.
12 Customizing the Proteus-III 12.1 DIS - Device information service Besides the AMBER SPP-like profile for data transmission, the Proteus-III contains the so called Device Information Service. This profile exposes manufacturer information about a device and is used to personalize the Proteus-III to fuse with the custom product. The Device Information Service is a standard BLE profile that is recognized by all devices with Bluetooth® capabilities.
13 Custom firmware 13.1 Custom configuration of standard firmware The configuration of standard firmware includes adoption of the non-volatile Usersettings (see chapter 8) to customer requirements and creating a customized product on base of the standard product with a unique ordering number for a specific customer that needs this configuration. For example if the UART baud rate shall be changed from the default value to another value.
The qualification(s) and certification(s) of the standard firmware cannot be applied to this customer firmware solution without a review and verification. 13.4 Contact for firmware requests Please contact your local field sales engineer (FSE) or wireless-sales@we-online.com for quotes regarding this topics. Proteus-III reference manual version 0.11 www.we-online.
14 Firmware update The Proteus-III offers two possibilities of updating its firmware. 14.1 Firmware update using the SWD interface To update the firmware of the Proteus-III the SWD interface of the module and a supported flasher hardware (such as SEGGER J-Link plus) can be used. Therefore the pins GND, VDD, /RESET, SWDIO and SWDCLK of the module have to be accessible and connected to the flasher hardware accordingly (corresponding documentation of flasher has to be read for further information).
2. during a reset and while restarting, a low signal has to be present on the BOOT pin of the module to start it in bootloader mode The bootloader mode has started successfully if LED_1 has turned on. After the bootloader has started successfully, the module goes into the advertising mode using the name "DFUProteus-III". Now, any BLE device hosting an application that understands the commands of the Nordic nRF52 BLE DFU Bootloader can connect in order to update the ProteusIII firmware.
14.2.1 Firmware update steps using the Nordic nRF Toolbox app If the radio module Proteus-III has been set to bootloader mode, the Nordic nRF Toolbox app can be used to perform the OTA firmware update. • Open the app, select the DFU function and press "SELECT FILE" • Choose "Distribution packet (ZIP)", select the new firmware and choose "All". • Press "SELECT DEVICE" and choose the appropriate module in the list of displayed devices. In bootloader mode the module is named "DFUxxxx".
If there is no device named "DFUxxxx" on the radio, please check whether the module has been started in bootloader mode. • Then press "UPLOAD" to transmit the selected firmware to the selected device. Proteus-III reference manual version 0.11 www.we-online.
15 Firmware history Version 0.x.x "Engineering" • Pre-release for test run Version 1.0.0 "Release" • First production release Proteus-III reference manual version 0.11 www.we-online.
16 Design in guide 16.1 Advice for schematic and layout For users with less RF experience it is advisable to closely copy the relating evaluation board with respect to schematic and layout, as it is a proven design. The layout should be conducted with particular care, because even small deficiencies could affect the radio performance and its range or even the conformity. The following general advice should be taken into consideration: • A clean, stable power supply is strongly recommended.
• Elements for ESD protection should be placed on all pins that are accessible from the outside and should be placed close to the accessible area. For example, the RF-pin is accessible when using an external antenna and should be protected. • ESD protection for the antenna connection must be chosen such as to have a minimum effect on the RF signal. For example, a protection diode with low capacitance such as the LXES15AAA1-100 or a 68 nH air-core coil connecting the RF-line to ground give good results.
• Filter and blocking capacitors should be placed directly in the tracks without stubs, to achieve the best effect. • Antenna matching elements should be placed close to the antenna / connector, blocking capacitors close to the module. • Ground connections for the module and the capacitors should be kept as short as possible and with at least one separate through hole connection to the ground layer. • ESD protection elements should be placed as close as possible to the exposed areas.
Figure 19: Dimensioning the antenna feed line as micro strip will lead to a trace width of W ∼ 1.9 mm. To ease the calculation of the micro strip line (or e.g. a coplanar) many calculators can be found in the internet. • As rule of thumb a distance of about 3×W should be observed between the micro strip and other traces / ground. • The micro strip refers to ground, therefore there has to be the ground plane underneath the trace. • Keep the feeding line as short as possible. 16.
16.3.1 Wire antenna An effective antenna is a λ/4 radiator with a suiting ground plane. The simplest realization is a piece of wire. It’s length is depending on the used radio frequency, so for example 8.6 cm 868.0 MHz and 3.1 cm for 2.440 GHz as frequency. This radiator needs a ground plane at its feeding point. Ideally, it is placed vertically in the middle of the ground plane.
16.3.4 Antennas provided by Würth Elektronik eiSos 16.3.4.1 2600130011 - Helike - 169 MHz dipole antenna Figure 20: 169 MHz dipole-antenna Specification Value Frequency range [MHz] 169 Impedance [Ω] 50 VSWR ≤ 2.1 Gain [dBi] 1 Dimensions (L x d) [mm] 320 x 15 Weight [g] 42 Connector SMA plug Operating Temp. [°C] -40 – +85 This antenna requires a ground plane which will influence the electrical parameters. Proteus-III reference manual version 0.11 www.we-online.
16.3.4.2 2600130041 - Herse - 434 MHz dipole antenna Figure 21: 434 MHz dipole-antenna Specification Value Frequency range [MHz] 433 Impedance [Ω] 50 VSWR ≤ 1.5 Polarization Vertical Radiation Omni Gain [dBi] 0 Antenna Cover TPEE Dimensions (L x d) [mm] 90 x 12 Weight [g] 9.6 Connector SMA plug Operating Temp. [°C] -40 – +80 This antenna requires a ground plane which will influence the electrical parameters. Proteus-III reference manual version 0.11 www.we-online.
16.3.4.3 2600130081 - Hyperion-I - 868 MHz dipole antenna Figure 22: 868 MHz dipole-antenna Ideally suited for applications where no ground plane is available. The 2600130081 antenna can be also used for 902MHz - 928MHz range. Specification Value Center frequency [MHz] 868 Frequency range [MHz] 853 – 883 Wavelength 0.5 wave VSWR ≤ 2.0 Impedance [Ω] 50 Connector SMA (Male) Dimensions (L x d) [mm] 142 x 10 Peak gain [dBi] -2.3 Operating temp.
16.3.4.4 2600130082 - Hyperion-II - 868 MHz magnetic base antenna Well suited for applications where the RF is lead through a metal wall that could serve as ground plane to the antenna. Figure 23: 868 MHz magnet foot antenna with 1.5 m antenna cable The 2600130082 is a kind of λ/4 radiator and therefore needs a ground plane at the feeding point. Specification Value Frequency range [MHz] 824 – 894 VSWR ≤ 2.
16.3.4.5 2600130021 - Himalia - 2.4 GHz dipole antenna Figure 24: 2.4 GHz dipole-antenna Due to the fact, that the antenna has dipole topology there is no need for an additional ground plane. Nevertheless the specification was measured edge mounted and 90° bent on a 100 x 100 mm ground plane. Specification Value Frequency range [GHz] 2.4 – 2.5 Impedance [Ω] 50 VSWR ≤ 2:1 Polarization Linear Radiation Omni-Directional Peak Gain [dBi] 2.8 Average Gain [dBi] -0.
17 Reference design Proteus-III was tested and certified on the corresponding Proteus-III evaluation board. For the European Conformity the evaluation board serves as reference design, for the FCC it is mandatory to follow at least the trace design. Complete layout and schematic information can be found in the manual of the Proteus-III evaluation board. Proteus-III reference manual version 0.11 www.we-online.
17.1 EV-Board CON4 60312102114405 GND C21 n.m. C6 n.m. P0.18/RST S1 3 SWCLK SWDIO GND VDD_RF C27 GND n.m. C28 22pF 1 2 3 4 5 6 7 8 GND WAKE_UP CTS RTS URXD UTXD LED_2 LED_1 PROTEUS-III ANT_PAD RF GND SWDCLK SWDIO RESET BOOT VDD 18 17 16 15 14 13 12 11 RF-module 1 2 3 4 5 6 P0.03/AIN1 S2 wakeup 430152043826 3 P0.03 Default jumper settings 00XXXXXXXX P0.12/A4 P0.11/A2 P1.09/URXD P1.08/UTXD P0.01/XL2 P0.00/XL1 P0.03/AIN1 n.m. P2 GND 4 P0.12/A4 P0.11/A2 P1.09/URXD P1.08/UTXD C9 n.m.
5V0 T1 IN IC2 TLV1117LV OUT GND ADJ OUT power-supply n.m. C4 100nF GND 5V DD+ P4 GND n.m.
no metal antenna Q1 1 Figure 27: Reference design: Layout Proteus-III reference manual version 0.11 www.we-online.
17.2 Trace design Figure 28: Trace design: Layout Figure 29: Reference design: Stack-up • Top layer is used for routing, filled with ground plane except area under the module and antenna free area. • Second layer is filled with ground plane, except the antenna free area. • Third layer is the supply layer, except antenna free area. Some routing is allowed, not dividing the supply layer in to many or too small parts. • Bottom layer is used for routing and filled with ground.
Figure 30: Trace design: Schematic Two variants of the Proteus-III are certified: • Using the on-board PCB antenna placing 22pF on C28 along with C27 and C28 as additional components to support 50Ω matched feed for the PCB antenna if needed in such case capacitors C6 and C21 would not be assembled.
18 Manufacturing information 18.1 Moisture sensitivity level This wireless connectivity product is categorized as JEDEC Moisture Sensitivity Level 3 (MSL3), which requires special handling. More information regarding the MSL requirements can be found in the IPC/JEDEC J-STD-020 standard on www.jedec.org. More information about the handling, picking, shipping and the usage of moisture/re-flow and/or process sensitive products can be found in the IPC/JEDEC J-STD-033 standard on www.jedec.org. 18.
Package thickness Volume mm3 <350 Volume mm3 350-2000 Volume mm3 >2000 < 1.6mm 260°C 260°C 260°C 1.6mm - 2.5mm 260°C 250°C 245°C > 2.5mm 250°C 245°C 245°C Table 25: Package classification reflow temperature, PB-free assembly, Note: refer to IPC/JEDEC J-STD-020E It is recommended to solder this module on the last re-flow cycle of the PCB. For solder paste use a LFM-48W or Indium based SAC 305 alloy (Sn 96.5 / Ag 3.0 / Cu 0.5 / Indium 8.9HF / Type 3 / 89%) type 3 or higher.
18.2.2 Cleaning Do not clean the product. Any residue cannot be easily removed by washing. Use a "no clean" soldering paste and do not clean the board after soldering. • Do not clean the product with water. Capillary effects can draw water into the gap between the host PCB and the module, absorbing water underneath it. If water is trapped inside, it may short-circuit adjoining pads. The water may also destroy the label and ink-jet printed text on it.
• Do not touch any exposed area of the antenna to avoid electrostatic discharge. Do not let the antenna area be touched in a non ESD-safe manner. • When soldering, use an ESD-safe soldering iron. 18.4 Safety recommendations It is your duty to ensure that the product is allowed to be used in the destination country and within the required environment. Usage of the product can be dangerous and must be tested and verified by the end user.
19 Physical dimensions 19.1 Dimensions Dimensions 12 x 8 x 2 mm Table 26: Dimensions 19.2 Weight Weight <1g Table 27: Weight Proteus-III reference manual version 0.11 www.we-online.
19.3 Module drawing 8,4 1,2 B3 9 3,6 B1 1,2 8 1 1,0 B6 18 1,2 13 12 0,8 2,0 ±0,2 6,0 8,0 ±0,3 12,0 ±0,3 Figure 32: Module dimensions [mm] Proteus-III reference manual version 0.11 www.we-online.
19.4 Footprint 12,5 4,23 6,0 1,9 18 0,5 3,6 no metall 12 B6 B1 B3 1 0,8 8 1,2 8,4 9 1,5 6,0 13 9,0 12,5 1,2 Figure 33: Footprint [mm] 19.5 Antenna free area To avoid influence and mismatching of the antenna the recommended free area around the antenna should be maintained. As rule of thumb a minimum distance of metal parts to the antenna of λ/10 should be kept (see figure 33).
20 Marking 20.1 Lot number The 15 digit lot number is printed in numerical digits as well as in form of a machine readable bar code. It is divided into 5 blocks as shown in the following picture and can be translated according to the following table. Figure 34: Lot number structure Block Information Example(s) 1 eiSos internal, 3 digits 439 2 eiSos internal, 2 digits 01 3 Hardware version, 3 digits V2.4 = 024, V12.
20.2 General labeling information The module labels may include the following fields: • Manufacturer identification WE, Würth Elektronik or Würth Elektronik eiSos • WE Order Code and/or article alias • Serial number or MAC address • Certification identifiers (CE, FCC ID, IC, ARIB,...) • Bar code or 2D code containing the serial number or MAC address The serial number includes the product ID (PID) and an unique 6 digit number. The first 1 to 3 digits represent the PID, then the ".
21 Bluetooth SIG listing/qualification Type Data Design name Proteus-III Declaration ID D047845 QDID 141060 Specification name 5.1 Project type End product Each product containing intellectual property of the Bluetooth® Special Interest Group (SIG) must be qualified by the SIG to obtain the corresponding Declaration ID. Every new Bluetooth® design must pass the qualification process, even when linking to a Bluetooth® design that is already qualified.
To perform the qualification process of a product integrating Proteus-III, please go through the following steps: 1. Visit https://www.bluetooth.org/tpg/QLI_SDoc.cfm . 2. Select option "Start the Bluetooth® Qualification Process with NO Required Testing". 3. Enter the QDID (see above) and select the corresponding Proteus-III entry. 4. Select your pre-paid Declaration ID (it can be selected as soon as the Declaration ID has been paid). 5. Follow the subsequent steps to finish the qualification process.
22 Regulatory compliance information 22.1 Important notice EU The use of RF frequencies is limited by national regulations. The Proteus-III has been designed to comply with the R&TTE directive 1999/5/EC and the RED directive 2014/53/EU of the European Union (EU). The Proteus-III can be operated without notification and free of charge in the area of the European Union. However, according to the R&TTE / RED directive, restrictions (e.g. in terms of duty cycle or maximum allowed RF power) may apply.
22.5 FCC Compliance Statement FCC ID: R7T1101102 This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions: (1) this device may not cause harmful interference, and (2) this device must accept any interference received, including interference that may cause undesired operation. (FCC 15.19) Modifications (FCC 15.
• A label must be affixed to the outside of the host product with the following statements: This device contains FCCID: R7T1101102 This equipment contains equipment certified under ICID: 5136A-1101102 • The final host / module combination may also need to be evaluated against the FCC Part 15B criteria for unintentional radiators in order to be properly authorized for operation as a Part 15 digital device.
22.7.1 Pre-certified antennas The Proteus-III is pre-certified with the following antennas. Product Certified antenna Proteus-III (2611011024000) PCB antenna included in the Proteus-III Proteus-III reference manual version 0.11 www.we-online.
22.8 ARIB Declaration of conformity Japanese Radio Law Compliance. This device is granted pursuant to the Japanese Radio Law. This device should not be modified (otherwise the granted designation number will become invalid) ID-Code (Interference provision) The MAC address of the radio device maintains the format 00:18:DA:xx:xx:xx. The latter part xx:xx:xx of the MAC address coincides with the serial number of the device. 22.8.
23 Important notes The following conditions apply to all goods within the wireless connectivity product range of Würth Elektronik eiSos GmbH & Co. KG: 23.1 General customer responsibility Some goods within the product range of Würth Elektronik eiSos GmbH & Co. KG contain statements regarding general suitability for certain application areas.
23.5 Product improvements Due to constant product improvement, product specifications may change from time to time. As a standard reporting procedure of the Product Change Notification (PCN) according to the JEDEC-Standard, we inform about major changes. In case of further queries regarding the PCN, the field sales engineer, the internal sales person or the technical support team in charge should be contacted. The basic responsibility of the customer as per section 23.1 and 23.2 remains unaffected.
24 Legal notice 24.1 Exclusion of liability Würth Elektronik eiSos GmbH & Co. KG considers the information in this document to be correct at the time of publication. However, Würth Elektronik eiSos GmbH & Co. KG reserves the right to modify the information such as technical specifications or functions of its products or discontinue the production of these products or the support of one of these products without any written announcement or notification to customers.
a failure of the product is reasonably expected to cause severe personal injury or death, unless the parties have executed an agreement specifically governing such use. Moreover, Würth Elektronik eiSos GmbH & Co. KG products are neither designed nor intended for use in areas such as military, aerospace, aviation, nuclear control, submarine, transportation (automotive control, train control, ship control), transportation signal, disaster prevention, medical, public information network etc.
25 License terms This License Terms will take effect upon the purchase and usage of the Würth Elektronik eiSos GmbH & Co. KG wireless connectivity products. You hereby agree that this license terms is applicable to the product and the incorporated software, firmware and source codes (collectively, "Software") made available by Würth Elektronik eiSos in any form, including but not limited to binary, executable or source code form.
design-in stage. In certain customer applications requiring a very high level of safety and in which the malfunction or failure of an electronic component could endanger human life or health, you must ensure to have all necessary expertise in the safety and regulatory ramifications of your applications.
25.6 Limitation of liability Any liability not expressly provided by Würth Elektronik eiSos shall be disclaimed. You agree to hold us harmless from any third-party claims related to your usage of the Würth Elektronik eiSos’ products with the incorporated Firmware, software and source code. Würth Elektronik eiSos disclaims any liability for any alteration, development created by you or your customers as well as for any combination with other products. 25.
List of Figures 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Block diagram of the module . . . . . . . . . . . . . . . . . . . . . . . . . . . Radio transmitting @ 8 dBm output power, 1 Mbps BLE mode, Clock = HFXO, Regulator = DC/DC (typical values) . . . . . . . . . . . . . . . . . . . . . . . . Current consumption calculation in advertising mode with 40ms advertising interval with 8 dBm output power, UART disabled . . . . . . . . . . . . . . . .
7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 Pinout, first part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Pinout, second part . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . LED behavior of the Proteus-III . . . . . . . . . . . . . . . . . . . . . . . . . . Message overview: Requests 1 . . . . . . . . . . . . . . . . . . . . . . . . . . Message overview: Requests 2 . . . . . . . . . . . . . . . . . . . . . . . . . .
more than you expect Internet of Things Contact: Würth Elektronik eiSos GmbH & Co. KG Division Wireless Connectivity & Sensors Max-Eyth-Straße 1 74638 Waldenburg Germany Tel.: +49 651 99355-0 Fax.: +49 651 99355-69 www.we-online.
