JP1 Remotes

One is the main (ie repeating) frame, where John was requiring the first burst to be the longest.

I haven't looked at X10 in a very long time and don't remember much. I do remember that UEI remotes send a different signal than the ones I found in Pronto CCF files for X10. I don't remember any details about that, but I think Rob may have a good understanding of that difference and its significance.

The first burst of an IR signal is the least reliable burst and the most likely to be shortened by a poor learn.

When a decoder relies on the first burst being longest, that ought to mean the first burst is always sent so much longer than others that it can significantly shrink but still be longest.

It sounds like I messed up X10 decoding in a couple ways.

I'll try to find time to test the new DecodeIR against my library of CCF files. I usually do a text diff of the massive output from that against an earlier version. It sounds like I will need to disable some of your changes in my test copy to get the differences to be small enough that I can find any important differences buried in all the unimportant ones.

Hey guys, I haven't read back to see everything that's been said about X10, but here's the story.

The signal generated by the HOME/0167 is quite different to the official X10 signal, but it's close enough that X10 devices will respond to it. This is a very old UEI setup code and it was deliberately designed to be hard to learn, my guess is so that people wouldn't buy cheap UEI remotes to program their more fancy learning remotes. If you want to replicate an official X10 remote, use my X10 Simple upgrade.

As far as DecodeIR is concerned, I would focus on getting it to recognize the official X10 signal first, then see what tweaks are needed to get it to recognize the UEI version also.

As to what the differences are between the two versions, I don't remember.

mathdon wrote:I don't think I have introduced any new bugs as a result, but I would be most grateful if Liz in particular, and anyone else interested in doing so, could give it a final checking over. I will deal with any bugs that are found, but I think we'll call a truce in the search and destroy mission on spurious decodes for the time being, as I suspect it could go on for ever!

Using 8910 and 7800 UEI version of few more protocols, some obviously fine, one or two maybe not, but I can't tell, so I'm just listing what's in the zip file. Oh I included 8910 device and setup codes and pid# in the filenames.
https://www.hifi-remote.com/forums/dload ... le_id=7369

These just for you collection, I have'm, might as well share
- Recheck of X10 looks decoded. Interesting. The first signal I put in has just X10 & misc. says no repeats, but there might be more words which I cut off & don't feel like retesting. If I didn't take a break would the numbers continue past 7? I don't care. I don't have X10
- pid 0014 Mitsubishi, I just had to see it as opposed to JVC
- pid 0045 RECS80(45) I did these two because you worked on RECS80
- pid 0068 RECS80(68), whoa!
- pid F12 - looks ok
- pid 001C - this one is ok as Sharp (distinct from previous Denon discussion)

These might need your look
- pid 007E PioneerMIX, perhaps refers to 4 device. I expected devices 170,211,175,212 from Devices.xls. I got Pioneer 170,175, Nec2 on 170 and RCA for 14, and considering how difficult Pioneer is for KM, I bet it is all ok. 3 files for this one as it's a curious one. Some decodes don't match what DecodeIR says especially the 50KHz signals in file c. Hmm, now that I think of it - if this setup code is for TV, transport buttons don't belong but I don't know what the transport device was at the time I ran this test.
- pid 0029 Hamlin - 5 transport keys decode as RCA, I cannot get any decoding for numbers, but they do send a IR signal. 2 files here. Hamlin isn't in DecodeIR but is in my 8910.
- pid 0021 Viewstar - few RCA and few gaps here

I, too, think this Search and Destroy mission should be over

Thanks for your other answers and thanks to John and Rob for joining in, as I'm driving blind through all this with little understanding really.

A quick reply to John and Rob - I've only just seen your post, Liz, and will reply later.

Rob, your X10 Simple just adds to the intrigue. It largely agrees with John's original IRP, ie all frames identical and the first burst a bit longer than the others. It is decoded by my Beta9, but of course without the counter N since that frame is missing. But John got the disstinctive start frame from somewhere, carrying the N value, and it is in the UEI executor (though as I said before, not quite the same), so I presume that is actually present in a real X10 signal. Conclusion - not much further ahead. It gives me no reason to change my Beta9 decoding.

John, I'm very pleased you still intend to run my revisions against your database. My generic enhancements (frame counting, spurious decode checking) are in a wrapper around your decode() so all you need do to disable them is change my call to decode2() back into a call to decode().
________________
Graham

