This circuit receives the signal from a IR remote control, like those used to control your TV or DVD player and allows the signal to be repeated in another location.  

To get a 40Khz carrier requires an output to be toggled on and off 40,000 times a second, which means the code needs to execute in 1,000,000/40,000 instruction cycles; this gives a very tight 25 instructions in which to do the job. Fortunately it’s an easy job to do so most of the instructions are just used to waste cycles.  It’s not easy to get an accurate frequency with so little time and  few instructions cycles to play with but the IR receivers  will work several Khz either side of their design detection frequency so it’s not a problem.

This code can generate a 40Khz, 38.4Khz or 37Khz carrier with a ~15% duty cycle.  The frequencies are configurable in the source code such that once programmed GPIO5 input on the PIC allows the selection of two frequencies.  By default the code is set to produce 40Khz and 37Khz carriers which are modulated by the logic level on GPIO2.  This would generally be connected to a IR decoder IC.

One thing I did find with the Sony equipment (I haven’t tested it with anything else), 875nM IR LEDs don’t seem to work, but the 950nM one specified works well. (TSUS5400, Mfg Vishay. Available from Farnell, part number 178302)

• Source Code (supports 12F629, 12F675, 12F683 21/06/2009)
• Hex (right-click Save As) for 12F675 / 12F629.
• Hex (right-click Save As) for 12F683
• Schematic

For more detail: IR Remote Control Repeater using PIC12F629

Current Project / Post can also be found using:

• pic12f629 remote control

The post IR Remote Control Repeater using PIC12F629 appeared first on PIC Microcontroller.

All remote controlled projects from this site can be controlled with remote controls which use the RC5 protocol, like the TV-remotes from Philips.
When all buttons from such a remote are in use then you could make a remote control by yourself.

Your own build remote control with only one button or maybe you want to build a remote with more then hundred buttons.
It is possible, however, you need the PIC Basic compiler from Crownhill seeing that everyone has his own wishes and you have to fill in which button sends which RC5 code (mentioned in the RC5 tables, see here and here).
The TRANSMIT.HEX file underneath is only an example, a TV-remote controller with only 5 buttons, namely Stand-by, Program + and -, Volume + and -.
On basis of the downloaded PIC Basic example you can expand the program to your own wishes.
If you need more buttons but the PIC has not enough inputs free, you have to write your own routine which read the buttons when they are connected in a matrix or with use of i.e. a 74HC165.
To see what system- and command codes your remote-control sends, you can build an other (easy) project: RC5/RC6 codes on a LC-Display.

For more detail: RC5 remote control using PIC12F629

Current Project / Post can also be found using:

• mini rc5 remote
• pic12f629 remote control from tv remote rc5
• RC5 REMOTE BASED PROJECT USING PIC
• rc5 remote control

The post RC5 remote control using PIC12F629 appeared first on PIC Microcontroller.

I had designed a remote unit for my ST4000+ autopilot. It did prove out the concept and I used it a lot, but it sported an unsightly coil cord (and of course unsightly coil cords have no place on boats) so I decided to build a wireless remote. The system (handheld Tx unit and stationary Rx unit) is based on a pair of microcontrollers and a pair of 433MHz radios.

