|
JP1 Remotes
|
View previous topic :: View next topic |
Author |
Message |
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Sun Feb 07, 2016 10:50 pm Post subject: Software Inquiry |
|
|
Do we have any programs in JP1 land which could generate Pronto hex from an rmdu file? I know we have John Fine's Makehex program, but the protocol names and parameters don't exactly match up with what RM uses, if I remember correctly.
If Barf is watching this, do you have something that can do this?
The reason I ask is because I'm looking for a better way of generating rid files for ReplayTV. We currently have the RidGen program, which has been patched to use Makehex and DecodeIR, but it's very much a patch and it requires the user to copy all the codes from RM over to RidGen by hand. Ideally, I'd like to be able to use RM to generate rid files just like it can generate bin files for Slingbox or OBJ files for the older ReplayTV systems, but both of those systems use UEI codes, whereas the rid files have a version of Pronto hex encoded into them.
If anyone wants to see what a rid file looks like, the following file includes a spreadsheet where I have broken out all of the data
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13916
The following post includes a detailed breakdown of the data:
http://www.avsforum.com/forum/27-replaytv-showstopper-pvrs/267352-adding-new-ir-blaster-codes-replay-unit-4k-5k-2.html?postid=4993160#post4993160
The following file contains the complete set of rid files that comes pre-installed on a ReplayTV unit
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=6891 _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Mon Feb 08, 2016 2:36 am Post subject: |
|
|
Quote: | Do we have any programs in JP1 land which could generate Pronto hex from an rmdu file? |
You can import rmdu files in IrScrutinizer, see this. Also this thread is very good. To summarize:
* Sometimes it works perfectly,
* Most of the time, you have to do some tweaking,
* If there are custom executers involved, forget it.
From IrScrutinizer, you can export in a number of formats, like text with Pronto.
It all boils down to the executor - protocol mapping, which is quite well described in the linked thread. If there is a particular executor/protocol that you would like to put in the "Sometimes it works perfectly"-category, feel free to ask!
Quote: | ... I'm looking for a better way of generating rid files for ReplayTV. We currently have the RidGen program... |
Looks like quite a large undertaking. Are the sources for RidGen available?
Greetz,
Bengt |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Feb 08, 2016 10:44 am Post subject: |
|
|
Ideally, I'd like this to work from RM. Given that John Fine has already created a program, MakeHex, that will generate Pronto hex when given the right parameters, would it be possible to incorporate that functionality into RM so that when a new ReplayTV rdf is selected, we can export a rid file in much the same way that we can export a Slingbox bin file?
The data in a rid file is largely based on Pronto hex, the main difference is that they indicate a sign, so where the NEC1 "one" pair would be "0015 0041" in Pronto hex, it would be "8015 0041" in rdf Pronto hex, where the "8" indicates a positive/ON time, and a "0" indicates a negative/OFF time (though I imagine it's just the most sig bit that is really used, not the whole nibble). _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Mon Feb 08, 2016 11:52 am Post subject: |
|
|
I like the idea of teaching RM how to generate pronto form signals (or more generally, raw signals). Then the logic for the executer <-> parameter logic would sit in RM instead of in IrScrutinizer. For this IrpMaster as Java library (.jar) can be used -- it has a clean API and integrates fine in RM, (as opposed to the ancient MakeHex). So the first part would be to implement a new export function, containing the raw and/or pronto form.
The second part would then be to generate the rid file. I quickly browsed the files, and could not really find anything that would qualify as a file format documentation for a programmer -- please correct me if I am wrong.
But let's do part 1 first . |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Feb 08, 2016 5:42 pm Post subject: |
|
|
This is how FlipFlop described the file layout in his AVS post...
FlipFlop wrote: | Header layout:
byte\tlen\tlabel\tdescription
0\t4\tunknown\talways 0
4\t4\tcode1\tIR code number
8\t4\ttype\tdevice type, 1=cable, 2=sat, 3=VCR
12\t4\tentries\tnumber of entries in the code table
16\t4\tbaseptr\tbyte offset into file for the code data
20\t4\tunknown\t(always 1, except for C7xxx and S7xxx codes)
24\t4\tcode2\tIR code number (second copy)
28\t64\tlabel\tASCII description for this codeset.
\t\tTerminated with 0xCD, except for C7xxx and S7xxx codes which use 0x00
92\t24*entries Code table
Table entry:
offset\tlen\tlabel\tdescription
+0\t4\tcodeid\treplaytv remote code number
+4\t4\tfreq\t(frequency in kHz)*10
+8\t2\tunknown\t(values seen: 33, 30, 100, 50, 42)
\t\t(possibly a ms delay before or after the transmission?)
+10\t2\tlength\ttotal length of code in words
+12\t2\tlength of initial fixed part of code
+14\t2\tlength of repeated part of code
+16\t4\tcode repetitions - always equal to 3
+20\t4\toffset to data from the beginning of the table, counting by 16-bit words
After the table, the raw IR data is stored at the offsets pointed
to by the +20 entry in the code table
The raw IR data are series of 16-bit words, ON if the msb is 1, OFF if the msb is 0
The lower 15 bits define a duration, in clock periods
Key deviations from DecodeIR requirements:
- It is allowable to have multiple ON's in a row, and/or multiple OFF's in a row.
- It is allowable to define a repeating sequence which begins with an OFF value.
- It is allowable to end a sequence with an ON value.
- The Length value could be longer than the sum of the initial fixed and repeated
sections of the code. In this case the remaining length is output after the
repeated section as a trailing section. |
I took that guide and then took a closer look at a specific rid file. I randomly picked one that I knew in advance used the NEC1 protocol so that I would recognize the Pronto format if it was in there. My results are here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=13916
The zip contains the following:- C0025fi.rid - the actual rid file
- C0025fi.hex.txt - a hexdump created using FRHed
- C0025.xls - a spreadsheet where I break out the data based on FlipFlop's description.
In the xls file, there are the following tabs:- Input - this is where I dumped C0025fi.hex.txt
- work1 - just grabs the hex data from the input tab (in column A), then in column B I concatenate it with the full string ending up in cell B1
- work2 - I do the same for the ascii data
- buttons - these are the button codes from FlipFlop's AVS post
- table - this is the table described above along with the data extracted from the rid file. There is one header followed by multiple table entries. The data on row 26 is the pseudo-Pronto data, you can only see the first 4 bytes but there's more in there, if you cut & paste it to Notepad you can see it.
- pronto - in this tab I grab all of the pronto code entries from the previous page. I did this so I could cut & paste them to Notepad and then use global edits to reduce them down to binary to confirm the format.
So what do you think? The file format appears to support more buttons than we actually need, as the Replay just needs to be able to change channels. Therefore RIDGen only supports buttons 0-9, Enter and Power.
My goal would be to create an RDF which just has those buttons defined, then we would open a regular JP1 upgrade using RM, select the new Replay RDF and then be able to export the data as a rid file, where RM would call your program to generate the data. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Feb 08, 2016 5:45 pm Post subject: |
|
|
You might be able to borrow some source code from here:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7046
Actually, this command line program (HEX2RID) might be exactly what we're looking for as it takes regular pronto hex as input and formats the rid file. So, if your tool can format the input file, this tool could do the rest. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Tue Feb 09, 2016 4:05 pm Post subject: |
|
|
Actually, HEX2RID looks quite usable. |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Wed Feb 10, 2016 10:30 am Post subject: |
|
|
Are you thinking of calling it, or incorporating the source code into something new? _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Sun Feb 14, 2016 2:00 pm Post subject: |
|
|
Actually, I do not know yet.
I suspect that the user base for the ReplayTV is pretty small. The last post is the replaytv forum is one and a half years old... I have never seen a one such myself. Searching on amazon.de gives exactly one hit, and that is a book from 2002, only partially about replaytv. Technically, to generate an input file for HEX2RID is probably not very hard, though.
Having RM generate raw code (pronto etc) is an interesting concept, I have already written about it. I would be happy to hear some feedback in particular from Graham and Dave.
I have been thinking about writing a Java class for mapping between protocols and executors, with the intention of being usable both in IrScrutinizer and in RM.
Bengt |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Sun Feb 14, 2016 2:49 pm Post subject: |
|
|
The RTV user base is small now because the company that owned it has gone bankrupt, but the user base doesn't post here, they post at Planet Replay
http://www.planetreplay.com/phpBB2/index.php
ReplayTV is a DVR/PVR that you can use to record live TV then you can share the programs that you have recorded with other Replay users, over the internet.
Since RTV is gone, thanks to hackers, we now supply the channel guide ourselves, using a program called WiRNS. It's a really great system, the only drawback is that it isn't digital, so many users have moved on to digital solutions.
One cool thing though is, you don't even need to own a Replay unit in order to use it. If you install WiRNS, and make a small registry edit, you can receive shows from other users which you can watch on your PC or stream using a streaming device, as they're MPEG2 format. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Mon Feb 15, 2016 5:17 am Post subject: |
|
|
Barf wrote: | Having RM generate raw code (pronto etc) is an interesting concept, I have already written about it. I would be happy to hear some feedback in particular from Graham and Dave. |
IIUC, the suggestion is to be able to generate pronto hex from the info in an rmdu file, i.e. essentially from a device upgrade. What would be the protocol input? Is the idea to start from the protocol code of some particular processor, or from the IRP, or something else? I'm not familiar with IR Scrutinizer, so perhaps you, Barf, already have the means to create pronto hex from an IRP. It sounds a big undertaking.
I have no proprietorial interest in RMIR, so I am entirely happy if Barf wants to develop this within RMIR. It is not something I would want to undertake. Is this the sort of feedback you want, Barf? You have my blessing if you want to do it. _________________ Graham |
|
Back to top |
|
|
mathdon Expert
Joined: 22 Jul 2008 Posts: 4523 Location: Cambridge, UK |
Posted: Mon Feb 15, 2016 5:48 am Post subject: |
|
|
On reading this thread more carefully, it appears that you, Barf, already have many of the pieces required and that the main stumbling block is the mapping between the fixed and variable bytes of the device upgrade and the parameters in the protocol IRP. For this, I have something that might help.
I have been working on a program that starts with the MAXQ code of an executor and generates the IRP. Here's a moderately complicated example of its output:
Code: | Denon/Denon-K Combo: PID=01C8
8 fixed bytes: bit-reversed A B C D E F G H
2 variable bytes: bit-reversed X Y
If Y:1:7=0
Preamble:
B=8*Y:5
A=X:3:5|(8*Y:5)
{38.0k,263}<1,-3|1,-7>((X:5,A:8,B:2,1,^68m,(X:5,~A:8,~B:2,1,^68m))+,(X:5,A:8,B:2,1,^68m))
If Y:1:7=1
Preamble:
N0=C[Y:-3:4]
N1=A:4^A:4:4^B:4:4^B:4
N2=((16*C[Y:-3:4]:4)|(A:4^A:4:4^B:4:4^B:4))^((16*X:4)|C[Y:-3:4]:4:4)^((16*Y:4)|X:4:4)
{38.0k,421}<1,-1|1,-3>(8,-4,A:8,B:8,N1:4,N0:8,X:8,Y:4,N2:8,1,-75m)2+ |
I hope this output is reasonably self-explanatory. At present this program works with 134 of the 168 executors in protocols.ini that have MAXQ code. It seems to me that this may provide the mapping you need. It is this program that is behind the information in this thread. _________________ Graham |
|
Back to top |
|
|
The Robman Site Owner
Joined: 01 Aug 2003 Posts: 21238 Location: Chicago, IL |
Posted: Mon Feb 15, 2016 11:16 am Post subject: |
|
|
At a higher level Graham, my ultimate goal is to be able to use a device upgrade to create a rid file for ReplayTV. The content of a rid file is loosely based on Pronto hex.
We have several programs that do some of the work already.- Makehex converts protocol data into Pronto hex
- Hex2Bin converts Pronto hex into a rid file
Barf also has programs that convert protocol data into Pronto hex.
My hope is that we can implement something that strings those programs together in such a way that, if I open a device in RM, and maybe select a new RDF for Replay, that I can create a rid file in much the same way that we create Slingbox bin files. _________________ Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help! |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Tue Feb 16, 2016 2:01 pm Post subject: |
|
|
Thanx for those encouraging words.
Quote: |
I have been working on a program that starts with the MAXQ code of an executor and generates the IRP. Here's a moderately complicated example of its output: |
Very interesting! In particular, I like that you bypass the RM special parameters, and just take them as a bunch of uninterpreted bytes. I will definitely ask you for your data base at a later date.
BTW, have a look at this stuff; it goes in the other direction, protocol -> executor. |
|
Back to top |
|
|
Barf Expert
Joined: 24 Oct 2008 Posts: 1415 Location: Munich, Germany |
Posted: Tue May 17, 2016 3:21 pm Post subject: |
|
|
Almost exactly three months later, I like to summarize from my personal POV.
The original problem has been decomposed into two sub-problems, where the second needs the first, but not vice versa:
1. Generate raw data from RM/JP1-type of data. Graham's idea of associating the "executors" (.i.e. the stuff in protocols.ini, unfortunately often called "protocols") with a IRP-form, taking either the executor raw data, or the executor parameters, as presented to the (RM) user, really seems like the right thing to do.
2. Take the thus generated raw code (call it "Pronto hex" if you desire) to Replay universe.
The first one is quite challenging and interesting. If the RM and executor experts can provide the IRP forms for the executors (or at least for substantial subset), I will be willing to integrate my stuff for the rendering, call it Girr-export.
The second one, again, requires the first. The number of stake holder is very low -- but on the other hand it would not be extremely hard either. It can be called it a replay-export from IrScrutinizer.... |
|
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
|