Any answer to your question PMWVideo?
I just recently got the same issue. And it's annoying! It only happens sometimes though.
Seems like the best CTON and CTOF times are setting both to 1.
Possibly, DirectTV might want something a bit more awkward... like 0.75 and 1.25.
I'll let you know if i get anything stable working.
I have had several issues with this. Thanks to this forum though I found the way to make it work without hours of moving the emitter to "just the right spot."
The resolution is to put a 1k resistor in-line with the positive side of the IR emitter and send the following to your IR port
In Australia we have a similar problem controlling Foxtel pay TV boxes reliably, Foxtel being (unhappily) about the only pay TV system in the market. The problem tends to manifest itself more as missed commands than duplicates, however...
We've found out a number of things:
* Where the purpose of an IR code is a "single shot" type command such as a digit, as opposed to a continuous/ramping command such as volume control, the IR function should be imported into the IR file with the number of repeats: 0. See the attached screenshot for how to check whether this is the case with the waveform view turned on in IREdit. I'm not sure that there is the facility in IREdit to change this or select it at the time when you're learning the code, but if you're keen enough to do a search for details on the CCF hex code format you can write out new codes by hand and import those.
* IR ports ain't IR ports, and did we waste time figuring that out. All AMX IR output devices seem to behave subtly differently. The classic example is IR ports on an NI-4100 vs the IR ports on an NXC-IRS4. Pulsing digits on a Foxtel box using send_command 'SP' (with the appropriate IR command as discussed above) from an onboard port on an NI-4100 works fine. Doing the same with a port on an NXC-IRS4 loaded into the same NI-4100 does not.
When we finally did realise that different devices were producing different results, AMX Australia confirmed that this is the case and was able to provide us with what they believe to be a guaranteed method of control which is platform independent. I don't like how it works, but it works and may help in your situation.
Important to note is that the technote which sings the virtues of send_command 'SP' should be ignored until they make this send_command function the same on all IR output devices. There is a note in the code provided to us which goes as follows:
/* NOTE TO PROGRAMMER
* The following code will work for an NI-2000 IR Port but not for an NXC-IRS4.
* The Foxtel Set-top box may occasionally ignore one or more of the IR code
* pulses from an NXC-IRS4 using SP commands.
*/
/*SEND_COMMAND dvFoxtel, "'CTON',0" // 0 tenths of a second IR pulse time
SEND_COMMAND dvFoxtel, "'CTOF',2" // 2 tenths of a second time between IR pulses
SEND_COMMAND dvFoxtel, "'SP',(FOXTEL_CH_MAP[nArrayIndex][1]+10)"
SEND_COMMAND dvFoxtel, "'SP',(FOXTEL_CH_MAP[nArrayIndex][2]+10)"
SEND_COMMAND dvFoxtel, "'SP',(FOXTEL_CH_MAP[nArrayIndex][3]+10)"*/
An abridged version of the code from AMX is as follows:
DEFINE_VARIABLE
integer holdTime = 2 // Minimum two tenths of a second button hold time
integer holdingRepeatcount // Variable to count out number of repeat executions of the button hold event handler
integer minHoldingRepeatCount = 5 // Minimum number of repeat executions of the button hold event handler to occur before executing code inside button_event:hold code block
integer nDevicePulseLength = 0 // Pulse Length of zero used for pulsing Foxtel IR codes
integer nSystemPulseTime // Variable to hold the current pulse time
DEFINE_EVENT
button_event[dvTP, GENERAL_COMMANDS] // Emulate a button on the Foxtel handheld remote control
{
push:
{
// Determine what channel to pulse, however you may want to do it...
// ...
// ...
nSystemPulseTime = get_pulse_time // Get the current pulse time
set_pulse_time(nDevicePulseLength) // Set the pulse time to zero
// Pulse the IR - Assums that the non-continuous codes are being used
pulse[dvDevice,<whatever_channel>]
holdingRepeatcount = 0
}
hold[holdTime,repeat]:
{
// Determine what channel to pulse, however you may want to do it...
// ...
// ...
holdingRepeatcount++
if(holdingRepeatcount >= minHoldingRepeatCount)
{
// Pulse the IR - Assums that the non-continuous Foxtel IR codes are being used
pulse[dvDevice,<whatever_channel>]
}
}
release:
{
set_pulse_time(nSystemPulseTime) // Restore the pulse time
}
}
button_event[dvTP, CHANNEL_COMMANDS] // Select a Foxtel channel (channel codes contain 3 digits)
{
push:
{
// Determine what digits to pulse, however you may want to do it...
// ...
// ...
// ...
if(nArrayIndex)
{
nSystemPulseTime = get_pulse_time // Get the current pulse time
set_pulse_time(0)
pulse[dvDevice,<first_digit>]
wait 2
{
pulse[dvDevice,<second_digit>]
wait 2
{
pulse[dvDevice,<third_digit>]
}
}
}
}
release:
{
set_pulse_time(nSystemPulseTime) // Restore the pulse time
}
}
Try using visible/flash infrared emitters! They have about a 1/4 the output of the regular emitters. They have less output due to the fact they are also lighting up an led when passing the signal. They are great for troubleshooting as well. You can get them from http://www.easyadapters.com/store/ir_emitters.htm#VIRE
Try using visible/flash infrared emitters! They have about a 1/4 the output of the regular emitters. They have less output due to the fact they are also lighting up an led when passing the signal. They are great for troubleshooting as well. You can get them from http://www.easyadapters.com/store/ir_emitters.htm#VIRE
My experience with those is that the output is so low they don't work at all. Might be the brand I used, might be the length of the wire, just be aware it's an issue.
I recently solved the issue at an old project - and this may or may not help you.
We subbed out the code on this house to a large automation programming house and they appear to like the TO command as opposed to the PULSE command.
Here I have been wasting a ton of hours setting different pulse times, when in reality TO must use a preset pulse time and is not related to the set pulse time. I changed all of the TO commands that related to satellite and whola - no more doubling.
Here is my online event.
Online:
{
SEND_COMMAND DATA.DEVICE,"'CTON',2"
SEND_COMMAND DATA.DEVICE,"'CTOF',3"
SET_PULSE_TIME(1)
}
Here is my online event.
Online:
{
SEND_COMMAND DATA.DEVICE,"'CTON',2"
SEND_COMMAND DATA.DEVICE,"'CTOF',3"
SET_PULSE_TIME(1)
}
Be aware that SET_PULSE_TIME is a global change that affects all the devices, not just the one you are referring to in the online command. If you want to use the CTON/CTOF commands, those apply to the XCH and SP send commands, which is what I've gone to exclusively based on the recommendation of other wise coders here in the forums.
Using the SP send command has greatly improved my ability to make easy adjustments to the systems I work on. I now dread going back to those projects I haven't changed.
when in reality TO must use a preset pulse time and is not related to the set pulse time.
I don?t believe there is any pulse time associated with a TO command.
The TO command:
BUTTON_EVENT[dvTP,1] {
PUSH: {
TO[BUTTON.INPUT] //turn button ON while pushed
TO[dvIR,1] //turn channel ON while pushed
}
}
Is a shortcut for this:
BUTTON_EVENT[dvTP,2] {
PUSH: {
ON[BUTTON.INPUT] //turn button ON
ON[dvIR,1] //turn channel ON
}
RELEASE: {
OFF[BUTTON.INPUT] //turn button OFF
OFF[dvIR,1] //turn channel OFF
}
}
SET_PULSE_TIME() sets the one global timer and determines the length of any PULSE command. I use the PULSE command where timing isn?t critical like for pulsing channels of virtual devices or possibly pulsing relays.
For what it?s worth I?ve decided to stay away from the PULSE command when it comes to IR (I?ll use TO in some cases) and opt instead to go with the SP command because I can set individual pulse widths for each IR device with the CTON and CTOF commands as you demonstrated.
We were finding that even a quick press and release would still yield a double command.
You are right also about the set pulse time. I think my placement in the online event was poorly thought out because of it's potential impact on the other IR devices in the system. I will change that by handling the set pulse time in the event as Vining displayed a few posts back.
The best part about the SP cmd is that it stacks and sends - fundamentally why it was developed back in the AXcent 2 days where, although there were 6 or so IR ports, there were only 2 physical devs in the box. So if you wanted to start 4 DVDs at once (as a poor example), it simply couldn't work.
SP wouldn't let them start all together on the Axcent2 either, but at least they would all receive the command! It's really easy for users to crash IR codes using PULSE unless you have gone to a lot of trouble to make a stack handler for each and every IR port you are using.
Multi user, multi room and a single communal dev to control is going to end in tears using PULSE for sure.
This is going to sound absurd - BUT - we ran into this problem a few weeks ago. You'll probably have to wind up moving the IR bug on the box. Our system was still new, but it the IR had been working just fine for several weeks. We had to eventually load up about 90% of the IR windows with black tape on our H20. We too also messed with the CTON / CTOF. The best we can configure is that there was some kind of "firmware" update, and the IR is super sensitive now.
You could also putting in a 1k resistor in series with the flasher. Either way, try to limit the amount of IR going to the box from the flasher. I've been using CTON-2 and CTOF-3 and it's worked fine.
Good luck!
The above message from J James is what i found to work. I put a piece of black tape over the Boxes EYE and put a pinhole in the tape and placed the IR Probe over the pinhole and this works 99% of the time. I have yet to try the Resistor Fix, but i assume it would be a more elegant solution.
The above message from J James is what i found to work. I put a piece of black tape over the Boxes EYE and put a pinhole in the tape and placed the IR Probe over the pinhole and this works 99% of the time. I have yet to try the Resistor Fix, but i assume it would be a more elegant solution.
For devs that are super sensitive to IR and get 'saturated' by normal placement, we have had plenty of success by pulling the diode out of the case and putting it in backwards - ie the 'blob' (lens) faces away from the dev.
For devs that are super sensitive to IR and get 'saturated' by normal placement, we have had plenty of success by pulling the diode out of the case and putting it in backwards - ie the 'blob' (lens) faces away from the dev.
The 1k dropper suggested is also a very good fix.
A couple things we've done in this regard...
1 place a small peice of electrical tape with a pin-hole poked in it over the IR emitter.
2 putting a small tuft of cotton over the emitter.
Comments
I just recently got the same issue. And it's annoying! It only happens sometimes though.
Seems like the best CTON and CTOF times are setting both to 1.
Possibly, DirectTV might want something a bit more awkward... like 0.75 and 1.25.
I'll let you know if i get anything stable working.
In other words when doing channel presets always do three pulses for station recall.
DATA_EVENT[dvDSS_1] { ONLINE: { SEND_COMMAND dvDSS_1,"'CTON',1" } } DEFINE_CALL 'SAT PRESET'(dev dvDEV_SAT,INTEGER iCH1, INTEGER iCH2, INTEGER iCH3) { iCH1 = iCH1+10 iCH2 = iCH2+10 iCH3 = iCH3+10 SET_PULSE_TIME(1) SEND_COMMAND dvDEV_SAT,"'SP',iCH1" SEND_COMMAND dvDEV_SAT,"'SP',iCH2" SEND_COMMAND dvDEV_SAT,"'SP',iCH3" SEND_COMMAND dvDEV_SAT,"'SP',21" WAIT 40 SAT_PRESET = 0 SET_PULSE_TIME(5) } BUTTON_EVENT[BTNS_SAT_PRESET] //SAT Presets { PUSH: { dev vdvDSS_SEL IF(SAT_PRESET = 0) //NOLONGER PULSING PRESET { SAT_PRESET = BUTTON.INPUT.CHANNEL IF(SAT_SEL > 0) TO[vdvTPa,BUTTON.INPUT.CHANNEL] ELSE SEND_COMMAND vdvTPa,'ABEEP' SWITCH(SAT_SEL) { CASE 91: (*SAT1*) {vdvDSS_SEL = dvDSS_1} CASE 92: (*SAT2*) {vdvDSS_SEL = dvDSS_2} CASE 93: (*SAT3*) {vdvDSS_SEL = dvDSS_3} CASE 94: (*SAT4*) {vdvDSS_SEL = dvDSS_4} } SET_PULSE_TIME(1) SWITCH(SAT_PRESET) { (* VIDEO PRESETS *) CASE 131: (*ESPN HD *) {CALL 'SAT PRESET'(vdvDSS_SEL,0,7,3)} CASE 132: (*COMCAST CHI *) {CALL 'SAT PRESET'(vdvDSS_SEL,6,4,0)} CASE 133: (*WGN CHI *) {CALL 'SAT PRESET'(vdvDSS_SEL,0,0,9)} CASE 134: (*NBC *) {CALL 'SAT PRESET'(vdvDSS_SEL,0,0,5)} CASE 135: (*CBS *) {CALL 'SAT PRESET'(vdvDSS_SEL,0,0,2)} CASE 136: (*ABC *) {CALL 'SAT PRESET'(vdvDSS_SEL,0,0,7)} CASE 137: (*BLOOMBERG *) {CALL 'SAT PRESET'(vdvDSS_SEL,3,5,3)} CASE 138: (*MSNBC *) {CALL 'SAT PRESET'(vdvDSS_SEL,3,5,6)} CASE 139: (*CNN *) {CALL 'SAT PRESET'(vdvDSS_SEL,2,0,2)} CASE 140: (*FOX CHI NEWS*) {CALL 'SAT PRESET'(vdvDSS_SEL,3,6,0)} CASE 141: (*WEATHER CH *) {CALL 'SAT PRESET'(vdvDSS_SEL,3,6,2)} (* MUSIC PRESETS *) CASE 161: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,3,7)} CASE 162: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,1,9)} //Rev1 CASE 163: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,3,2)} //Rev1 CASE 164: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,2,4)} CASE 165: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,3,6)} //Rev1 CASE 166: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,0,0,0)} CASE 167: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,5,7)} CASE 168: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,5,8)} CASE 169: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,5,6)} //Rev1 CASE 170: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,5,9)} CASE 171: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,5,1)} //Rev1 CASE 172: (* *) {CALL 'SAT PRESET'(vdvDSS_SEL,8,5,2)} } } SET_PULSE_TIME(5) } }I have had several issues with this. Thanks to this forum though I found the way to make it work without hours of moving the emitter to "just the right spot."
The resolution is to put a 1k resistor in-line with the positive side of the IR emitter and send the following to your IR port
Data_Event[dvHDSat2]
{
Online:
{
SEND_COMMAND dvHDSat2,"'CTON',2"
SEND_COMMAND dvHDSat2,"'CTOF',3"
}
}
After doing this, everything worked perfectly!
-Noah
We've found out a number of things:
* Where the purpose of an IR code is a "single shot" type command such as a digit, as opposed to a continuous/ramping command such as volume control, the IR function should be imported into the IR file with the number of repeats: 0. See the attached screenshot for how to check whether this is the case with the waveform view turned on in IREdit. I'm not sure that there is the facility in IREdit to change this or select it at the time when you're learning the code, but if you're keen enough to do a search for details on the CCF hex code format you can write out new codes by hand and import those.
* IR ports ain't IR ports, and did we waste time figuring that out. All AMX IR output devices seem to behave subtly differently. The classic example is IR ports on an NI-4100 vs the IR ports on an NXC-IRS4. Pulsing digits on a Foxtel box using send_command 'SP' (with the appropriate IR command as discussed above) from an onboard port on an NI-4100 works fine. Doing the same with a port on an NXC-IRS4 loaded into the same NI-4100 does not.
When we finally did realise that different devices were producing different results, AMX Australia confirmed that this is the case and was able to provide us with what they believe to be a guaranteed method of control which is platform independent. I don't like how it works, but it works and may help in your situation.
Important to note is that the technote which sings the virtues of send_command 'SP' should be ignored until they make this send_command function the same on all IR output devices. There is a note in the code provided to us which goes as follows:
An abridged version of the code from AMX is as follows:
DEFINE_VARIABLE integer holdTime = 2 // Minimum two tenths of a second button hold time integer holdingRepeatcount // Variable to count out number of repeat executions of the button hold event handler integer minHoldingRepeatCount = 5 // Minimum number of repeat executions of the button hold event handler to occur before executing code inside button_event:hold code block integer nDevicePulseLength = 0 // Pulse Length of zero used for pulsing Foxtel IR codes integer nSystemPulseTime // Variable to hold the current pulse time DEFINE_EVENT button_event[dvTP, GENERAL_COMMANDS] // Emulate a button on the Foxtel handheld remote control { push: { // Determine what channel to pulse, however you may want to do it... // ... // ... nSystemPulseTime = get_pulse_time // Get the current pulse time set_pulse_time(nDevicePulseLength) // Set the pulse time to zero // Pulse the IR - Assums that the non-continuous codes are being used pulse[dvDevice,<whatever_channel>] holdingRepeatcount = 0 } hold[holdTime,repeat]: { // Determine what channel to pulse, however you may want to do it... // ... // ... holdingRepeatcount++ if(holdingRepeatcount >= minHoldingRepeatCount) { // Pulse the IR - Assums that the non-continuous Foxtel IR codes are being used pulse[dvDevice,<whatever_channel>] } } release: { set_pulse_time(nSystemPulseTime) // Restore the pulse time } } button_event[dvTP, CHANNEL_COMMANDS] // Select a Foxtel channel (channel codes contain 3 digits) { push: { // Determine what digits to pulse, however you may want to do it... // ... // ... // ... if(nArrayIndex) { nSystemPulseTime = get_pulse_time // Get the current pulse time set_pulse_time(0) pulse[dvDevice,<first_digit>] wait 2 { pulse[dvDevice,<second_digit>] wait 2 { pulse[dvDevice,<third_digit>] } } } } release: { set_pulse_time(nSystemPulseTime) // Restore the pulse time } }Try using visible/flash infrared emitters! They have about a 1/4 the output of the regular emitters. They have less output due to the fact they are also lighting up an led when passing the signal. They are great for troubleshooting as well. You can get them from http://www.easyadapters.com/store/ir_emitters.htm#VIRE
My experience with those is that the output is so low they don't work at all. Might be the brand I used, might be the length of the wire, just be aware it's an issue.
We subbed out the code on this house to a large automation programming house and they appear to like the TO command as opposed to the PULSE command.
Here I have been wasting a ton of hours setting different pulse times, when in reality TO must use a preset pulse time and is not related to the set pulse time. I changed all of the TO commands that related to satellite and whola - no more doubling.
Here is my online event.
Online:
{
SEND_COMMAND DATA.DEVICE,"'CTON',2"
SEND_COMMAND DATA.DEVICE,"'CTOF',3"
SET_PULSE_TIME(1)
}
Be aware that SET_PULSE_TIME is a global change that affects all the devices, not just the one you are referring to in the online command. If you want to use the CTON/CTOF commands, those apply to the XCH and SP send commands, which is what I've gone to exclusively based on the recommendation of other wise coders here in the forums.
Using the SP send command has greatly improved my ability to make easy adjustments to the systems I work on. I now dread going back to those projects I haven't changed.
Brad
The TO command:
BUTTON_EVENT[dvTP,1] { PUSH: { TO[BUTTON.INPUT] //turn button ON while pushed TO[dvIR,1] //turn channel ON while pushed } }Is a shortcut for this:
BUTTON_EVENT[dvTP,2] { PUSH: { ON[BUTTON.INPUT] //turn button ON ON[dvIR,1] //turn channel ON } RELEASE: { OFF[BUTTON.INPUT] //turn button OFF OFF[dvIR,1] //turn channel OFF } }SET_PULSE_TIME() sets the one global timer and determines the length of any PULSE command. I use the PULSE command where timing isn?t critical like for pulsing channels of virtual devices or possibly pulsing relays.
For what it?s worth I?ve decided to stay away from the PULSE command when it comes to IR (I?ll use TO in some cases) and opt instead to go with the SP command because I can set individual pulse widths for each IR device with the CTON and CTOF commands as you demonstrated.
You are right also about the set pulse time. I think my placement in the online event was poorly thought out because of it's potential impact on the other IR devices in the system. I will change that by handling the set pulse time in the event as Vining displayed a few posts back.
Thanks for setting me straight.
SP wouldn't let them start all together on the Axcent2 either, but at least they would all receive the command! It's really easy for users to crash IR codes using PULSE unless you have gone to a lot of trouble to make a stack handler for each and every IR port you are using.
Multi user, multi room and a single communal dev to control is going to end in tears using PULSE for sure.
Another vote for SP from me!
The above message from J James is what i found to work. I put a piece of black tape over the Boxes EYE and put a pinhole in the tape and placed the IR Probe over the pinhole and this works 99% of the time. I have yet to try the Resistor Fix, but i assume it would be a more elegant solution.
The 1k dropper suggested is also a very good fix.
A couple things we've done in this regard...
1 place a small peice of electrical tape with a pin-hole poked in it over the IR emitter.
2 putting a small tuft of cotton over the emitter.
Plus they come with phoenix connectors and noise chokes!