Hints and tips when using RC1xx0 RF Modules

Transcription

1 AN001 : HI NTSANDTI PS WHENUSI NGRC1 XX0RFMODULES WeMakeEmbeddedWi r el ess Easyt ouse

2 Hints and tips when using RC1xx0 RF Modules By H.Moholdt Keywords Interfacing to RS232/RS485/RS422 level shifters Using a terminal window for easy configuration Troubleshooting Introduction The RC1xx0 series of RF Modules with integrated protocol offers easy adaption of wireless communication utilizing a simple UART serial interface. This document addresses notes related to using a standard level shifter together with the module, practical considerations to ease the setup of the radio module and finally troubleshooting hints and tips. Interfacing to RS232/485/422 Level Shifters The modules provide an UART interface which is widely described in the literature and is a simple to use module-to-microcontroller interface. To interface to computers and peripherals with RS232/485/422 interface, one single integrated circuit is required for level shifting. There are numerous vendors of such ICs. The RC1xx0DK Demonstration Kit utilizes a ST3232 (MAX3232) level shifter (3V version) to convert the UART interface to a standard RS232 interface for connection to a computers serial interface. With a single IC (and required capacitors for the voltage translator inside) the RC1xx0 modules offer simple cable replacement. If you operate your level shifter at 5V, remember that the maximum output voltages of the module are always 2.7V, regardless of the voltage applied to the VCC pin as it is internally regulated. Ensure that your level shifter has threshold voltages which match this voltage. Note also that pin 5 on the module (TXD) is OUTPUT from the module and shall typically be connected to a pin named TNin while pin 6 on the module (RXD) is INPUT to the module and is typically connected to a pin named RNout on a level shifter. See also the schematic for RC1xx0DK in the Demonstration Kit User Manual as a reference for connection. For handshaking and collision avoidance on a half-duplex connection the module provides RTS (Ready To Send) and CTS (Clear To Send). RTS is a Request to send from the party which have data to transmit while CTS can be seen as an acknowledge to do so, Cleared to send. Please see more about this feature in widely available literature. Default factory setup for the modules is no flow control, but this can easily be re-configured. 9-Pin DSUB TXD RTS RXD CTS T2OUT R2IN MAX232 T1OUT R1IN R1OUT T1IN T2IN R2OUT Not shown are external capacitors. Only signalling pins are shown GND CTS RTS CONFIG TXD RXD GND RC1xx0 Page 2 of 8

3 Using a Terminal Window for Easy Programming As described in the RC232 User Manual, asserting CONFIG brings the modules into configuration mode. By using a commercial PC Terminal Program (TP) sending configuration instructions via the UART is simple. Configuration means changing frequency, addressing information etc. The TP usually requires communication via a serial interface like RS232, named the COM-port (COM1-COMn). The most available terminal program is HyperTerminal, installed with Windows operating system on most computers. HyperTerminal, however, only offers ASCII code communication. This is useful if you want to test wireless communication between two computers, which can be done without any change in the module default setup. As soon as you want to change the default settings a terminal program with hex-code facilities is necessary. There are numerous vendors of such. One of them is LOOK RS232 being available from Below is an example of configuring an RC1xx0 module by the use of this program. Make a Connection with the COM1-port (File -> Connection) with setup as described in the RC232 User Manual (19.2kBd, no flow control etc). By enabling Hex and Chr simultaneously from the vertical taskbar in LOOK (the narrow field in the middle of the screen) you can see both ASCII and Hex response in the window to the right. Enable also the Input and Output data stream from the same toolbar so you can observe data in both directions on the bus. Task; we will change the default-settings for PACKET_TIMEOUT in the non-volatile configuration memory. According to RC232 User Manual page 6 this memory location is 0x10 and setting this parameter to 0x03 is done by the following sequence; M, 0x10, 0x03, 0xFF, X Once you seen the reply > after asserting CONFIG do the following from the "Data Send Task" window (upper left window): hexadecimal 4D hexadecimal 10 hexadecimal 03 hexadecimal FF hexadecimal 58 (Remember 4Dh = ASCII M and 58h=ASCII X ). Step one by one instruction-line by using the down-arrows in the very left toolbar. Remember to place the cursor at the first instruction line before sending data at this line with the down-arrow. Observe the response from the module in the status window to the right. After the final character, there shall be no > as the module is out of CONFIG-mode and back in IDLE mode. Page 3 of 8

4 The instruction '0' (ASCII zero ) reads out the entire configuration memory. If you enter this character after pressing CONFIG again, all memory locations are read into the status window. By enabling 8B (8 Bytes per line) and disabling R (Reverse fill order) in the middle taskbar, 8 bytes will be written per line, starting with memory location 0x00 at the top left. The location 0x10 (16d) should have changed from 0x7C (124) to 0x03. Change it back again to the default value 124 if you will keep the module in the default condition with 2 s timeout. Troubleshooting Topics The topics addressed below are based on frequently asked questions. Physical interfacing: The modules have an internal voltage regulator providing low noise 2.7 V for the radio transceiver. The I/Os are 5V input tolerant but there is no internal level shifting above 2.7 V, i.e. all output voltages swing between 0 and max 2.7 V. Ensure your external connections to the module have threshold voltages which allows for communication towards 2.7 V logic. Also, note that the output impedance of the I/O pins is 100 kω as given in the datasheet. This implies that the load should be high impedance (CMOS or similar) to not reduce logic level. Loading the output pins capacitive or with low impedance circuitry could reduce signal integrity. Checks for correct connections: - Pull ON/OFF pin high (VCC) for power ON to the module - CONFIG must be pulled high when not in CONFIG-mode - Current consumption in IDLE/Receive mode is approximately 10 ma for RC10x0 and 20 ma for RC12x0. If both RXEN and TXEN is pulled low, SLEEP mode is entered with low current consumption as a result (85 ua for RC10x0 and 0.9 ma for RC12x0) Page 4 of 8

