JP1 Remotes

Tommy Tyler · Posted: Sun Oct 04, 2009 8:47 am Post subject:

The plot thickens! Incidentally, I'm testing with WinXP Pro (SP3). While repeating my tests just now I had the surprising (and pleasant) experience of seeing IRScope work with the new dll. How to explain this in few words? My problem is signal dependent, and it's all Liz' fault. She invented a "Widget Killer" somehow!

During all my previous tests I was sending a signal that uses Dish_New protocol, Device 1.0, Key 55, Hex DA. I accidentally pressed a different device button just now and, voila! IRScope worked perfectly with 2.38. And now that I have crawled out from under my rock and learned you guys are looking out for the Widget, and saw the "3 frames" message on a Sony signal, you won't hear any more from me about not being able to use the Widget to count repeats.

Which leaves the Dish anomoly. Actually, I can't blame it on Liz. When I send that same signal from a Dish OEM remote it hangs IRScope as well. Is that a bug in IRScope or DecodeIR? I ask because the problem doesn't occur with the old dll.

Tommy Tyler · Posted: Sun Oct 04, 2009 9:03 am Post subject:

Just for the record, I just downloaded a fresh copy of 2.38 and there was no change in the failure mode. It's CBL1401 protocol that does it. Vicky, can you try that?

Tommy Tyler · Posted: Sun Oct 04, 2009 9:18 am Post subject:

Graham,

With DecodeIR.dll versions 2.36 and 2.37 IRScope decodes CBL1401 properly. With version 2.38 it hangs. Does that help narrow down what the problem might be?

Tommy

mathdon · Posted: Sun Oct 04, 2009 10:01 am Post subject:

vickyg2003 · Posted: Sun Oct 04, 2009 10:47 am Post subject:

Graham, I just tried Cable/1775 with Irscope and my computer seems to be hung up. I think you might replicate this with Cable/0610 on the Stealths.
_________________
Remember to provide feedback to let us know how the problem was solved and share your upgrades.

Tip: When creating an upgrade, always include ALL functions from the oem remote, even if you never plan on assigning them to a button. Complete function lists makes an upgrade more helpful to others.

Tommy Tyler · Posted: Sun Oct 04, 2009 10:48 am Post subject:

My mistake. I thought I had keyed that setup code into a 6131 successfully, but Vicky rightly suggested 1401 might be Liz' upgrade, and that's exactly what it is. (So I DO get to blame this on Liz after all.) The upgrade is CBL1401 and here's the upgrade code:

02 15 3E FE C4 7E C1 B0 00 80 40 C0 68 78 08 2C
00 40 6C 5C 48 68 78 70 60 50 40 E5 94 98 0D 80
C5 C9 84 7C

Tommy

Tommy Tyler · Posted: Sun Oct 04, 2009 10:53 am Post subject:

Also hangs with CBL0775, which is resident in many UEI remotes.

Tommy

Tommy Tyler · Posted: Sun Oct 04, 2009 10:57 am Post subject:

Also hangs with CBL1170, so it seems to be Dish anything that it really dislikes.

Tommy

mathdon · Posted: Sun Oct 04, 2009 11:56 am Post subject:

None of the Cable codes that have been mentioned exist in my remotes, neither in Cbl or Sat devices. However, I've pasted Tommy's code into IR.exe and at first I thought all was OK. Widget decoded it first time. But on repeated tries I get the hang-up perhaps 50% of the time. So that gives me something to go on. BTW The same PID is used for SAT/0610 and that works perfectly every time. In fact, it's one of the protocols I used for testing. It is described in John's documentation as not robust, so I was pleased that I had got it being recognised correctly every time. It looks as if somehow it can get into an endless loop, though. I will investigate and report later.
______________
Graham

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Graham,
First, good news: when I did the Sharp/Denon 11,2 sequence I got three lines, so your 'pause' dtection worked well, thank you!

Now the bad news. I concur with everything Tommy said. It don't like DishNetwork protocol 0002 or 01E2. In DecodeIR 2.38 earlier it works, in the last one, Beta7 it hangs with 90% CPU utilization and no threads other than IRscope visible in ProcessExplorer. That's on XP-Pro-SP3, old Pentium3 box. I suspect the cause might well be the fix for Denon. Dish pids have very short leadout. If you need IRscope file, let me know.

Tommy, Vicky, thanks for joining in this fun Smile

_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

0002 is plain DISH NETWORK protocol, used in many S3C8+ remotes.
01e2 is 0002:5 (see RM protocols.ini).
In this instance, while 6131 uses 0002, Comcast S3F8 and Atlas use 01E2 though you woudn't know it from KM, because the choice is 0002, but the code matches 01E2.

Tommy is right that the 01E2 he uses has been changed by me to switch unit on the fly. But that is not really related to widget issues.
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Third msg of the day Smile

In case still needed, Dish protocol macros - raw data and pics
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=7339
Proof of work fine in the previous version of DecodeIR
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

mr_d_p_gumby · Posted: Sun Oct 04, 2009 1:21 pm Post subject:

ElizabethD · Advanced Member Joined: 09 Feb 2004 Posts: 2348

Hi Mike!
Makes sense. But at one point when there was no Comcast support in KM, I used RM and it brought in 01E2. There's a difference of 2 or so bytes in those protocols. Go figure. Far as I know using 0002:5 worked for Tommy on his Atlas remote. And it appears to me 0002:5=01E2. Boy, this is difficult stuff, how do you ever sift through????
_________________
Liz
Tweeking 8910, HTPro/9811, C7-7800, 6131o, 6131n, AtlasOCAP-1056B01, RCA-RCRP05B and enjoying the ride Smile

mathdon · Posted: Sun Oct 04, 2009 5:04 pm Post subject:

Just a quick update. The fix will have to wait until tomorrow (UK time). I know where the bug lies. It isn't the Denon fix, as Liz thought, it's the fix to make a gap of more than 200ms be treated as separating distinct button presses. With my supposed "enhancements", the code now has a loop within a loop within a loop within a loop. Exclamation

When there is a non-robust protocol and one of the possible spurious decodes (that I am trying to filter out) reaches the signal end and so has a lead-out time of more than 200ms, there is a potential for an endless loop. I haven't yet figured out how to avoid the endless loop, keep the 200ms signal separation and at the same time filter out all the unwanted spurious decodes. I can do two out of three, but not all three. But don't worry, I'll figure it out in the end!
______________
Graham