For the newcomers, just a brief explanatory note: the HT12E is a library that let your Arduino board interface with a remote control operated by an HT12E encoder chip, so that you can control the operation of your Arduino at distance.

The basic idea of this library is to configure your Arduino project like this:

\-------Arduino side-----------/ \---------------------Remote control side----------------------/It means that, in order to decode the incoming stream from a remote control, all you will need is an RF receiver, the HT12E library and the Arduino board. No need to include an HT12D chip on the Arduino side. That's because the library mimicks the internal clockwork of an HT12D.

Does it compare the data stream 3 times as the HT12D does? I am afraid I do not understand some of the code as I am a newbie still.

I have one application where I use 5 of the address lines to step through 32 binary switches ( via 5-32 line decoder ) and the 4 bit data from each switch is sent sequentially. Its pretty slow but doesn't matter for my application

The other 3 address lines are used for a one of 8 addresses ( security is not an issue in my application )

Would this library be able to be altered to receive these 32 nibbles so that I could decode them for sending to my displays?

That's right, the library listens for the incoming stream and checks if the same data shows up 3 times in a row to be sure it's real data.

The HT12D does that, too, according to documentation provided in data sheets.

When there is something wrong, the threefold checking is aborted and an error code is returned by the library.

I couldn't imagine someone would use the address bits as data. Anyway, the library can be customized for your need just by changing how you instantiate the library (that means you'll most probably need to work on HT12E::HT12E()).

@Boffin1, I do not think the address pins could be used to send data, although that does seem like a possible thing at first. Note that on the transmitting side (encoding side), address/data are virtually indistinguishable, and IMHO if their logic levels are same (& no inversion etc. is used), they are as good as 12 encodable bits. The challenge is on the receiving/decoding side. The HT-12D, decoder after 3 cycles of continuous address matches, will lead to VT being signalled, and all you have are the 4 data pin's output. And remember that the output, post match is latched. AFAIK, there is no reliable way to without the VT signal, to figure out using this IC, 12-bits of all-data, although using tri-state there should've been a way.

A signal on the DIN pin activates the oscillator which in turn decodes the incoming address and data. The decoders will then check the received address three times continuously. If the received address codes all match the contents of the decoder's local address, the 12-N bits of data are decoded to activate the output pins and the VT pin is set high to indicate a valid transmission. This will last unless the address code is incorrect or no signal is received.The output of the VT pin is high only when the transmission is valid. Otherwise it is always low.

Having said that, you might like to look at the VirtualWire protocol, where in the manchester decoding is done completely in software. VirtualWire protocol, IMHO, is not directly usable in this case, but could be modified, especially leveraging it's fine play with the timing, matching it to the timing of the HT-12D, and then decode 12-bits ! This is like turning the receiver into a promiscuous-mode sniffer. I would like to do this myself, but at the moment have multiple other priorities stacked up.

I used to use a separate HT12D chip in each unit to be controlled, and by sequencing through the addresses as described, I would update ( and latch ) each unit in turn.

It was rather slow but worked very well. That is why I thought of using the same encoding/decoding sytem, but with the arduino scanning the addresses.

I have now been dragged into the 21st century and I am going over to using Arduino at both ends.

I have developed a system using the VirtualWire library, which seems to be working fine, if there are any problems in trials I can easily make it repeat the code say 5 times, and look for the same decoded data 3 times, much the same as with the HT12.

That's right, the library listens for the incoming stream and checks if the same data shows up 3 times in a row to be sure it's real data.

No experience with this particular device, but I like to comment on the number 3. You have a good reason to use this number but it is hardcoded everywhere in the lib, and I can imagine that the user of the lib wants to use 1,2,3,4,5,6 .. 10 retries. Why?

first, 3 retries is still no 100% guarantee that it's real data.second, 1 or 2 retries would be faster - especiallly just 1 retry, and allows the user to let the Arduino do things between retries. (blink a led, move a motor etc)finally, more than 3 retries could be needed if line conditions are not 100% (that's why you are using 3 in the first place I guess) . However if I change the value 3 to e.g. 5 in the lib I get in conflict with the internal errorhandling which uses the values 4,5,6, as errorcodes.

- One solution is to make the retry count a parameter with default 3. - A better solution (best imho) is to remove the retry from the library alltogether and leave the number of retries to the user using the lib. He can add a while or for loop around any call.

Furthermore I advice to rethink the errorhandling => use a private int called errorCode, that is more descriptive that reusing the retry counter (maintainability) and it will not conflict with modifications of the retry counter If you decide to keep it.

Finally, you did a good job writing a library, so please write a small playground article where you explain more of the code and its usage

I'll rework on the library API by building up methods like those of some standard libraries:

HT12E::available()

HT12E::error()

HT12E::read()

And I agree with you about the threefold check, which should not be hardcoded. My idea is to let the available() operation tell you when there is potentially real incoming data, and it will be up to the developer to decide whether one, two or n-fold checking is enough or not.

Okay, I understand what you did to decode a signal sent by HT12E. But I would also like to simulate a HT12E. Send that same code that just got by using a transmitter.

Imagine that I'd like to create a repeater to a remote control. My arduino receives the control code, and transmits the same code, so that the central gate of my house "think" that is the control that is sending the request.

I don't know the protocol to implement this in manchester source code. As you already decoded, because the receiver sends in manchester pro Arduino, should be easy to do the reverse process, use an output pin of the Arduino to send this code to the transmitter.

Some years ago - BIFA - ( before I found Arduino ), I made a display board with 9 LED displays, each with it's own HT12D decoder , a CD4011 BCD-7 seg decoder, and ULN2003 driver.

The board has 3 sets of 3 digit numbers 0-999 , each set a different colour . The original unit had a single remote control, with 3 sets of BCD switches.

I have to change the transmitting end, but don't really want to rebuild the whole display, which is working fine.

I have to have 3 separate remotes, each with a single button that increments its own colour counter with each press.If the button is held in the counter is reset to zero ( I think this request is impractical, it would be better to have the units reset first, then the tens, then the thousands, or it could take forever to correct a mistake )

I have 3 spare transmitter units with HT12E encoder chips and transmitters, so each can send a simple code to the receiver, which I can try the HT12 library again, or use a HT12D chip ( I couldn't get the library going last time )

I am thinking of taking the BCD data ( representing button 1, 2 , or 3 ) from the decoder chip, and feeding this to an Atmega chip. ( or even easier if the library for the decoder works for me )

I can do a bit of manipulation with the counting and the reset timing, but then I want to send out the Holtek protocol data to the 9 chips, with the correct address code for the one that needs changing.

I think I can do it, but I just need some advice on generating the pulse widths of the ones, zeros, and spaces.

Is the micros or millis accurate enough? or is there another preferred method ?

Well I hooked together some switches and set some pullups, and have a sort of code, with odd serialprint telltales here and there, it runs until it gets to the "switch" function, I put a serialprint there and it doesnt show up.

The idea is that 3 remotes can each increment their own coloured display with a pushbutton, which comes to the chip via a HT12 decoder as Bin0 Bin1 and Bin2, and the valid transmission VT from the HT12.

I need to be able to reset each counter by holding the button in, so I included a flag to stop it incrementing each loop while the buttons pressed. I am not using a real timer for the reset delay, just counting loops.

heres the code for as far as the red button, the monitor shows it gets to serial print counter 2, but not the switch function, can I use functions() as I have here, being called from other functions? or perhaps I cannot have for loops in a switch case ? any ideas?