- Quick Links
- Useful Documentation
- Hardware Description
- Setting Up Your Terminal
- RN42 UART Commands
- Connecting to Remote Devices
- Sending Wireless Data
- Manipulating GPIO
- Restoring Factory Settings
- Contact the Author
The RN-42-EK board was used to evaluate the RN42 module.
If your computer has a built-in Bluetooth adapter, you can use that to communicate with a single RN42 module. If you don't have a built-in Bluetooth adapter in your computer, you can still experiment with the RN42...you'll just need two modules. You can connect the module(s) to your computer using a hard-wired connection. I would recommend using the RN-42-EK board to evaluate the module since it comes with an on-board USB interface. You don't need to worry about interfacing with any USB/UART bridge cable. The RN-42-EK comes with everything you need to start prototyping with the RN42.
Here are some additional items you might find useful:
RN-42-EK Pin Assignments
Once you have your module hard-wired to your computer, you need to setup your terminal software with the proper settings to properly communicate over UART. There are many free terminal programs available like Tera Term or RealTerm. If you are running Windows XP, you will have HyperAccess installed by default. Tera Term is my terminal emulator of choice. It supports multiple serial communication protocols, file transfer protocols, and also has a built in scripting language. For the purposes of this page, we are just interested in simple UART communication, so I will show you how to configure Tera Term to communicate with these modules.
You should be ready to communicate with your module over UART. To test it out, type the characters '$$$' and you should get 'CMD' as a response. If not, double check your connections and serial settings. Make sure all the Ground pins are connected! If you want to see every character that you type, you can turn on local echo by selecting "Setup" from the menu bar and clicking on "Terminal". The "Terminal Setup" dialog box has a check box for enabling/disabling local echo. Also, within the "Terminal Setup" dialog box, I like to set the New-line Receive setting to CR+LF. That way when you send a command to the RN42, it will send a newline before displaying a response.
I know you want to start wireless transmission right away without even having to think, but just tap the brakes for a minute. Let's take a quick look at some of the UART commands as they will be involved in later sections.
There are four types of UART commands for the RN42:
The module must be put in Command Mode in order to properly receive commands. This is accomplished by sending '$$$' over UART. You should get 'CMD' as a response indicating the module is in Command Mode. Type 'X' and press <enter> to view all of the current settings for the module. To exit Command Mode, send three minus signs and press enter (- - -<enter>).
The image shown to the right displays the serial readout after sending the 'X' command. We can see the firmware revision and date loaded at the top. Then we see the General Settings section which includes the module's Bluetooth address, name, UART baudrate, mode of operation, authentication setting, 4-digit pin code, whether or not bonding is enabled, and the remote address stored in memory. Next, we see the Advanced Settings which are specific to the Bluetooth standard and how you want your link setup. We won't mess with any Advanced settings on this page. At the bottom of the readout, we see the Other Settings section. This is where you can set the Bluetooth profile, CMD character, enable sniff mode, enable low power mode, change the TX power, set/read I/O pins, set/read the sleep timer, enable Debug mode, and switch roles.
I recommend reading through all of the available commands in the Command Reference Guide. For now, let's just touch on a few important ones.
Example: Set Authentication Setting to Open Mode
Alright, it's time to get our hands dirty.
By default, SSP authentication is enabled on the RN42 module. That means that the host will receive a prompt and you will need to confirm that you want to pair with the device. This allows you to easily connect a single RN42 with a PC or Android device. You simply confirm you want to pair with the slave, and begin wirelessly transmitting data (you may need to enter the default pin 1234 to pair with the device)......but what if you're not using your computer's built-in Bluetooth adapter? If you have two RN42 modules that you want to automatically connect to each other, the default authentication setting will cause problems. By default, two RN42 modules won't automatically connect without software configuration. You'll need to change the authentication setting to a value of either 0 (for Open Mode) or 4 (for Pin Code mode). Open mode will disable authentication and allow connection without a passcode or verification of any kind. Pin Code mode will require a 4-digit code to complete the connection. The default pin code for the RN42 is '1234' which is hard-coded into every module. Since the pin code matches in each device by default, Authentication setting 4 will allow automatic connection between two RN42 modules. Here's a breakdown of how to change the Authentication setting (remember if you are connecting a single RN42 to your computer, you don't need to worry about this):
Once authentication is disabled, the module can be bootstrapped to an automatic configuration using the appropriate I/O settings. To enable automatic communication with no host controller configuration, externally drive PIO3 and PIO6 high on one device and only PIO3 on the second device. This can be done using external jumpers, dip-switches, or pull-up resistors. For safety reasons, you should always use a pull-up resistor between the I/O pin and VDD, even if you are using jumpers or dip-switches (see Manipulating GPIO section below for details). On power up, as long as authentication is disabled, the devices will automatically connect and then any data received over UART will be immediately transmitted to the remote device. It's a good idea to power the slave device first and wait a few seconds before powering up the master. The master will typically fail to pair with the slave if they are powered up simultaneously. When connected, the green LED on the RN-42-EK will turn solid green.
The connection process can be completely software controlled if desired. One of the devices will need to be configured as the master. You can externally drive PIO6 high (with pull-up) to enable auto-master mode, or you can manually configure the module as a master using the SM command. If you know the address of the remote device you want to connect to, you can hard code the address into the master using the SR command. If you don't know the address ahead of time, you'll probably want to scan for devices using the I or IN commands. The IN command is faster, but doesn't return the Bluetooth name (see Command Reference Guide for more information). Here's a breakdown of how you would use the SM, IN, SR, and C commands to connect to a remote device through software:
The screenshot below shows the terminal windows during the manual connection procedure for the master and slave devices on the left and right, respectively. You can see the slave device was the third device found in the Inquiry scan (Roving Networks devices use the 0x1F00 COD). There is no feedback in the terminal that you have successfully connected to the remote device except to try sending characters. After connecting, characters typed in one terminal appeared in the second terminal. You can physically see the LED turn solid green on each RN-42-EK board when they have successfully connected.
Master (left) and Slave (right) Terminal Output During Manual Connection
Once the master and slave are connected, the Bluetooth link is seen as a transparent serial (UART) connection between the two hosts. In the example above, two PC terminal programs were used as the hosts and ASCII characters were used as the data. However, a microcontroller could also be used as the host controller for the RN42. Anything transmitted over UART will be received wirelessly by the remote device. The exception to this is if one of the modules is placed in Command Mode. As long as a module is in Command Mode, nothing will get transmitted wirelessly. However, as long as you don't mess with the link settings, the modules will remain connected and wireless transmission will resume once Command Mode is exited (- - -<enter>).
Note: The "T,1<enter>" command can be used to enable Bluetooth transmission while in Command mode.
The RN42 has a handful of GPIO pins that can be used for miscellaneous purposes. If you are using a microcontroller or FPGA to control the RN42, this gives you the opportunity to increase your I/O count. If you are using a terminal program as your host, it gives you some command based control over some digital I/O pins. Most GPIO pins are used by the firmware in some way. I would recommend not using the GPIO if you don't need to. If you need to use the GPIO pins on the RN42, I would recommend using GPIO9~11. These pins can only be used as outputs, but they aren't used by the firmware in any way. GPIO3 and GPIO6 can be used if auto-connect isn't desired and could be used as digital inputs.
Here is a breakdown of the GPIO pins on the RN42 and how they are used by firmware.
|Available GPIO||Default Function||Applicable UART Commands|
|GPIO2||Output - Status Pin (1=connected, 0=disconnected)||Not recommended for miscellaneous use.|
|GPIO3||Input - Auto discovery (high to enable)||SQ,4 S@ S& S% S^|
|GPIO4||Input - Restore Factory Defaults||Not recommended for miscellaneous use.|
|GPIO5||Output - Status Pin, toggles based on state, low when BT connected||Not recommended for miscellaneous use.|
|GPIO6||Input - Set BT Master (1=auto master)||SQ,4 S@ S& S% S^|
|GPIO7||Input - Set UART Baud Rate (1=9600, 0=115200/firmware control)||Not recommended for miscellaneous use.|
|GPIO8||Output - RF data TX/RX||Not recommended for miscellaneous use.|
|GPIO9||Input - pull-down enabled||G* S*|
|GPIO10||Input - pull-down enabled||G* S*|
|GPIO11||Input - pull-down enabled||G* S*|
See the RN42 UART Commands section above for command-based usage of these pins.
Note: If you are designing a custom board and plan on utilizing GPIO3, 4, 6, or 7 and their hardware bootstrapping features, you need to use pull-up resistors between these pins and Vcc, even if you are using jumpers or dip-switches. If you don't use pull-ups and connect Vcc directly to one of these pins, it will be fine as long as they are configured as inputs. But if you unintentionally configure one as an output, and Vcc is connected to one or more of these pins, you will have a dead short from VCC to GND which could wreck your module and/or power supply. There is no downside to adding pull-up resistors other than it takes a little bit more board space and adds pennies to your design cost. Both are negligible tradeoffs for most applications. You've been warned...do yourself a favor and USE PULL-UPS.
There are a variety of reasons why you may want to restore factory settings. You could have misconfigured something and want to start from scratch. Maybe you are pulling a module from the field and want to restore factory settings while it sits on a shelf. It's also possible that you are unable to communicate with the module locally due to UART baud rate or framing issues. Whatever the reason, rest assured there are a couple of ways to restore factory default values.
If you are unable to communicate with the module locally over UART, or if it's simply more convenient to perform a hardware restore, GPIO4 can be used in a special sequence to restore factory settings to the RN42. It's typically recommended to break out GPIO4 to a jumper or dip-switch with a pull-up to VDD to make it easy for the user to control GPIO4 externally. Here is the procedure for a hardware restore:
It's recommended to wait approximately 1 second between toggling GPIO4.
If UART communication with the RN42 is readily available, it's very easy to restore factory settings using the SF command. The SF command will reset all settings except the module's Bluetooth Name. Here is the procedure for a software restore.
You can verify settings were restored by entering command mode and sending the 'X' command.
The purpose of this page was to help you get started with RN42 modules and make it easier for you to implement them in your own design. They are very handy modules that make Bluetooth communication easy to achieve and take care of much of the required FCC testing for you. However, they do have a few quirks to them that can be frustrating at times and I hope this page eliminates some of that frustration. If you have questions, feedback, or would like to see something added to the wiki, let me know at email@example.com. I hope you enjoy experimenting with the RN42 from Microchip!
- Scott S.