The text above is a simplified look at the receiver. There are a few more lines of code in the sketch - mostly to send the information on the OLED display, but this is generally the heart of what happens.

There are three sections here, and we can show a simple block diagram of each section below.

• Section 1. The first section (beginning with mySwitch.available) tests to see if there was any received data. If so, the receiver data is placed into a variable called curCode, then progresses to Section 2. If there was no received data, the control falls down to Section 3.

• Section 2. The variables MOTORIN, MOTOROUT, DIMMER1, DIMMER2 contain the predefined codes for the transmitter having those functions. The Select/Case statement evaluates the received value to these four values. If a match is found, the corresponding relay is turned ON.

  Note that in the case statement, as soon as a code is recognized and it's relay turned on, it exits this section (due to the BREAK statement). No further codes are evaluated. Therefore any time sensitive functions should always be located at the beginning. For example, a motor. When we release the button, we want it to stop immediately with minimal delay. Therefore, we place the motors first.

  Each code can only be placed one time in the switch statement. An error will be generated if duplicates are found. However, additional case statements can be added for the same function. For example, if we want to have a second code turn DIMMER1 on, we could insert the following lined after DIMMER1's case statements, as shown below in RED.

   

   

  Pay attention to the syntax and punctuation, and where the colon and semicolon is. Also, a break is required for each case. In the example, we "hard coded" the receiver code into the sketch. We could also have assigned a variable (say DIMMER1-1), and then defined it in the devices.h file where the other codes are. Note that the new case also turns on the same relay for the dimmer, so nothing more is needed.

  You can add as many case statements for the 4 channels as necessary; only limited by performance (if the receiver becomes slow), or memory warnings.

• Section 3. When receiver data was available in Section 1, the current time (in milliSeconds) was assigned to the timeDelay variable. In this section, 300mS after the data was received (contained in timeOffset), the relays are turned off. This then results in a momentary output of the relay, which turns on when the transmit button is pressed, and turns off 300mS after the button is released. As long as the button remains depressed, the relay will remain energized.

  While the timeOffset value of 300mS can be adjusted, caution must be taken to ensure things do not get flaky.

  • If the setting is too short, the relay will rapidly turn on and off while the button is depressed.
  • If the setting is too long, the relay will remain energized longer than desired when the button is released.

  Finally, everything pauses for 250mS after release of the relay to prevent the relay from turning on more than once if the operator keeps the button held down too long. Again, the setting is important, and if not set properly:

  • If the setting is too short, the relay may turn on and off multiple times if the button is not released quickly enough.
  • If the setting is too long, the receiver may not respond to the next button depression.

Prior to configuring the receiver, we must know the transmit code for each button we want to program. If the OLED monitor is attached, the transmit code will be displayed each time the receiver detects a transmission.

If the OLED monitor is not attached, the Arduino IDE itself can be used to display this information (the NANO must be connected to the computer).

From the IDE, click on the SERIAL MONITOR button and a new screen will appear. Ensure "9600baud" is selected in the lower right corner of the screen.

This is actually the diagnostic printout from the receiver. It contains not only the received code (yellow arrow) but additional information that will be used in future projects. For now, all we need is the code (typically 7 or 8 digits).

As mentioned, the receiver has a configuration file, "devices.h". This file contains the transmitter's code assignments for each button to be programmed. Not only does the receiver recognize the transmitter codes that are mapped to it's relays, it can also recognize any other code in the distributed system. There is a database of sorts that contains each known code and it's function, regardless of whether or not those codes trip a relay on the receiver. When encountering these codes, they will be displayed if the monitor is connected. And if those codes are ALSO defined for one of the relays, it will also trip that relay.

In the first section, you will see the assignment for MOTOROUT, DIMMER1, DIMMER2, and MOTORIN. These are the channel assignments. In fact, if you look at MOTOROUT, you will see that we have already assigned 5592332 for the motor function. to assign the 4 channels you desire to the MOTOROUT, DIMMER1, DIMMER2, and MOTORIN functions, simply determine their code as shown above, then put those codes into the four define statements. You will need to upload the sketch again after doing this.

Next, you will encounter a define statement called DEVICECOUNT. It needs to be adjusted anytime you add or remove from the database. More on that later. But for now, just remember where it is in thie file.

In the last section, you will see a structured array containing both the transmitter code, and a label describing the function. There are 18 records in this array, which of course matches the number in DEVICECOUNT. The transmit code must always be first, followed by the function name in quotes.

The function name can be anything, 12 spaces or less. However, all names should be 12 characters long, with leading spaces before and after the label. When the receiver detects an incoming code, it will search on the codes in the array, and if it finds one, it will display the corresponding label describing the function.

To add a record, you can simply insert it in any line within the array. There are no performance considerations from the first to last record. One caution though, pay close attention to the syntax, and especially the lack of a comma after the last line.

If you add or remove records, be sure to adjust the count in DEVICECOUNT.

Again, I put most, if not all of the user variables into the devices.h file so later updates of the program will not require reloading all of this information. In fact, unless you have added to the case statements (described in the prevous section), you should not have to make any changes to the program file.

In a future project, I will be expanding the 4 Channel receiver to 8 channels. When I do that, we will be modifying the sketch and be adding Latching logic (the current receiver is only momentary). So this project will grow over time.

As mentioned previously, if too many additional codes or functions are added to the sketch, the program might become unstable. In that case, you can do the following to reduce memory needs.

• If you are using the OLED monitor, consider turning the Serial Display OFF.
• If you are not using the OLED monitor, turn off the monitor lines in the sketch.
• Turn the Splash Screen graphic off. If you do this, you must turn on the text splash screen as per licensing.
• Reduce the width of the labels from 16 characters to 12. This will also require changing the setCursor statements in the sketch, or the text will not be centered.

Note that while I could have added a function to center the labels without needing to add spaces to the names (which will save memory), I made them all 16 characters for ease of formatting by the user. However, if needed in future releases, I can add that functionality.