Question: So why did I build my own remote when there are readily available remotes that come with the wireless receivers?

Answer: It became a challenge to remember that Button 1 is for this, and Button 2 is for that, not to mention having remote clutter.

Yes, I can put a "cheat-sheet" on the back of the remote, or otherwise label the buttons, but I wanted something that looks professional.

As well, the remote will at some point include IR (Optical Infra-Red) capability, so it will become an all-in-one remote.

Question: Why did I go with a stand-alone remote rather than incorporating WiFi or Bluetooth into a smartphone?

Answer: It is a performance issue really. Quite simply put, I tested devices such as the SonOff Wi-Fi to RF bridge. Testing determined that all of the available solutions had too much delay (the time delay between depressing/releasing the remote and the device responding to those commands).

This might be OK for turning lights on or off, but it could result in incorrect "parking" of awning motors, as well as excessive motor-stall time. Frankly, this solution is not high-performance enough for motor control.

As well, there is a lot of overhead, politics, and hoops to jump through by both Apple and Android in fielding apps for smartphones. While Android is not as bad, it is still cause for some headache. And Apple actually charges developers these days for fielding apps.

There are some apps in existance, but they either cost money (sometimes periodic fees), or require a network server, cloud, or even internet connectivity to function. That seems to me to be just too complex for this project.

Building this remote is not cheap. I spent $150 or so to build it. While on one hand it's a bit expensive, it's cost is in line with Lippert's Linc Remote transmitter. Also, a lot depends on parts sourcing. Since I built the remote in the winter time, I could wait a few extra days for delivery from less expensive component suppliers.

The readily available transmitter and receiver components of the seemingly ubiquitous Wireless Remote relays are quite common. They are readily available, cheap, and have sufficient range for our purposes. And they work remarkably well for my needs. They are known as ASK (Amplitude Shift Keying... i.e Amplitude Modulation) / OOK (On-OFF Keying) devices.

One thing I made sure of is that all of the devices I used were compliant with FCC (Federal Communications Commission) requirements. Not all devices available on Amazon, etc. seem to have the FCC logo on them. I am not sure if those devices are FCC compliant or not.

Generally when using these devices, two rules apply:

• The item in use cannot cause interference with other devices.
• You must accept any interference from other devices using the same frequency.

Fortunately, the Remote Relay system is simple and can be used for my purposes. Typically when you push a button, a 24bit code is sent from the remote. If the receiver is programmed to that code, it will respond with some action. Each button on the remote uses a different code, and the receivers can typically be progrmamed so that it's relay or relays can be mapped to a remote's button. Note that one remote's button can be mapped to multiple receivers, and in some cases, multiple receivers can be mapped to a single remote.

Most relay/receivers have 5 possible functions, although for the most part - all channels must have the identical function. You typically cannot assign one channel as Momentary, and another channel as Toggle.

• Latching (also known as Self-Lock, or Self-Latching)
• Toggle
• Momentary (also known as Inching, non-Latching, or Jog)
• Alternate (also known as Interlock or sometimes Latching - not to be confused with the above latching term)
• Delay (ON for a specified time delay, then OFF).

The latching function alternates it's state with every subsequent reception of the proper code. Typically, one button (code) is used for turning the relay ON, and a second button (code) is used to turn the relay OFF. This is the familiar A-B button scenario and requires a remote having two buttons. This would work well if you wanted to control a light.

The Toggle function is almost the same as latching, except it uses a single button (code). The first reception will turn the relay ON, the second reception will turn the relay OFF, and the third turns the relay ON again. It differs from Latching in that only a single button is required. Single button remotes that support Latching actually use Toggle mode to perform the ON-OFF action.

In the momentary function, the relay is on only as long as the transmit button is depressed - in other words, as long as the receiver receives the code. This would be appropriate for an awning motor, where you want the awning to extend or retract only while you keep the button depressed.

The Alternate function is not used a lot, but it is sometimes available. It is also only useful for multi-channel receivers (having more than one relay). The Alternate function combines a latching action with a selector action. In this scenerio, the channel receiving the code is turned on and all other channels are turned off. If you have ever seen a vintage automobile radio having a push-button channel selector, it works something like that.

