JP1 Remotes

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.

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?

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

Tommy Tyler wrote: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?

It would do if I had a remote that supported CBL/1401. I take it that is a UEI device setup code. Can anyone tell me what the Protocol ID is, or even better, if there is an RMDU file for it?
______________
Graham

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.

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

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

Tommy

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

Tommy

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

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

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.

Third msg of the day

In case still needed, Dish protocol macros - raw data and pics
https://www.hifi-remote.com/forums/dload ... le_id=7339
Proof of work fine in the previous version of DecodeIR

ElizabethD wrote: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.

The RCA RCRP05B is the only remote I know of with 01E2 resident. The Atlas & others use 0002:5 as the Dish Network Combo protocol.

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????

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. 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