JP1 Remotes

[bvwelch]

John,

Thanks for looking at my test results.

What I meant by "confusing", was, that, I believe that for this test case, for each "click" on my DMR-E85 "CH +" button on the front panel, I expect to see two lines of output in the IRCapture gui window-- that is, if I am changing to channel 3, I (think) it is sending "0" followed quickly by "3", or for channel 12, it is sending "1" following by "2".

So, I expect two lines of output, one for each NEC1 command.

So, when, instead, I see many lines, I figured something got "confused". Certainly I am...

By the way, I can see the need for a sensor such as we are using, to determine the actual carrier frequency, but couldn't we add, in addition, a IR recevier that also does the demodulation (n hardware) for us? Say, to a different parallel port pin?

Seems like this would give us the best of both worlds.

William

[johnsfine]

[bvwelch]

John,

Thanks for your reply. I will try making those source code changes you mentioned.

Actually, what I was suggesting, was that we (somehow) look at both sensors at once-- at the same time-- and maybe the extra info from the 2nd sensor could help somehow. By all means keep checking the frequency with the 1st sensor.

I like the idea of some options dialog to tweak the behaviour of the program, without having to recompile it.

Thanks again,

William

[bvwelch]

Greetings John,

Well, I disabled the code you mentioned, and the "philips cable box" (NEC1) does seem to be decoded correctly almost every time.

I thought you might be interested in seeing the results of the "scientific atlanta" box setting. So I changed the DMR-E85's setting to that choice and collected some data.

I've uploaded the data here:

http://bvwelch.com/oct25.zip

Test case #4 is the "philips" box, and Test cases #5 and #6 are for the "scientific atlanta".

I ran the same procedure-- clicking very slowly thru the channels from 2 to around channel 40.

I hope you find this useful. If you would like additional tests run, I am happy to do so.

For my own "translator", I suppose I will go back to the "philips" setting though.

You asked what was my goal in running these tests? I was hoping to find a "cable box" setting, that was decoded very reliably by IRCapture / IRDecode, and that way, when I build my "translator", I could be sure of:

1) exactly what the "translator" unit is being sent from the DMR-E85, and

2) I could use IRCapture / IRDecode to test my transmitter -- make sure it sends the same Humax IR codes. You may recall, my first usage of IRCapture / IRDecode was to "learn" my Humax IR codes. It works very well for that already!

Thanks again for all your help!

William

[johnsfine]

[johnsfine]

[bvwelch]

John,

Thank you for your help and detailed explanations of what is going on.

I think I will choose the "philips" cable box setting for my project. I is a great comfort to know that generally the IRCapture and IRDecode will be able to help me, if my project gets into trouble at a later stage. From what I can see, all the DMR-E85 does is to send the complete channel number every time, so hopefully it will do the same thing during a "timer record" scenario. Perhaps I should set up a "timer record" and see if it tries to send anything more than the channel number.

By the way on the Humax HFA100, since it is an "over the air" digital tv tuner, it has channels like "19-1" and "19-2". Initially, I was hoping to find something in the existing "supported" list that was also using channel numbers like that. But I haven't been able to find anything. So, I plan to just "kludge" it, by, for example mapping "19" to "19-1", and "20" to "19-2", etc.

Thanks again for your help,

William

[bvwelch]

I am happy to report that the project is "sort of" working. But changing channels isn't completely reliable. At first I had about one second between each digit in the channel command. Most of the time the channel was wrong or didn't change. Also, some times the on-screen display seemed to display the wrong channel.

I reduced the spacing between digits to 200 milliseconds, and now it works most of the time, perhaps failing 20 percent of the time. It looks like the 2nd or 3rd digit is missing in those cases.

I plan to try increasing the spacing to 500 milliseconds next.

But there is one thing-- I am not implementing the "repeat pattern" at the end of each digit. I may try implementing that, to see if it helps. But I am a little confused as to how to do this. I've seen in the IRP notation for NEC1, and in a description about it in the forum, that it is (16,-4,1,-173). But I am not sure how long to pause, after the lead-out, before starting the repeat pattern. I've seen a datasheet for the UPD6121 chip, and it looks like that it needs to start 108 milliseconds from the start of the previous lead-in. I can implement that, but I am not sure if that is correct or necessary.

William

ps Perhaps this topic should move elsewhere in the forum? Not sure where or how to do this.

[johnsfine]

[bvwelch]

I started a new topic over in the Non-JP1 forum about my project:

http://www.hifi-remote.com/forums/viewtopic.php?t=5380

Thanks very much for your help-- I am happy with the results of the project!

William