CaptureIR progress

[johnsfine]

I'll try to find time to double check that the selection of pin 10 still works. I know I tested that once. But it isn't the pin I used on either of my current set ups. There is a data table in the C code telling CaptureIR.dll what each pin number means. I should switch my solderless unit to use pin 10, since that's easy and I advised you to use pin 10.

Did you also select active high?

Meanwhile, how accessible are the pins of the QSE158?

Since the QSE158 is active high, it should be pulling pin 10 low most of the time. What is that voltage?

When it gets IR, it should let pin 10's internal pull up bring pin 10 high. I don't know how your volt meter will average things. I haven't yet tried this myself. But I think the voltage should be mearsurably higher while IR is hitting the device.

Regarding porttalk.reg, I guess you got that elsewhere and I should include it in the .zip for others.

I guess I need to improve some diagnostics in CaptureIR.dll so it gives us more of a clue what it sees.

[gfb107]

Pin 10 seems to be at 4.6V all the time, if the cable is plugged in. There are definitely no shorts other than the intentional pins 18-25

[johnsfine]

I think you have a hardware problem. Hopefully someone else will have a suggestion. I just tested:

1) I connected exactly as you did (except for shorting ground connections). Normally I use power from the USB, but I switched it to printer port pin 1 for this test.

2) I measured 3.28 volts at pin 1.

3) I measured .017 volts at pin 10.

4) I used a continuous low duty cycle IR signal (repeat part of NEC1). While it was on I measured .140 volts at pin 10.

5) I set captureIR to use pin 10 active high and it worked fine.

6) I disconnected pin 10 from the QSE158. Now it reads 4.98 volts.

I wonder if you have an active low part shipped by mistake. Does pin 10 go down in voltage when it gets an IR signal?

The middle lead is signal. As I look at the IR sensor side of the part, the ground lead is on the left and power on the right. That's what I see in Tommy's picture. Is that what you wired?

I assume my volt meter measuring DC on a non DC signal does not integrate correctly. 0.140 volts would equal 2.5% of the time at 4.98 volts and 97.5% of the time at .017 volts. But I think the actual signal has IR less than 2.5% of the total time. Anyway the voltage isn't totally unreasonable vs. expected, so I think I'm right about being able to measure what I think I'm measuring.

[gfb107]

That's how I wired it.

I just did a clean reinstall of CaptureIR and DecodeIR, and suddenly it works!
Very cool. Thanks, and sorry for the wild goose chase.

[johnsfine]

sorry for the wild goose chase.

No problem. That was a test process I wanted to go through myself anyway. It was quite easy with the solderless breadboard setup.

I have a lot of different IR detectors on order from Mouser. I want to test each of them (voltages, behavior, etc.) when they arrive and I wanted a baseline for that test process.

I'm glad you have a working CaptureIR now. It's a great tool for testing all the other JP1 and JP1.2 stuff.

[johnsfine]

There is a bug in CaptureIR, related to something you (Greg) asked me about recently (I forget where/when).

The object containing the up-to-four hex results from a decode somehow ends up shared by multiple signals.

So the displayed hex and EFC are only valid for the most recently decoded signal. As you look at the list of captured signals in the GUI only one has correct hex and EFC.

I hope to find time soon to fix that, but I really don't understand how that table operates at all. If you have more insight into why that wrong sharing occurs, please tell me.

[gfb107]

I assume you have a single DecodeIRCaller object you use to decode all the signals, instead of creating a new one for each signal.

The DecodeIRCaller has a member int[] hex which is created at the time the DecodeIRCaller is created.

Each time DecodeIRCallers's getHex() method is invoked, it returns a reference to that same member.

Here's a simple fix that will also address my desire for the hex results to be the correct length.

Code: Select all

public int[] getHex()
{ 
   int len = 0;

   // figure out how many valid values there are
   while( hex[ len ] != -1 )
     ++len;

   // create a new results array of the correct length
   int[] rc = new int[ len ];

   // copy the hex to the new results array
   System.arraycopy( hex, 0, rc, 0, len );

   return rc;
}

[johnsfine]

Thanks for a very good start. I made that change, except I used

Code: Select all

           while ( len < 4 && hex[ len ] != -1 )

because I don't think hex[3] is always -1 (though it is usually -1).

Then I ran CaptureIR. That table was totally broken and the .err file quickly led me to the lines in CaptureIR.java where I needed to change.

Code: Select all

            for (int i = 0; i < 4; i++)

to

Code: Select all

            for (int i = 0; i < hex.length; i++)

Sometimes making half a correction and looking at the .err is easier than figuring out the whole correction in advance.

Now the EFC's and hex seem to be working correctly in CaptureIR.

[gfb107]

Might I suggest

Code: Select all

           while ( len < hex.length && hex[ len ] != -1 )

Just in case you ever change to a value other than 4.

[johnsfine]

I just uploaded a new version to
https://www.hifi-remote.com/forums/dload ... le_id=3760

I finally started changing the version number. This one is Prototype 12, build 1.

I made a few minor cleanups in the executable code and I added a Readme.txt file and PortTalk.reg to the .zip file.

[roblai]

I have downloaded the last version of CaptureIR and when it lounched, I keep getting a pop-up window titled: DLL Error with the word "getVersion" in it.

It looks like CaptureIR don't connect with DecodeIR.

I did read the readme file and I have placed the the DLLs in the proper locations (I even placed the DecodeIR all over the place to make sure).

Any advice?

[johnsfine]

I changed the Java interface between CaptureIr and DecodeIr recently. The error message you are getting implies one or the other isn't the changed version.

Oops! I just checked the posted Decode_IR_DLL.zip and it was an older one.

I used that web space to get the newer one from one computer to another myself, so I'm pretty sure it WAS the new one. But just now it wasn't. I uploaded it again:

http://john.fine.home.comcast.net/ir/Decode_IR_DLL.zip

[roblai]

Thank You John, now it works

I will be able to experiment.

Robert

[binky123]

In the past, I've hooked up 2 wires(Vout and GND) from a IR sensor on a VCR into the parellel port of a PC. I then ran some software like irscan.bas to periodically sample the Vout line. I sampled some known signals to see what the output values were and then moved on to decode some unknown signals.

The LIRC project has some simple designs for IR detectors as well.

You will have to find some way to capture the IR signals into a known format so it can be converted into JP1.

[johnsfine]

In the past, I've hooked up 2 wires(Vout and GND) from a IR sensor on a VCR into the parellel port of a PC.

CaptureIR ought to work with that hardware as well. It should be easier to get decodes with CaptureIR than the software you described.

I have a broken VCR. I was planning, when I find time, to extract the IR sensor from the VCR and figure out how to power it to test it as yet another sensor for my own CaptureIR testing. But if I understand you correctly, it's easier to leave the sensor in the VCR. My broken VCR still powers up. If I can open it up without further breaking it, I should be able to add the two wires you suggest and avoid removing the sensor and figuring out how to power it. I wouldn't try that with an unbroken VCR, but I guess you're more skilled at such things than I.