The Proteus-II exists in two variants, one variant with integrated PCB-antenna, and the other
variant with 50Ω connection to an external antenna. For the general functionality there is no
difference between the variants.
The Proteus-II 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®LE 5
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.
The Proteus-II uses the Bluetooth®LE standard to provide general data transmission between several devices. The standard itself offers a wide range of configurations and possibilities to suit and optimize sophisticated customer applications. To fulfill the needs and
specifications of such applications a tailored firmware can be developed on the basis of the
Proteus-II hardware. This includes the connection and communication to custom sensors,
custom Bluetooth®LE profiles, timing configurations, security configuration as well as power
consumption optimizations.
1.1.1. Key features
The Proteus-II offers the following key features that are described in the manual in more
detail:
SPP-like connection-based secured data transmission: The Proteus-II firmware imple-
ments an SPP-like Bluetooth®LE profile that allows the bidirectional data transmission
between several Proteus-II and/or to other Bluetooth®LE devices implementing the
AMBER SPP profile. Any module in the network can initiate connection setup. Secured
connections allow the transmission of encrypted data (user-defined key or pairing).
Fast sensor data transmission via Beacons: The Proteus-II supports the transmission and
reception of Beacons. Beacons are fast broadcast messages that allow the energyefficient unidirectional transmission of data. Especially in sensor networks, this feature
is suitable for the frequent transmission of measurement data as it removes the need
for connection-based communication and therefore is more energy efficient.
Advanced customization capabilities: The configurable Device Information Service (DIS),
the UUID and the appearance of the Bluetooth®LE profile, enable to personalize the
Proteus-II to fuse with the user’s end product.
Low power position sensing solutions: The current TX power of any Proteus-II is always
transmitted with each advertising packet when the module is in command mode. With
this, distance estimation and position sensing solutions can be realized conveniently
by performing a passive scan.
Fast serial interface: The Proteus-II offers a UART-interface to communicate with a host
using a user-defined baud rate and a simple command interface.
Latest microprocessor generation provided by Nordic Semiconductor nRF52 series:
The heart of the Proteus-II is a Bluetooth®LE chip of the nRF52 series offering high
performance values combined with low power consumption. It is a 32 Bit ARM CortexM4F CPU with 512kB flash + 64kB RAM and up to 4dBm output power.
Bluetooth®5 stack: The Bluetooth®5 stack enables fast and energy efficient data trans-
mission using state-of-the-art technology of Nordic Semiconductors.
High throughput mode: The Proteus-II 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-II - Application Note 4".
All Bluetooth®LE roles supported: The integrated Bluetooth®LE stack supports all Bluetooth®LE
roles. Depending on the current state of operation the Proteus-II firmware automatically switches its role to execute the user’s instructions.
Flexible wired interfacing: If custom hardware does not support UART communication or
in case of a host less implementation, the Proteus-II is equipped with extra pins suited
for custom device/sensor connection. With help of these, a tailored firmware can be
developed which is optimized to the customer’s needs. The pins can be configured to
various functions such as UART, SPI, I2C, ADC, PWM, NFC and GPIO.
OTA firmware update: The Proteus-II firmware provides over the air firmware update ca-
pabilities. Firmware updates can be applied using the Nordic Apps for cell phones.
Peripheral only mode: The Proteus-II firmware provides the "peripheral only" operation
mode (see chapter10), that allows the easy adaption of already existing custom hardware with the Bluetooth®LE interface. By default, this mode offers the static passkey
pairing method with bonding and a transparent UART interface. With this, custom hardware can be accessed by mobile Bluetooth®LE devices (like smart phones including
a custom App) using an authenticated and encrypted Bluetooth®LE link without the
need of configuring the module.
1.1.2. Connectivity
The Bluetooth®LE standard allows to setup a network with various Bluetooth®LE devices
from different manufacturers. To be able to communicate with Proteus-II devices, the AMBER SPP-like profile must be known and implemented by all network participants. Thus
arbitrary Bluetooth®LE devices (like iOS or Android devices) must implement this profile,
too. To do so, the Proteus-II application note 1 contains the design data of the AMBER
SPP-like profile.
Table 4: Power consumption for 100% transmission/reception
Due to the Bluetooth®LE time slot operation, the real operating currents are
reduced significantly and depend on the user selectable advertising and connection interval settings.
1
Transmitter only with DC/DC converter from nRF52 data sheet.
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 Figure3and
Figure4). 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.
Nordic Semiconductor provides an online tool calculating the average current of a Bluetooth
connection. It can be accessed at https://devzone.nordicsemi.com/power/ .
with external antenna. In case of module with
integrated antenna, do not connect.
2GNDSupplyGround
3SWDCLKInput
4SWDIOInput
5P0.21/RESETInput
Serial wire clock. Uses internal pull down resistor. Do not connect if not needed.
Serial wire input/output. Uses internal pull up resistor. Do not connect if not needed.
Reset pin. A low signal resets the module. Uses
internal pull up resistor.
Boot pin. A low signal during and short after re-
6P0.05/AIN3BOOTInput
set starts the module in OTA bootloader mode.
Uses internal pull up resistor1. Do not connect if
not needed.
7VDDSupplySupply voltage
Operation mode pin with internal pull down resis-
8P0.10/NFC22OP_MODEInput
tor1during start-up. Low level or open: Normal
Mode. High level: Peripheral only Mode. Do not
connect if not needed.
9P0.09/NFC12RESERVEDI/ODo not connect.
10P0.00/XL1
3
LED_1Output
Indicates the module state (active high). Do not
connect if not needed.
11P0.01/XL2
3
LED_2Output
Indicates the module state (active high). Do not
connect if not needed.
12P0.02/AIN0UTXDOutputUART(Transmission)
13P0.03/AIN1URXDInput
14P0.04/AIN2/RTSOutput
15P0.28/AIN4/CTSInput
UART (Reception). Uses internal pull up resistor1.
Only used if flow control is enabled. Do not connect if not needed.
Only used if flow control is enabled. Do not connect if not needed.
Wake-up will allow leaving the system-off mode
16P0.29/AIN5WAKE_UPInput
or re-enabling the UART. Uses internal pull up
resistor1. Do not connect if not needed.
17GNDSupplyGround
Table 8: Pinout
1
Internal pull ups or pull downs are configured at startup by the firmware installed in the SoC. The pull up on
the /RESET pin cannot be disabled by firmware.
2
NFC pins available for NFC function in custom firmware. The standard firmware of Proteus-II does not
implement this function.
3
Pins available to connect an external crystal in custom firmware. The standard firmware of Proteus-II does
In factory state the modules are immediately ready for operation; the following pins are required in the minimal configuration:
VDD, GND, UTXD, URXD, /RESET
If the flow control is enabled additionally the pins /RTS and /CTS shall be connected.
We recommend to additionally have the pins SWDIO and SWDCLK accessible in order to
support a fail-safe firmware update. A standard socket on the customer’s PCB for connecting a flash adapter can be useful for debugging purposes (e.g. a JTAG 2*10 pin header with
2.54mm pin-to-pin distance).
Implementing the fail-safe firmware update method using the SWD interface is
recommended. Without having the SWD interface available a fail-safe firmware
update on a customer PCB cannot be guaranteed.
If the module has to be connected to a PC, a converter (TTL to RS-232 or TTL to USB) has
to be used. See chapter3for details on all pins. Please refer to the Proteus-II-EV schemes
for a reference design.
The logic level of the module is based on 3V. A 5V logic level must not be
connected directly to the module.
4.2. 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
"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.
This section describes how to quick start the data transmission between two Proteus-II 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-II-EV is recommended.
Connect the two devices (modules, EV-boards or USB dongles) to a PC. A terminal program, for example hterm, is used to perform the communication via COM ports. The two
corresponding COM ports have to be selected and opened with a default configuration of
115200 Baud, 8 data Bits, 1 stop Bit and parity set to none (8n1).
To reproduce the following sequence, note that, the
is different, thus it has to be replaced it in the commands below. In addition, the
checksum has to be adjusted, when adapting any command. The command
structure and checksum calculation is described in chapter8.
Note that the module goes to
after
RF_AdvertisingTimeout
CMD_SLEEP_CNF
default value is 0s, which means that it will run forever.
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.
InfoModule AModule B
⇐ Response
started in
⇐ Response
started in
2. Request the
InfoModule AModule B
⇒ Request
⇐ Response
module A is 0x55 0x00 0x00 0xDA 0x18 0x00
⇒ Request
⇐ Response
module B is 0x11 0x00 0x00 0xDA 0x18 0x00
3. Connect module A to module B via Bluetooth®.
CMD_GETSTATE_CNF
ACTION_IDLE
CMD_GETSTATE_CNF
ACTION_IDLE
FS_BTMAC
CMD_GET_REQ
CMD_GET_CNF:FS_BTMAC
CMD_GET_REQ
CMD_GET_CNF:FS_BTMAC
mode.
mode.
of both modules.
with settings index 402 10 01 00 04 17
with settings index 402 10 01 00 04 17
: Module A
: Module B
of
of
02 41 02 00 01 01 41
02 41 02 00 01 01 41
02 50 07 00 00 55 00
00 DA 18 00 C2
02 50 07 00 00 11 00
00 DA 18 00 86
This example is taken from an older firmware. Using newer firmwares with the
optional Bluetooth®4.2 feature "LE Packet Length Extension", the maximum
supported payload per packet may be higher than 0x13.
The Proteus-II 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-II can operate in different states. Depending on the active state several commands of the command interface (see chapter7) are permitted to modify the state, configure
the module or transmit data over the radio interface. An overview of the different states and
the corresponding allowed commands can be found in Figure7.
When the Proteus-II is powered up, it starts in
advertises (Bluetooth®LE role "peripheral"), such that other devices in range (Bluetooth®LE
role "central" or "observer") can detect it and connect to it. If no connection was setup after
RF_AdvertisingTimeout
advertising.
The
ACTION_IDLE
stops advertising and scans for other advertising modules in range (Bluetooth®LE role "central").
When leaving the
in
ACTION_IDLE
The
ACTION_CONNECTED
other module (Bluetooth®LE role "peripheral") or by setting up a connection itself (Bluetooth®LE
role "central"). In this case it stops advertising and data can be transmitted and received
to/from the connected module. This state remains active as long as the module does not
disconnect itself (e.g. due to a timeout), no disconnection request from the connected device
is received.
When disconnecting, the module goes to
state also allows to switch to
ACTION_SCANNING
state and starts advertising again.
seconds, the module goes to
state with the corresponding command, the module is
state can be entered either by getting a connection request from an-