![]() Why?įirst, 3 retries is still no 100% guarantee that it's real data. 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. No experience with this particular device, but I like to comment on the number 3. 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. I would like to do this myself, but at the moment have multiple other priorities stacked up. 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. Having said that, you might like to look at the VirtualWire protocol, where in the manchester decoding is done completely in software. The output of the VT pin is high only when the transmission is valid. This will last unless the address code is incorrect or no signal is received. 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. The decoders will then check the received address three times continuously. Here's text, verbatim from the "HT 12D" datasheet - A signal on the DIN pin activates the oscillator which in turn decodes the incoming address and data. 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. And remember that the output, post match is latched. 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. The challenge is on the receiving/decoding side. ![]() is used), they are as good as 12 encodable bits. Note that on the transmitting side (encoding side), address/data are virtually indistinguishable, and IMHO if their logic levels are same (& no inversion etc. Serial.println(valor, BIN) // data received from the remote I do not think the address pins could be used to send data, although that does seem like a possible thing at first. If(valor > 0xFFF0) Serial.println(valor, HEX) // error catching Unsigned int _mask // this is the address maskīyte _tries // this is how many times Arduino could find HT12E(int pin, unsigned int addrMask) // this is the constructor Note : make sure HT12E is operating at 3~4kHz clock range _mask = addrMask 9000 & _dur 250 & _dur 500 & _dur 3) // error handling ![]() HT12E::HT12E(int pin, unsigned int addrMask) That's because the library mimicks the internal clockwork of an HT12D. ![]() ![]() No need to include an HT12D chip on the Arduino 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. The basic idea of this library is to configure your Arduino project like this: -wire-air-wire-wire. New releases of the library will be posted here from now on.įor 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. As the old forum was transplanted but set as read only, I had to create a new topic here to foster discussions about the library. ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |