Home› AMX User Forum› AMX General Discussion

Dell W5001C Plasma

undrtkrundrtkr Posts: 35
in AMX General Discussion
About a week ago I posted a question about adding IR Hex codes to IR edit. I've just now taken the time to look at the IR document the client sent me and the manual for the display. Apparently this model doesn't allow for discreet input selection. You have to send the input pulse, a menu pops up on the screen and the user has to use the up and down arrow buttons to select a source.

I really LOATH this type of control. Reading through the manual it states that any Philips codes will work for this TV. I've looked through the AMX Database and found an IR file for a Philips plasma tv that has discreet input commands listed as AV1, AV2, AV3, VGA etc. The inputs on the back of the Dell display and the menu screen list the inputs as AV1, AV2, AV3, etc.

My question is has anyone attempted to control this Dell display or one similar. Should I take the chance and use the AMX provided Philips file or just accept what I have.

My experience tells me NOT to trust the manual but I wanted to get other peoples opinion first.

Comments

  • [Deleted User][Deleted User] Posts: 0
    Give it a try.
    undrtkr wrote:
    Should I take the chance and use the AMX provided Philips file or just accept what I have.

    My experience tells me NOT to trust the manual but I wanted to get other peoples opinion first.

    Yes, try the Phillips file and if that doesn't work deal with what you have. You have nothing to lose by trying to find an IR file substitute that operates the Dell plasma.

    As a side note, you are finding out the hard way that picking the right components is essential in designing and programming a robust AMX system.
  • undrtkrundrtkr Posts: 35
    B_Clements wrote:
    Yes, try the Phillips file and if that doesn't work deal with what you have. You have nothing to lose by trying to find an IR file substitute that operates the Dell plasma.

    As a side note, you are finding out the hard way that picking the right components is essential in designing and programming a robust AMX system.

    Yeah, unfortunately I'm not a designer so I have no say. Also the client is Dell so they wanted to use their existing displays.
  • NMarkRobertsNMarkRoberts Posts: 455
    IR sequences

    They may be nasty, but sequences of IR pulses to achieve some aim do work well, if you are prepared to invest some time in coding the standard routines and structures that you will use again and again in this situation.

    First you need a state engine to keep track of whether or not the device is already in a given state, because you don't want to send complicated IR sequences to reassert the state every time you do anything to it, because the damn thing will flicker all over the place and take forever.

    I use a generalised table-driven state engine that can be used for a multitude of purposes, I just have to enumerate the states I want to track and my standard routines will do all the wrangling for me.

    However something like a display can make do with hard-coded tracking (eg) just 3 variables, and asserting them only when they change. You have to make sure you assert them in the right order, eg:

    Power
    Input
    Screen mode

    Now you work through your states whenever they need reviewing (deciding that is another entertaining problem), and reassert whatever needs it one at a time.

    Perhaps I should clarify the "state engine" thing. When complex timing issues are involved, you can't have prescriptive code in your mainline saying "do this, now do this, now do that". Instead it has to say "I want this done, and this, and this" leaving a trail of crumbs for the device module, and a separate loop in the device module says "what needs doing next?"

    Then you need a queueing mechanism for the individual IR pulses that are required for each of those top-level state changes. Some can require as many as 13 pulses (that's my record anyway, to get to AV input 2 on a VCR) and you also need a variable pause mechanism for commands that might take a long time eg Power On.

    You simply cannot do this with a hard-coded sequence of WAITs - you have to build a queueing engine.

    Yes, this sounds like a lot of hard work, but one day you will solve a difficult problem at the last moment in a darkened room with a serious beer thirst raging because you already have the tools at hand and you know that you just have to slot the right values in to the table definitions and the rest will look after itself. You only have to code the difficult bits once - then you can use them again and again.

    PS when I did this last week for a TV in a courtroom my IR sequence for input 1 *included* power on so I had to fudge the state engine accordingly.
Sign In or Register to comment.