Aaron Hanson
allaboutcircuits.com
Learn how to use a Microchip Bluetooth module to prototype digital input and digital control peripherals.
In this article, the three in a four-part series on Microchip's RN487x Bluetooth modules, I'll show you how to create a digital input (a switch) and a digital control (of an LED).
Please refer back to Part 2 of article for background and instructions on how to configure the RN487x module.
Project 1: RN478x Digital Input Switch
Our design pattern has three components we need to provide:
- Hardware: Task-specific hardware to generate the digital signal
- Configuration: RN487x module commands to allocate a variable in a database, and to map the signal to the variable
- Application: Script on a workstation, to accept the database value
What follows is the component breakdown.
Digital Input Hardware
The role of ‘digital input’ is simply provided by a switch; SW1 (Figure 5).
Figure 5. | The role of ‘digital input’ is simply provided by a switch. |
The RN487x module has internal pullups on the pins, so a normally-open switch connected to ground on closure will give us the necessary 2-state control.
Since we are only managing one signal and we aren't using PWM, we’ve chosen the RN4871. The circuit can be powered by a pair of AAA batteries, or even a coin-cell (Figure 6).
Figure 6. | Schematic diagram of connecting a switch to a RN4871 module. |
The remaining circuit elements are;
- C1: A bypass capacitor to stabilize power
- R1,C2: A delay for the processor reset at power-on
- J1: A serial port for configuration
Digital Input Configuration
Before creating the configuration for this example, make sure the module is in a known state. This is described in the Part 2 on common initialization. Do not skip this step!
We only need one characteristic in the database to represent our sensor state. So we create one service, and one characteristic in that service. The two corresponding commands are:
PS,59c88760536411e7b114b2f933d5fe66
PC,59c889e0536411e7b114b2f933d5fe66,10,01
The first command, PS, creates the service. The second command, PC, creates the characteristic. In both commands, the first parameter is the identifier that allows our peripheral to exist in the universe of other Bluetooth peripherals and still be accessed uniquely. This parameter must conform to the UUID standard. You can use the example values shown. It is also easy to create any number of standard UUIDs [1].
In the PC command, the second parameter tells the Bluetooth layer how changes in the value should get to the client. In this case the parameter "10", says that changes to the value can result in an immediate notification to clients. This is an important part of our intent for this example. Finally, in the PC command, the third parameter defines the size of the value in bytes; just one in this case (01).
The script part of our configuration looks like this:
@PW_ON
SW,0A,09
@PIO1H
SHW,0072,01
@PIO1L
SHW,0072,00
There are three methods in this script, each prefixed with ‘@’. Each method runs on a specific system event.
- PW_ON: Runs at power-on. The method configures our pin of interest (P1_2) as a ‘triggered’ digital input signal.
- PIO1H: Runs whenever the trigger signal transitions to high. The method writes a ‘1’ to the database.
- PIO1L: Runs whenever the trigger signal transitions to low. The method writes a ‘0’ to the database.
Digital Input Application
The Python script is switch.py and can be found in Download section. Edit the script and replace the sample MAC address with the MAC address of your device. Then, to exercise the example, simply apply power to the peripheral, then run the script on a system with the appropriate Bluetooth capabilities. See the appendix for help with this setup in Linux. The script will issue messages to indicate progress while connecting to the peripheral. After the peripheral is connected, press and release the switch a few times. Every open/close event of the switch will be noted with a message from the running script.
The script is short and includes comments for all the function blocks and GATT API calls.
The BLE feature we use that is unique to this example is notification.
We use a callback method to handle a signal change from the peripheral when it happens. We don’t need to poll the peripheral to learn the state of the signal.
We must tell the peripheral that we want these notifications by writing to a system characteristic.
Project 2: RN487x Digital Control
Our design pattern has three components we will need to provide:
- Hardware: Task-specific hardware to express a digital output
- Configuration: RN487x module commands to allocate a variable in a database, and to map the variable to the signal
- Application: Script on a workstation, to write the database value
What follows is the component breakdown.
Digital Control Hardware
The role of ‘digital output’ is simply provided by an LED; D1 (Figure 7).
Figure 7. | The role of ‘digital output’ is simply provided by an LED. |
The RN487x module reference circuits suggest open-collector GPIO so we illuminate the LED accordingly, by sinking current.
Since we are only managing one signal and we aren't using PWM, we’ve chosen the RN4871. The circuit can be powered by a pair of AAA batteries, or even a coin-cell (Figure 8).
Figure 8. | Schematic diagram of connecting LED to a RN4871 module. |
The remaining circuit elements are;
- C1: A bypass capacitor to stabilize power
- R1,C2: A delay for the processor reset at power-on
- J1: A serial port for configuration
Digital Control Configuration
Before creating the configuration for this example, make sure the module is in a known state. This is described in the Part 2 on common initialization.
Do not skip this step!
We only need one characteristic in the database to represent our sensor state. So we create one service, and one characteristic in that service.
The two corresponding commands are:
PS,59c88760536411e7b114b2f933d5fe66
PC,59c889e0536411e7b114b2f933d5fe66,08,01
The first command, PS, creates the service. The second command, PC, creates the characteristic. In both commands, the first parameter is the identifier that allows our peripheral to exist in the universe of other Bluetooth peripherals and still be accessed uniquely. This parameter must conform to the UUID standard. You can use the example values shown. It is also easy to create any number of standard UUIDs [1].
In the PC command, the second parameter tells the Bluetooth layer how changes in the value should get to the peripheral. In this case, the parameter (08), says that the peripheral must send a confirmation to the client when a value is changed. Finally, in the PC command, the third parameter defines the size of the value in bytes; just one in this case (01).
The script part of our configuration looks like this:
@CONN
|O,08,72
There is just one method in this script ‘@CONN’. It runs each time a client connects to the peripheral.
The single script line is a ‘handle association’ command, with a very powerful result. It associates the database variable with a digital pin output command. The "08" parameter is a bitmask that specifies the pin that our LED is connected to. The "72" parameter is a unique and permanent handle to the characteristic we created in the database. So after a client connects, every time the client writes a new value to the database variable, our LED will go on or off accordingly.
Digital Control Application
The Python script is light.py and can be found in Download section. Edit the script and replace the sample MAC address with the MAC address of your device. Then, to exercise the example, simply apply power to the peripheral, then run the script on a system with the appropriate Bluetooth capabilities. See the appendix for help with this setup in Linux. The script will issue messages to indicate progress while connecting to the peripheral. After the peripheral is connected, the script will send a new command to the peripheral every second. The commands will turn the LED on and off.
The script is short and includes comments for all the function blocks and GATT API calls. The BLE feature we use that is unique to this example is handle association.
You can see this whole example in action in the accompanying project video.
This concludes part 3 of our four-part series on the RN487x module.
Part 4 will follow the same design pattern to create an analog sensor and an analog control. It will also include some topics for further study that apply to all the examples projects.