IR Remote Control

[HOME AUTOMATION]

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'

[HOME AUTOMATION]

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

[GDMike]

What the, Dr frankenautomation!! Coool stuff here

Edited May 27, 2020 by GDMike

[HOME AUTOMATION]

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.

[HOME AUTOMATION]

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!

[GDMike]

Super duper. Cool stuff!!

 

[HOME AUTOMATION]

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

[HOME AUTOMATION]

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

[GDMike]

It's beyond me. But I'd love to see a video of it sometime.

It sounds awesome

[HOME AUTOMATION]

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.
 

[HOME AUTOMATION]

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

[+Ksarul]

This is a mighty interesting project. . .

[HOME AUTOMATION]

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.