5 - Connect RXEN and TXEN directly to VDD if you will not use hardware-enabling of SLEEP-mode. Software-activated SLEEP using Z command will still work. - Check for 2.7 V at VDD pin - Check for 32 khz oscillator signal at pin 20 If all these parameters are measured OK the module is correctly connected and other troubleshooting efforts should be guided towards configuration of the module and communication towards it. Communication hints: Permanent/Non-permanent memory configuration: As specified in the RC232 User Manual there are two ways of storing default setup for the module. Setup stored in the non-volatile memory will be kept after power off and reset. Most parameters are only possible to change and store in non-volatile memory by sending the Memory Configuration command M as the first character, as in the example above. Some parameters can be changed on the fly and temporarily stored, as is the case for Channel ( C ), Output power ( P ), and Destination address ( T ). The two types of configurable parameters are shown in two different tables in the User Manual. PACKET_TIMEOUT: If set to 0 (zero = None ) the module transmits only when buffer is full or PACKET_END_CHARACTER is received. That is, the timeout-function is disabled, not set to zero length. In this mode the module could act as stuck in absence of end character or before the number of characters in the buffer reaches PACKET_LENGTH. Handshaking: In buffered mode the module disables its UART during radio-transmission of a packet. This means, when the module is emptying its buffer after timeout (starting after last received character), full buffer or received end character, it will not read the UART, and characters presented will not be buffered but rejected. This is typically the case if you continuously enters characters from a terminal window and fills up the buffer; When the module starts to transmit, characters entered during the transmission will be ignored. The handshaking signals RTS and CTS can be used to stop the host from entering characters to the UART when the module is busy. See timing diagram in datasheet. RSSI: For the RC10x0-modules, RSSI is an analogue voltage at pin 19. For the RC12x0-modules the RSSI is a byte returned after sending the S command. Remember the analogue RSSI is nominal V (no signal present) and lowered by increasing input power. Also, the RSSI is only affected when a signal is received. In buffered mode the RSSI must be monitored with an oscilloscope (RC10x0) and the voltage will drop during packet reception, or S must be sent during the reception of a packet (RC12x0). VCC rise time versus power on reset: If VCC has a slope slower than specified in the datasheet the internal power-on reset could fail. If this happens, the module may fail to initialize correctly. However, in most cases the internal Watchdog will reset the module after 2 seconds. To ensure proper power up sequence there are at least two solutions; A. The ON/OFF pin could be controlled by a Supervisory Circuit (IC) like Microchip MCP , often also connected to a microcontroller if used in the system. B. Assess RESET after VCC has reached at least 2.8V. Lost transmissions and extra characters: Radio signals are susceptible to interference and from time to time this will cause bit errors. Note the following: With CRC enabled a whole packet will be rejected even with only a single bit error With CRC enabled two or more bit-errors can give the same CRC-byte and then pass through, so CRC enabled does not guarantee for absolutely no received bit errors Page 5 of 8

6 Usually, with received extra characters this is due to unintentional transmissions at the transmitting module. Check for unintentional UART transitions (interpreted as start-bits which will cause a timeout transmission with or without CRC enabled) If you enable CRC at the transmitting module while omitting CRC at the receiving module, two extra bytes (the CRC) will come through. This will of course not work in the opposite direction. Some RS232 I/O cards and some USB to RS232 converters remove any spacing between two following characters. If you send a text string without using handshaking or press enter (enter = carriage return and line feed, i.e. two ASCII characters) with no delay between the two characters this could cause transmission errors. There must be a delay of 78 us (1.5 stop-bit) between two characters on the UART (see datasheet). For some I/O cards and converters configuring extra stop-bits (1.5 or 2 stop-bits) will not help since the hardware (or firmware inside) removes the extra stop-bits. If you experience communication problems, observe RXD on the transmitting module to ensure there is sufficient delay between the UART stop-bit and the following start-bit, or enable handshaking. Page 6 of 8

7 Document Revision History Document Revision Changes 1.0 First release 1.1 Design Update Disclaimer Radiocrafts AS believes the information contained herein is correct and accurate at the time of this printing. However, Radiocrafts AS reserves the right to make changes to this product without notice. Radiocrafts AS does not assume any responsibility for the use of the described product; neither does it convey any license under its patent rights, or the rights of others. The latest updates are available at the Radiocrafts website or by contacting Radiocrafts directly. As far as possible, major changes of product specifications and functionality, will be stated in product specific Errata Notes published at the Radiocrafts website. Customers are encouraged to check regularly for the most recent updates on products and support tools. Trademarks RC232 is a trademark of Radiocrafts AS. The RC232 Embedded RF Protocol is used in a range of products from Radiocrafts. The protocol handles host communication, data buffering, error check, addressing and broadcasting. It supports point-to-point, point-tomultipoint and peer-to-peer network topologies. All other trademarks, registered trademarks and product names are the sole property of their respective owners. Life Support Policy This Radiocrafts product is not designed for use in life support appliances, devices, or other systems where malfunction can reasonably be expected to result in significant personal injury to the user, or as a critical component in any life support device or system whose failure to perform can be reasonably expected to cause the failure of the life support device or system, or to affect its safety or effectiveness. Radiocrafts AS customers using or selling these products for use in such applications do so at their own risk and agree to fully indemnify Radiocrafts AS for any damages resulting from any improper use or sale. 2017, Radiocrafts AS. All rights reserved. Page 7 of 8

8 For More Information, Please Visit Our Website! VISIT NOW Tel: