This project is split between two components, transmitter and receiver. The transmitter is configured to send a predetermined signal to the receiver upon the push of a button. The message sent is a direction of clockwise or counterclockwise which is represented as 1 or 2 in the byte sent. This message is taken in by the receiver which then determines which output pin to trigger, thus spinning a motor attached to the receiver either clockwise or counterclockwise. This motor will then lock or unlock a deadbolt. This configuration is for visual demonstration of how the radios work, and can be reconfigured to perform any task which can be conceived of using 2.4GHz communication.
The transmitter uses a CC2500 low cost, low power 2.4 GHz RF Transceiver from Anaren as the radio module and the RL78 G12 microcontroller from Renesas. Also connected to the microcontroller is a button which triggers an interrupt when pressed, initiating the sending of data. The radio communicates with the microcontroller via 4-pin serial peripheral interface (SPI) in order to send data to the receiver. Since the radio is acting as a slave, the MOSI and MISO ports on the radio module are configured for SO and SI (Slave In and Slave Out). Once the packet is configured in the microcontroller code, the microcontroller sends the packet to the radio which then broadcasts it out to the receiver. This entire unit is powered via coin battery.
| Transmitter | Schematic | |
The receiver uses the same radio module and microcontroller. The radio on the receiver is also acting in slave mode, using the same SPI interface for passing data from the radio to the microcontroller. Additionally, the receiver has a multicolor LED which is used to test signaling the clockwise and counterclockwise direction of the motor. Then, of course, is the motor which operates at 9V. This unit is powered by a 16V DC power jack which feeds from a standard wall outlet.
| Receiver | Schematic | |
In the transmitter code we begin by defining the pins on the RL78 to the corresponding pins on the CC2500 radio module and the button that triggers the message. There are also some constants used for normal operations of the radio module like entering the receive or transmit states which are set up. For the main portion of the code (i.e. upon first startup or after a reset) we begin by initializing the ports on the RL78 for their respective functions. That is to say: all pins should be in digital mode; P1.1, P1.3, P1.4 and P4.1 should be configured for input. P1.1 corresponds to the input from the radio module (slave device), P1.3 corresponds to GDO0 (General Digital Output pin) on the radio module and is an interrupt pin and the same for P1.4 which corresponds to GDO2, and P4.1 is the button pin. The pull-up resistor option should be set on port 4 corresponding to the button pin to identify a particular range in which the button is to be considered active (pressed). This is because the speed at which a human can trigger the button is much slower than the device can read it, therefore there must be an acceptable range at which the button approaches closing of the connection to the lines which is considered "close enough" to trigger the sending of a packet.
After this setup of the ports the clock and SPI interface are set up. The SPI interface operates primarily on the P1 pins, and CS (Serial configuration interface, chip select) operates on P2.1. After setup of the SPI interface, we configure the registers for the radio module. The registers are configured using the SmartRF Studio software provided by Texas Instruments. We accept the defaults with a couple exceptions:
In MCSM1 the transmitter should be in the IDLE state after sending a packet. In MSCM0 we want to automatically calibrate when going from IDLE to RX/TX and we set our PO_TIMEOUT to 64. Given our desired values we call the Init_CC2500 method which utilizes the SPI interface to load the values to the radio. One thing to note in this method is that we clear CS (represented by *CS on the diagram). This is a requirement for transmission over the SPI interface bus and will happen anytime communication over the SPI interface bus should be enabled. Once CS is low, we wait for MISO (Slave Out, in this case) to go low which is the second requirement for transmission over the SPI interface bus. If CS goes high during a transfer, that action is cancelled. At the end of the Init method, we call Send_CC2500 which then loads the register data to the radio itself and sets them. We then return to the main method to enter the main loop after setting the direction bit (clockwise or counterclockwise for the motor), the button state, and the button interrupts.
In the main loop, we clear the button interrupt flag, enable the button interrupt and then go to sleep. Once the button is pressed, the interrupt is raised and the microcontroller begins to process the transmission of a packet. After the interrupt is raised, the microcontroller must check the button state to see if it is up or down. For this the logic is to check whether the button is pushed, if it is then compare the shift value for the button de-bouncing to the release threshold and set the button state to off if the threshold is met then return to waiting for the next button press. If the threshold was not passed then we must delay for a period of time and check again what the state of the button is. Similarly, if the button state is off (which it is initially), then we expect that the button is in the process of being pushed. If the button has not passed our threshold for being pushed down then we must wait for a period of time and check again. Once we pass our threshold, the transmission can finally take place. Our packet is simple: comprised of preamble bits and sync word, which are automatically handled by the radio module; a length field giving the length of the packet in bytes; the address field to specify the device which the packet came from; the data field containing the message being sent, in our case 1 or 2 for the direction; and an optional CRC code which is also handled by the radio module. Once the packet is composed, we strobe the radio to enter the transmission state. After transmission of the data we return to the main loop, clear and enable the button interrupt and then sleep; waiting for the next button push.
The receiver is in many ways similar to the transmitter as the same basic rules apply between the radio module and microcontroller. The receiver waits for a packet instead of waiting for a button press but the concept is similar. One other major difference between the two is that the transmitter is operating off a coin battery whereas the receiver is powered by a wall outlet, making power consumption of very little concern so we don't enter a sleep state upon reception of a packet (which would require the enabling of Wake on Radio control in the registers). Additionally, while the SPI interface is configured the same, the receiver module has a few more pins used as outputs compared to the transmitter module. Namely, P2.0, P4.2, P6.0 and P6.1 are all used for outputs to the 2 LEDs and the motor directions respectively. The pins on port 6 are connected to an H-bridge which determines where the positive and negative ends meet the motor and alternates the direction depending on the output values. The radio registers are set up with the same values as the transmitter code and the SPI interface is used in similar fashion.
In the main loop we immediately call the receive packet method which checks for the transmission of a packet. Once a packet is received, the data is read and the direction bit is determined. After determining the direction a delay of 300ms is called over which the corresponding LED is lit and the motor is turned on. After the delay call, both are turned off and the process is repeated.
While the current configuration of these devices is set to rotate a motor upon the press of a button, several possible enhancements and variations could be made. Currently, the transmitter only sends a simple 1 or 2 message to the receiver. This message could be made to be anything and could be encrypted using something like an RSA algorithm to increase security of the traffic. Currently everything is simply transmitted in the open. A similar project done using an Arduino board and Bluetooth module even has an app developed which accepts a pin code to open or close a solenoid lock. Here is the link to that project.
Last modified:Mon, Jan 23, 2023.