 |
JP1 Remotes
|
| View previous topic :: View next topic |
| Author |
Message |
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
 Posted: Sun Sep 02, 2012 8:56 am Post subject: |
 |
|
Thanks Vicky!!! I'll check them out and surely be back with questions. =) |
|
| Back to top |
|
 |
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 9:23 am Post subject: |
|
|
It occurs to me that you might as well put the ";" delimiter in all the timing displays, just for consistency.
Now, are you ready to start taking this to the next logical step?
As you know, once I've entered a good rounding time, the next thing I do is cut & paste all the timing data from the summary sheet over to Notepad so I can edit it into binary format, and then I try to break the signal up into fixed data and variable data, usually in 8-bit chunks. Then, I'll try to determine if it's LSB or MSB so I can deduce the OBCs and device codes. Also, if there's a checksum, I'll try to find the pattern for that too.
So, how much of this can be automated? I'm thinking the place for any automation is the Timing Summary sheet. You should be able to make good educated guesses as to the leadin and leadout pairs. For the ONE and ZERO pairs, if the ON times are constant, make the ONE pair be the one with the longer OFF time. These would be the default times that could appear in a new control panel on the side of the Timing Summary sheet, but the user can change them as needed. Of course, as Vicky pointed out, there are signals with more than two logical pairs (not including leading, leadout and mid-frame burst pairs). Typically we just see signals with 4 pairs, but the XMP protocol has 16. So, this panel should be expandable to handle as many pairs as needed.
Once the pairs are entered, it would produce the binary. You have an advantage over DecodeIR at this point because you can see the whole set of learned commands, so you can make judgement calls as to whether the signal is LSB or MSB, etc, so maybe the software can have the first crack at sorting it all out, but the user should get the last word, of course. Once the binary breaks have been determined, between the fixed and variable data, maybe the software could also have a go at looking for and cracking checksums. The most common checksum is to simply have data be followed by its complement. Typically the complement is 8-bits, but there are some protocols were the OBC is just 7-bits and the final bit is the complement of the last OBC bit. Other checksums are more complicated, of course, so the routine that looks for checksums would ideally be a separate routine so that, as we discover more complicated checksums, we can add new examples into the routine for it to look for. (We had one recently that did a MOD(15) on the data).
You know what would also be great for this, if you take it on, would be to have the ability to look at more than one IR (or RMIR) file at once, because you often need to use 2 or 3 files to capture all of the signals, due to the limitation of the learning memory.
_________________
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: Sun Sep 02, 2012 11:39 am Post subject: |
|
|
| Vyrolan wrote: | | My statement was meant more to show that decoding and the new "timing analysis" achieve different goals. |
I'm not sure where you see the end-point of "timing analysis". To me, the end-point would be the construction of the IRP form for the signal. This is certainly different from decoding, and a first attempt was made to do this by me in ExchangeIR.dll, which is used to attempt to display the IRP Form of decodable and non-decodable signals in both IR.exe and IRScope. Barf has further developed this in IRPMaster.
I have had the long-term intention of using Barf's java code to add the display of an IRP Form for learned signals also in RMIR. I hope you will take this on board now in your plans for timing analysis, via ExchangeIR, Barf's code or by your own developments. ExchangeIR is very much a first attempt that just grew in a fairly structureless way as I experimented more and more with what could be done, but I hope it can provide ideas towards a more structured analysis. It works with most signals that DecodeIR can decode, including some quad phase protocols and, I think, XMP. Its failing is that it too often fails on non-decodable signals, which of course is its most important use  . But however you proceed, I would like to suggest that the construction of an IRP Form for a signal or batch of signals should be the ultimate aim of timing analysis.
When I first started developing ExchangeIR, I didn't really believe that it would be possible to automate timing analysis to the point of creating an IRP Form. My work persuaded me that is IS possible, and I hope you will take up this baton and run with it. You have certainly proved very adept at running in the week or so since you joined this Forum  .
_________________
Graham |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 1:59 pm Post subject: |
|
|
| The Robman wrote: | | It occurs to me that you might as well put the ";" delimiter in all the timing displays, just for consistency. |
I thought about that too and went back and forth on it. I've got a simple idea to try...I'll make a change and see what it looks like.
| The Robman wrote: |
Now, are you ready to start taking this to the next logical step?
As you know, once I've entered a good rounding time, the next thing I do is cut & paste all the timing data from the summary sheet over to Notepad so I can edit it into binary format, and then I try to break the signal up into fixed data and variable data, usually in 8-bit chunks. Then, I'll try to determine if it's LSB or MSB so I can deduce the OBCs and device codes. Also, if there's a checksum, I'll try to find the pattern for that too.
So, how much of this can be automated? I'm thinking the place for any automation is the Timing Summary sheet. You should be able to make good educated guesses as to the leadin and leadout pairs. For the ONE and ZERO pairs, if the ON times are constant, make the ONE pair be the one with the longer OFF time. These would be the default times that could appear in a new control panel on the side of the Timing Summary sheet, but the user can change them as needed. Of course, as Vicky pointed out, there are signals with more than two logical pairs (not including leading, leadout and mid-frame burst pairs). Typically we just see signals with 4 pairs, but the XMP protocol has 16. So, this panel should be expandable to handle as many pairs as needed.
|
I've definitely thought about this already. I'm not sure how far we want to go. I've been messing around with a separate app (written in C# which I know better than Java) to do some of this with an eye towards working with multiple IR/RMIR files or a single *.ict file from IRScope. It's a fun challenge, and I think we could handle a lot of the simple cases. My original goal though with these changes in RMIR has been to facilitate easier human decoding first...that's merely the tip of the iceberg compared to doing it automated. I do think we can easily produce the binary though as you suggest though. I've already analyzed them enough to know the pairs so it's easy to have logic around which one is Zero and which is One (and letting the user control it). We can see how it goes... =)
| The Robman wrote: | | Once the pairs are entered, it would produce the binary. You have an advantage over DecodeIR at this point because you can see the whole set of learned commands, so you can make judgement calls as to whether the signal is LSB or MSB, etc, so maybe the software can have the first crack at sorting it all out, but the user should get the last word, of course. Once the binary breaks have been determined, between the fixed and variable data, maybe the software could also have a go at looking for and cracking checksums. The most common checksum is to simply have data be followed by its complement. Typically the complement is 8-bits, but there are some protocols were the OBC is just 7-bits and the final bit is the complement of the last OBC bit. Other checksums are more complicated, of course, so the routine that looks for checksums would ideally be a separate routine so that, as we discover more complicated checksums, we can add new examples into the routine for it to look for. (We had one recently that did a MOD(15) on the data). |
Now things start to get really crazy...the complexity will grow and grow and grow. We'd have to weigh the benefits of successful automation versus the time of development and also the cost of incorrect results. The logical extension of all of this is that if we can figure out all that, why not just automatically build the protocol upgrade. As soon as we do that though, it starts to be this thing people rely on and expect to work and if it doesn't, they'll get very frustrated and confused. Like I said I think it's a very interesting challenge and a fun problem, but going from "printing rounding timings correct with some semicolons" to "fully decoding the signal, finding static vs variable, figuring out checksum, etc" is waaaaaaaaaaaaay more than 1 step. =) We'd have to build a plan to get there with smaller iterations.
Another concern is that the further we take it, the higher the barrier of entry for writing new analyzers. We'd have to design the framework such that different kinds of signals could support various levels. Some simple signals could be fully analyzed to the point that a protocol upgrade is created automatically...but others only go so far as to print timings in a way useful for human decoding...others may fall in the middle and can create the binary but that's it.
| mathdon wrote: | | Vyrolan wrote: | | My statement was meant more to show that decoding and the new "timing analysis" achieve different goals. |
I'm not sure where you see the end-point of "timing analysis". To me, the end-point would be the construction of the IRP form for the signal. This is certainly different from decoding, and a first attempt was made to do this by me in ExchangeIR.dll, which is used to attempt to display the IRP Form of decodable and non-decodable signals in both IR.exe and IRScope. Barf has further developed this in IRPMaster.
...however you proceed, I would like to suggest that the construction of an IRP Form for a signal or batch of signals should be the ultimate aim of timing analysis. |
I would agree...in addition to my responses to Rob above, I think we should be able to produce the IRP from the signal. If we could do everything Rob envisions, then producing the IRP would be a trivial addition. =)
| mathdon wrote: | | When I first started developing ExchangeIR, I didn't really believe that it would be possible to automate timing analysis to the point of creating an IRP Form. My work persuaded me that is IS possible, and I hope you will take up this baton and run with it. |
I make no guarantees...who knows what will catch my fancy next week... =) As I've said though, it is a very intriguing challenge, and I do agree that it must be possible.
| mathdon wrote: | | You have certainly proved very adept at running in the week or so since you joined this Forum |
Thanks for that...just trying to help! |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 2:57 pm Post subject: |
|
|
I agree, I did kinda combine several steps into one there. Given that the number of new protocols needing decoding isn't that high, I'm still happy to do it by hand each time, or I may develop a spreadsheet that does the editing for me.
It would be a good idea for this to be handled by a separate tool, a tool that could handle various file formats (ie, IR, RMIR, CCF, ICT, LIRC, etc)
Barf has been developing a tool (called IRMaster) that might be best suited for this sort of thing.
Currently, when someone posts an ICT file that contains a new protocol, I run it through a spreadsheet that I developed that converts the data into an IR file, then I open it using IR and use the rounding features to decode it.
_________________
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: 21237
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 3:14 pm Post subject: |
|
|
I just noticed a bug in the Timing Summary sheet, the Repeat: portion is at the end of the line, not on a new line
_________________
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 |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 3:18 pm Post subject: |
|
|
| The Robman wrote: | I agree, I did kinda combine several steps into one there. Given that the number of new protocols needing decoding isn't that high, I'm still happy to do it by hand each time, or I may develop a spreadsheet that does the editing for me.
It would be a good idea for this to be handled by a separate tool, a tool that could handle various file formats (ie, IR, RMIR, CCF, ICT, LIRC, etc)
Barf has been developing a tool (called IRMaster) that might be best suited for this sort of thing.
Currently, when someone posts an ICT file that contains a new protocol, I run it through a spreadsheet that I developed that converts the data into an IR file, then I open it using IR and use the rounding features to decode it. |
I agree...my side project has been along those lines...load up multiple learns (via multiple IR/RMIR files or a single ICT file) and then support doing all of the work you mention. We could build that into RMIR...it'd be just another editor part you could pull up. I also agree that there's probably not a ton of new protocols to be decoded (and certainly the rate at which they appear doesn't seem high).
In general, I feel a lot better about building a tool that makes it easier for a human to decode them than I do about one that tries to do it all on its own. I think we could build that out and then slowly try to automate more and more of the process. That way we have a working manual tool, but we have a path for improving it over time. |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 3:23 pm Post subject: |
|
|
| The Robman wrote: | | I just noticed a bug in the Timing Summary sheet, the Repeat: portion is at the end of the line, not on a new line |
Yea I noticed that one too...I've already fixed in code but just haven't published new jar. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 3:51 pm Post subject: |
|
|
Here's a sample set of IR files to look at (picked at random)
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=11300
And here's a spreadsheet that will convert it to binary for you:
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=11301
To use the XLS, paste the output from the Timing Summary sheet (not including the 1st two lines) into the Input sheet, then on the Output sheet, enter the "1" pair in cell B2 and the "0" pair in cell B3. Then, looking at the data in the G column, count the positions to see where the binary starts and enter that value in cell A5.
Btw, for some reason, I can't get the signal on the REW button (in the 1.ir file) to decode as bi-phase.
Finally, is there a way to edit signals in RMIR like you can in IR.exe?
_________________
Rob
www.hifi-remote.com
Please don't PM me with remote questions, post them in the forums so all the experts can help!
Last edited by The Robman on Fri Dec 07, 2012 2:27 pm; edited 1 time in total |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 7:21 pm Post subject: |
|
|
| The Robman wrote: |
Finally, is there a way to edit signals in RMIR like you can in IR.exe? |
It seems that RMIR only lets you edit them via changing the UEI Learned hex data. What kind of editing would you like to be able to do?
| The Robman wrote: |
Btw, for some reason, I can't get the signal on the REW button (in the 1.ir file) to decode as bi-phase.
|
Two things going on here...first of all, this signal exposes a bug in the biphase analyzer...it thinks that the rounding is lower than it actually is, so it fails. I will fix that part.
I believe the correct rounding is 275, but I also think this is an incomplete learn. The signal ends with ( +82 -130988 ) which seems incorrect. I think the learn got cut short and only learned the +82 and then this magical 131ms were tacked on as an off time. I wonder if this learn was done with a button tap instead of holding? With the weird final pair like that, the biphase analyzer won't recognize it even if the rounding is properly set.
I'm guessing it should show like this:
+1925 -825; -825 +825 ; -275 +275 ; -275 +275 ; -275 +275 ; -275 +275; +275 -275 ; +275 -275; -275 +275; +275 -275; -275 +275 ; -275 +275 ; -275 +275 ; -275 +275 ; -275 +275 ; -275 +275 ; -275 +275; +275 -275; -275 +275 ; -275 +275 ; -275 +275; +275 -275 ; +275 -275 ; +275 -275 ; +275 -275; -275 +275; +275 -275 ; +275 -275 ; +275 -275 ; +275 -275 ; +275 -275 ; +275 -275; -275 +275 ; -275 +275 (this on time was cut short); -130900 (lead out probably way wrong)
So it's a case of "bad input yields bad output." |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 7:57 pm Post subject: |
|
|
| Vyrolan wrote: | | It seems that RMIR only lets you edit them via changing the UEI Learned hex data. What kind of editing would you like to be able to do? |
I'd like to be able to switch over to Pronto hex mode, like you can do in IR.exe, because I can actually read Pronto hex easily and if you find a code posted somewhere on the web, it's most likely going to be in Pronto hex 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!
Last edited by The Robman on Fri Dec 07, 2012 2:33 pm; edited 1 time in total |
|
| Back to top |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 8:05 pm Post subject: |
|
|
| The Robman wrote: |
| Vyrolan wrote: | | It seems that RMIR only lets you edit them via changing the UEI Learned hex data. What kind of editing would you like to be able to do? |
I'd like to be able to switch over to Pronto hex mode, like you can do in IR.exe, because I can actually read Pronto hex easily and if you find a code posted somewhere on the web, it's most likely going to be in Pronto hex format. |
I agree completely...I remember being kinda surprised I couldn't import learns via pronto. That's something we'll have to look into for sure. |
|
| Back to top |
|
|
The Robman
Site Owner
Joined: 01 Aug 2003
Posts: 21237
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 10:19 pm Post subject: |
|
|
There is logic in IR.exe that converts to and from Pronto format, so hopefully that will give you an idea of how to do it.
I was just putting together a spreadsheet to convert learned times into XMP format and I noticed that RMIR doesn't have the seeding value for rounding that IR has. That was introduced specifically for the XMP protocol, if I remember correctly. For XMP, the base pair is approx "+210 -756'" (that's "0"), then for each pair after that, the OFF time increases by about 142. So, in IR.exe you would enter 756 as the seed time and 142 as the rounding. This will completely mess up the ON time, but that's OK because we know the ON time is 210, but it lets us easily (relatively speaking) manually decode an XMP signal.
The following file includes some XMP learns and a spreadsheet that decodes the first of the files. When I open any of these files using RMIR, the Timing SUmmary button doesn't work, it appears to depress but the timing panel doesn't come up.
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=11302
_________________
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 |
|
|
Vyrolan
Joined: 24 Aug 2012
Posts: 168
Location: Chicago, IL
|
| Posted: Sun Sep 02, 2012 10:39 pm Post subject: |
|
|
| The Robman wrote: | | There is logic in IR.exe that converts to and from Pronto format, so hopefully that will give you an idea of how to do it. |
I'll look into it...it's definitely a functionality that we should have in RMIR.
| The Robman wrote: | | I was just putting together a spreadsheet to convert learned times into XMP format and I noticed that RMIR doesn't have the seeding value for rounding that IR has. That was introduced specifically for the XMP protocol, if I remember correctly. For XMP, the base pair is approx "+210 -756'" (that's "0"), then for each pair after that, the OFF time increases by about 142. So, in IR.exe you would enter 756 as the seed time and 142 as the rounding. This will completely mess up the ON time, but that's OK because we know the ON time is 210, but it lets us easily (relatively speaking) manually decode an XMP signal. |
Aw...I didn't know what the seed was... =) I'll look into it.
Yes, I think there is a bug where it can freeze up trying to analyze. I saw it in a sample earlier...I'll investigate and fix...thanks for another reproducible instance. |
|
| Back to top |
|
|
mathdon
Expert
Joined: 22 Jul 2008
Posts: 4523
Location: Cambridge, UK
|
| Posted: Mon Sep 03, 2012 3:07 am Post subject: |
|
|
| Vyrolan wrote: | | I remember being kinda surprised I couldn't import learns via pronto |
Lack of time!
| The Robman wrote: | | There is logic in IR.exe that converts to and from Pronto format |
The conversion code is actually in ExchangeIR.dll, with the intention that at some time a JNI native interface would be added to it and then RMIR given a similar Pronto conversion facility to that in IR.exe. IRScope, which is written in MS C++, also has this facility via ExchangeIR.
I hope that, armed with this info, you should find it an easy task to add Pronto conversion to RMIR.
_________________
Graham |
|
| 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
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
File Section
Wiki
