Home AMXForums Archive Threads AMX Applications and Solutions

IR problems

Hi there.
i'm controlling two dvd/vcr via ir.
I found the ir codes on amx database and implemented some code to manage all the possibilities.
Something like this:
// PLAY
BUTTON_EVENT[vTP2,57]
{
    PUSH:
    {
	IF(CURRENT_DVDVCR == 1)
	    TO[DVDVCR1,1]
	ELSE
	    TO[DVDVCR2,1]
    }
}

The problem is that for some really weird reason the same code for different commands does not work (event is fired but led does not light up).
// POWER
BUTTON_EVENT[vTP2,62]
{
    PUSH:
    {
	IF(CURRENT_DVDVCR == 1)
	    TO[DVDVCR1,9]
	ELSE
	    TO[DVDVCR2,9]
    }
}

I found out that TO[DVDVCR,N] works just for N<7....why???

Comments

  • DHawthorneDHawthorne Junior Member Posts: 4,584
    I've seen something like this. I had captured the IR for an IR PC Keyboard, and all of the keys were of the type that repeated the key code for as long as you held down the button. This made it very difficult to capture, because if you held the button a split second longer on the verification pass than you did for the initial (or vica versa), the capture failed. I found that the only way to consistently capture them was to press the keys as quickly as I could.

    This led to exactly that you are describing. My captures mostly worked, but some repeated no matter how short I made the press (captured too much). Some didn't work at all (probably captured too little). But even the ones that did work as a pulse would not work in a TO. They just pulsed and went off. I wound up doing some funky things with the timing to get what I needed working. Eventually, I recaptured them all with a Marantz RC5400, then captured that with my IRIS, and all was well and worked as expected.

    But my conclusion was the structure of the IR itself was non-standard enough that the IRIS didn't quite get them right. The RC5400 was better at capturing them, and itself put out a more standard format that the IRIS was able to deal with properly.

    So, that's my guess as to your problem: something is wrong with the IR codes stored, and because of that, the IR port is unable to sustain the transmission in a TO. I would try recapturing (preferably, using an intermediate device as I did).
  • lattanzilattanzi Junior Member Posts: 22
    Ok.
    But the main proble is that the NI-400 IR LED does not light up for those commands with code >7
    Unfortunately i don't have the DVDVCR to try...the only feedback i have is the NI IR led...it should light up any TO command i send to the IR port...right?
  • mpullinmpullin Obvious Troll Account, Marked for Deletion Posts: 949
    lattanzi wrote:
    Ok.
    But the main proble is that the NI-400 IR LED does not light up for those commands with code >7
    I have never seen IR commands sent in this way before (using TO). I agree it's odd that it should work for some cases but not for others. But try this:
    // PLAY
    BUTTON_EVENT[vTP2,57]
    {
        PUSH:
        {
    	IF(CURRENT_DVDVCR == 1) ON[DVDVCR1,9]
    	ELSE ON[DVDVCR2,9]
        }
         RELEASE:
         {
            IF(CURRENT_DVDVCR == 1) OFF[DVDVCR1,9]
    	ELSE OFF[DVDVCR2,9]
         }
    }
    
    If it still doesn't work, just try simpler and simpler versions until it DOES send, and then work up to what you want, in an attempt to determine exactly where the problem is.
  • lattanzilattanzi Junior Member Posts: 22
    No way Matt...other ideas?

    I attach some screenshots
    IM1.JPG 156.5K
    IM2.JPG 137.3K
  • DHawthorneDHawthorne Junior Member Posts: 4,584
    For the sake of testing, forget about sustaining the IR for a minute. Does PULSE on the channels above 7 cause the light to flash? If it does, the IR file is bad and cannot support a maintained IR. If it doesn't, there is no IR for those channels at all in the file. Eitehr way, there is a problem with the IR file, just different problems. I don't see anything wrong with your code.
  • lattanzilattanzi Junior Member Posts: 22
    Solved

    I fill so stupid!!!!
    Thanks to Dave i was able to find out what was wrong...i did not upload the ir file to the controller!

    Now everything's fine!

    I'm so sorry guys...
  • Chip MoodyChip Moody Junior Member Posts: 727
    "to" Fyi...

    I started on Axcent2s, being taught to do

    PUSH [TP,1]
    {
    TO [VCR,1]
    }

    I still use the TO with BUTTON_EVENTs to this day. I infrequently need to use PULSE, and I RARELY ever have need for any of the IR-related SEND_COMMANDs. With the TO keyword, there's also no need for all the extra work/code to do ON/OFF commands with PUSH/RELEASE handlers.

    - Chip
  • viningvining X Member Posts: 4,358
    Doing a TO would seem to have inherent problems. Your IR output pulse time would vary by the lenght of time the button is held or TOed. With finicky IR products like the recent Samsung DLP issue I had the pulse time needed to be set to 2/10th second pulse time to prevent doubling the command with cursor movements.

    Doing a TO to pulse IR seems wrong and problamatic and beacause we're in the business of trying to control things with the least chance of problems I think this method is something to avoid.

    You have more flexability and control using the Pulse command and IMHO is the most right method to employ. You also have an assortment of support commands to allow you to tweak your pulse. XCH, CH set_pulse_time, CTON, etc... to allow you to do various control options and maximize reliability.
  • Chip MoodyChip Moody Junior Member Posts: 727
    I suppose it depends on the application at hand. If you specifically HAVE to pulse a channel on a driver, I suppose... All I can say is that after years of controlling VCRs, DVDs, Cameras and the such, I've had no problems with using TO, and for functions like ramping volume, scrolling through a menu or moving a camera, a PULSE won't cut it...

    For programmatically controlling devices (I.E., not simply tying a button push to an IR function) I'm likely to use PULSEs, but I didn't think that was what was being discussed.

    - Chip

    vining wrote:
    Doing a TO would seem to have inherent problems. Your IR output pulse time would vary by the lenght of time the button is held or TOed.
  • NMarkRobertsNMarkRoberts Junior Member Posts: 455
    This is mine

    I've tried all sorts of different ways for an industrial strength IR pulse and this appears to be the survivor with which I have found fewest issues:

    (******************************************************************************)
    define_function SendIRCommand(
    dev dArgDevice ,(* Input - Device number *)
    integer nArgCTON ,(* Input - Tenths sending *)
    integer nArgCTOF ,(* Input - Tenths pausing afterwards *)
    integer nArgChannel ,(* Input - IR Command Number *)
    char sArgComment[] )(* Input - Comment *)
    (******************************************************************************)
    {
    #if_defined FullDebug
    DebugString("'Send IR[',itoa(nArgChannel),
    ']Dev[',UnwrapDevice(dArgDevice),
    ']CTOn[',itoa(nArgCTOn),
    ']CTOF[',itoa(nArgCTOF),
    ']'",sArgComment)
    if (nArgChannel <= 0)
    {
    Error('Zero SendIrCommand')
    return;
    }
    #end_if (* FullDebug *)

    (* Make sure device isnt confused and trying to send an empty command or something *)
    send_command dArgDevice,'IROFF'

    nIrPortActiveChannel = nArgChannel
    on [dArgDevice,nArgChannel]
    wait nArgCTON
    {
    off [dArgDevice,nArgChannel]
    wait nArgCTOF
    {
    nIrPortActiveChannel = 0
    }
    }
    } (* SendIRCommand *)
Sign In or Register to comment.