The keypad/transmitter is on the left. It consists of a PIC16F628 microcontroller, Parallax 433MHz transmitter module ( and antenna, and membrane keypad built into the plastic box. It’s powered by a 9V battery. Power saving firmward allows it to run continuously for several months…there is no power switch. The receiver is on the right (above.) It consists of a Parallax 433MHz receiver module and antenna, PIC16F628 microcontroller, and Seatalk interface components. Schematic and firmware details are below.

Code:

/****************************************************************************

seatalk_wireless_remote_tx_1.c

This program is a remote control transmitter that sends a RxCx
number in an eight-byte message sentence with checksum.

Message protocol to the wireless receiver
* Each 9600 baud message contains a command and checksum:
   0xff    // wake up the transmitter and receiver
   0xff    // wake up the transmitter and receiver
   0xff    // wake up the transmitter and receiver
   'J'     // character
   'S'     // character
   'F'     // character
   cMsgCode   // which key was pressed
   'J' + 'S' + 'F' + cMsgCode   // equals checksum

                    +5
                    |
                    14
                ----------
      R4 ----6-| B0    A0 |-17-- out to Parallax 433MHz transmitter
      R3 ----7-| B1    A1 |-18-- out to LED
      R2 ----8-| B2       |
      R1 ----9-| B3       |
      C3 ---13-| B7       |
      C2 ---12-| B6       |
      C1 ---11-| B5       |
               |          |
 10MHz XTAL-15-|  16F628  |
       XTAL-16-|          |
                ----------
                     5
                     |
                    Gnd

          KEYBOARD ASSIGNMENTS
            C1      C2      C3
        +------------------------+
    R1  |      (cable here)      |
        |                        |
    R2  |                        |
        |                        |
    R3  |                        |
        |                        |
    R4  |                        |
        +------------------------+

***************************************************************************/

For more detail: WIRELESS REMOTE CONTROL for Raymarine ST4000 Autopilot using PIC16F628

Current Project / Post can also be found using:

• diy remote control raymarine
• raymarine st4000 autopilot fjernbetjening
• 오토파일럿 st4000

The post WIRELESS REMOTE CONTROL for Raymarine ST4000 Autopilot using PIC16F628 appeared first on PIC Microcontroller.

Introduction 

This little project will demonstrate how you can build NEC protocol based Infrared Remote Control to use with various NEC Protocol IR receivers.

actually there are lots of projects out there to accomplish this task but i have to write my own code because of too many requests on this IR(infrared) Remote Control Relay Board with PIC 12F675 Microcontroller   people keep asking “Where is the Transmitter for this” although you can use any NEC protocol based remote ,but i just wanted to build one by my self. so here it is.

Current Project / Post can also be found using:

• pic with nec ir protocol transmitter

The post NEC Protocol IR (Infrared) Remote Control With a Microcontroller appeared first on PIC Microcontroller.

The lamp in my bedroom is a very cheap lamp from Wal-Mart. It stands in one corner of my room, opposite of the door. This is where the problem is: If it is dark, I have to walk across the room, not trip on anything, find the small knob to twist to turn on the lamp, walk back towards whatever I need to do in the room. That is a whole lot of unnecessary walking.

As can be imagined, this annoyed me. I decided to make a remote-control for the lamp. And since I was making a remote control, I decided that I might as well make it a dimmer – something I’ve wanted from this lamp for a while. I lacked any enclosures, so I used a tin can from what I can only assume were Chinese Altoids.

The IR protocol is very simple. At the physical layer I stole it from a previous project of mine. IR 940nm LED is used. The carrier frequency is 34KHz. A 1-bit is sent with 0.5 ms of modulated carrier and 1.5 ms of darkness. A 0-bit is sent with 0.5 ms of modulated carrier and 0.5 ms of darkness. The packet begins with a preamble byte of 0xFF. Then comes a header of 0x06. Then comes the device ID – a 32-bit identifier of the device. For this project, I used a device ID of {‘A’ ‘B’, ‘L’, ‘1’}. Then comes the button code.

2 bytes are used, big-endian. This project uses just three button codes: 0 for “power on/off”, 1 for “brightness up,” and 2 for “brightness down.” Then comes a checksum. It is used to make sure that the packet is received successfully and error-free. Then comes the trailer byte of 0xFF. This protocol allows for over 4 billion device types and more than 65 thousand buttons for each.

For more detail: Remote-Control Light Dimmer

Current Project / Post can also be found using:

• www light dimmer using pic microcontroller and tv remote com

The post Remote-Control Light Dimmer using pic microcontroller appeared first on PIC Microcontroller.

I wanted to play around with something IR remote-controlled, so I decided to make a remote-control mood light. There were two parts to the project: making the remote and making the light. For the remote, I tore down a remote control for a floor fan, removing all its insides, and replacing it with mine. I used a PIC12F1840 micro for the remote, mostly since I have a lot of these lying around. For the receiver, I used the same microcontroller. The enclosure for the mood light? a glass jar with some paper to diffuse the light (I am not too much into making enclosures). There were some interesting issues along the way, but now the project pretty much works. It has 4 high-brightness LEDs in it: White, Red, Green, and Blue.

Features? Currently the device has 2 modes, switchable using the “Mode” button. “On/Off” turns the device on and off, as expected. Settings are backed-up in EEPROM, so after any power loss, device comes back to the same mode and settings as it was in when it was last on. Fade mode fades between colors randomly, with adjustable speed and brightness. Adjustment is made using the “up”/”down” buttons. What is adjusted is selected using the “O” button. Increasingly bright white blinks after pressing the “O” button mean you’re in brightness adjustment mode. White, Red, Green, Blue flashes after pressing the “O” button mean you’re adjusting speed. Solid mode is a solid color, each of whose WRGB components is adjustable up/down using the “up”/”down” buttons. Current component is selected using the “O” button – when pressed, it flashes just that color for half a second to indicate what you’re adjusting. Selected color is saved when you switch modes, and restored when you re-enter solid mode. When in off mode, you can anter diagnostic mode by entering on the remote: “Up Down Up Down O O”. This shows some values using LEDs. Each value is preceded by a color to indicate the meaning. Then decimal digits of the value are sent, one at a time, using dimwhite blinks. The end of each digit is signified by a bright white blink. So to send 102 we’d see a dim white blink, a bright white blink, another bright white blink, two dim white blinks and a bright blink. For now only two vales are shown. Software version (color code green) and remote battery voltage (color code blue). The code is very modular, so adding new modes is dead easy.

The remote has 5 buttons, with black labels on grey background. I used a sharpie to color the background black, hiding the labels, except “on-off” and “mode.” Outlines of arrows were left grey next to two buttons and a circle next to third. So now the buttons are “Mode”, “Up”, “Down”, “O”, “On/Off”. Internally, the PIC reads the buttons by connecting them to pins RA0 – RA4, with internal pullups enabled and the other end of buttons grounded. This is where I hit the first snag. I was expecting to use Interrupt-On-Change to wake the PIC from low-power sleep when a button is pressed. No matter what I did, this feature would not work. I had used it on previous models of PIC devices successfully, and I’ve been through the doc over and over, with no results. I am now reasonably convinced that this must either be a mistake in the docs, or a silicon problem. Now this was a major problem. No low power sleep means no way to not run through another set of batteries every week. After some thoughts, I decided to measure the power consumption of the PIC while running on its LFINTOSC oscillator at 31KHz. It was less than 0.01mA. I guess this is low power enough. So now whenever I need to wait for button presses, I switch to LFINTOSC, and repeatedly read the port pins and look for changes.

I would love to have a working sleep mode, but sadly that appears impossible with this chip. The chip switches to 4MHz HFINTOSC-generated speed when sending a signal, and then back to low power mode when it is done with that.

The physical layer of the communication on the remote side is a single 940nm IR LED with a 38.6 KHz carrier frequency (generated by the CCP/PWM module). Data is sent in 8-bit bytes, MSB first. Each bit is a sequence of 0.5ms of modulated light, followed by 1 or 1.5 ms of darkness. 1.5ms means bit is 1, 1 ms means bit is 0.

For more detail: Remote Control mood light[/jar]

The post Remote Control mood light[/jar] appeared first on PIC Microcontroller.

ow that we listen to MP3s, and watch XVIDs or x264s, a computer is the entertainment center in at least one room of most homes. Unless you have a special HTPC, though, you’re probably stuck using the keyboard to pause, change the volume, and fast-forward through annoying Mythbusters recaps. PC remote control receivers range from ancient serial port designs (who has one?) to USB devices not supported by popular software. In this how-to we design a USB infrared receiver that imitates a common protocol supported by software for Windows, Linux, and Mac. We’ve got a full guide to the protocol plus schematics and a parts list.

Remote controls transmit data on an modulated infrared beam. An infrared receiver IC separates the modulated beam into a clean stream of 0s and 1s. The data stream is decoded by a microcontroller and sent to a computer over a USB connection. Software processes the codes and triggers actions on the computer.

Background

Computer infrared receivers

The oldest PC infrared receiver design uses a receiver IC to toggle a serial port pin, usually DCD. This design probably originated on Usenet, and it’s still the most popular on the web: Engadget, Instructables, etc. These aren’t true serial devices because they don’t send data to the PC. Instead, a computer program times pulses on the serial port and demodulates the signal. This is a super simple design, but it depends on direct interrupt access and timing precision that’s no longer available in Windows. Linux or Mac users can try this receiver, if you still have a serial port. We couldn’t get this type of receiver to work with the serial port on a modern Windows XP PC, and don’t expect the precise timing to transfer through a USB->serial converter.

Some more advanced infrared receivers are true serial port devices that measure or decoding infrared signals before sending data to the computer. The UIR/IRMan and UIR2 incorporate a classic PIC 16F84, but don’t provide firmware and/or source code. These devices should work on a modern computer, through a USB->serial converter if necessary. The USBTINY and USBIRBOY are native USB devices, but lack wide support.

Receiver software

Regardless of receiver type, the computer needs a program to listen for incoming remote commands and convert them to actions on the computer. Linux and Mac users have LIRC, which supports a bunch of different receiver types. Windows users are a bit less fortunate. WinLIRC is an abandoned Windows port of LIRC for simple interrupt-based serial port receivers; WinLIRC was last developed in 2003. Girder was originally a freeware PC automation utility, but has become expensive bloatware with a 30 day trial. Fortunately, the last freeware version of Girder (3.2.9b) is still available for download.

Working with IR remote protocols

Decoding IR signals

Remote controls encode commands in the spacing or timing of a 38KHz carrier pulse, [San Bergmans] has an explanation of the principals involved. An infrared receiver IC separates the data stream from the carrier. Our job is to decode the data stream with a microcontroller. There are dozens of remote control protocols, but Phillips’ RC5 is widespread and commonly used by hobbyists.

RC5 is stream of 14 equal length bits of exactly 1.778ms per bit time. A pulse during the first half of the bit time represents 0, a pulse in the second half represents 1. This scheme is called Manchester coding.

We used a logic analyzer to examine the output of a Happauge WinTV remote control, a known RC5 remote. The diagram shows two presses of the 1 button, and two presses of the 2 button; note that the output is inversed and the Manchester coding is backwards from the above description.

The first two bit times are start bits, followed by a toggle bit. The toggle bit inverses each time a button is pressed so the receiver can tell the difference between a hold and a repeated press. The next 5 bits are the address (0b11110=0x1E), followed by the command (0b000001=0x01, 0b000010=0x02). A backwards compatible extension to RC5 uses the second start bit as command bit 7.

Representing remote codes to the computer

Looking at previous designs, we saw three general methods of communicating remote commands to a computer:

• Protocol specific receivers decode one protocol, and send actual decoded commands to the PC
• A more general type of receiver measures the timing and spacing of each pulse and sends the full waveform to the PC for analysis.
• Some receivers create a unique hash for a signal, but don’t actually include enough data to fully recreate the waveform.

While our preference is towards the general hash method, our only remote uses RC5 and it was more interesting to build an RC5 specific decoder. We describe modifications for a more general version in the firmware section.

Computer interface protocol

We didn’t want to write our own receiver software or driver, so we looked for an existing, well established communication protocol to imitate. The UIR/IRMAN/IRA/CTInfra/Hollywood+ type receiver is supported by Girder and LIRC, and uses a simple serial protocol with handshake:

• The device is initialized by the DTS and DTR pins of the serial port. We don’t have these and don’t care.
• The computer sends “IR”, with an optional delay. The device replies “OK”. We’ll just send “OK” on every “R”
• Remote control codes are sent as a unique six byte hash. We’ll decode an RC5 signal and send the actual values, but a generic hash could be used instead.

This protocol is for a serial port device, but our USB receiver will appear as a virtual serial port and the program won’t know the difference.

Hardware

Click here for a full size schematic (png). Our receiver is based on a USB enabled PIC 18F2455 microcontroller, the smaller, cheaper version of the 18F2550. The 18F family is programmable with the hobbyist favorite JDM-style programmers if a diode is used to drop VPP to a safe level. The PIC gets one decoupling capacitor (C1), and a diode (D1) and resistor(R1) on the ICSP programming header. We exposed the serial port on a pin header for debugging or a mixed USB/serial port version using a MAX RS232 transceiver IC.

The USB peripheral requires a 20MHz external clock (Q1, C5,6), and a .220uF capacitor. We faked the capacitor using 2 x .1uF decoupling capacitors (C2,3). A 3mm LED (LED1) and a 330ohm current limiting resistor (R2) show USB connection status.

We used a TSOP-1738 infrared receiver IC which calls for a 4.7uF decoupling capacitor (C4). If you can’t find this particular IC, any receiver listed here should work. The TSOP-1738 output is the inverse of the received signal, it pulls to ground when a pulse is detected, so a pull-up resistor (R3) holds the pin high when no signal is present. Check if you use a different receiver, you may need to use a pull-down resistor and reverse the Manchester decoding routine in the firmware.

Firmware

The firmware is written in C using Microchip’s free demonstration C18 compiler. Firmware and source are included in the project archive (zip).

We used version 2.3 of Microchip’s USB stack to create a USB serial port using the default drivers already available on most systems. The USB stack has simple functions to enumerate the USB device and transfer data between device and host. It only took a few pin changes to get the CDC demonstration working on our custom hardware.

Our implementation of the UIR/IRMAN/IRA/CTInfra/Hollywood+ protocol simply responds to the letter ‘R’ with ‘OK’. This should satisfy the handshake requirements of any implementation of this protocol.

We chose to specifically decode RC5 (and RC5x) because it’s a widely used protocol, and the only type of remote we have to work with. Most of the decoding is done in the interrupt handler:

For more detail: How-to USB remote control receiver

The post How-to: USB remote control receiver using pic microcontoller appeared first on PIC Microcontroller.

This little project will demonstrate how you can use NEC IR protocol based TV, DVD or VCR remote control to control you home appliances like fan bulb or virtually anything. There are lots of projects out there to accomplish this task but i have to write my own code because of too many requests on IR infrared Remote Control Relay Board with PIC12F675 Microcontroller. There are a number of consumer Infrared protocols out there and they have been used for every single purpose possible, like PDA laptops and other consumer appliances. RC-5 & RC-6 by Phillips, RCA are few examples of consumer IR protocols.

In this demonstration we will stick the to NEC protocol by NEC corporation,
NEC Infrared Protocol
A 9ms leading pulse burst (16 times the pulse burst length used for a logical data bit)
A 4.5ms space
The 8-bit address for the receiving device
The 8-bit logical inverse of the address
The 8-bit command
The 8-bit logical inverse of the command
Final 562.5µs pulse burst to show end of message transmission.
Logical ‘0’ – a 562.5µs pulse burst followed by a 562.5µs space, with a total transmit time of 1.125ms
Logical ‘1’ – a 562.5µs pulse burst followed by a 1.6875ms space, with a total transmit time of 2.25

The transmission of 0 and 1 is shown in the image blow
There are four bytes of data bits are being sent in least significant bit first order the figure blow shows the format of an NEC IR transmission frame, for a command of 0xB1 (10110001b) and an address of 0x8D (10001101b) .

16 bits for the address (address + inverse) require 27ms to transmit time .and the 16 bits for the command (command + inverse) also require 27ms to transmit time.
because (address + address inverse) or (command+command inverse) will always contain 8 ‘0’s and 8 ‘1’s so (8 * 1.125ms) + (8 * 2.25ms) == 27 ms .
according to this total time required to transmit the frame is (9ms +4.5ms +27ms+27ms) = 67.5 ms.

Logic Analyser shows the timing details
T1 leading pulse at 84.115ms
T2 space on 93.28ms
T3 Address starts at 97.580ms
T4 Address ends , address inverse starts 107.670ms
T5 address inverse ends , command starts at 124.486ms
T6 Command ends, command inverse starts 135.696ms
T7 Command inverse ends and last 562.5µs pulse to show end of transmission

Extended NEC protocol (not used in this demonstration)
The NEC protocol is so widely used that soon all possible addresses were used up. By sacrificing the address redundancy the address range was extended from 256 possible values to approximately 65000 different values. This way the address range was extended from 8 bits to 16 bits without changing any other property of the protocol. The command redundancy is still preserved. Therefore each address can still handle 256 different commands.in extended protocol instead of sending address and address inverse we send address low and address high as shown in the image blow.
Repeat Codes
If the key on the remote controller is kept depressed, a repeat code will be issued, typically around 40ms after the pulse burst that signified the end of the message. A repeat code will continue to be sent out at 108ms intervals, until the key is finally released. The repeat code consists of the following, in order:

A 9ms leading pulse burst
A 2.25ms space
A 562.5µs pulse burst to mark the end of the space (and hence end of the transmitted repeat code).
the figures give blow show the timing of repeat codes. If user keeps the key depressed the repeat codes keep coming. T8 shows the timing of repeat code.

For more detail: Infrared Remote Control with Microcontroller

The post Infrared Remote Control with Microcontroller appeared first on PIC Microcontroller.

IRMimic features:

• Simple to train – Can learn up to 16 IR commands, and each can be in a different format/protocol
• Two different operating modes – Keypad or MCU interface
• LED indicator output – Indicates training is complete
• Small size – 18 pin DIP IC

• Chip operates from 3-5 volts DC
• Standby mode permits battery operation
• Can learn many different IR remote control protocols.  Not limited to a few specific ones.
• In keypad mode, most remote control commands are repeated if key is held down.
• Kit w/pc board available for easy implementation. (All through-hole components for easy assembly.)

Add IR remote control of other equipment to your next project.

With IRMimic, just apply power, train the chip with the IR remote control commands you want to generate, and you’re ready to go. Command patterns are safely stored in internal non-volatile memory. IRMimic can be re-trained many times if needed.

IRMimic can learn up to sixteen different remote control commands, each in a different format, if needed.

In keypad mode, up to 16 pushbutton switches, plus the “Learn” switch, can be connected. Each key controls a different command.

You can also control IRMimic with your favorite microcontroller, using MCU mode. Just provide 4 code select inputs, a learn input, and a send input.

Based on an 18-pin Microchip® PIC 16LF87 CMOS microcontroller with EEPROM, IRMimic has been developed to work with most modern IR remote controls and accompanying equipment. It supports bi-phase, pulse width, and pulse position encoding techniques, as well as others.

Chip only – $9.95 (plus small per-order S&H fee)
(programmed, with code protect bit set)
Please download IRMimic chip data sheet. Also, please take a look at the schematic for the IRMimic pc board and the sample application schematics.

For more detail: IRMimic™ Trainable IR Remote Control Transmitter

The post IRMimic™ Trainable IR Remote Control Transmitter using pic microcontoller appeared first on PIC Microcontroller.

Control up to 8 devices by this easy constructable remote control. It can work as a radio or infrared remote control, depending on the components. Each device output can be configured to be momentary (turned on while you press the button) or latched. Latched outputs can be toggled on/off by one button per channel, or turned on and off by two buttons per channel.

Try it now, before building! Click on the transmitter buttons with the green labels on the left and see how the receiver outputs (K1-K8) change. Change the number of transmitter or receiver channels. Switch the receiver output type between latched and momentary.

Containing a PIC microcontroller, the circuit is very flexible. You can decide which receiver outputs are latched and which are momentary. The Manchester-coded transmitter output is well suited for the cheapest ASK radio modules or for infrared control. The units are configurable to a unique address, which must match to control the devices.

Related project: Learning remote control receiver
Take your existing remote control and control everything with it. This receiver can learn codes from an RC-5 format IR remote control, and associate the buttons to different channels and actions.

Related project: 2^16 remote control encoder and decoder
If you have TTL signals to control remote digital output lines, please check this project instead.

If you have trouble with programming PIC microcontrollers, you can consider builing other circuits based on Holtek HT-12D, HT-12E, Princeton PT2262, PT2272 and Motorola MC145026, MC145027, MC145028 encoders/decoders.

4/8-channel V4.2 radio transmitter

The difference between the 4-channel and the 8-channel version is only the software inside. The 8-channel transmitter has one button (S1-S8) per channel. The 4-channel transmitter uses S1-S4 buttons to turn on, S5-S8 buttons to turn off channel 1-4 (use with latched outputs on the receiver). The D1-D4 diodes and J1-J4 jumpers are optional, and are used to setup the transmitter address. Higher supply voltage results higher transmit power, but V+ range is 2-5.5VDC for the PIC MCU. When V+ is higher than 5VDC, use separate power for the mcu.

Configure & download
What if you can’t get a pic16f630?

• use a pic16f676
• try a pic16f628, here is the modified transmitter

For more detail: DIY remote control based on PIC16F628

The post DIY remote control based on PIC16F628 appeared first on PIC Microcontroller.

The 6 Channel RF Remote Controller designed using CC2500 RF Transceiver modules and PIC16F1847 micro-controller from microchip. Transmitter provided with 6 tact switch, 4 Address Jumpers to pair multiple unit so they don’t interfere with each other. Board provided with power LED, valid transmission LED. Project works with 5 V DC, On board LM1117-3.3V regulator for CC2500 Module.  Two in one PCB can be used as Transmitter & Receiver.

Receiver works with 5V DC. 4 Jumper to paring RX& TX units, valid signal LED, power LED, and 9 Pin connector for outputs.  Same PCB is used as transmitter and receiver.  All outputs are Latch Type and TTL 5V Signal for easy interface with other devices like Relay Boards, Solid State Relays.

CC2500 RF Module

The CC2500 is a low-cost 2.4 GHz transceiver designed for very low-power wireless applications. The circuit is intended for the 2400-2483.5 MHz ISM (Industrial, Scientific and Medical) and SRD (Short Range Device) frequency band. The RF transceiver is integrated with a highly configurable baseband modem. The modem supports various modulation formats and has a configurable data rate up to 500 baud. CC2500 provides extensive hardware support for packet handling, data buffering, burst transmissions, clear channel assessment, link quality indication and wake-on-radio.

The main operating parameters and the 64-byte transmit/receive FIFOs of CC2500 can be controlled via an SPI interface. In a typical system, the CC2500 will be used together with a microcontroller and a few additional passive components.

for more detail:6 CHANNEL RF REMOTE CONTROLLER USING CC2500 RF MODULES

The post 6 CHANNEL RF REMOTE CONTROLLER USING CC2500 RF MODULES appeared first on PIC Microcontroller.

I had designed a remote unit for my ST4000+ autopilot. It did prove out the concept and I used it a lot, but it sported an unsightly coil cord (and of course unsightly coil cords have no place on boats) so I decided to build a wireless remote. The system (handheld Tx unit and stationary Rx unit) is based on a pair of microcontrollers and a pair of 433MHz radios.

The keypad/transmitter is on the left. It consists of a PIC16F628 microcontroller, Parallax 433MHz transmitter module ( and antenna, and membrane keypad built into the plastic box. It’s powered by a 9V battery. Power saving firmward allows it to run continuously for several months…there is no power switch. The receiver is on the right (above.) It consists of a Parallax 433MHz receiver module and antenna, PIC16F628 microcontroller, and Seatalk interface components. Schematic and firmware details are below.

Code:

/****************************************************************************

seatalk_wireless_remote_tx_1.c

This program is a remote control transmitter that sends a RxCx
number in an eight-byte message sentence with checksum.

Message protocol to the wireless receiver
* Each 9600 baud message contains a command and checksum:
   0xff    // wake up the transmitter and receiver
   0xff    // wake up the transmitter and receiver
   0xff    // wake up the transmitter and receiver
   'J'     // character
   'S'     // character
   'F'     // character
   cMsgCode   // which key was pressed
   'J' + 'S' + 'F' + cMsgCode   // equals checksum

                    +5
                    |
                    14
                ----------
      R4 ----6-| B0    A0 |-17-- out to Parallax 433MHz transmitter
      R3 ----7-| B1    A1 |-18-- out to LED
      R2 ----8-| B2       |
      R1 ----9-| B3       |
      C3 ---13-| B7       |
      C2 ---12-| B6       |
      C1 ---11-| B5       |
               |          |
 10MHz XTAL-15-|  16F628  |
       XTAL-16-|          |
                ----------
                     5
                     |
                    Gnd

          KEYBOARD ASSIGNMENTS
            C1      C2      C3
        +------------------------+
    R1  |      (cable here)      |
        |                        |
    R2  |                        |
        |                        |
    R3  |                        |
        |                        |
    R4  |                        |
        +------------------------+

***************************************************************************/

For more detail: WIRELESS REMOTE CONTROL for Raymarine ST4000 Autopilot using PIC16F628

Current Project / Post can also be found using:

• autohelm st4000 remote control
• st4000 remote control

The post WIRELESS REMOTE CONTROL for Raymarine ST4000 Autopilot using PIC16F628 appeared first on PIC Microcontroller.

Introduction 

This little project will demonstrate how you can build NEC protocol based Infrared Remote Control to use with various NEC Protocol IR receivers.

actually there are lots of projects out there to accomplish this task but i have to write my own code because of too many requests on this IR(infrared) Remote Control Relay Board with PIC 12F675 Microcontroller   people keep asking “Where is the Transmitter for this” although you can use any NEC protocol based remote ,but i just wanted to build one by my self. so here it is.

Current Project / Post can also be found using:

• stm32 nec
• ir remote control nec protocol
• ir remote nec mikroc pic
• Microcontroller NEC ir

The post NEC Protocol IR (Infrared) Remote Control With a Microcontroller appeared first on PIC Microcontroller.

The lamp in my bedroom is a very cheap lamp from Wal-Mart. It stands in one corner of my room, opposite of the door. This is where the problem is: If it is dark, I have to walk across the room, not trip on anything, find the small knob to twist to turn on the lamp, walk back towards whatever I need to do in the room. That is a whole lot of unnecessary walking.

As can be imagined, this annoyed me. I decided to make a remote-control for the lamp. And since I was making a remote control, I decided that I might as well make it a dimmer – something I’ve wanted from this lamp for a while. I lacked any enclosures, so I used a tin can from what I can only assume were Chinese Altoids.

The IR protocol is very simple. At the physical layer I stole it from a previous project of mine. IR 940nm LED is used. The carrier frequency is 34KHz. A 1-bit is sent with 0.5 ms of modulated carrier and 1.5 ms of darkness. A 0-bit is sent with 0.5 ms of modulated carrier and 0.5 ms of darkness. The packet begins with a preamble byte of 0xFF. Then comes a header of 0x06. Then comes the device ID – a 32-bit identifier of the device. For this project, I used a device ID of {‘A’ ‘B’, ‘L’, ‘1’}. Then comes the button code.

2 bytes are used, big-endian. This project uses just three button codes: 0 for “power on/off”, 1 for “brightness up,” and 2 for “brightness down.” Then comes a checksum. It is used to make sure that the packet is received successfully and error-free. Then comes the trailer byte of 0xFF. This protocol allows for over 4 billion device types and more than 65 thousand buttons for each.

For more detail: Remote-Control Light Dimmer

Current Project / Post can also be found using:

• remote control lamp diagrams
• light dimmer pic
• light dimmer using pic microcontroller
• pic dimming light

The post Remote-Control Light Dimmer using pic microcontroller appeared first on PIC Microcontroller.

Control up to 8 devices by this easy constructable remote control. It can work as a radio or infrared remote control, depending on the components. Each device output can be configured to be momentary (turned on while you press the button) or latched. Latched outputs can be toggled on/off by one button per channel, or turned on and off by two buttons per channel.

Try it now, before building! Click on the transmitter buttons with the green labels on the left and see how the receiver outputs (K1-K8) change. Change the number of transmitter or receiver channels. Switch the receiver output type between latched and momentary.

Containing a PIC microcontroller, the circuit is very flexible. You can decide which receiver outputs are latched and which are momentary. The Manchester-coded transmitter output is well suited for the cheapest ASK radio modules or for infrared control. The units are configurable to a unique address, which must match to control the devices.

Related project: Learning remote control receiver
Take your existing remote control and control everything with it. This receiver can learn codes from an RC-5 format IR remote control, and associate the buttons to different channels and actions.

Related project: 2^16 remote control encoder and decoder
If you have TTL signals to control remote digital output lines, please check this project instead.

If you have trouble with programming PIC microcontrollers, you can consider builing other circuits based on Holtek HT-12D, HT-12E, Princeton PT2262, PT2272 and Motorola MC145026, MC145027, MC145028 encoders/decoders.

4/8-channel V4.2 radio transmitter

The difference between the 4-channel and the 8-channel version is only the software inside. The 8-channel transmitter has one button (S1-S8) per channel. The 4-channel transmitter uses S1-S4 buttons to turn on, S5-S8 buttons to turn off channel 1-4 (use with latched outputs on the receiver). The D1-D4 diodes and J1-J4 jumpers are optional, and are used to setup the transmitter address. Higher supply voltage results higher transmit power, but V+ range is 2-5.5VDC for the PIC MCU. When V+ is higher than 5VDC, use separate power for the mcu.

Configure & download
What if you can’t get a pic16f630?

• use a pic16f676
• try a pic16f628, here is the modified transmitter

For more detail: DIY remote control based on PIC16F628

Current Project / Post can also be found using:

• pic16f628a remote control
• PT2262 MICROCONTROLLER
• remot contol surkit bod formula image

The post DIY remote control based on PIC16F628 appeared first on PIC Microcontroller.

I wanted to play around with something IR remote-controlled, so I decided to make a remote-control mood light. There were two parts to the project: making the remote and making the light. For the remote, I tore down a remote control for a floor fan, removing all its insides, and replacing it with mine. I used a PIC12F1840 micro for the remote, mostly since I have a lot of these lying around. For the receiver, I used the same microcontroller. The enclosure for the mood light? a glass jar with some paper to diffuse the light (I am not too much into making enclosures). There were some interesting issues along the way, but now the project pretty much works. It has 4 high-brightness LEDs in it: White, Red, Green, and Blue.

Features? Currently the device has 2 modes, switchable using the “Mode” button. “On/Off” turns the device on and off, as expected. Settings are backed-up in EEPROM, so after any power loss, device comes back to the same mode and settings as it was in when it was last on. Fade mode fades between colors randomly, with adjustable speed and brightness. Adjustment is made using the “up”/”down” buttons. What is adjusted is selected using the “O” button. Increasingly bright white blinks after pressing the “O” button mean you’re in brightness adjustment mode. White, Red, Green, Blue flashes after pressing the “O” button mean you’re adjusting speed. Solid mode is a solid color, each of whose WRGB components is adjustable up/down using the “up”/”down” buttons. Current component is selected using the “O” button – when pressed, it flashes just that color for half a second to indicate what you’re adjusting. Selected color is saved when you switch modes, and restored when you re-enter solid mode. When in off mode, you can anter diagnostic mode by entering on the remote: “Up Down Up Down O O”. This shows some values using LEDs. Each value is preceded by a color to indicate the meaning. Then decimal digits of the value are sent, one at a time, using dimwhite blinks. The end of each digit is signified by a bright white blink. So to send 102 we’d see a dim white blink, a bright white blink, another bright white blink, two dim white blinks and a bright blink. For now only two vales are shown. Software version (color code green) and remote battery voltage (color code blue). The code is very modular, so adding new modes is dead easy.

The remote has 5 buttons, with black labels on grey background. I used a sharpie to color the background black, hiding the labels, except “on-off” and “mode.” Outlines of arrows were left grey next to two buttons and a circle next to third. So now the buttons are “Mode”, “Up”, “Down”, “O”, “On/Off”. Internally, the PIC reads the buttons by connecting them to pins RA0 – RA4, with internal pullups enabled and the other end of buttons grounded. This is where I hit the first snag. I was expecting to use Interrupt-On-Change to wake the PIC from low-power sleep when a button is pressed. No matter what I did, this feature would not work. I had used it on previous models of PIC devices successfully, and I’ve been through the doc over and over, with no results. I am now reasonably convinced that this must either be a mistake in the docs, or a silicon problem. Now this was a major problem. No low power sleep means no way to not run through another set of batteries every week. After some thoughts, I decided to measure the power consumption of the PIC while running on its LFINTOSC oscillator at 31KHz. It was less than 0.01mA. I guess this is low power enough. So now whenever I need to wait for button presses, I switch to LFINTOSC, and repeatedly read the port pins and look for changes.

I would love to have a working sleep mode, but sadly that appears impossible with this chip. The chip switches to 4MHz HFINTOSC-generated speed when sending a signal, and then back to low power mode when it is done with that.

The physical layer of the communication on the remote side is a single 940nm IR LED with a 38.6 KHz carrier frequency (generated by the CCP/PWM module). Data is sent in 8-bit bytes, MSB first. Each bit is a sequence of 0.5ms of modulated light, followed by 1 or 1.5 ms of darkness. 1.5ms means bit is 1, 1 ms means bit is 0.

For more detail: Remote Control mood light[/jar]

The post Remote Control mood light[/jar] appeared first on PIC Microcontroller.

ow that we listen to MP3s, and watch XVIDs or x264s, a computer is the entertainment center in at least one room of most homes. Unless you have a special HTPC, though, you’re probably stuck using the keyboard to pause, change the volume, and fast-forward through annoying Mythbusters recaps. PC remote control receivers range from ancient serial port designs (who has one?) to USB devices not supported by popular software. In this how-to we design a USB infrared receiver that imitates a common protocol supported by software for Windows, Linux, and Mac. We’ve got a full guide to the protocol plus schematics and a parts list.

Remote controls transmit data on an modulated infrared beam. An infrared receiver IC separates the modulated beam into a clean stream of 0s and 1s. The data stream is decoded by a microcontroller and sent to a computer over a USB connection. Software processes the codes and triggers actions on the computer.

Background

Computer infrared receivers

The oldest PC infrared receiver design uses a receiver IC to toggle a serial port pin, usually DCD. This design probably originated on Usenet, and it’s still the most popular on the web: Engadget, Instructables, etc. These aren’t true serial devices because they don’t send data to the PC. Instead, a computer program times pulses on the serial port and demodulates the signal. This is a super simple design, but it depends on direct interrupt access and timing precision that’s no longer available in Windows. Linux or Mac users can try this receiver, if you still have a serial port. We couldn’t get this type of receiver to work with the serial port on a modern Windows XP PC, and don’t expect the precise timing to transfer through a USB->serial converter.

Some more advanced infrared receivers are true serial port devices that measure or decoding infrared signals before sending data to the computer. The UIR/IRMan and UIR2 incorporate a classic PIC 16F84, but don’t provide firmware and/or source code. These devices should work on a modern computer, through a USB->serial converter if necessary. The USBTINY and USBIRBOY are native USB devices, but lack wide support.

Receiver software

Regardless of receiver type, the computer needs a program to listen for incoming remote commands and convert them to actions on the computer. Linux and Mac users have LIRC, which supports a bunch of different receiver types. Windows users are a bit less fortunate. WinLIRC is an abandoned Windows port of LIRC for simple interrupt-based serial port receivers; WinLIRC was last developed in 2003. Girder was originally a freeware PC automation utility, but has become expensive bloatware with a 30 day trial. Fortunately, the last freeware version of Girder (3.2.9b) is still available for download.

Working with IR remote protocols

Decoding IR signals

Remote controls encode commands in the spacing or timing of a 38KHz carrier pulse, [San Bergmans] has an explanation of the principals involved. An infrared receiver IC separates the data stream from the carrier. Our job is to decode the data stream with a microcontroller. There are dozens of remote control protocols, but Phillips’ RC5 is widespread and commonly used by hobbyists.

RC5 is stream of 14 equal length bits of exactly 1.778ms per bit time. A pulse during the first half of the bit time represents 0, a pulse in the second half represents 1. This scheme is called Manchester coding.

We used a logic analyzer to examine the output of a Happauge WinTV remote control, a known RC5 remote. The diagram shows two presses of the 1 button, and two presses of the 2 button; note that the output is inversed and the Manchester coding is backwards from the above description.

The first two bit times are start bits, followed by a toggle bit. The toggle bit inverses each time a button is pressed so the receiver can tell the difference between a hold and a repeated press. The next 5 bits are the address (0b11110=0x1E), followed by the command (0b000001=0x01, 0b000010=0x02). A backwards compatible extension to RC5 uses the second start bit as command bit 7.

Representing remote codes to the computer

Looking at previous designs, we saw three general methods of communicating remote commands to a computer:

• Protocol specific receivers decode one protocol, and send actual decoded commands to the PC
• A more general type of receiver measures the timing and spacing of each pulse and sends the full waveform to the PC for analysis.
• Some receivers create a unique hash for a signal, but don’t actually include enough data to fully recreate the waveform.

While our preference is towards the general hash method, our only remote uses RC5 and it was more interesting to build an RC5 specific decoder. We describe modifications for a more general version in the firmware section.

Computer interface protocol

We didn’t want to write our own receiver software or driver, so we looked for an existing, well established communication protocol to imitate. The UIR/IRMAN/IRA/CTInfra/Hollywood+ type receiver is supported by Girder and LIRC, and uses a simple serial protocol with handshake:

• The device is initialized by the DTS and DTR pins of the serial port. We don’t have these and don’t care.
• The computer sends “IR”, with an optional delay. The device replies “OK”. We’ll just send “OK” on every “R”
• Remote control codes are sent as a unique six byte hash. We’ll decode an RC5 signal and send the actual values, but a generic hash could be used instead.

This protocol is for a serial port device, but our USB receiver will appear as a virtual serial port and the program won’t know the difference.

Hardware

Click here for a full size schematic (png). Our receiver is based on a USB enabled PIC 18F2455 microcontroller, the smaller, cheaper version of the 18F2550. The 18F family is programmable with the hobbyist favorite JDM-style programmers if a diode is used to drop VPP to a safe level. The PIC gets one decoupling capacitor (C1), and a diode (D1) and resistor(R1) on the ICSP programming header. We exposed the serial port on a pin header for debugging or a mixed USB/serial port version using a MAX RS232 transceiver IC.

The USB peripheral requires a 20MHz external clock (Q1, C5,6), and a .220uF capacitor. We faked the capacitor using 2 x .1uF decoupling capacitors (C2,3). A 3mm LED (LED1) and a 330ohm current limiting resistor (R2) show USB connection status.

We used a TSOP-1738 infrared receiver IC which calls for a 4.7uF decoupling capacitor (C4). If you can’t find this particular IC, any receiver listed here should work. The TSOP-1738 output is the inverse of the received signal, it pulls to ground when a pulse is detected, so a pull-up resistor (R3) holds the pin high when no signal is present. Check if you use a different receiver, you may need to use a pull-down resistor and reverse the Manchester decoding routine in the firmware.

Firmware

The firmware is written in C using Microchip’s free demonstration C18 compiler. Firmware and source are included in the project archive (zip).

We used version 2.3 of Microchip’s USB stack to create a USB serial port using the default drivers already available on most systems. The USB stack has simple functions to enumerate the USB device and transfer data between device and host. It only took a few pin changes to get the CDC demonstration working on our custom hardware.

Our implementation of the UIR/IRMAN/IRA/CTInfra/Hollywood+ protocol simply responds to the letter ‘R’ with ‘OK’. This should satisfy the handshake requirements of any implementation of this protocol.

We chose to specifically decode RC5 (and RC5x) because it’s a widely used protocol, and the only type of remote we have to work with. Most of the decoding is done in the interrupt handler:

For more detail: How-to USB remote control receiver

Current Project / Post can also be found using:

• usb pic remote control circuit

The post How-to: USB remote control receiver using pic microcontoller appeared first on PIC Microcontroller.

IRMimic features:

• Simple to train – Can learn up to 16 IR commands, and each can be in a different format/protocol
• Two different operating modes – Keypad or MCU interface
• LED indicator output – Indicates training is complete
• Small size – 18 pin DIP IC

• Chip operates from 3-5 volts DC
• Standby mode permits battery operation
• Can learn many different IR remote control protocols.  Not limited to a few specific ones.
• In keypad mode, most remote control commands are repeated if key is held down.
• Kit w/pc board available for easy implementation. (All through-hole components for easy assembly.)

Add IR remote control of other equipment to your next project.

With IRMimic, just apply power, train the chip with the IR remote control commands you want to generate, and you’re ready to go. Command patterns are safely stored in internal non-volatile memory. IRMimic can be re-trained many times if needed.

IRMimic can learn up to sixteen different remote control commands, each in a different format, if needed.

In keypad mode, up to 16 pushbutton switches, plus the “Learn” switch, can be connected. Each key controls a different command.

You can also control IRMimic with your favorite microcontroller, using MCU mode. Just provide 4 code select inputs, a learn input, and a send input.

Based on an 18-pin Microchip® PIC 16LF87 CMOS microcontroller with EEPROM, IRMimic has been developed to work with most modern IR remote controls and accompanying equipment. It supports bi-phase, pulse width, and pulse position encoding techniques, as well as others.

Chip only – $9.95 (plus small per-order S&H fee)
(programmed, with code protect bit set)
Please download IRMimic chip data sheet. Also, please take a look at the schematic for the IRMimic pc board and the sample application schematics.

For more detail: IRMimic™ Trainable IR Remote Control Transmitter

The post IRMimic™ Trainable IR Remote Control Transmitter using pic microcontoller appeared first on PIC Microcontroller.

This little project will demonstrate how you can use NEC IR protocol based TV, DVD or VCR remote control to control you home appliances like fan bulb or virtually anything. There are lots of projects out there to accomplish this task but i have to write my own code because of too many requests on IR infrared Remote Control Relay Board with PIC12F675 Microcontroller. There are a number of consumer Infrared protocols out there and they have been used for every single purpose possible, like PDA laptops and other consumer appliances. RC-5 & RC-6 by Phillips, RCA are few examples of consumer IR protocols.

In this demonstration we will stick the to NEC protocol by NEC corporation,
NEC Infrared Protocol
A 9ms leading pulse burst (16 times the pulse burst length used for a logical data bit)
A 4.5ms space
The 8-bit address for the receiving device
The 8-bit logical inverse of the address
The 8-bit command
The 8-bit logical inverse of the command
Final 562.5µs pulse burst to show end of message transmission.
Logical ‘0’ – a 562.5µs pulse burst followed by a 562.5µs space, with a total transmit time of 1.125ms
Logical ‘1’ – a 562.5µs pulse burst followed by a 1.6875ms space, with a total transmit time of 2.25

The transmission of 0 and 1 is shown in the image blow
There are four bytes of data bits are being sent in least significant bit first order the figure blow shows the format of an NEC IR transmission frame, for a command of 0xB1 (10110001b) and an address of 0x8D (10001101b) .

16 bits for the address (address + inverse) require 27ms to transmit time .and the 16 bits for the command (command + inverse) also require 27ms to transmit time.
because (address + address inverse) or (command+command inverse) will always contain 8 ‘0’s and 8 ‘1’s so (8 * 1.125ms) + (8 * 2.25ms) == 27 ms .
according to this total time required to transmit the frame is (9ms +4.5ms +27ms+27ms) = 67.5 ms.

Logic Analyser shows the timing details
T1 leading pulse at 84.115ms
T2 space on 93.28ms
T3 Address starts at 97.580ms
T4 Address ends , address inverse starts 107.670ms
T5 address inverse ends , command starts at 124.486ms
T6 Command ends, command inverse starts 135.696ms
T7 Command inverse ends and last 562.5µs pulse to show end of transmission

Extended NEC protocol (not used in this demonstration)
The NEC protocol is so widely used that soon all possible addresses were used up. By sacrificing the address redundancy the address range was extended from 256 possible values to approximately 65000 different values. This way the address range was extended from 8 bits to 16 bits without changing any other property of the protocol. The command redundancy is still preserved. Therefore each address can still handle 256 different commands.in extended protocol instead of sending address and address inverse we send address low and address high as shown in the image blow.
Repeat Codes
If the key on the remote controller is kept depressed, a repeat code will be issued, typically around 40ms after the pulse burst that signified the end of the message. A repeat code will continue to be sent out at 108ms intervals, until the key is finally released. The repeat code consists of the following, in order:

A 9ms leading pulse burst
A 2.25ms space
A 562.5µs pulse burst to mark the end of the space (and hence end of the transmitted repeat code).
the figures give blow show the timing of repeat codes. If user keeps the key depressed the repeat codes keep coming. T8 shows the timing of repeat code.

For more detail: Infrared Remote Control with Microcontroller

Current Project / Post can also be found using:

• infrared development board MCP2155
• ir remote receiver microcontoller
• Micro controller based infra red remote control

The post Infrared Remote Control with Microcontroller appeared first on PIC Microcontroller.

All remote controlled projects from this site can be controlled with remote controls which use the RC5 protocol, like the TV-remotes from Philips.
When all buttons from such a remote are in use then you could make a remote control by yourself.

Your own build remote control with only one button or maybe you want to build a remote with more then hundred buttons.
It is possible, however, you need the PIC Basic compiler from Crownhill seeing that everyone has his own wishes and you have to fill in which button sends which RC5 code (mentioned in the RC5 tables, see here and here).
The TRANSMIT.HEX file underneath is only an example, a TV-remote controller with only 5 buttons, namely Stand-by, Program + and -, Volume + and -.
On basis of the downloaded PIC Basic example you can expand the program to your own wishes.
If you need more buttons but the PIC has not enough inputs free, you have to write your own routine which read the buttons when they are connected in a matrix or with use of i.e. a 74HC165.
To see what system- and command codes your remote-control sends, you can build an other (easy) project: RC5/RC6 codes on a LC-Display.

For more detail: RC5 remote control using PIC12F629

Current Project / Post can also be found using:

• codes tv remote control
• ir remote pic12f629
• rc5 codes table for lighting

The post RC5 remote control using PIC12F629 appeared first on PIC Microcontroller.