New NI firmware breaks XCHM
RicardoSiqueira
Posts: 373
in AMX Hardware
I always upload the latest firmware to my home system (NI-3000) before attempting it in the field.
Here is a problem that I found with the latest NI firmwares (Duet + Device) that may affect a lot of dealers out there:
- It breaks the XCHM extended channel mode. If you do favorite channels for Sats and Cable boxes this may affect you. It doesn't send the first digit correctly or depending on the mode, it sends a 0. For example, you try channel 922 using Mode 0 and it should do:
'XCH 922' The resulting IR would be 9-2-2
However, it misses the 9 sending 2,2. This was verified on a Scientific Atlanta Cable box that used to work fine for almost 2 years using the XCHM mode 0.
I also tried mode 1 and 2 in my office with another NI-3000 and a LG Sat and it also have problems. In this case it sends a 0 instead of the first number. For example HBO channel 501:
'XCH 501' The resulting IR would be 5-0-1-enter (Mode 1)
'XCH 501' The resulting IR would be 5-0-1(Mode 2)
Instead it sends a 0 in placle of the first digit 5. The worse is that in the Netlinx Studio Diagnostics Window it shows the correct call, but never sends it correctly. I had to physically connect a LG Sat to the NI IR port to confirm this problem.
Line 100 :: Command To [5001:10:3]-[XCH501] - 09:03:59
This is a very serious problem that affects all my projects. AMX needs to fix this as soon as possible or at least have a work around for us that uses the XCHM correctly. Can anybody confirm this? Any ideas? I believe that the problem may be with the Device Firmware v1.11.136. I will try to downgrade my system to test.
Sincerely,
Ricardo
Here is a problem that I found with the latest NI firmwares (Duet + Device) that may affect a lot of dealers out there:
- It breaks the XCHM extended channel mode. If you do favorite channels for Sats and Cable boxes this may affect you. It doesn't send the first digit correctly or depending on the mode, it sends a 0. For example, you try channel 922 using Mode 0 and it should do:
'XCH 922' The resulting IR would be 9-2-2
However, it misses the 9 sending 2,2. This was verified on a Scientific Atlanta Cable box that used to work fine for almost 2 years using the XCHM mode 0.
I also tried mode 1 and 2 in my office with another NI-3000 and a LG Sat and it also have problems. In this case it sends a 0 instead of the first number. For example HBO channel 501:
'XCH 501' The resulting IR would be 5-0-1-enter (Mode 1)
'XCH 501' The resulting IR would be 5-0-1(Mode 2)
Instead it sends a 0 in placle of the first digit 5. The worse is that in the Netlinx Studio Diagnostics Window it shows the correct call, but never sends it correctly. I had to physically connect a LG Sat to the NI IR port to confirm this problem.
Line 100 :: Command To [5001:10:3]-[XCH501] - 09:03:59
This is a very serious problem that affects all my projects. AMX needs to fix this as soon as possible or at least have a work around for us that uses the XCHM correctly. Can anybody confirm this? Any ideas? I believe that the problem may be with the Device Firmware v1.11.136. I will try to downgrade my system to test.
Sincerely,
Ricardo
0
Comments
This function will break down any 1,2,or 3 digit channel number and send the correct ir commands. For example this will send 0 0 2 for channel 2 and so on.
DEFINE_FUNCTION fnGET_TV_STATION(DEV dvSOURCE,INTEGER PRESET) { LOCAL_VAR INTEGER CHAN1[3] CHAN1[1] = (PRESET/100+10) CHAN1[2] = ((PRESET%100)/10+10) CHAN1[3] = ((PRESET%100)%10+10) SEND_COMMAND dvSOURCE,"'SP',CHAN1[1]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[2]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[3]" }Once again hope this helps.
Ricardo
I updated to 136 from 115, did extensive xchm testing with no problems. I wonder why the inconsistency from system to sytem?
Did you have a cable box or sat attached. Remember, Studio Diagnostics will report correct use of XCH and the IR port may pulse the correct number of times, but the IR codes will be wrong. I tested on (1) NI-4000 and (3) NI-3000 and all had the same problem under 136. Later I loaded all NIs with 115 and everything is back to normal.
I have sats (1-hdtivo and 3-hdsats) attached, and I was onsite to test.
I have tested this and can not duplicate.
Thanks
--John
XCH - I was not setting CTON and CTOF (an oversight, actually, but it was working). Favorites are working fine after reboot & device renumbering. No change to code. TimeWarn.irl. 8400 DVR. Digits only, no select/enter. Three digit codes work fine.
Curious if DSS receivers (especially those with delicate timing required for same-digit-twice channels & the early HR10-250) are more sensitive????
Bill
DATA_EVENT[dvCable]
{
ONLINE: //IR device comes ONLINE
{
SEND_COMMAND dvCable,'SET MODE IR'
SEND_COMMAND dvCable,'CARON'
SEND_COMMAND dvCable,"'CTON',3"
SEND_COMMAND dvCable,"'CTOF',3"
SEND_COMMAND dvCable,'XCHM-0'
}
}
I use a structure to load the favorite channel numbers and send_command XCH to pulse the IRs. I know that this part is correct because it has worked for the past 2 years and it still works 100% under v115 and v118 of the Device Firmware and I have confirmed this in 4 NIs.
I would like to thank everyone that replied to this thread, and I am also curious to know why with some people it works under v136. Firmware upgrades should not affect IR files that work fine on previous firmware versions. On this firmware might be my files, the next yours and so on. Can you imagine the chaos. Hopefully, AMX can explain this one. For those willing to test my IR files, please let me know the results.
Sincerely,
Ricardo
I am using DIRECTV0.IRL and HUGHES09.IRL for sat and tivo control and I keep the code simple:
send_command dvsat,"'XCH ',itoa(button.input.channel)"
I leave cton and ctof at default values and use set_pulse_time for ir adjustments. No problems with xchm at this time.
It can be due also to different version of boards inside NI
Vinc
Do you have a small test program that you can share with us that we can use to confirm/refute what you?ve been experiencing?
Consider the following code:
DEFINE_DEVICE dvTP = 10001:1:0 dvCable = 5001:9:0 dvSat = 5001:10:0 DEFINE_EVENT DATA_EVENT[dvCable] { ONLINE: { SEND_COMMAND DATA.DEVICE,'SET MODE IR' SEND_COMMAND DATA.DEVICE, 'CARON' //Mode 0 Example: 'XCH 3' The resulting IR would be 3-enter. SEND_COMMAND DATA.DEVICE, 'XCHM-0' } } DATA_EVENT[dvSat] { ONLINE: { SEND_COMMAND DATA.DEVICE,'SET MODE IR' SEND_COMMAND DATA.DEVICE, 'CARON' //Mode 1 Example: 'XCH 3' The resulting IR would be 0-0-3-enter. SEND_COMMAND DATA.DEVICE, 'XCHM-1' } } BUTTON_EVENT[dvTP,1] { PUSH: { //Mode 0: This should produce 1-2-3-enter SEND_COMMAND dvCable,'XCH 123' } } BUTTON_EVENT[dvTP,2] { PUSH: { //Mode 1: This should produce 4-5-6-enter SEND_COMMAND dvSat,'XCH 456' } }Are saying that pushing button 1 will not send the expected 1-2-3-enter (mode 0) but will instead miss the 1 and send 2-3?And are you also saying that pushing button 2 will not send the expected 4-5-6-enter (mode 1) but will instead replace the 4 with a 0 and send 0-5-6-enter?
Mode 0 sends an enter so ?XCH 922? should produce 9-2-2-enter
Let us know what you see if you decide to run the above code.
Can anyone say if this is a real problem or not? Does it break XCHM or not? Thanks
DATA_EVENT[dvSat] { ONLINE: { SEND_COMMAND DATA.DEVICE,'SET MODE IR' SEND_COMMAND DATA.DEVICE, 'CARON' //Mode 1 Example: 'XCH 3' The resulting IR would be 0-0-3-enter. SEND_COMMAND DATA.DEVICE, 'XCHM-1' } } BUTTON_EVENT[dvTP,2] { PUSH: { //Mode 1: This should produce 4-5-6-enter SEND_COMMAND dvSat,'XCH 456' } } Note: I also tried XCH 123, XCH 789, XCH 501 and XCH 100Under v136:
It worked, but sometimes it would miss sending one digit.
Under v115:
100% hit, no problems.
Then, I tried my code to initilaize the device:
DATA_EVENT[dvSat] { ONLINE: { SEND_COMMAND dvSat,'SET MODE IR' SEND_COMMAND dvSat, 'CARON' SEND_COMMAND dvSat,"'CTON',3" SEND_COMMAND dvSat,"'CTOF',3" //Mode 1 Example: 'XCH 3' The resulting IR would be 0-0-3-enter. SEND_COMMAND dvSat, 'XCHM-1' } } BUTTON_EVENT[dvTP,2] { PUSH: { //Mode 1: This should produce 4-5-6-enter SEND_COMMAND dvSat,'XCH 456' } } Note: I also tried XCH 123, XCH 789, XCH 501 and XCH 100Under v136:
It worked, but it also sometimes missed sending one digit.
Under v115:
100% hit, no problems. I little faster then Joe's code since I am using the CTON 3 and CTOF 3 instead of default 5.
Anyways, Taking in consideration my testing and DHawthorne problems with v118. I am sticking with v115 for now on all my NIs. v115 feels a little more responsive and accure. Attached please find the IR file I used for the Sat in case you want to replicate my findings or have a LG Sat to test. Again, thanks everyone for participating in this tread.
Sincerely,
Ricardo
I have found timing of the IR pulses are critical when controlling a cable box and less so for DSS receivers as well as the quality of the IR file.
The problem could be cable box specific instead a problem with the firmware. Perhaps the firmware tightened up the timing a bit. This would be much different than "losing" a specific IR pulse in the IR queue.
I like to use " 'CTON',1" and " 'CTOF',4" for most DSS receivers for quick preset changes. The Scientific Atlanta DVR8000 also worked well with these settings, but I need to try this out with v136.
I recall problems with other cable boxes where I needed to use the settings " 'CTON',3" and " 'CTOF',8". You can change these settings on-the-fly with 'Control a Device' within NetLinx Diagnostics. Use the proper Send_Command as you do in your program.
That said, and knowing Engineering watches these forums, could we get some official word on whether this update is working as intended? It's very possible that previous versions had issues that actually made them work better with flaky devices because way the implementation was broken catered to those devices weakness ... so fixing themactually broke them for those devices unless set up properly (for those of you who dabble at all in HTML design, I'm thinking of IE support of CSS, and how strict support of the actual standard breaks many web sites that work with IE because it ignores the errors in them).
The bottom line is that although I am using 115 without trouble right now, I am leary of getting bitten by the bugs 118 and 136 were intended to fix. I know that AMX policy is generally to keep mum about bugs until a fix can be offered, but this can often be very frustrating to those of us who have to deal with those bugs and griping customers.
AMX does watch these from time to time.
This latest release addressed a lot of big issues. 232 and JVC Ir being amoung the biggest.
I'm not sure that this is the proper place to put an official update on this release. Not all of the AMX dealers/installers use these forum. (sadly).
Some IR files work fine and obviously the ones that RicardoSiqueira is using are now not working as they did in previous builds.
If AMX had a beta version would anyone here be willing to try it? I'm sure certain beta agreements would have to be filled out.
All comments made by me are my personal opinions and are not made on behalf of AMX.
I just wrote a smiple little routine that executes an XCH every five seconds, starting at 1 going on until I tell it to stop. It's currently on 460 and the cable box has not missed one digit yet. I have initialized the CTON and CTOF. And yes - I have sat here for the past 30+ minutes watching it. I personally would and never have used XCH in any of programs for a client, and instead have used a routine similar to "pauld". I use 'SP' only now, and any of the jobs that were done prior to my employment have v115 firmware loaded. I have had problems with the IR in the dreaded 118 firmware, and have had to revert back to v115 instead.
My personal conclusion is that it works fine, and that the XCH should be removed all together from AMX. Now that this magnificent way of sending channels (pauld's routine) has been thrown in the open, I would also suggest that everyone use it from now on.
Just my two cents . . .
Everybody feel free to use/modify this routine (in my earlier post), I think this kind of routine should be in the public library.
Paul
DEFINE_FUNCTION fnGET_TV_STATION(DEV dvSOURCE,INTEGER PRESET) { LOCAL_VAR INTEGER CHAN1[4] CHAN1[1] = (PRESET/1000) CHAN1[2] = (PRESET/100+10) CHAN1[3] = ((PRESET%100)/10+10) CHAN1[4] = ((PRESET%100)%10+10) IF(PRESET>=1000) SEND_COMMAND dvSOURCE,"'SP',CHAN1[1]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[2]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[3]" SEND_COMMAND dvSOURCE,"'SP',CHAN1[4]" }We could argue that XML parsing should be built into NetLinx with the introduction of ethernet enabled masters, but we've had to come up with a module to do that. What would be the challenge if AMX did everything for us?
STACK_VAR INTEGER x1 STACK_VAR INTEGER x2 STACK_VAR INTEGER x3 STACK_VAR INTEGER x4 STACK_VAR INTEGER nCHAN STACK_VAR CHAR temp_CHAN[10] nCHAN = ATOI(sCHAN) . . . x4 = nCHAN/1000 + 10 IF(x4-10) SEND_COMMAND dvIROUT,"'SP',x4" x3 = (nCHAN - ((nCHAN/1000)*1000))/100 + 10 IF(x4-10 or x3-10) SEND_COMMAND dvIROUT,"'SP',x3" ELSE { SEND_COMMAND dvIROUT,"'SP',10" } x2 = (nCHAN - ((nCHAN/100)*100))/10 + 10 IF(x4-10 or x3-10 or x2-10) SEND_COMMAND dvIROUT,"'SP',x2" ELSE { SEND_COMMAND dvIROUT,"'SP',10" } x1 = (nCHAN - ((nCHAN/10)*10)) + 10 IF(x4-10 or x3-10 or x2-10 or x1-10) SEND_COMMAND dvIROUT,"'SP',x1" ELSE { SEND_COMMAND dvIROUT,"'SP',10" } temp_CHAN = sCHAN IF(FIND_STRING(temp_CHAN,'.',1)) { REMOVE_STRING(temp_CHAN,'.',1) IF(nDASH_BTN) SEND_COMMAND dvIROUT,"'SP',nDASH_BTN" nCHAN = ATOI(temp_CHAN) x2 = (nCHAN - ((nCHAN/100)*100))/10 + 10 IF(x2-10) SEND_COMMAND dvIROUT,"'SP',x2" ELSE SEND_COMMAND dvIROUT,"'SP',10" x1 = (nCHAN - ((nCHAN/10)*10)) + 10 IF(x2-10 or x1-10) SEND_COMMAND dvIROUT,"'SP',x1" ELSE SEND_COMMAND dvIROUT,"'SP',10" } IF(nENTER_CHAN) SEND_COMMAND dvIROUT,"'SP',nENTER_CHAN" } }//END SWITCHI use this code with Dish Network, DirecTV, and Comcast Cable receivers. Both the DASH and ENTER commands are optional, depending on the receiver in question. I am posting this because I saw everyone else posting their version and I felt left out
Jeff
I think you need a little more modification to the code. CHAN1[2] doesn't exclude the 1000s digit. On the plus side, Looking over this code has caused me to evaluate my code a little. I definately see where MOD (%) can help shorten the code (and maybe speed it up). In CHAN1[4], you could make it as short as = (PRESET%10+10).
I will leave my original code posted as it has been tested, but I REALLY like the MOD formulas used above.
Jeff
The first line should be:
The great thing about this is all you need to do is make panel modifications if a station changes. You make all your TV stations on a seperate port, and number them with the according station number. So let's say for example, ABC is channel 7, the button's programmed channel would be 7. And in code, you throw in something like this:
BUTTON_EVENT[dvTP_CAB,BUTTON.INPUT.CHANNEL]// ANY BUTTON ON PORT X { PUSH: CALL 'GET CABLE'(dvCABLE,BUTTON.INPUT.CHANNEL) // DO IT! }The one I use is a DEFINE_CALL - works the same - and so if channel ABC changes to channel 13, you make the change in the Panel. It's great because no code has to be changed, the processor never reboots in an update (for channels that is), and no one needs to check over the code again to make sure nothing has gone crazy.