JP1 Remotes

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

bvwelch wrote: So, when, instead, I see many lines, I figured something got "confused".

That sounds like it is caused by the incorrect boundaries added by frequency detection, as I described above. But I can't rule out the possibility that there is also some other flaw in capture/decode.

You mentioned you had the ability (java compiler installed, etc.) to rebuild an edited version of this software. Note line 309 of IRSignal.java is a complicated if statement for detecting a boundary across which the wavelength changes. You may want to edit that to make that if always false (or just remove lines 309 through 323). Until I improve the handling of frequency boundaries, you would be better off not having them at all.

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?

I'm not sure which problem you want to solve:

1) Our existing hardware/software approach is marginal in whether it can do a decent job of computing the right frequency.

That's no reason to switch to a sensor that hides the frequency from us entirely.

2) Our attempts to determine the right frequency are currently generating problems that are worse than not knowing the frequency would be.

Again, that should be fixed in the software and I will. It doesn't mean switch to hardware that hides the frequency. Meanwhile I told you how to eliminate all (I think) the damage of the attempts to compute frequency while only somewhat reducing the ability to compute frequency.

3) You might be aware that common IR sensors that demodulate internally have a much wider range of acceptable distance than this sensor or other sensors I've seen results from that don't demodulate internally. I don't know how much of that is made possible by the internal demodulation vs. how much derives from other aspects of the intended market of the devices.

Anyway, with this device I get dramatically different results as a function of distance over a practical range of under 1 inch up to 3 feet (beyond which I don't recall getting any results good enough to use). A demodulating sensor may have a practical range out to 20 feet and may give the same results at 2 feet as at 20 feet.

But those sensors having timing rules that are even more restrictive than you would initially guess from their demodulation. They give you better results on protocols that fit their designed timing by killing the ability to capture signals outside that range.

That's a good idea for the sensor in your project, where you will preselect a single input protocol and can select one that's a perfect fit for your sensor. I don't think its a good idea for an IR analysis system for ooking at unknown signals and hoping to do better than a JP1 learning remote at seeing what those signals really are.

However, if you want to wire it up, I'll help you fix the software to be able to use it.

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

I still think I can get best practical frequency detection while still surpressing the consequences. But if I can't, we just need an options dialog in CaptureIr so a no-consequences version of frequency detect is selected by default and an expert can switch to more accurate with more risk of consequences.

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

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

bvwelch wrote: Test case #4 is the "philips" box,

Item 8 in cap4.txt is a failed decode. The point of failure corresponds to line 685 in log4.txt

On that line we see the first half of the On part of a burst followed by a long Off. By hand decoding that signal you can see there were actually two bursts there. So the capture missed the second half of the On of one burst and all of the On part of the next burst.

Most likely that is a timeslicing problem, meaning Windows took the CPU away from that (high priority) task at that moment for at least 1400 microseconds.

My version of the capture code keeps track of those blind spots due to timeslicing. But my diagnostic display only dumps them for the beginning and end of the capture. This one wasn't near enough to either beginning or end, so I can only deduce not directly see that this failure was due to timeslicing.

If I can figure out how to add some pull down menus to the Java code, I can add the ability for an advanced user to foucus in on a bad decode, and optionally a bad burst within that decode and then see the size of the blind spots that occured during that time.

We can't stop Windows from creating these blind spots and we can't stop the blind spots from trashing the capture. But the code does already record them, so we can let the user know that the failure was due to a Windows timeslicing blind spot. Many other failures are due to the distance pickyness of this IR sensor. We want the user to experiment with different distances to fix failures that might be due to distance, but not experiment with distance for failures that we know are due to Windows.

For the intended purpose of CaptureIr, it is good news that your system got only two of these failures in sixteen two-command captures. If CaptureIr had been invented for IR control of a PC rather than for investigating IR code sets, two such failures in sixteen macros would be terrible. For investigating code sets, doing it over in these cases isn't too hard if needed. For this particular code set you can see all the info you need even with two commands dropped.

bvwelch wrote: Test cases #5 and #6 are for the "scientific atlanta".

I didn't take as close a look at those, but I'm pretty sure I understand what is going wrong.

When the capture code hits the .5 second gap, it suspends capturing while all the demodulation and diagnostic display and decoding occurs.

Meanwhile the device you have sending the IR signals has started the next command and CaptureIr restarts a capture near the end of a command, getting just a small amount of garbage that it can quickly demodulate and restart again, this time I think getting a clean start before another command.

For those with hyperthreading or dual core or dual cpu systems, the streaming support I have planned should fix this (if I ever get around to writing it). But for current typical home systems, with CPU power comperable to your system, that will almost certainly hurt more than it helps.

The user should be given control of the .5 second timeout through the UI. To get a tricky capture such as this, the user may need to experiment with tweaking that:

Maybe you can set the timeout lower to start processing each command sooner after it ends and maybe be done before the next command starts. Getting rid of my diagnostic output will help that, and maybe it justifies moving the demodulate code from Java to C++ for greater speed.

Maybe you can set the timeout lower so that the next command begins before the timeout after each command. Then CaptureIr would continue capturing without processing through the entire series of commands then demodulate and decode all of them at the end.

BTW, there is plenty of data posted here and at RC on this standard Scientific Atlanta (Panasonic_old protocol, device 27) code set. So if you actually wanted details of that code set you wouldn't need to use a method this hard to get it. The first semi-correct decode you got tells you it is this standard code set and from there you can just download an upgrade for the rest rather than continue with capture and decode. But I understand at the moment you are investigating the tool more than you are investigating the code set.

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

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.

bvwelch wrote:I am happy to report that the project is "sort of" working.

For any lurkers trying to sort through the many topics of this thread, you mean the project described way back here of using a pic micro to receive one IR protocol and transmit another.

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

Or maybe I'm confused about the project. How do you have control over the digit timing? If you're doing protocol translation one command at a time the originating device (DMR-E85) has control of the digit timing.

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

That sounds like the spacing is now too little. Have you tried something in between?

bvwelch wrote: 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,

Now I'm even more confused. I thought your pic would be receiving NEC1 but transmitting something else to the Humax. I guess you didn't mention what code set the Humax needs.

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

Since NEC1 uses the inverse of the function byte as a function check byte, every function is the same length. The duration of the active signal depends only on the XOR of the device and subdevice numbers. If you really want to follow spec, you could hand precompute the correct gap for the end of frame (based on your device and subdevice numbers) and then program in that gap.

bvwelch wrote:I can implement that, but I am not sure if that is correct or necessary.

For digits, I don't think the repeat pattern is needed at all nor even helpful. I also don't think you would need to get very close to the spec'ed 108 ms, if you did want the repeat pattern.

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

You're absolutely right that discussion of the pic based DMR-E85 to Humax HFA-100 translation device (if that's still what we're talking about) belongs in a different thread.

I think I'm a moderator here and have the rights to rearrange things that way (extract all pic and DMR-E85 posts from this thread and assemble them into a new thread). But I don't have the expertise. Maybe Rob will tell me how. He's done such things several times before.

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

https://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