JP1 Remotes

semuther · Joined: 29 Sep 2003 Posts: 27

I would like to control various IR devices using an emitter connected to my PC. Is there software which would allow me to generate IR with a PC using data from JP1 upgrade files?

If not, I see lots of home brew and commercially made IR transceivers for the PC with learn/emit software. Anyone have any comments on what some of the better hardware and software combinations are for this?

Thanks

Steve

The Robman · Posted: Thu May 11, 2006 7:35 am Post subject:

I think this is what you need...
http://www.lirc.org/
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

johnsfine

semuther · Joined: 29 Sep 2003 Posts: 27

johnsfine · Posted: Thu May 11, 2006 9:12 am Post subject:

semuther · Joined: 29 Sep 2003 Posts: 27

The Robman · Posted: Thu May 11, 2006 9:37 am Post subject:

How soon do you need this to be up and running? If you can wait a while, as John mentioned earlier, there's a good chance that once JP1.2 remotes are fully supported by our JP1 software and hardware, we might have the ability to control the remote from the PC, so your JP1.2 remote would, in effect, be your IR emitter.

ps. If you check "disable BBCode" iwhen you post, you can't quote other people's posts. I've had to go back and edit all of your previous posts so they display correctly.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

johnsfine · Posted: Thu May 11, 2006 9:45 am Post subject:

1) Try reading through the winlirc site before you search elsewhere. Maybe I have a mental block about Windows ports of Linux applications. I always find their documentation is a serious impediment. Maybe you'll find your way through winlirc more easily than I did, or maybe it's the best choice despite documentation issues, or maybe their support forum is as beginner friendly as ours (I don't think many online forums are, but maybe).

2) A question for any lurkers drawn to this topic:

What is the best basic model for a program in the remote that give the PC control?

A) Let the PC give the ID of a button in the remote and tell the remote to pretend that button was pressed. So the PC would "press" the CBL button, then "press" the button for some command in CBL mode, etc.

B) Let the PC give a setup code and hex command and that signal would be transmitted.

C) Let the PC give a protocol ID and fixed data and hex command (and probably duration as well) and THAT signal would be transmitted.

If I were using it, I would prefer C because it is more flexible, it is less dependant on the prior state of the remote, and I'm comfortable copying fixed data and hex commands from an rm upgrade (and/or writing my automation software so it pulls the data from an rmdu file).

But I expect most users would find (A) gives a better fit to the way they think about the problem.

What do you think? I may or may not use your answers when I may or may not write software for the 6820/8820 to do this operation (10820 is the same for software, but I think external rather than battery power is appropriate for the remote and a 10820 is harder to externally power).

semuther · Joined: 29 Sep 2003 Posts: 27

The Robman · Posted: Thu May 11, 2006 11:57 am Post subject:

I think option A is probably easier to implement, but option C is the better approach. Of course, your analysis of what's physically possible will dictate what options can even be considered.

Under option C, if it's possible to feed fixed and variable data to the remote, along with a protocol upgrade if the protocol isn't resident in the remote, I'm imagining that we could create a virtual remote on the PC where the user can add unlimited upgrades, in unlimited device modes. They would then be able to program macros that would kick off at specified times that would send a series of "buttons" to the remote, where a "button" is a combination of fixed data, variable data and possibly a protocol. They should also be able to just "press" a button.

Option A would be simpler. The virtual remote would be an accurate reflection of the real remote, so any upgrades available in the virtual remote would have to be actually installed in the real remote. But from that point on, it would work the same as under option C, where the user can both "press" a button live and also program timed macros.
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!

johnsfine · Posted: Thu May 11, 2006 1:07 pm Post subject:

I haven't tried coding it yet, but I expect B would be easiest to create, and C slightly harder and A harder still.

Part of the problem (maybe a big part) is knowing what the invoked operations will do to ram (finding the safe parts of ram for the program to use that won't be stepped on by the things invoked). Keystrokes can invoke macros, which can do who knows what. Direct use of protocol executors makes it easier to assume reasonable restrictions on the ram use of the invoked actions.

Downloading protocol executors on the fly is enough harder, with rare enough benefits, that I'm pretty much rejecting that without further investigation, sorry. (vs. sending fixed data with the hex commands, eliminating the need for device upgrades, which is not much harder than using setup codes, might even turn out to be easier).

semuther · Joined: 29 Sep 2003 Posts: 27

Sorry, posted this from an old screen before seeing the previous post. My
question below would, from a user perspective, seem like the cleanest way to go but obviously there are other considerations. I may for the time being simply use some apps I am finding which just memorize LED blink sequences and play them back on demand. My applications are limited in terms of the required functions but this approach is OK for the time being.

-----

My simplistic question after reading the above:

- You've got learned device upgrades on a PC
- You know what the various protocols are

Can you have an app that takes the above, integrates it with some sort of GUI and commandline interface (such that batch files can be written and scheduled) and simply blinks an IR led connected to one of the PC's parallel port lines via a resistor? Why involve a permanently connected remote?

The GUI might emulate a common remote such as an 8910.

Sorry, I'm not a software guy, I design RF and microwave hardware for a living....

Steve

johnsfine · Posted: Thu May 11, 2006 2:49 pm Post subject:

semuther · Joined: 29 Sep 2003 Posts: 27

For me anyway, the gui is a secondary issue. What I would want to do is, assuming a commandline interface, write batch files for sequences of IR button pushes to, say, move my satellite dish from one bird to another at a certain time via windows scheduler.

Understand the latency issues. That, as we hardware people say, is a software issue.

I can, however, assist with the design of the parallel port to IR interface. A signle output pin (or bit) on the parallel port can source up to 2.5mA of current which is enough to light a low power LED (IR or visible) OR drive a buffer for more current and larger emitters. In fact, in the industrial control world, this is done all the time for opto-isolated power switches for large machines.

If a way can be found to deal with the latency issue, that port could feed, I forget how many lines but there are at least 8 bits, multiple LEDs going to multiple IR controlled devices for all kinds of interesting control applications.

Steve

johnsfine · Posted: Thu May 11, 2006 6:46 pm Post subject:

If you want to run long wires from your printer port all over the room, I guess it isn't harder for the PC to support up to a dozen instead of one.

I was assuming one IR output aimed at several devices across the room.

When I did such things long ago on much slower computers without Windows (so latency was entirely under my control) I found it much easier to use a pair of IR LEDs wired in series rather than just one. That reduced aiming problems, and the hardware person helping me at the time said the higher voltage across two series IR LEDs made the current control simpler. Just currious if you have an opinion on that one. I have no idea now how you do current limiting for an IR LED powered by the printer port.