IR Blaster - Why is this so hard ?

[mindy1701]

So I have IR blaster - Home made.
It's on the DTR line of the serial port.
Im running winLIRC.
Dish Network

I have it working in test mode. IE I can send channels numbers to the Sat Box.
But I can only send single numbers at a time, anytime I try say 222 the box picks up 22 changes to HSN and then sees another 2.

It's like the number seportation is way to long and the box is timing out.

Is there an easyer way to make a simple blaster work with GBPVR.

Thanks
Mindy

[sub]

This type of stuff is external to GB-PVR.

GB-PVR can run whatever .exe utility you have to control your home made blaster. It just passes the complete channel number to it though, for example "222" - it'd be up to that executable to send the individual digits, and whatever init-digit delay, and any required repeat count.

[mindy1701]

I understand that it is outside of the GB-PVR application.
Can someone point me to some exe that will work with a IR blaster.(Output only)

I have fought with winLIRC for hours with no workable results.

[stefan]

I'm not sure whether server suite works with a serial blaster, but people seem to like it. Could be worth reading the thread:

http://forums.nextpvr.com/showthread.php...rver+suite

[martint123]

I tried with something like this in the early days. It's not so much the serial port as just one, software controlled pin. A snag is that to get the timings correct it has to stop just about everything else from running on the.

I gave up in the end and spent money on one the hardware blasters that offloaded the task to a little chip!

[markbb1]

I understand that it is outside of the GB-PVR application.
Can someone point me to some exe that will work with a IR blaster.(Output only)

I have fought with winLIRC for hours with no workable results.

The native capability of WinLIRC is the transmit.exe executable that sends a digit at a time. Let me digress a bit before I point you at some info that might help. WinLIRC has to use the processor to toggle that DTR line to transmit. If the cpu gets interrupted by a higher priority process while sending a digit, the digit will get corrupted, and your receiver will ignore it. So if you want to schedule recordings in the middle of the night, sometimes it might be on the wrong channel.

Now, you can check out the second post of the thread at http://forums.nextpvr.com/showthread.php?t=36496 and it should help you understand what you are up against. The delay between digits has to be controlled in order to work, and that control is external to WinLIRC.

The one thing I never could understand is why nobody ever coded and compiled in C or C++ a multidigit WinLIRC transmit.exe version that used the tcp/ip capabilities instead of the clipboard to pass the command and make it session independent. Put the name of the remote and the delay and the number of times to repeat in a .ini file. Some guy did a .vbs thing, some other guy did a java thing. You need the specific runtime environment for that particluar compiler to run either of them. I wrote a .cmd (batch) file that pops up a dos window when it changed channels. One guy that tried that found that focus did not return to the htpc program after the dos window went away. Also, transmit.exe uses the clipboard to hand off the parameters. One user found that the recording executable was running a different window "session" than WinLIRC was running in, so no channel change. I also found that I got better accuracy by rewiring my transmitter and receiver to use the data pins instead of DTR and DCD.

Anyway, read my .rtf file and the thread at http://forums.gbpvr.com/showthread.p...89&mode=linear and you should be able to get something going. If not, you probably need to buy something else like an MCE remote, beanbag, and emitter. This post may sound harsh, but I really would have liked to get WinLIRC working better myself. If I could write C or C++ code, I would have a much better answer for you.