I've looked at your .png files, Liz, but not yet at the accompanying .ict files for more detailed info. Apart from Viewstar I don't see anything to worry about. Protocols like RECS80, where John puts some additional debug info into the Misc field, will always look complicated. My frame counting counts identical outputs from John's original decode, and if there is anything different then it will be reported as a different signal.

You have one signal that doesn't decode at all, but DecodeIR doesn't yet support that protocol so I would prefer a blank than a spurious decode. X10 remains an interest. The HCS08 executor from UEI has a 4-bit counter (actually 5 bits in the IR engine, but only 4 are used in this executor). It looks as if the S3C8 executor only uses a 3-bit counter. I wouldn't like to speculate on whether that is the limit of its IR engine, or just what UEI have used in this executor, but it is certainly a difference between the two processors.

I'll look in more detail later, but on the whole I'm happy that you haven't found anything more than this for me to worry about!
______________
Graham

I was curious so I used Rob's X10 protocol put into 8910 then out to the widget. Don't know what to expect or think about it bcause I can't match hex, some sort of offsetting going on. So the zip includes KM and IR files in case I messed up big time.
https://www.hifi-remote.com/forums/dload ... le_id=7370

mathdon wrote:Rob, your X10 Simple just adds to the intrigue. It largely agrees with John's original IRP, ie all frames identical and the first burst a bit longer than the others. It is decoded by my Beta9, but of course without the counter N since that frame is missing. But John got the distinctive start frame from somewhere, carrying the N value, and it is in the UEI executor (though as I said before, not quite the same), so I presume that is actually present in a real X10 signal. Conclusion - not much further ahead. It gives me no reason to change my Beta9 decoding.

I can't speak to where John got that frame from, and I bet he doesn't remember, but if it's not in my Simple upgrade, it's not in the real X10 signals. Like I said, there's a ton of junk in the UEI signal, which is there on purpose to cause problems.

Your decode needs to allow for the junk, because people might learn from a UEI remote, but it should by no means *require* it.

If you want proof, take a look at the X10 files at Remote Central. You can run the CCF files through John's DecodeCCF program which uses DecodeIR to see how they decode.

The Robman wrote:Your decode needs to allow for the junk, because people might learn from a UEI remote, but it should by no means *require* it.

Absolutely. If there is no start frame (your "junk") then the protocol name is reported as X10. If there is a UEI-style start frame then the protocol name is reported as X10.5 (or whatever, where 5 is the counter value).

Even though my look-ahead facility combines differing frames and returns a single entry when the protocol spec includes them (eg the JVC frames with and without lead-in), it *always* returns a decode, whether all the frame types are present or not, and in a way that is distinctive according to what it finds (like the X10 v. X10.5). In the X10 case it will even return a decode if *all* it finds is your "junk" frame. It will give X10.5 as the protocol name but the Misc column will say "invalid signal".
________________
Graham

ElizabethD wrote:Don't know what to expect or think about it bcause I can't match hex, some sort of offsetting going on. So the zip includes KM and IR files in case I messed up big time.

Different protocols can use different hex for the same OBC. What you are seeing in IRScope is the hex value that UEI protocol 003F needs to give the correct IR signal. What you are seeing in IR.exe is the hex value that Rob's X10 Simple needs to give the correct IR signal. Rob's hex seems to be straight LSB. The conversion in protocol 003F is that the hex is the LSB of 2*OBC+1. Example: Button 6, OBC=9. 2*OBC+1=19, which in binary is 00010011. In LSB form (reversing the bits) that is 11001000, which in hex is C8. But for Rob, 9 in binary is 00001001, reversed is 10010000, ie hex 90. [Edit: Table removed.]

Hope this clarifies things. If you look in DecodeIR.html in the Beta9 package you will see that the OBC to Hex translation is given there.
__________________
Graham

mathdon wrote:Absolutely. If there is no start frame (your "junk") then the protocol name is reported as X10. If there is a UEI-style start frame then the protocol name is reported as X10.5 (or whatever, where 5 is the counter value).

Why are you displaying this? I haven't been following this discussion so I may have missed something, but have we found a use for this info? If, as I believe, this part of the signal is junk, there doesn't seem to be much reason to decode it and display it. Plus, in the world of newbies, less is more. I can see the posts now, and not just from newbies, asking what settings in RM they need to use to get the X10.5 portion of the signal formatted.

The Robman wrote:Why are you displaying this? I haven't been following this discussion so I may have missed something, but have we found a use for this info? If, as I believe, this part of the signal is junk ...

