JP1 Remotes

[Tommy Tyler]

John,

Your experiment that gave different duty cycles for the IR pulses at different distances is similar to my experience, as mentioned in one of my earlier articles. There are a number of factors that probably contribute to this distortion of individual pulses. I've always assumed one of them was that the LED light output does not just switch on to full intensity instantaneously, but rather ramps up at some finite speed dependant on turn-on characteristics of the driving circuit and delay parameters of the LED itself. We all tend to think of the LED signal as a perfect rectangular pulse stream with vertical edges, but I don't think that's the case. I think the light output must be a trapazoidal shaped signal. Since the detector has a fixed threshold where there is enough light shining on it to trigger the output (what they call Positive Going Threshold Irradiance in the specs) the output will be triggered earlier when the LED is closer because the ramped-up light output will reach the threshold quickly, whereas at distance the ramp must reach nearer the peak before detection occurs. Eventually the distance becomes so great that the intensity at the top of the ramp is insufficient, and you get no signal at all.

All this is greatly affected by ambient light levels. The detector doesn't care where it gets its threshold satisfied, whether from static, ambient light, or from the LED pulses. So if the illumination happens to be at about 50% of threshold, the rising edge of the led pulse will trigger it sooner. To further complicate matters, the spec sheet shows a range of threshold irradiance of 25 to 250 uWatts per square centimeter, with no idea of how this 10-to-1 range might vary with supply voltage, temperature, etc.

For the foregoing theory to explain why duty cycle is distance-dependant presumes the light output ramps up over a period of several uS, which even I find hard to believe.

As for delays, there are more factors. The output switching circuit of the detector is fast (takes less than 0.1uS to turn on or off), but the spec sheet says there is a propagation delay of 6uS TYPICAL (no min or max specified) on both the rising and falling edges of the output signal with respect to the light input signal. This shifts the entire detected pulse train nominally 6uS behind the actual IR signal. This is no doubt due to circuit reponse time from the photodiode at the front end, through the amplifier, to the switching circuit at the rear end. Again, no information on how this might be affected by supply voltage, ambient temperature, etc.

To answer your question, when using the QSE158 part (green color code on the end) the open-collector transistor is normally on when the probe is dark, and turns off when the probe is illuminated above the threshold.

In summary, the probe is NOT a good detector if you are trying to capture actual duty cycles or precise turn-on times of the IR signals. But I still maintain it is 100% reliable at catching all the LED pulses in a burst, so that burst on and off times can be measured relatively and compared with an accuracy at least within the period of the carrier. Even carrier frequency measurements are unaffected by propagation delay or duty cycle distortion, only errors in the time measurement from the leading edge of the first to the nth pulse.

I'll be glad to look into this further and make more detailed tests for you if you'll tell me why you are having a problem.

I would have posted this sooner but you specifically asked for "expert comment", and I was waiting to see if a real expert might speak up.

Tommy

[The Robman]

[johnsfine]

I finally got some more time to work on this.

I got the first fully working version my own more complex rewrite of the capture and demodulate code. It keeps track of the observed latency, so that it won't misinterpret latency as a gap in the signal and so that latency can be prevented from distoring the computed frequency.

Having written the code myself, I was then able to understand a demodulate problem that was present both before and after my changes, but I didn't initially understand:

The code attempts to understand multi-protocol macros by detecting boundaries across which the frequency changed. This is a worthy goal, but so far has done more harm than good, because errors in frequency are treated as changes in frequency.

I think I have gotten control of frequency errors due to Windows latency, both to reduce such errors and to avoid recognising a change in frequency within the range of any errors introduced by latency.

But I am seeing frequency errors from other causes:

I recently tested with an MX-850 with marginal batteries and saw a lot of doubled rising edges: real rising edge, followed one sample later by a falling edge, followed one sample later by rising, followed by a few cycles representing the rest of the high interval (streached to wrong duty cycle as I described in an earlier post). I think this must be an interaction between the bad batteries in the remote and the below spec power to the IR sensor. So maybe the answer is that the voltage doubler is a required part of this design (I haven't yet tried building a new one including that).

But the demodulate software could easily detect such problems as a significant frequency shift during a single burst. A true frequency shift from a multi-protocol macro should occur between bursts, not during a burst. Multi-protocol macros are rare. I don't want to give up entirely on representing them, but I'm OK with failing to see them when the signal is degraded. So the next software change I'll try is to turn off frequency shift boundaries for the entire frame whenever a significant frequency shift occurs inside a single burst.

[Tommy Tyler]

[johnsfine]

I got those results on the fast computer. It is sampling every 1.6 uS.

The main change I added to the capture and demodulate process is that it records details of the sampling intervals, so that it can automatically factor out sampling problems (what I described above as latency issues).

I am quite confident that the digital output of the IR sensor does actually double those rising edges.

Once we get into the cause of that doubling, I'm only speculating. Your guess is better than mine.

I think I observed that moving the MX-850 very close to the sensor (1 inch) eliminated the doubling. At the time I measured the capture behavior I didn't know the condition of the MX-850's batteries. Before writing the above I post, I checked those batteries and found each of the four was 1.1 volts (they are ordinary alkaline batteries, so 1.1 volts is pretty bad). I haven't yet retested with better batteries.

[bvwelch]

Greetings,

I just wanted to report that I built the interface and used the new Java app to figure out how to decipher the remote for my Humax HFA-100.

This is a great toolset! Thank you all for making it available-- Tommy, Hal, and John.

John, I think it was you that suggested combining both the JP1 connection and the IR sensor in the same cable. I "sort of" did that-- I used two telephone cables and connected them to the same DB25 w/ hood. Seems to work well.

Thanks again,

William

[johnsfine]

[bvwelch]

Greetings,

I've gotten a lot of good usage out of this setup. But as I try various things, I am wondering if I am trying to do things now, that are not reasonable for this setup.

For example, I am trying to decode the "IR Blaster" messages from Panasonic DMR-E85 dvd record, that it will send to a "cable box" if you have one between the "cable" and the DMR-E85.

I can choose which "cable box" from an on-screen menu of the DMR-E85. Using the menu, I have tried many different models (I don't really have these boxes, but I am just looking at the output of the IR Blaster). Most choices just seem to confuse CaptureIR/DecodeIR, but a few of them work-- for example, a Philips model that uses NEC1, and a Motorola model that uses Jerrold.

I am guessing that the issue is that CaptureIR/DecodeIR isn't expecting multiple commands. But I am not sure about this.

Why I am doing this? Because I want to hook my DMR-E85 to my Humax HFA-100 HDTV tuner, and it is not supported by the DMR-E85. I plan to use a little picmicro circuit (and my own custom firmware) to "translate" between a "supported" cable box and my Humax.

I think I can manage without CaptureIR/DecodeIR, but it sure is handy when it works!

Thanks for any comments,

William

[johnsfine]

[bvwelch]

John,

Thanks for your reply. Let me address your last point first-- Yes, it might be easier to modify the "innards" of the DMR-E85 itself. But I am reluctant to do this for a few reasons- 1) the product is already discontinued, 2) I don't want to void my warranty, and 3) I think the picmicro project might be more fun.

For example, I might want to do a IR to RF (X10) translator. I know there are some products out there, but they seem expensive to me.

I was surprised at a "Philips" box using NEC1 also. But it does show up in the Devices.xls as cable setup code 0290, which is listed in the 8811 manual as a Philips cable box. I am wondering about the Motorola too- perhaps the DMR-E85 menus are incorrect-- just because they "say" Philips or Motorola doesn't mean they actually transmit some other protocol by mistake.

I am guessing that the DMR-E85 sends the exact channel number out every time. Of course this is just a guess, but in the Philips mode, CaptureIr/DecodeIr displays the entry for 0, then the entry for 1 very quickly. then when I hit the "+", it will show entries for 0, then 2. when I hit the "+" again, I see the entries for 0, then 3, etc ,etc. I can only guess that it takes this approach for every set top box.