A relative new function some remotes are beginning to include is a Delay mode. Sometimes the delay time is programmable too, usually in increments of 5 seconds. In this mode, the Relay turns ON when the button is depressed, then after 5, 10, or more seconds, the relay turns OFF.

Some manufacturers use different termonology such as inching, pulse, hold, toggle, or similar, but they all fall within one of the three descriptions above.

However, there are some limitations to these Wireless Relays that you need to be aware of - and one major reason I decided to build my own remote. As shown in the above graphic, there is no way to assign only 2 selected channels of a multi-channel remote to a multi-channel receiver. The receiver will respond to all of the channels on the remote. And the mapping is arbitrary. For example, receiver channel 1 might respond to transmit channel 1, 5, 6, and 12; receiver channel 2 might respond to transmit channel 4, 7, 11, and 15.

The only way to obtain a one-to-one receiver to remote relationship is to exclusively use single channel receivers.

A second limitation is many remotes are mapped with the same code. For example, I purchased 4 different transmit-receive pairs and all of the remotes had the same code sequence. I could understand this if all four remotes were purchased as a set, but they were not. I have no idea if every one of the thousands of remotes produced by this manufacturer has the same code or not, but it is another limitation you may have to contend with.

It is also useful to know remote behavior. Typically the output signal is not constant, rather it is a series of quick bursts containing the transmit code. This action continues as long as the transmit button is depressed. Each burst lasts approximately 350mS (milliseconds), and the null beteen the bursts only a few mS. I have learned that replicating this burst action is critical to matching the performance of the remotes.

Thus, to replicate the system, all I have to do is to learn what codes are used for each function, and transmit those codes using the behavior pattern used by the commmercial remotes. That is essentially the function of the remote we are building.

I also discovered the pulse width setting is important. This setting is in the Arduino sketch, and comes with the RC-Switch library (the software that provides the interface to the remote module). The pulse width setting sets the amount of time each code is sent, and is more or less equivalent to the baud rate. From testing, I have found that most of the generic 433Mhz wireless relays require around a 300uS to 400uS pulse width. Too short or too long means the receiver will not recognize the transmitted code. OK, seems locigal.

The remote uses a clone of an Arduino Mega 2560. There are two such manufacturers of these microcontrollers. One made by RobotDyn, and one made by EpalSite called Meduino. Ordinarily, the Mega is too large to incorporate in such a project, but the mini versions of the Arduino Mega have a much smaller footprint that will fit into the case. Unfortunately Arduino does not make the small footprint version.

We had to go with the Mega 2560 as the normal Arduino boards, such as NANO, MICRO, and UNO just do not have the flash memory required to power the project.

The LCD graphics display takes a lot of program space. I was able to get the system to run on a NANO, but I was right at the maximum of it's capacity with a 16 button device.

In contrast, the initial sketch (program) uses 10% of the Mega's capacity, so there is a lot of room to add more transmit buttons and other features, such as password protection.

Unfortunately the two Mega Minis do not have the same pinout or pin spacing - although they are similar. Nevertheless, that means the we must design the circuit board for one or the other.

In the initial design, I ran across some criticism of the RobotDyn version - in that it was not stable. However, I built two prototypes, one using each of the two Mega Minis, and both worked. Perhaps RobotDyn had early production boards that did not work well, I have no idea.

For the final "production" version, I ended up using the Meduino as it was slightly smaller, and it allows a more favorable placement of the other components on the board. The price, as well as the availability of each of the two Mini Megas are comparable, so the only real advantage is the smaller footprint of the Meduino. Consequently, the circuit board for the remote only supports the Meduino version of the Mega 2560.

Suprisingly, there are not many components to the remote. The major components are as follows:

• Mega Mini 2560 Pro Embedded MPU (EpalSite Meduino).
• Adafruit 2.8" TFT LCD with Touchscreen
• STX882 Module (also supports other modules).
• Auto power-off circuit.

Depending on the remote used, it's supply voltage is either 3.3V, 5V, or 12V (a bit less with the battery voltage of this project). Voltage selection is configured during construction.