Point 1. The display of this counter value is NOT MY IDEA. John's decode was written to display it in the same manner (as part of the protocol name). It didn't do so only because of a bug in his code.

Point 2. You may believe that the start frame is junk, but I don't. I am sure you are right that if I look at X10 signals in RemoteCentral I won't see that start frame. I have a JVC OEM remote that doesn't send the initial lead-in and so displays as JVC{2}. That is not evidence that *all* JVC remotes behave that way (we know they don't, of course). So just because some X10 remotes don't have this start frame doesn't mean that there are not later ones that do. I do not believe UEI would have put in such a specific and unusual frame just to confuse us. And as I have said, John felt it worth including and displaying, too.

Point 3. I am happy to stop developing DecodeIR, or IR.exe, or both, or to disappear from the JP1 world entirely. You have only to say the word.

Graham

mathdon wrote: Point 3. I am happy to stop developing DecodeIR, or IR.exe, or both, or to disappear from the JP1 world entirely. You have only to say the word.

Graham

Whoa there! I'm not seeing any syggestion of the sort in Rob's post. Your efforts (and more importantly, results) upgrading IR.exe and DecodeIR.dll are MOST welcome. That said, I agree with Rob, that in addition to "completeness" and "accuracy" in the refinement of the tools, one should keep in mind that the ultimate end user is NOT the expert who lives on this forum all of the time ("Get a LIFE, already, Cap'n, wouldja?"), but that the tools should be most simply and easily usable by the newbie who stumbles onto this site and could benefit from the tools to upgrade the performance of his/her remote.

To that end, the point that the output of DecodeIR.dll as displayed in IRTool or IR.exe or RMIR should be readily transferable to the KM or RM tools that the individual is likely to be using is indeed one that should be kept in mind. If there are too many data in the decode to make it useful to the "basic" user, then there should be some way of displaying just the data required.

ElizabethD wrote:These might need your look ...
- pid 0021 Viewstar - few RCA and few gaps here

Liz, I'll answer this now in case the boss sacks me - see my previous post. And no, I'm not laughing.

The volume and channel signals are certainly not Viewstar, so I suspect there was punchthrough in operation there. The remaining signals *are* Viewstar, but due to a bug in John's code they don't show up. I am doubtful if anything would show up as Viewstar. He has a test that requires the maximum burst length to be less than 1.48 times the minimum burst length. Since the nominal ratio is 1.5, a perfect signal would fail that test. The ratio from the first of your Viewstar signals was 1.502, almost spot on the nominal value but giving a test failure. I didn't check the others in detail.

I have changed the ratio in that test to allow up to 20% more than the nominal 1.5. CBL/0063 now shows up correctly as Viewstar. I don't regard this as needing a new Beta. If there are no other problems, and if I am still developing DecodeIR, it will just be a minor change made in the release version.

I had to use RM to create an upgrade, but RM has its own Viewstar issue. It treats the OBC to Hex translation as MSB. It is actually LSB.
_________________
Graham

Capn Trips wrote:To that end, the point that the output of DecodeIR.dll as displayed in IRTool or IR.exe or RMIR should be readily transferable to the KM or RM tools that the individual is likely to be using is indeed one that should be kept in mind. If there are too many data in the decode to make it useful to the "basic" user, then there should be some way of displaying just the data required.

I have just pointed my OEM cable remote at IR Widget and been told that the signal is

RC5. Device=10. Key=1, Hex=F8 F9 FA, T=0, U=1772:1800

I know of no way to suppress the surplus information. If I look at RC5 in DecodeIR.html then it says nothing about what T and U mean. In a recent post, Liz said that an RC5 decode was too complicated for her to understand (or words to that effect).

In contrast, if you look at X10 in DecodeIR.html you will find a complete explanation of what the decode means, and what the difference between a display of X10 versus X10.7, say, means.

I only see one difference in the two situations. One decode is due to John Fine, one of the wise gurus of JP1. The other is due to me, a newbie upstart.
_______________
Graham

mathdon wrote:Point 3. I am happy to stop developing DecodeIR, or IR.exe, or both, or to disappear from the JP1 world entirely. You have only to say the word.

Please, DON'T EVEN THINK ABOUT IT. IT's NOT an OPTION.

Thanks for the explanations of the latest files. This is very educational.

When you return to IR itself, will you be looking at the USB for Delcom driver? I hope.