SP interval

frthomas

Hello,

The forum approved way of sending IR code is to use SP. I have code that does RESET IR, set CTON and CTOFF to 5 at ONLINE time of the IR device, and then later in the program I do stack 5 SP (i.e. 5 lines of SEND_COMMAND "dIR, blabla")

It works... but I get each pulse sent at 8 seconds interval, which is a bit long...

Before I do a time line or some other method to do that, since stacking pulse does not seem to work, anyone has an idea what I could be doing wrong?

Studio 2.4, NXI 1.0.22, NXC-ME 2.30.135

Thanks

Fred

Chip Moody

Sorry - no help here. I still use TOs and PULSEs.

The whole SP thing has always seemed like more work than called for or needed, IMHO...

- Chip

vincen

Don't forget Fred that between each pulse, are added CTON time (to send the previous IR) plus CTOF (Time between pulse), so if you get a CTON 3 and a CTOF 5 it'll start pulse of second IR 8/10 second after start of first pulse

What are values of your CTON and CTOF ?

Vince

wcravenel

About a year ago I had great difficulty with the DirecTV HD Tivo unit, forcing me to look at timelines for favorites. I later tried CTON, CTOFF & XCH. I find that CTON of 2, CTOFF of 3 (set at online for that IR device) and XCH (passing only chan # for a unique port on G4 panels ie dvTPDSSFavs) works very well.

I still set pulse time at 2, and any button event for dvTPDSS (again, another unique port on TP) still gets PULSE[dvDSS, button.input.channel].

So, CTON 2, CTOFF 3 has worked for me for a number of components so far.

Bill

DHawthorne

I use the SP functon extensively. Keep in mind, it's broken on the latest NI firmware (1.00.118), revert to 1.00.115 or don't use it. Typically, I set all IR devices to CTON 3, then adjust from there if there are issues. Most typically, a device needs a shorter pulse to prevent double events. This can vary on some with how it was captured in the first place. It's very rare to need less than 2 for the CTON value, and I almost never mess with the CTOFF at all.

Oddly enough, making the CTOFF value too small sometimes makes the device less responsive. They are sensitive to the blanks in a transmission.

But I can't imagine where you are getting an eight second delay, unless that was a typo and you menat 8/10 (which is the default, as noted). I am willing to bet it's that firmware bug. Try starting your sequence with a CP (which clears the queue first) and see if that resolves it. If using CP breaks other things (clears the queue before all your commands are out) revert the firmware until AMX releases a fix.

VLCNCRZR

basic methods

I am with Chip on this one.

I have never had any issues with TO's and PULSES.
It is about as solid as you can get, and easy to implement.

When I find simple methods that work dependably, I try to
stick to them.

frthomas

Thanks to all for your responses.

I use 5 for CTON and CTOFF. The pulses ARE sent, and I guess last 0.5 seconds. They do operate on the device correctly, although I am sure a smaller CTON would do it as well. But this is not my issue.

My issue is that there is 8 SECONDS (eight full seconds) between the pulses, with CTOFF set to 5 (which is normally 5 1/10th of seconds). Netlinx behaves like my CTOFF value was 16 times larger (i.e. set to 80).

From your posts, it all seems to indicate it should not work like that, hence my question, why does it? It also seems no one has seen this behaviour before...

Thanks

DHawthorne

I've never had an issue with TO's - they have their place; but I never use a PULSE for IR if I can help it. Here's why:

You can only set the pulse time globally for all pulses, which applies to relays and other channels as well as IR. That means if you have devices that require different timing, you have to track it all yourself. If using SP/CP, you set it per device, once, and you are done.

You can't queue a PULSE. If you are doing a sequence of IR commands, you have to make your own timing routines to keep them from stepping on each other.

I don't see a PULSE as a simpler solution at all, to me, SP is far easier to work with (firmware glitches notwithstanding).

alexanbo

Make sure when you're sending the CTON and CTOF commands you use a decimal number as the argument, not an ascii number.

For example:

SEND_COMMAND dvDEV,"'CTON',5"

Not

SEND_COMMAND dvDEV,"'CTON 5'"

As the later will be convert the ASCII 5 to it's decimal equivalent which is 53.

alexanbo

By the way the problem I have with TO's is if you use them in conjuction with say a button press from a wireless touchpanel and the wireless touchpanel goes offline while a TO is active, or if the system misses the Release sent by the wireless touchpanel, the TO can continue indefinetly.