JP1 Remotes

The Robman wrote:I think you just volunteered!

• specify interval between broadcasts
• specify range of IR codes to process.
• pause the process, in order to manually rotate through the last few broadcasts to identify and notate their purpose.
• summary report of found codes along with their notes

• ability to read an IR/RMDU file for purposes of
  • setting the appropriate protocol and device parameters
  • using the defined functions (RMDU) or device button (IR) as either the specified range or as a filter for a customized range.
• ability to create an IR/RMDU file from the identified signals

java -classpath dist/harctoolbox.jar  org.harctoolbox.protocol -g globalcache -w 3000 -v rc5 0 0:127

For compatibility purposes, I would recommend the transport to use LIRC or WinLIRC, so it can be used with a range of IR output devices

specify interval between broadcasts
specify range of IR codes to process.

cauer29 wrote:If I'm understanding this correctly, you want to an automated way to run through a range of OBCs or EFCs for a given protocol and have the user able to stop the scan at any point if he detects a response from the target equipment. Do you want this to stick to one protocol/device/sub-device, or do you want to add that dimension too?

cauer29 wrote:I suppose that barring multi-protocol or device/sub-device, I have all of the pieces for this. I have an old SmartHome Houslinc that originally had a built-in JP1 remote something like a 15-1925 and you can press the virtual buttons on this remote via computer sending some simple cmds. The original 15-1925 has given way via transplant surgery, to a more modern JP1.3 15-100 remote. A cmd can be sent to the Houselinc to press any button on the 15-100 and so any protocol supported by the 15-100, whether built-in or via upgrade, can be sent from computer. A mere matter of some trivial program on the PC end is needed to run a scan of all EFCs. I had such a program originally before the current incarnation of franken-remote. That was back when I was bypassing most of the Houselinc's innards and doing the button pushes directly via parallel port. These days, it's more convenient to use the serial Houselinc comm protocol to press the 15-100's buttons.

In any case, this probably isn't suitable for much of anybody else to build/use, mostly since you'd be hard pressed to dig up the original Houselinc on which it's based. The overall concept used by the houselinc could be duplicated with fairly minimal effort. Imagine that a JP1 remote has a keypad matrix composed of 8 rows and 8 columns. In an over-simplified way, the remote enables one column at a time, looking for keypresses on a given row. So, all you have to do to be able to "press" any key, is connect a single pole 8 throw switch to the rows and another to the columns. Then select the row with one and the column with the other, then connect the "common" pole of the two switches together momentarily and the remote will think that the key corresponding to the row and column you've selected, has been pressed.

Of course, we don't have to resort to mechanical switches. We have electronic switches in the form of 74HC4051 "one of eight" analog switches. One for the rows and one for the columns is all it takes. Then you just need 7 (3 for row, 3 for col and 1 for enable) bits from a parallel port to drive the select lines on the switches.

The hardest part doing this from scratch, is to wire up the 8 rows and columns to a JP1 remote.

cauer29 wrote:Now that I think about this some more, I'm certain that I read about a special protocol that does the whole EFC scan automatically. Here's 3 of them:

https://www.hifi-remote.com/forums/dload ... le_id=1759

https://www.hifi-remote.com/forums/dload ... le_id=1458

https://www.hifi-remote.com/forums/dload ... le_id=1759

Barf wrote:eferz, I can offer you this on my project page http://www.harctoolbox.org. Download the binary or source, and then call the main routine in the class org.harctoolbox.protocol like,e.g.

Code: Select all

java -classpath dist/harctoolbox.jar  org.harctoolbox.protocol -g globalcache -w 3000 -v rc5 0 0:127

to send rc5 codes for device 0 and functions/commands 0 up to 127 with delay of 3000 milliseconds to a GlobalCache with IP-Name globalcache. No GUI, but searching for undocumented IR-Commands if for experts, and experts do not need GUI

For compatibility purposes, I would recommend the transport to use LIRC or WinLIRC, so it can be used with a range of IR output devices

I once submitted a patch to Lirc for accepting network raw signals in Pronto format, but it was rejected by the then-maintainer, Christoph Bartelmus, who meant that IR command were much better in a database on the server If I recall correctly, my software supports such a patch LIRC-Server, as well as GlobalCache Ethernet devices, and IRTrans (ethernet only).

specify interval between broadcasts
specify range of IR codes to process.

yes and yes. I am not sure about the "notetaking", surely the transmitting computer cannot /in general) note that a command was reacted on, so it has to be some sort of notepad. Should be possible to do a "notepad" with the supported Python-scripting.

Barf wrote:To generate an RMDU-File is not at all hard, look at my LIRC2XML-stuff in the file section for a similar endeavor. Reading out parameters of IR/RMIR is not really a useful concept: if you already have the information there, why do you need to go exploring?

Barf wrote:Generating an RMIR-File: yeah, I have done some attempts not completely without success, would require to talk to RMIR over an API. Much harder.

Though, I still think that an IR "war dialer" would be a valuable JP1 tool. Maybe I should put up a bounty for its creation? I can't afford much, but I'm willing to put my money where my mouth is. How about this, $50 for someone to create the tool with the following specifications:

The IR war dialer in its basic form must be able to sequentially broadcast IR signals within a specified range for purposes of identifying applicable to any IR remote controllable device. For compatibility purposes, I would recommend the transport to use LIRC or WinLIRC, so it can be used with a range of IR output devices such as the Iguana Works's IR transceivers. For the bounty, and continued support on this forum the tool must be open sourced and should also posses the following features.

specify interval between broadcasts
specify range of IR codes to process.
pause the process, in order to manually rotate through the last few broadcasts to identify and notate their purpose.
summary report of found codes along with their notes