Search the Community
Showing results for tags 'ir remote control'.
Found 1 result
This is a continuation of an idea that got a little spring-boarding in another thread... Thanks to the participants, for their motivations... Special thanks to @apersson850 for a patient and helpful review. The purpose of version 1.0, at conclusion was simply to directly control an IR device using a physical connection... Further testing, over the course of a few days, revealed inconsistent reliability(keypresses being missed). I tried adjusting the software's timing, circuit changes, to no avail. I then continued to investigate the possibility of adding an external generator circuit to produce the 38K carrier needed for IR transmission.(Nov 17) I determined: To move forward with the IR sender idea, in order to explore physical separation as an electrical isolation solution... Finally, the IR carrier module arrived(May 11th, from China). After the addition of an inverter, the IR sender worked out! However, the "keypress" issue persisted. I had been so close, but, for one thing, had failed to mind the separation pulses, when adjusting the total number of data pulses sent.(Thanks, Classic99's DEBUGGER). After achieving some measure of success... I decided to look into decoding the remote control's signals, on-the-fly... in order to REMOTE CONTROL the TI itself. After reviewing some others findings... https://www.electroschematics.com/ir-decoder-encoder-part-1 This was successful, and also led me to developing a way to produce the needed IR signals, directly from the extracted HEX CODES! Now, only a small buffer is needed to reproduce any device's(NEC) codes! The above images, from >1000 to >1FFF, is ment to load into MINIMEMORY, from >7000 to >7FFF. While reviewing the image, try and pretend that the first >1, in the addresses is a >7. This image contains 5 subroutines that can be called manually by using EASY BUG's (E)Execute COMMAND. 1. RECEIVE IR, at >7120, will scan the output from an IR receiver, connected to a port on the TI's 9901 interface I.C.. The subprogram fills the buffer at >7D00, with word values representing the length of the pulses received. 2. SEND IR, at >7160 will read the values from the buffer at >7D00, and reproduce the pulses needed to drive a 38kHz IR sending module, connected to a port on the TI's 9901 interface I.C.. 3. KEY SEQ. PLAYER, at >7DCA(Execute >7DCC), Sends a series of keypresses(Bursts), repeatedly, by modifying the buffer addresses used in the SEND IR routine. This method is now, as though it were deprecated. 4. KEY DECODER, at >7EA0(Execute >7EA6), will read the buffer at >7D00, and write the derived HEX CODES to addresses >7EA0(DEVICE ID) and >7EA2(COMMAND). 5. KEY ENCODER, at >7F00(Execute >7F08), will read HEX CODES specified in R1 and R2 at addresses >7F0A(DEVICE ID) and 7F0E(COMMAND), than write the pulse length values to the buffer at >7D00, capable of driving the SEND IR subroutine! These synthesized values are experimental. I'm not using a scope of any kind or even a calculator! So, YMMV. These pulse values are within the detection range of, and appear to work well with: The only test unit I'm using. To be sure, I'm not certain if I should be counting MARKs or SPACEs, HIGHs/LOWs, here. I did a lot of trial and error to get this to work... Looking at the buffer(>7D00). The first word(>0266) seems to be a waking-up shift from HIGH to LOW and could perhaps trigger an interrupt. The second word(>0134) at(>7D02) seems to be a header/tail pulse. The third and every other word(>0024) is a LOW, separator pulse. Looking at the fourth word(>0023) in the buffer, from the ASCII view, a #, can be seen. The #'s are the 0's, the o's are the 1's, and the $'s are the separator pulses. So the HEX CODE seen is ########=>00, oooooooo=>FF, #o#o##o#=>52, o#o#oo#o=>AD, or >00FF, >52AD. >00FF being the Device's ID, and >52AD being the COMMAND CODE(for "key 9" on my device). P.S. Any ideas on how I could bottle and sell this are welcome. H.A. phm3058C.BIN phm3058G.BIN