Nec Gt-1150
Thomas Hayes
Posts: 1,164
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?
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?
0
Comments
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
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..
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.
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
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.
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
However this code just attempts to do what you are doing and does not address what Chip writes.
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