|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
eferz Expert
Joined: 03 Jun 2010 Posts: 1078 Location: Austin, Texas |
Posted: Thu Aug 11, 2011 1:12 pm Post subject: Software Request: IR War Dialer |
|
|
Spun off from this thread:
http://www.hifi-remote.com/forums/viewtopic.php?t=12655
The Robman wrote: | I think you just volunteered! |
This is slightly embarrassing. I've had my web browser sitting on page 2 of this thread for about two weeks waiting for a response. The detail of a third page has eluded me till now. How embarrassing.
Anyways, I'm definitely not up to writing code any more. I realized that while going through Alan Richey's source code for that hex code reformatter tool he had coded prior to the XML implementation for RM/RMIR. I found myself not being able to code myself out of a paper bag loop.
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
I'd be willing to add an additional $50, if the program was also compatible with IR/RMIR with this feature set:- 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
[In retrospect, perhaps this post is too off-topic to the original post. Robman or any moderator, if any of you know a more suitable forum for this post, I wouldn't mind this post being severed from this thread and moved into a different forum.] |
|
Back to top |
|
|
cauer29
Joined: 03 Feb 2010 Posts: 236
|
Posted: Thu Aug 11, 2011 9:51 pm Post subject: Re: Software Request: IR War Dialer |
|
|
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?
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.
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:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=1759
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=1458
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=1759
A.A. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Fri Aug 12, 2011 12:20 pm Post subject: Re: Software Request: IR War Dialer |
|
|
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: |
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
Quote: | 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). Quote: |
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.
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? 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. |
|
Back to top |
|
|
eferz Expert
Joined: 03 Jun 2010 Posts: 1078 Location: Austin, Texas |
Posted: Wed Aug 24, 2011 6:19 pm Post subject: Re: Software Request: IR War Dialer |
|
|
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? |
For my own needs, I only need the single dimension; however, I can see how shifting across dimensions could help others. The same way throwing out the IR codes for "power" helps people find compatible IR profiles with a non-learning remote.
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. |
Wow! You really put a lot of thought into this lo-tech hack. I like it! Unfortunately, I don't think its something that's easily portable to be consider a "JP1 tool" but it does sound like an awesome project.
This is interesting, sounds like something I can use to hidden codes within a range. Then I can go through the old fashion way of uploading and then hunt and peck them out later. I'm going get a JP1 remote so that I can play with it.
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: |
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
Quote: | 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). Quote: |
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. |
This is awesome, Barf. If only you could put together some sort of UI to tie it together. That would be sweet.
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? |
The idea is to save time by using the RM/RMIR list to either filter out codes within a range or specify a group of non-sequential codes you want test
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. |
Definitely, sounds difficult. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Fri Aug 24, 2012 1:19 pm Post subject: |
|
|
I think that the current release 0.3.0 of IrMaster actually does satisfy all of the requirements
Quote: |
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
|
(Implemented with the current release is the pausing and resuming feature, and the note-taking feature.) Of course, there is no automatic recognition of recognized commands (how would that work?), but the user can type her observations in as notes (in the supported popups).
The $50 can be donated to the Free Software Foundation . |
|
Back to top |
|
|
|
|
You cannot post new topics in this forum You cannot reply to topics in this forum You cannot edit your posts in this forum You cannot delete your posts in this forum You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|