I can tweak the sources to IrCapture and/or IRdecode and rebuild them to see if changing the timeouts will help. Or maybe I can tweak IrCapture to store away, say several seconds of samples, before sending them to IrDecode.

Or maybe I will just put the project away for awhile, until you are ready to release another version.

One other potential problem is that my computer is in one room, and my "home theater" stuff is in another, so I built a quick and dirty "IR extender" (wired). I may have poor quality at the computer end, but it looks pretty good on the o'scope.

If you like, I can capture some files tonite of Scientific Atlanta and/or other set top boxes tonite and let you see what I mean by "confusing" IrCapture/IrDecode.

Thanks again,

William

[johnsfine]

What version of Windows are you using?

Are you using Allowio/Porttalk to give CaptureIr access to the printer port?

Are you launching CaptureIr from a .bat file, or how?

What kind of computer (how fast? How many CPUs? Hyper-threading?)

I'd like to have you try my version as is or nearly as is, including some debugging output it sends to the window of the .bat file I use to run it.

That would give me a third sample point on whether the code I added is too heavy for computers slower than mine (if your computer is) as well as how the behavior may depend on the printer port voltage etc.

That debugging output may give further insight into those "confusing" results. But I also might understand those just from the files you just said you'd capture. You can email thos if it's more convenient (because it doesn't seem like anyone else here is interested to see them) or post in diagnosis area or elsewhere and give a URL. But I may still need more of a description of what you consider "confusing".

[johnsfine]

I just posted the .jar, .bat, and two dlls I'm using in a .zip file at
http://www.hifi-remote.com/forums/dload.php?action=file&file_id=2333

I hope that's all the files you would need to try my version.

The .bat file has explicit paths on my machine, so you would need to edit that to use it.

It uses much more complex capture and demodulate routines. Currently those both dump diagnostic output to the .bat files window while also puting the decodes and raw data in the captureIr window.

[bvwelch]

John,

I just measured my Parallel port at pin 1, and it is only 3.3 volts. Should I worry?
I can kludge up an external battery if you think it would help. It seemed to work fine when I was "learning" about my original Humax remote.

[bvwelch]

John,

I installed your latest version and I uploaded the results here:


http://bvwelch.com/oct24.zip

Thanks for your help!

William

[johnsfine]

I took just a quick look so far.

The capture and demodulate seems to work fairly well on your system, no BIG latency issues from the slower CPU nor from having only one. There are some issues that I ought to fix, but they aren't very different from what I see on my computer.

You may be interested in the meaning of some of the diagnostic output. Looking at log1.txt:

Line 9:

PortReader: clock=3.58Mhz unit=279.365nS timeout=500000uS gap_limit=1789772

The performance timer used for all the measurements is 3.58 MHz, so all measurements have a granularity of (1/3.58) microseconds which equals 279 nanoseconds.

The Java code gave the C code a timeout of 500000 microseconds (half a second). If we want to capture slower macros before we have streaming support, we just increase that timeout. That same timeout converts to 1789772 of the 3.58MHz units.

Line 10
PortReader: readLen=34737
That tells how many numbers (at six numbers per modulation cycle) were stored in the buffer by this capture.

Line 11:
2971.607 4460887.000 2.514 84.089 92.470 2.794 3.073 5.587 2.794 3.073 14.248 2.794

This is the beginning of the detail on individual modulation cycles. All the values are in microseconds. The first few have slightly special meanings. After that there are six values per cycle with consistent meanings:

1: 2971.607 While waiting for the signal to start, the capture thread runs at ordinary priority. On a single CPU system that means it gets time sliced away for big chunks of time. If a signal happened to start during one of those times, it would miss the start. This 2971.607 is the longest such blind period that occured. If the beginning of a signal seemed to be missing (which isn't the case this time) we could manually compare that blind period to the amount that seems to be missing to determine whether that is likely to be the cause.

2: 4460887.000 This is the time it waited from when it started capturing until it saw the first active edge of the signal (so about four and a half seconds).

3: 2.514 This is the uncertainty around the first edge. Remembering that this number itself is uncertain plus or minus the granularity of 279 nS, it tells the sampling interval at the time the edge was seen.

4: 84.089 This tells the biggest blind spot that occurred during item 5 below. The thread changes its own priority at the beginning of this interval (first active half cycle) which creates a big blind spot. Depending on the polarity of input as it comes out of that initial blind spot, the blind spot duration may be included in either item 4 or item 6.

For a few protocols, the blind spots in items 1 and 4 may be enough to consistently wreck the capture. But those are rare. Most protocols have lead-in that can be trashed without losing any important information, and most protocols have repeating frames so that you could trash the whole first frame without losing much. Protocols with neither lead-in nor repeats are rare.

5: This value includes item 4. This value plus item 6 is the apparent length of the first half cycle. Obviously some edges were missed.

6: Like item 3, this is the interval within which the edge was detected.

After that, the items are in groups of three. Each group is a half cycle. The second and third numbers added together are the apparent length of the half cycle. The first number is the longest blind spot that occured during the second number. The third in the uncertainty around the edge that ended the half cycle.

This diagnostic output shows just a chunk of the cycles at the beginning and end of the capture. It doesn't show the entire 34737 numbers, so it may not be representative. I want to replace it with GUI support to allow the advanced user to selectively view parts of this in the raw signal area.

Notice the 20.952 on line 44. That is a blind spot from some device interrupt. If there were a lot of those or they were close to the timescale of bursts, that would indicate the single CPU can't accurately capture the signal. But in this case that blind spot is trivial.

Note that you are seeing the inverted duty cycle (2/3 On and 1/3 Off) that I see when the remote is close to the sensor. I was hoping that was due to low power supply to the sensor. Since you say you fixed that, I guess it is due to something else. I have no clue what.

The next part of the debugging output is from the Java code doing demodulate:

Line 77:
burst 8997.2-4496.1 [ 29.613 26.073-26.089 ] weight=8859.2

It has demodulated a burst (the NEC1 lead-in burst) of 8997 On and 4496 off. It displayes three versions of the modulation wavelength. First is the maximum possible value (including full uncertainty of both edges) of the smallest observed single cycle of the burst. If the modulation is stable, the true wavelength must be less than that. Next are the minimum and maximum possible values of the true wavelength based on a complicated averaging of the low latency measurements within the burst. That formula is accurate if the actually frequency as received by the IR detector is stable. Finally it gives the weight, which is the amount of the On half of the burst that was used in that formula (which wasn't rejected because of blind spots or other latency issues). That weight is used in averaging the final frequency across bursts.

Lines 86,87
burst 572.29-558.58 [ 29.892 27.112-27.392 ] weight=536.66
Frame End: waveLength = 26.045

Here we have a burst that has a significantly longer wavelength than could be consistent with the precceding set of bursts. So it marks the end of a frame not including this burst and computes the average wavelength of that ended frame.

This frame end is NOT correct and results in failure to decode the actual signal. The code has already factored out any possible errors due to capture latency, so the frequency error either occured in the IR sensor or the transmitting device. It also attempts to detect some of those external frequency errors and reports them as "Unstable" (see line 98) and from that point on it stops ending frames.

This whole concept of ending frames on frequency shifts isn't working out. I need to turn it off and pass the whole capture together to DecodeIr. But in case the frequency really has shifted (multi-protocol macro) I need to enhance the interface between CaptureIr and DecodeIr to cover multiple frequencies.

Switching to your cap1.txt, notice that the first capture (lines labeled 1 through 3 in that file) was broken into the three parts you can see in this diagnostic output, and none of the parts was enough for a decode. If they hadn't been split they would be easy to decode.

This failure is all in my new demodulate method. I think I was getting similar (and even worse) examples of the same failure with the old demodulate. But I didn't keep good notes.

Is this the problem you described as "confusing" in the other version, or was that something else I haven't found yet in your files?