The RobotDyn version board does not require a separate power supply as the microcontroller includes 5V and 3.3V power sources rated at 1A, which is sufficient to power the LCD (5V) and remote (3.3V). The EpalSite Meduino version board also has 5V and 3.3V power sources.

While the 5V source is also rated at 1A, the 3.3V source is rated at 150mA. The lower power 3.3V regulator may or may not have sufficient capability to power the remote. Fortunately, the STX882 remote requires less than 50mA @ 3.3V, so the Meduino version should have sufficient capability.

However, should a different remote be used, a daughter board is available with it's own regulator (3.3V or 5V @ 300mA) that is powered directly from the battery.

Speaking of batteries, I decided to use Li-Ion 14500 (AA sized) rechargeable batteries. They offer 3.7V each @800mAH, which is sufficient to provide over 4 hours of operation. The batteries are used in series which gives an internal voltage of almost 8V.

No battery charger is included as Li-Ion chargers are hard to build, especially those that charge more than a single cell. As well, the small case I am using is just about full. Since the batteries are standard AA, we can use a case with an external battery door to allow quick exchange of batteries.

In normal use, the batteries should almost last a full camping season without needing recharging. The graph shown above is the actual discharge curve of the remote as powered by the Li-Ion batteries. I created this graph by using the datalogging function of my KeySight U1252B multimeter. I am estimating each use of the remote will last 1 minute or less (with the auto shutoff circuit). This equates to at least 240 sessions. Given we camp typically 70 nights a season, we can use the remote each 4 times each camping day before having to recharge it. As Li-Ion has excellent charge retention (up to 36 months), and some "recovery", the number of sessions could be much higher.

Typically, only a single cell Li-Ion battery is used, and for projects requiring more voltage, a DC Buck-Boost circuit is used to achieve higher voltages. I was able to get the project to run on a single battery this way, but the auto-off interfered with the Buck-Boost circuit. I could have also run both LCD and Mega 2560 on 3.3V, alleviating the need for the higher voltage, but there is simply more energy in two batteries than one. Power is a combination of volts and amperes, and more voltage requires less amperage for the same amount of power - which means two batteries discharge more slowly than one. Such are the typical tradeoffs in a project.

The above auto-off schematic is my own design. It works surprisingly well - I love it when a plan comes together. So here is how it works...

Depressing the HOME button turns the device on. When depressed, battery voltage is presented to the TLP222A Solid State Relay, which turns on the internal LED via 1k resistor. The LED then turns on the photo-sensitive MOSFET, thereby attaching the battery voltage to the LED. This in effect removes the HOME button from the circuit, and regardless of the state of the HOME button, the device stays powered.

This allows the device to power up. During normal operation, the HOME button is also used to return the menu to the beginning among other functions, and those functions are achieved by toggling the logic level on the MPU each time the button is depressed. The 10K pull-down resistor ensures a good Logic 1 and Logic 0 level to be sensed by the MPU. The 1N4148 diode prevents the battery from permanently placing a Logic 1 on the MPU input.

The Zener diode drops the voltage sent to the MPU pin to less than 5V, which prevents damaging the MPU (otherwise, the full 7.8~8V battery voltage would be put on the MPU pin, which could damage it). Since luckily, the threshold for Logic 1 and 0 are at TTL levels (around 1V), the selected Zener can drop the battery voltage down to around 2V and still provide proper operation. This is necessary due to the loss of voltage as the batteries discharge (see the discharge curve). This allows the batteries to operate until they are in the <3V range.

When the MPU decides to shut down the device due to timeout after last action, 5V will be placed on the MPU's port connected to the 2N2222 transistor via 10K resistor. This turns the Transistor ON, which places a ground on the LED of the Solid State Relay - effectively turning the relay off. When turned on, the 10uF capacitor keeps the transistor turned on for a short period of time, preventing hysterisis (rapid on-off cycling of the transistor). This ensures a solid shut-down action.

If you study the larger version of the above schematic, you will see that the only additional component is a voltage divider that senses the battery voltage, allowing display of the remaining battery. In reality, it is a fairly simple device. Programming (which we will discuss later) is not as difficult as you might believe, given the availability of sufficient progrmaming libraries (collection of functions dedicated to the various hardware).