Shop OBEX P1 Docs P2 Docs Learn Events
How to record, store and replay IR signals from a remote control — Parallax Forums

How to record, store and replay IR signals from a remote control

JBWolfJBWolf Posts: 405
edited 2012-12-30 04:04 in Propeller 1
Hello,
I need to control my camera from the propeller.
I have the camera and the remote control, goal is to record the desired signals from the remote control, store them permanently in code or external file... then play select codes back when desired.
I just started looking into this today so I only have a mediocre understanding of how the signals are encoded.
I was able to use "IR_KIT" from OBEX to take a look at the signal marks and spaces, but I do not understand how I can record or play these back.

Was hoping someone could lend a helping hand with this task.
Thanks in advance!
J
«1

Comments

  • localrogerlocalroger Posts: 3,451
    edited 2012-12-23 12:44
    This isn't a hard thing to do, but it needs to be done in PASM so it's not a beginner's project.

    Basically you set up a PASM cog engine to record how long the output of the IR detector stays high and low, recording the state and duration to a Hub RAM array until you get a "pulse" that's long enough to signal end of message. Then you set a flag that pauses recording and signals your Spin main program to save the results.

    Then you use another PASM engine to read the array (which you've presumably put in a DAT section somewhere in your playback program) and pulse the IR LED for the recorded times.

    This ends up with a lot more data for all the bit images than you would have code if you knew the remote's "language" as in the IR kit method, but it doesn't require you to know the remote's language or for it to be standard to work.

    I did some similar stuff to profile the signals from 7-inch LCD's back when I was hacking them but that was all specific to video timing and the actual code wouldn't do much for you, alas.
  • JBWolfJBWolf Posts: 405
    edited 2012-12-23 23:39
    oof, didnt see that coming... unfortunately ASM is one of the languages I know next to nothing about.
    Was hoping I could accomplish this task with spin.

    Anyone know of an existing object I could use to accomplish this goal? Or would anyone be willing to take this on? I would be eternally grateful!
    For my specific task, I only need to record each one of the signals once, store them into a file along with an identifier, then be able to play them back as desired.
    For example I would be using the IR codes to zoom in/out most often, I would like to be able to replay these at different repeat rates depending on how fast I would like to zoom.

    This would also make a great addition to the OBEX. One to record and store IR signals along with an identifier. Another to replay from stored.
    I would be willing to give whoever does this, the use of my signature space :)
  • JBWolfJBWolf Posts: 405
    edited 2012-12-23 23:44
    Just curious why I cannot accomplish this in spin, I was thinking since the prop runs at 80mhz it would be fast enough.
    I am using a sony product, I read somewhere that these are the slower of the IR signals.
    Was hoping I could write a spin program to wait for an IR receiver to go high, then every clock cycle take a reading of whether it is still high or low, record these high/low periods and then store them when the signal stays low for a long period of time ie. 1 sec.
    Then for replaying, simply set the IR led pin high, waitcnt for the recorded amount of time, set pin low, waitcnt for recorded amount of time and repeat until signal transmission is complete.
  • JBWolfJBWolf Posts: 405
    edited 2012-12-24 00:54
    Here is why I was hoping this to be possible:
    This program ir_capture.spin uses spin to accomplish that method mentioned in my previous post to record mark and space pairs in microseconds, then it simply displays them in serial terminal.

    Here is a capture of the Sony remote's 'zoom in' button using that program:
    capture format:
    1,n - number of samples detected
    2,mark,space - mark,space pair in usec
    3 - likely end of individual code

    1,160
    2,2387,606
    2,592,606
    2,1191,605
    2,592,606
    2,1190,606
    2,1190,606
    2,591,579
    2,617,606
    2,1190,607
    2,591,606
    2,591,606
    2,1189,606
    2,1191,606
    2,591,606
    2,1190,605
    2,1191,19580
    3
    2,2388,606
    2,591,606
    2,1191,605
    2,591,605
    2,1191,580
    2,1216,605
    2,592,606
    2,591,605
    2,1191,605
    2,592,606
    2,591,606
    2,1190,606
    2,1191,605
    2,591,606
    2,1190,606
    2,1191,19564
    3
    2,2387,581
    2,616,606
    2,1191,605
    2,592,605
    2,1191,605
    2,1191,606
    2,591,606
    2,591,606
    2,1190,607
    2,590,606
    2,592,580
    2,1215,606
    2,1190,606
    2,591,607
    2,1189,605
    2,1191,19580
    3
    2,2387,605
    2,592,606
    2,1190,605
    2,591,606
    2,1190,606
    2,1191,605
    2,592,606
    2,591,582
    2,1215,579
    2,618,605
    2,592,580
    2,1216,606
    2,1191,581
    2,615,606
    2,1191,607
    2,1188,19564
    3
    2,2387,578
    2,620,605
    2,1191,606
    2,592,605
    2,1190,606
    2,1191,606
    2,591,604
    2,593,606
    2,1189,605
    2,592,605
    2,592,606
    2,1190,605
    2,1191,606
    2,591,607
    2,1189,580
    2,1217,-9336002
  • frank freedmanfrank freedman Posts: 1,983
    edited 2012-12-24 01:03
    Actually, you might try if you have access to a storage scope or logic analyzer to capture the output of the remote and see what the output timing id for the device in question. Hack the remote and go direct with the scope to the output circuit of your remote or put an ir receiver circuit into the scope. Once you understand the remote timing requirement, you could determine if spin will work or not. LR may be right after all, but why miss an opportunity to learn something along the way.

    I have an ADC sampling at 100ksps under pasm, but IIRC under spin far less. PASM is fun and gives much more control over what you want to do. Quirky? Yeah, a bit, but I like it better than spin. Still making too much of a mess with C to say much there......
  • JBWolfJBWolf Posts: 405
    edited 2012-12-24 01:06
    From what I can tell by that capture, it looks like 5 repeats of the 'zoom in' code.
    Each set has very similar timing sequences with deviation of only +/- 25 micro-seconds... not sure if those differences are from the remote or from the prop recording.

    This program did it all in spin.
  • JBWolfJBWolf Posts: 405
    edited 2012-12-24 01:08
    What would determine whether I could accomplish this in spin or need to use asm?
    I'm guessing timing between high/low periods? What is the point at which spin becomes ineffective?
  • StefanL38StefanL38 Posts: 2,292
    edited 2012-12-24 03:49
    Hi JB,

    now that it is clear which product (Sony) you are using it is possible to give more detailed advice.

    In general there are three levels in IR-encoding. one level can be done by external hardware.

    First level: creating / decoding a carrier-frequency of 36 to 40 kHz. Most common is 38kHz.

    Second level: switching on/off this carrier-frequency for certain amounts of times to encode databits 0/1 / to decode the databits by measuring these times.

    third level: decoding the bitstream of 12, 15, or 20 bits

    Recording every single on/off of the carrier-frequency is to fast for SPIN
    At 38kHz every 26 microseconds is a new pulse to detect them you should sample at minimum half the time.

    You can buy IR-receivers that convert the carrier-signal ON/OFFs into the databitstream.
    Therefore you have to measure the carrier-frequency of your remote-control. If I remember right
    there are some frequency measuring-objects in the OBEX.

    If you know the frequency you can buy the IR-receiver-module with the matching carrier-frequency
    here are some of them http://www.vishay.com/ppg?82492

    The output-signal of these IR-receivers is the databit-stream. The frequency of this bitstream is much lower than
    the carrier-frequency and it is possible to analyse it in SPIN.

    For sending the signal another cog is started. A hardware-counter inside the cog will create the carrier-frequency and in SPIN
    you will switch ON/OFF the carrierfrequency.

    This is the raw route how it can be done. For more details you have to look into other objects and then ask here again.

    In the attachments some info about IR-remote controls

    best regards
    Stefan
  • JBWolfJBWolf Posts: 405
    edited 2012-12-24 04:45
    Thanks, I will look into this!
  • StefanL38StefanL38 Posts: 2,292
    edited 2012-12-24 06:40
    Hi PB,

    now I remembered that Jonny Mac coded a Sony-SIRC IR-code decoder
    and uploaded this as an object to the obex
    http://obex.parallax.com/objects/477/

    To use this you need one of these IR-Receivers that decode the databitstream like mentioned above.
    best regards
    Stefan
  • JonnyMacJonnyMac Posts: 9,108
    edited 2012-12-24 08:47
    Just curious why I cannot accomplish this in spin, I was thinking since the prop runs at 80mhz it would be fast enough.

    Because the Spin interpreter is actually running at 20MHz, and it takes time to retrieved tokens from the hub and process them. I've done a lot of work with IR, especially SIRCS. These articles from my N&V column may be helpful.

    -- http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/prop/col/nvp4.pdf

    This one uses the SX chip, but is specifically about a camera control project.

    -- http://www.parallax.com/Portals/0/Downloads/docs/cols/nv/vol8/col/nv154.pdf
  • Martin_HMartin_H Posts: 4,051
    edited 2012-12-24 09:01
    If you know C consider giving Prop gcc or Catalina a try. I've written cog mode C code and it works quite well. I've also used Spin2cpp to convert Spin code to C as well. The tricky bit is getting messages to and from C in the cog. They use a structure called a mailbox to do that.

    To actually interpret the IR I would consider porting the Arduino library as a starting point.
  • Beau SchwabeBeau Schwabe Posts: 6,566
    edited 2012-12-24 10:14
    This might be helpful...

    http://obex.parallax.com/objects/790/
  • DamoDamo Posts: 16
    edited 2012-12-24 11:56
    Check out gadget gangsters web remote. You don't need the Ethernet part, but the IR part should do what you want. It simply records and plays back IR commands on request. His articles are way easy to follow. I find it much easier to disect and modify exsisting (functional) code that write it from scratch. That's the beauty of the OBEX. Good luck, and merry Christmas.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-12-24 13:19
    The link Beau posted was the one I was about to look for. If you can't use a ready made "Sony" object, check out Beau's link. It should do all that you want.

    BTW, I did something like this a while back with a camara that didn't seem to match any of codes I could find. I used a very rough version of something like Beau linked to, to record the pulses and play them back. It worked as I had hoped.
  • JBWolfJBWolf Posts: 405
    edited 2012-12-25 00:39
    Beau: I tried using the object, but no matter which button I press, this is the only thing I get back.
    I also noticed if I press the same button again, it returns a slightly different code.
    Not sure how to replay that code with this objext

    Waiting to decode IR signal...
    Bit Count:
    16
    IR Code:
    322F0C0B0C170C0B0C170C170C0B0C0B0C170C0B0C0B0C170C170C0B0C170C1787
    Bit Pattern: Fixed Space/Manchester
    .111111111111111
    Bit Pattern: Fixed Mark/Manchester
    ...............1
    Wrong code!
  • StefanL38StefanL38 Posts: 2,292
    edited 2012-12-25 00:52
    Hi JB,

    what hardware are you using to receive the IR-signals? As you seem to be new to this -
    for us (the forum-members) it is important to know your setup.

    Did you try JonnyMacs code?

    best regards
    Stefan
  • JBWolfJBWolf Posts: 405
    edited 2012-12-25 06:11
    I decided to review the PEKit labs book on PWM in section 7. in particular p.163-167
    I believe I have found a plausible method to recreate the signal that was measured in post #5 above and would like a second opinion.
    The method I am thinking of is setting a specific pulse duration, then use waitcnt to pause until the next pulse.

    The pulse durations/frequency I believe necessary were found using IRcapture.spin.
    The format it reported is "2, high duration in usec, low duration in usec"
    2,2387,606
     2,592,606
     2,1191,605
     2,592,606
     2,1190,606
     2,1190,606
     2,591,579
     2,617,606
     2,1190,607
     2,591,606
     2,591,606
     2,1189,606
     2,1191,606
     2,591,606
     2,1190,605
     2,1191,19580
    

    So from this report I see a pulse pattern of approx 600 microseconds repeated 42 times... in the first line "2387,606", the first set of high time 2387 is roughly 600 x 4, then a low time of 606 which is only +6usec... I believe 600usec would suffice.
    All lines after this are still very close approximations of 600usec... add all pulse durations of 600usec together and there are 42 total.
    So by setting a pulse duration at 600usec would mimic the frequency of the OEM remote control for this one signal (zoom in).
    Now I was thinking of building a DAT table consisting of the high/low state of each sequential 600usec pulse. so the first one "2387,606" is four pulses with the pin high, and one low. so the DAT table for this first set would be 1,1,1,1,0.
    Since this one IR sequence consists of 42 pulses, the DAT table will have a total of 42 values. At the end of each 600usec pulse, it will compare with the DAT table to see if the hi/low state of the next pulse should remain the same or be switched.

    After reacquainting myself with PWM and NCO, It looks like I can accomplish those pulses using this code:
    Please note: ctra[30..26] := 100 is supposed to be "ctra[30..26] := (percent sign)00100", for some reason the percent sign and two zeros get lost here
    PUB ReplayIRZoomSignal | T, tInc, Pulse, PulseCount
    ctra[30..26] := 100                           ' NCO Single ended
    ctra[5..0] := 1                               ' IR LED on pin #1
    frqa := 1                                     ' Add 1 to phsa with each clock cycle
    dira[1]~~                                     ' Set IR LED pin to output
    
    tInc := clkfreq/1_000_000                      ' Set time increment to microseconds
    Pulse := 600 * tInc                            ' Set pulse duration to 600usec
    
      Repeat PulseCount from 0 to 42               ' Begin replaying 42 sets of 600usec pulses 
          dira[1] := BitSet[PulseCount]            ' Check DAT table to see if this pulse should be high or low, set pin high/low immediately after checking (starts at 0 so first pulse is off)
          T := cnt                                 ' Mark current clock cycle
          phsa := -Pulse                           ' Initiate pulse with duration of 600usec
          T += Pulse                               ' Calculate clock cycle after 600usec
          waitcnt (T)                              ' Wait 600usec from Mark to allow pulse to complete before starting next pulse
    
    DAT
    BitSet long 1,1,1,1,0,1,0,1,1,0,1,0,1,1,0,1,1,0,1,0,1,0,1,1,0,1,0,1,0,1,1,0,1,1,0,1,0,1,1,0,1,1,0
    ----------------------------------------------------------------------------------
    

    I just put that together, so it may need a little revising yet.
    The only thing that I think may affect the timing is the amount of clock cycles it takes to execute a command.
    For example, how much time/clock-cycles pass between 'T:=cnt' and 'phsa1:=-Pulse'
    I'm thinking I will have to pair this code along with the IRcapture.spin program to visualize the results and tweak the waitcnt to get the IR output to match with the OEM recorded times.
    Hoping all I will have to do is reduce the waitcnt from 600usec, to 600usec minus the time elapsed between commands.

    I imagine that some amount of clock cycle execution delay will mess with my desired results, but I do not believe they will be so much that they exceed 600usec.
    If by some chance they do, I am willing to manually code each pulse line-by-line rather than using a more time consuming task such as comparing the current loop number against the DAT table for output pin state.

    What do you guys think about this approach?
  • JBWolfJBWolf Posts: 405
    edited 2012-12-25 07:49
    Stephan: I am using the IR receiver that came with the PEkit - #350-00014
  • LoopyBytelooseLoopyByteloose Posts: 12,537
    edited 2012-12-25 08:36
    I can't seem to find what kind of camera - other than Sony - or what task you expect to perform.

    If you are able to use a Linux OS, such as Ubuntu, then you can using quite a few free and helpful tools for IR remote control. They include a huge database of known device protocols. There is also decoding software.

    If you do NOT want to have Linux installed as a regular OS, it can be installed on a USBmemory stick and be booted just for working with your IR project. Nothing touches the hard disk or the existing OS in your computer.

    Also, some camera are more hackable than others. Canon has a wonderful project that you can up-grade and hack Canon cameras with a SDcard that boots more features.

    http://www.lirc.org/

    http://www.lirc.org/
  • JBWolfJBWolf Posts: 405
    edited 2012-12-25 10:57
    I tried to be as clear as possible in my first two posts as to what I am trying to do.
    I need to have the propeller control my camera via IR.
    I have a remote control for the camera, but since I cannot program a remote control to perform conditional functions, the propeller needs to become the new remote control.

    I am trying to record IR signals from the remote control, then play them back as desired (i.e. record the zoom in button from the sony remote control, then use the propeller to zoom in via pushbutton or other method). I would like to do this for several different buttons.

    The camera is a DCR-TRV30.
    Here is the product manual, unfortunately I could not find any information in there relating to IR codes or the remote control beyond simple usage.
    http://www.docs.sony.com/release/DCRTRV30.pdf
  • JBWolfJBWolf Posts: 405
    edited 2012-12-25 10:57
    Merry X-Mas!
  • DamoDamo Posts: 16
    edited 2012-12-25 12:10
    Did you try "magic ir" from the OBEX .? It will record and playback IR signals which is exactly what you are trying to do. I've played with it before and it works great, no knowledge of ir signals is needed.
  • Duane DegnDuane Degn Posts: 10,588
    edited 2012-12-25 12:28
    I tought about suggesting MagicIR but I knew Beau had a much better program.

    It's been several years since I've worked with IR stuff, but when I did, I was doing exactly what you want to do. I used an IR LED to control my camera from a Propeller chip.

    I made a demo for MagicIR that would output the data in a format that could be pasted into a spin file "DAT" section so it could be used in other code.

    Here's a portion of some of the generated code.
    DAT
      
    '0:telephoto
    IR00 long  $00045607, $0006613C, $0006FDF5, $0007738C, $00080F2B, $000990BC, $000A2D4F, $000AA33C
    

    I've attached the demo and I've attached the program with data I pasted in. Most of the AX12WithIrControl will be useless to you. The method you're after is "playcode". This is the method that uses the data to control the IR LED.

    While I don't really trust either of the programs attached, the AX12... program is really buggy. Hopefully there's enough information there to see how to call the "playcode" method.
  • JBWolfJBWolf Posts: 405
    edited 2012-12-25 13:02
    Oh sweet, I will definitely look into that Duane, thanks!
    I tried to figure out the magicIR beyond just the demo.... I was able to get it to work, but I couldnt make heads or tails of the ASM to do anything with it.

    I revised that code I posted previously and gave it a try, I can see the IR led flash using the 'nightshot' on the camera (its like a weak nightvision)... but alas no zoom.
    Not sure if I coded it well or if it will even work like that... was up all night reading the PEkit book and just ate a big xmas lunch, so im in idle mode now.
    I will check out those object and get back to you.
    I downloaded everything in OBEX that showed up in a search for "IR"... no luck so far, but this all is still really new to me... I just started on this IR project yesterday.
  • StefanL38StefanL38 Posts: 2,292
    edited 2012-12-25 13:44
    Hi PJ,

    I downloaded the datasheet http://www.parallax.com/Portals/0/Downloads/docs/prod/audiovis/PNA4601M.pdf
    of the PE-Kit-IR-receiver
    http://www.parallax.com/Store/Components/Optoelectronics/tabid/152/ProductID/177/List/1/Default.aspx?SortField=ProductName,ProductName


    There are several things to clear:
    The datasheet says supply-voltage 4,7V to 5,3V.
    Are you supplying the sensor with this voltage?

    Hi-level output-voltage is 4.8V to 5V.
    A 5V voltage should'nt be connected directly to the propeller.
    There must be a 10kOhm current-limiting resistor between a 5V-sensor and the propeller-chip.
    (which is mentioned in the PE Kit Labs)

    The parallax-page says its the IR-receiver subtype PNA4601M.
    If this is true the carrier-frequency is 36,7 kHz. As far as I know it most common is 38kHz.
    So it might be that the a 36,7 kHz receiver does not react properly on a 38kHz signal.

    You should check the carrier-frequency of your remote-control with the phototransistor #350-00018
    and a frequency measuring object.


    @Parallax-Team: Can you please re-check if the sensortype is really a PNA4601M?

    It's the Propeller Education Kit. What the heck does a 5V Sensor do in a 3.3V MCU-Kit when you can get
    3.3V IR-receivers easily?
    For example: an IR-receiver from Vishay
    http://www.vishay.com/ppg?82492 Supply-Voltage-range 2.7 to 5V

    best regards
    Stefan
  • JonnyMacJonnyMac Posts: 9,108
    edited 2012-12-25 14:12
    The camera is a DCR-TRV30.

    Did you try my SIRCS decoder/display from my article? Every bit of Sony gear I have uses SIRCS, which is why I decided to become so familiar with it. I created an SIRCS transmitter so that I could control a VCR and a Sony SLR (that I used for time-lapse movies). Seems a shame to go through all this trouble to bit-bash a known and easy-to-use protocol.
  • JonnyMacJonnyMac Posts: 9,108
    edited 2012-12-25 14:14
    So it might be that the a 36,7 kHz receiver does not react properly on a 38kHz signal.

    Those receivers are fairly forgiving, especially when the transmitter is close. The wide bandwidth characteristic is what allowed Andy Lindsay to create a distance measurement strategy out of what is, essentially, a digital device.
  • JBWolfJBWolf Posts: 405
    edited 2012-12-29 11:47
    Sorry for the delay.
    Just started a new job Wed and they been keeping me pretty busy.
    I'm hoping to make some progress on this over the weekend.... I am looking at the SIRCS code now, what is the serial transmit for? can I view it with PST or with an LCD?
    It looks like by default it transmits on pin 30... what did you use on this pin? Can I change that to work with USB for displaying on PST?

    I could not find any information on the purpose of the SIRCS code and what I may be able to do with it.... it looks like it just displays an IR 'code' that was received.
    How can I use this to store or replay an IR code?
    Can I write down a displayed code and put it into Duane's AX12 code above to replay?
    Thanks for the help
  • MagIO2MagIO2 Posts: 2,243
    edited 2012-12-29 12:11
    Pins 30&31 are your connection to the PC - at least during development time. So you can start the PST to see what's going on.
Sign In or Register to comment.