HOME AUTOMATION Posted May 15, 2020 Share Posted May 15, 2020 (edited) 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 meant 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 Edited December 28, 2020 by HOME AUTOMATION spellin' 4 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 27, 2020 Author Share Posted May 27, 2020 I have switched to using a board mounted IR RECEIVER, this is giving more consistent values. I've been reconstructing the source code, from the many hex-edited mods I'd made. I'm slowly making the sources more RELOCATABLE... in order to satisfy the exhilarated masses! I know it's been a real let down, that this requires both dedicated CRU IN and OUT ports. So I've been looking into some sort of dongle to support this... I tried to integrate the last version's subroutines into a "type-on-screen" program. It turned out that while RECEIVE IR works well for scanning a single keypress, under test conditions. When used as a keyscan routine, it failed miserably! It seems that by the time One, releases a key, the repeat codes(shorter) have already presented into the next scan loop, usually leaving it hanging. I tried adjusting variously placed delays, to little avail... many dropped characters and a need to type at a precise speed(Ha!). After doing some more signal analysis... I arrived at the following updated observations: The first word(>0266), in the buffer at >7D00, is indeed the very first pulse sent by the remote control, this is the rather long, HEADER pulse, all the other pulses are very short, data seperator pulses. The second word, if less than >115 is a toggle bit(key held down). If greater than 115, the second word indicates a 32-Bit data BURST will follow. These values can be enforced to provide DEBOUNCE. Here I have done so... While it is still theoretically possible to get hung-up in the data timing loops, I haven't been able to get that to happen. If it did happen, execution should self-resync on the next BURST. None the less, I intend to correct this, in order to make certain that the subroutine cannot hang, though this will require re-calibration. For now I am just shunting the toggle codes back to reject/re-scan. I have determined that the BUFFER could be eliminated, at least for NEC codes. However, I'm keeping with this method, as it seems to offer greater flexibility. I've provided the latest .BIN image... ...and here, the Source Code... as such, for possible review. Spoiler AORG >7200 DEF SCANER SCANER CLR R12 LI R7,>88 LI R6,>7D00 NEXT CLR *R6+ DECT R7 JNE NEXT LI R6,>7D00 WAIT TB 17 JEQ WAIT TEST CLR R5 CHECK1 INC R5 TB 17 JNE CHECK1 MOV R5,*R6+ CLR R5 CHECK0 INC R5 TB 17 JEQ CHECK0 MOV R5,*R6+ CI R6,>7D8A JLE TEST RT END AORG >7240 DEF SEND SEND CLR R12 SBZ 16 LI R6,>7D00 MARK CLR R5 MOV *R6+,R5 CHECK1 SBO 16 NOP DEC R5 JNE CHECK1 SPACE CLR R5 MOV *R6+,R5 CHECK0 SBZ 16 DEC R5 JNE CHECK0 CI R6,>7D88 JLT MARK LI R8,>44FF WAIT DEC R8 JNE WAIT RT END AORG >7270 DEF DECODE HEXCOD DATA 0,0,>40 DECODE LI R3,>7D04 CLR R4 ADVANC INCT R3 C *R3+,@HEXCOD+4 JGT ONES ZEROS SLA R4,1 JMP DONE16 ONES SLA R4,1 INC R4 DONE16 CI R3,>7D44 JNE DONE32 MOV R4,@HEXCOD DONE32 CI R3,>7D84 JLT ADVANC MOV R4,@HEXCOD+2 RT END AORG >72B0 DEF ENCODE STABLE DATA >266 BURST DATA >134 TAIL DATA >0A9F OFFSTA DATA >0024 ENCODE LI R9,>00FF LI R10,>52AD LI R3,32 LI R4,>23 LI R5,>6F LI R6,>7D06 LI R8,>24 MOV @STABLE,@>7D00 MOV @BURST,@>7D02 MOV @TAIL,@>7D86 MOV @OFFSTA,@>7D04 MOV R9,R7 GEN SLA R7,1 JOC ONE ZERO MOV R4,*R6+ JMP NEXT ONE MOV R5,*R6+ NEXT CI R3,17 JNE COUNT MOV R10,R7 COUNT MOV R8,*R6+ DEC R3 JNE GEN RT END AORG >7310 DEF SEQPLA SAVRTN DATA 0 SEQPLA MOV R11,@SAVRTN JMP GO PLAY BL @>72C0 BL @>7240 GO MOV *R13+,R10 CI R10,>0 JNE PLAY OUT MOV @SAVRTN,R11 RT END AORG >7330 DEF RECEIV RECEIV CLR R12 LI R7,>88 LI R6,>7D00 NEXT CLR *R6+ DECT R7 JNE NEXT LI R6,>7D04 WAIT TB 17 JEQ WAIT CLR R5 HEADER INC R5 TB 17 JNE HEADER CI R5,>200 JLT WAIT CLR R5 TBFLAG INC R5 TB 17 JEQ TBFLAG CI R5,>115 JLT WAIT TEST CLR R5 CHECK1 INC R5 TB 17 JNE CHECK1 MOV R5,*R6+ CLR R5 CHECK0 INC R5 TB 17 JEQ CHECK0 MOV R5,*R6+ CI R6,>7D88 JLE TEST RT END AORG >7380 DEF ONSCRN REF VSBW DTAB DATA >6897,>30CF,>18E7,>7A85,>10EF DATA >38C7,>5AA5,>42BD,>4AB5,>52AD ONSCRN MOV R11,R15 INPUT CLR R0 PRESS BL @>7330 BL @>7276 LI R1,DTAB LI R2,JTAB CLR R3 COMP INCT R3 CI R3,22 JEQ PRESS C @>7272,*R1+ JNE COMP DECT R3 A R3,R2 MOV *R2,R2 BL *R2 SWPB R1 BLWP @VSBW INC R0 JMP PRESS JTAB DATA D0,D1,D2,D3,D4,D5,D6 DATA D7,D8,D9 D0 LI R1,>30 RT D1 LI R1,>31 RT D2 LI R1,>32 RT D3 LI R1,>33 RT D4 LI R1,>34 RT D5 LI R1,>35 RT D6 LI R1,>36 RT D7 LI R1,>37 RT D8 LI R1,>38 RT D9 LI R1,>39 RT END AORG >7E00 LIST DATA >38C7 "5" DATA >30CF "1" DATA >4AB5 "8" AORG >7DE0 DEF GOSEQ GOSEQ LI R9,>00FF LI R13,>LIST BL >7312 B >7DE0 END Version 3 phm3058C.BIN phm3058G.BIN 2 Quote Link to comment Share on other sites More sharing options...
GDMike Posted May 27, 2020 Share Posted May 27, 2020 (edited) What the, Dr frankenautomation!! Coool stuff here Edited May 27, 2020 by GDMike 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 27, 2020 Author Share Posted May 27, 2020 Why thank-you, Sir, for your enthusiasm! What a gentlemanly-like thing to say... ...I think. Breathe ...I command you! ... Hmm, maybe he needs, more ELECTRO-PLASMA. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 29, 2020 Author Share Posted May 29, 2020 (edited) Sooo, I wanted others to be able to share in the bounty, w/o having to tear-down their TI's, in order to gain access to the needed I/O ports. Getting enough power from the JOYSTICK port, to run both the emitter and the receiver, simultaneously, involved some squeezing. At one point I started designing a hungry, Joule thief type circuit with little supercapacitors, in an attempt to get sufficient current and voltage in spurts, but somehow managed to do w/o. Emitter power is probably minimal(untested). I had to disable some of the keyboard's lines, in the port initialization routine, not sure if putting them back will straighten things out for KSCAN w/o a reset. Also the ALPHA-LOCK(keep down for full power). Anyway, One could put a cheap IR SENDER nearby to boost the signal! I doubt though that this will work on a QI model. P.S. I'm wondering if there's a way to get my sub. hooked by the keyboard's SCAN routine, than perhaps I could set the final values at >8375, then return or barge back into it(providing compatibility for existing software). So far the only thing I've come up with involves a need for the LOAD interrupt line... P.P.S. I'll try to upload the modified routines and port initialization, a little later on today. Edited May 30, 2020 by HOME AUTOMATION raised capacitance! 3 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted May 29, 2020 Share Posted May 29, 2020 Super duper. Cool stuff!! 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted May 30, 2020 Author Share Posted May 30, 2020 (edited) These can be used as a update/replacement to/of post #2's sources, for the purpose of using the JOYPORT. Spoiler AORG >71F0 DEF INITPO INITPO CLR R12 SBZ 31 SBZ 21 SBO 19 SBO 20 RT END AORG >7200 DEF SCANER SCANER CLR R12 LI R7,>88 LI R6,>7D00 NEXT CLR *R6+ DECT R7 JNE NEXT LI R6,>7D00 WAIT TB 5 JEQ WAIT TEST CLR R5 CHECK1 INC R5 TB 5 JNE CHECK1 MOV R5,*R6+ CLR R5 CHECK0 INC R5 TB 5 JEQ CHECK0 MOV R5,*R6+ CI R6,>7D8A JLE TEST RT END AORG >7240 DEF SEND SEND CLR R12 SBZ 20 LI R6,>7D00 MARK CLR R5 MOV *R6+,R5 CHECK1 SBO 20 NOP DEC R5 JNE CHECK1 SPACE CLR R5 MOV *R6+,R5 CHECK0 SBZ 20 DEC R5 JNE CHECK0 CI R6,>7D88 JLT MARK LI R8,>44FF WAIT DEC R8 JNE WAIT RT END AORG >7330 DEF RECEIV RECEIV CLR R12 LI R7,>88 LI R6,>7D00 NEXT CLR *R6+ DECT R7 JNE NEXT LI R6,>7D04 WAIT TB 5 JEQ WAIT CLR R5 HEADER INC R5 TB 5 JNE HEADER CI R5,>200 JLT WAIT CLR R5 TBFLAG INC R5 TB 5 JEQ TBFLAG CI R5,>115 JLT WAIT TEST CLR R5 CHECK1 INC R5 TB 5 JNE CHECK1 MOV R5,*R6+ CLR R5 CHECK0 INC R5 TB 5 JEQ CHECK0 MOV R5,*R6+ CI R6,>7D88 JLE TEST RT END Edit: I changed the above TB instructions from 4, to 5, in order to match the connection diagram in post #5... TB 4 works with PIN5! TB 5 works with PIN9. Edited June 2, 2020 by HOME AUTOMATION 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted June 11, 2020 Author Share Posted June 11, 2020 (edited) I just got around to, a next step in this, a couple days ago... Since I now have a dedicated receiver and transmitter on the breadboard, I thought I would disconnect the MP3 player from the TI, and connect it to a 9-volt battery, to check operation at a distance. The second and smaller MP3 player, I developed this on, had no 5-volt regulator... so, I switched back to using the first. To my chagrin, I could get no response. I tried, varying the pulse lengths and distances, restoring full power, adding delays ...NO. So I think the issue is: I decided early on in this project, to truncate the first toggle bit and it's header, as they seemed to go unused. However, this sequence is necessarily appended to the first keypress, by the REMOTE. I suppose some decoding programs may use this as an activation bit, of sorts. Here is what I'm analyzing... The excluded sequence is shown in bytes >1D88 tru >1D8D. Not sure when I'll get to this ...Oh my! Edited June 12, 2020 by HOME AUTOMATION 2 1 Quote Link to comment Share on other sites More sharing options...
GDMike Posted June 11, 2020 Share Posted June 11, 2020 It's beyond me. But I'd love to see a video of it sometime. It sounds awesome 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted June 12, 2020 Author Share Posted June 12, 2020 Thanks again for your interest. I was considering a short demo... but there have been a few difficulties. I'll see if that's possible, but for right now, no promises. 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted June 26, 2020 Author Share Posted June 26, 2020 (edited) I've put in about 3 to 4 hours of the last week, trying to make sense of this dilemma. After replacing the missing sequence, the smaller player still works, yet, still no improvement on the MUSIC SPEAKERS, mp3 player. Looking deeper, in an effort to find the cause, I recall that the brightness of the emitter output from the 38k board, appeared to be substantially dimmer than that from the actual remote control, when viewed through an IR sensitive camera, even at full power. By switching the emitter through an opto-coupler, I was able to reach higher power. This was also unsuccessful. Next, I replaced the sender's emitter, with the emitter previously removed from from the original remote control I had experimented on. This too was a failure, and after about a minute the emitter failed(open) as well, from the excess current through the opto-coupler, as I used no limiting resistor, ouch! I've taken notice that the 38k sending board does not use a X-TAL, whereas the actual remote control does! Perhaps some frequency disparity exists there. Becoming desperate myself ...to properly analyse the signal I am generating, while having neither a second working TI to do so, or an oscilloscope handy, I came up with the idea to record the output from the TI's I/O port, to a wave editor, through my laptop's MIC input. Shown, TI's 9901 output, active-high, as I was using VCC as a reference here. I notice that some of the separator pulses are a bit too long, perhaps interrupts are causing this... ...I meant to have them off. Also the remote control's output, through the stand alone receiver(active-low): ...Some differences in the output. In both of the above images, >00FF7A85 "key 3" is shown. Not sure why I'm not showing the toggle bit here! ...hmm? Next, I tried playback of the remote control's signal, from the laptop's headphone jack to the 38k emitter board. Once again, the smaller mp3 player responds well, the MUSIC SPEAKERS player, will not! There had been mention in one of the articles I reference, to the effect that some knock-off IR receivers have poor sensitivity. Using a voltmeter, I found that the receiver is only getting about 2.6 volts when powering this mp3 player at 5 volts. Apparently the IR receiver may not be powered through the 7805 regulator, but may instead use a current limiting resistor. This unit is meant to be powered from a 12 volt source. Perhaps 5-9 volts is insufficient for proper operation. Next I'll try powering from a car battery. I have one sitting across the room! If that doesn't do it, I'll probably remove/replace the IR receiver module for more testing... Wave 3(00FF 7A85).wav Edited June 26, 2020 by HOME AUTOMATION 3 1 Quote Link to comment Share on other sites More sharing options...
+Ksarul Posted September 8, 2020 Share Posted September 8, 2020 This is a mighty interesting project. . . 1 1 Quote Link to comment Share on other sites More sharing options...
HOME AUTOMATION Posted September 8, 2020 Author Share Posted September 8, 2020 Thanks, I needed that! That means a lot, coming from someone... with a few more TI accomplishments than myself under their belt. Feels good to be included. I seem to recall the idea developing during a dream that became somewhat lucid! Unfortunately, I'm having some issues with my motivations lately. Also, this project was drawing my interests away from my obligations a bit too much, considering that I am working under a deadline! So I had to put it aside for now. I seem to recall that you are working on a Video Controller project that just might benefit from something like this. In it's final form; the parts of these programs that establish the pulse durations, need to be adjusted so that they can't hang for more than a moment, should something go wrong. This being consistent with my general HOME AUTOMATION operational plan. 3 1 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.