Home AMX User Forum AMX General Discussion
Options

Nec Gt-1150

Hi everyone.
Okay I have a NEC GT-1150 here that is driving me around the bend. I am trying to obtain the lamp run time for the unit. I have the correct code(manual directly from NEC tech department) and when I send the request, I receive the data and when I go to add it up its not the correct run time. I am calculating the data manually from the buffer I created to capture this info. I.E. of code sent to projector: $03,$8C,$00,$00,$00,$8F I am getting the correct responds but the data is flawed. Anyone see an error with the command?

Comments

  • Options
    Joe HebertJoe Hebert Posts: 2,159
    Hi Thomas,

    The best I can tell, the command looks right according to the manual. What are you receiving back from the unit for DATA01-04? What is the hour calculation you come up with regading those data bytes? And what do you think the hours should be?

    Cheers,
    Joe
  • Options
    Hi Joe
    I won't be back into the office till Monday(slacking off in my old age) and I'll post the data recieved. The projector says 4 hrs and the data adds up to .9 hrs or something like that..
  • Options
    Hi Joe
    Here is the raw code I am getting from the buffer.-$23,$8C,$01,$50,$10,$BD,$3E,$00,$00,$15,$6,$00,$00,$C6,$65,$52,$00,$00,$E4,$57,$00,$D8. Now once you drop the header the first 8 bits of data you get the total run time(normal + eco mode) you have $BD+$3E+$00+$00(NORMAL MODE)=$FB convert to DEC = 251/60 = 4.1 hrs.
    $15+$06+$00+$00=1B convert =27/60=.45 hrs
    total run time = 4.55 rounded to nearest hour = 5
    The projector is also giving me 5 hrs. I think were I made the mistake was following the dam manual. When I took a really close look at it and did the cal's they had I found a mistake that they made. Page 136 in the manual I have is incorrect.
  • Options
    Has anyone ever checked how accurate the data flow from the GT-1150 was? After some screwing around I was able to get the raw code, exact the info and calculate it all to get a run time. however I find that the data is not always the same(anywhere near) if I request the info again. There seems to be alot of extra garbage in the recieved data that isn't really necessary. Just checking if anyone else had this before?
  • Options
    Hi Thomas,

    My short answer is - "why aren't you using the NEC module from AMX's site?". Of course, you could be doing this in Axcess, in which case proceed to the long answer.

    Long answer:

    You're doing the math incorrectly. Take the first four data bytes that you got in: $BD,$3E,$00,$00. This is really a long integer that has been sent least significant byte first. Construct a full long integer like this: $00 00 3E BD, or 16061 decimal. NEC gives you the time in seconds - not minutes - so you'll need to divide that by 3600 to get 4.46 hours. Do the same with the eco bytes: $15,$6,$00,$00 --> $00 00 06 15 --> 1557 seconds --> .43 hours. Add 'em up to get 4.89 hours.

    Now, especially if you're working in Axcess, you'll want to save yourself some time/head stress. Think about numbers $1000000 and larger that >could< be returned by the projector. That turns out to 4660 hours, so unless you've got magic bulbs the rest of the world doesn't have, you're never* going to see that number or higher come from the projector. Of a four-byte message, that tells us that we can ignore the top-most byte.

    Now look at the lowest byte. It represents a max of 255 seconds. Chances are you don't care about 4.25 minutes when you're trying to calculate lamp hours, so - you guessed it - we can ignore the bottom-most byte as well.

    If you get that raw string into a variable like "Msg", I'd suggest writting a code block that takes in that raw string and does this:

    (Msg[7] + (Msg[8] * $100) + Msg [11] + (Msg[12] * 255)) / 14

    That divide by 14 takes care of the "multiply by 256 then divide by 3600" part, which while not perfect, you couldn't do in in Axcess anyway...

    In your example, you'd have ($3E + ($00 * $100) + $06 + ($00 * $100) = $44 or 68. 68 / 14 = 4.86 hours.

    I haven't done the calculation to see how far off from 100% this is, but considering what you're trying to do, I don't think it's enough to warrant fretting over...

    - Chip


    * = never say never
  • Options
    Thanks Chip
    I read over everything and it seems to make sense(that scares me) The manual semed to jump from A to Z on how to obtain the correct runtime. Thanks I owe you one. Later this week or late at night I'll write a 'call' that will work with both axcess and netlinx.
  • Options
    ColinColin Posts: 51
    getting the elements into a usable figure

    I am having an issue trying to get the 4 elements into a singular form to do the final maths on

    {
    REMOVE_STRING(cPJ_DATA,"$23,$96,$01,$10,$06,$00,$01",1)
    BYTE[1] = GET_BUFFER_CHAR(cPJ_DATA)
    BYTE[2] = GET_BUFFER_CHAR(cPJ_DATA)
    BYTE[3] = GET_BUFFER_CHAR(cPJ_DATA)
    BYTE[4] = GET_BUFFER_CHAR(cPJ_DATA)
    LAMPTIME = "BYTE[1],BYTE[2],BYTE[3],BYTE[4]"
    }

    I just get the first element, anyones help greatly appreciated

    Cheers

    Colin
  • Options
    NMarkRobertsNMarkRoberts Posts: 455
    You haven't told us what your variables are declared as or used Hungarian notation to give us a hint but I'll guess you are trying to shove a character array into an integer or some such. That doesn't work. This very literally spelled out code might (untested):
    (* Add up 4 bytes from a string, least significant byte first *)
    define_function long AddItUp(
      char sArgString[])
    {
    stack_var integer nMyPointer
    stack_var long    lMyResult
    
    for (nMyPointer = 4; nMyPointer >= 1; nMyPointer--)
      {
    	lMyResult = (lMyResult * 255) + type_cast(mid_string(sArgString,nMyPointer,1))
      }
    
    return lMyResult;
    }
    

    However this code just attempts to do what you are doing and does not address what Chip writes.
  • Options
    sethollesetholle Posts: 66
    Nec projector warm up times

    Just a note, after working with numerous nec models, the warm and cool down timer are almost never consistent. Sometimes it will take 30 seconds, sometimes five minutes, and the feedback is almost never correct.
    Sometimes it will just stop talking for awhile.
    A way around this is to put in place your own code to disable projector functions for a prescribed period of time. You then test it, in a mission critical place this is more reliable then relying on nec feedback.
    I have never had success with any of the modules for the nec projectors. But use modules for almost anything else.
    Hope that helps
    SEth c. olle
Sign In or Register to comment.