JP1 Remotes

It was just an ordinary signal with some latency problems at the beginning. The rest looked like the second half of what I posted only a lot more of it, with a random scattering of -47's and nothing worse (sorry, I copied straight from the GUI and never saved). It never switched over to modulated.

It hasn't happened again (I haven't tried a single CPU system where such things should be more common).

I expect the latency glitch causing those -47's is pretty common even on the fast system. But those just compromise the frequency calculation. They don't mess up the decode nor become visible except in the one case above.

The conditions for recognizing complete demodulation failure was wrong, and it was concluded it's failed if the first part was unmodulated.

Prototype 10 is here.

I started adding the build version that gets incremented every time I build it. The version number, prototype xx, still relies on my manual update because I don't want to bump it up in every build. The build number should serve as a good enough indicator even if I forget updating the version.

Hal

mtakahar wrote:Tommy, do you think it's easy to modify IRDC to support ~450KHz signals? Please don't bother seriously trying to design it, at least yet. Just a thought.

Yes, but . . . There's a 10MHz version of the 82C84 counter chip, and you can easily replace the 1MHz xtal osc with 10MHz. But at that frequency you're going to overflow the counter pretty quickly, depending on what's coming in. And obviously the 40us 1-shot that demodulates the input would probably need to be shortened. I can't give you much more of an answer without knowing what the 450kHz is doing.

Wow, that goes way back. I didn't think anybody remembered that project.

Tommy

According to what I've read here and in the old Yahoo! group, at least the Sony one seems to be similar to Sony 15 with just higher carrier frequency. (An upgrade:
http://groups.yahoo.com/group/jp1/files ... _Final.txt)

The 1-shot may not need to be changed if demodulated signals look similar to the regular ones.

I think I have a 10MHz quarz already. I'll try to get the 10MHz version of 82C84.


BTW, I'll be out of town the entire next week. I may not be able to respond until I come back.

Thanks,
Hal

I've done more testing related to the point John raised regarding minimum operating voltage for the IR probe. Apparently John was exactly right in his concern that we were operating below the manufacturer's spec. I finally found a combination laptop and probe that confirms that. The failure mode is kind of insidious in that it usually seems to result in an erratic signal rather than complete failure. There's no problem with desktop PCs that have 5V on their parallel port connector pin 1.

The quick fix is to add an external battery to boost the voltage supplied to the probe. Any battery will do, a single 1.5V Alkaline battery, a 3V Lithium coin cell, a 9V battery, anything you happen to have. Since the sensor IC has an open-collector output, its supply voltage can be higher than the laptop voltage without any problem. And its maximum voltage spec is 18V, so it's not likely you will exceed that.

Open your connector hood, unsolder the wire to pin 1 and bring it out to the positive terminal of the battery. Then add a new wire from the negative teminal to pin 1.

If you want to know how long the battery will last, find its capacity in mA-hrs and divide by 2 mA, the current drawn by the probe. For example, a AAA Alkaline battery has a capacity of around 1000mA-hrs, so it should last at least 500 hours, and maybe ten to twenty times that long when the laptop is turned off. And a AA Alkaline has two to three times that capacity.

Boosting the laptop's 3.3V output with a simple voltage doubler is a trivial task, but it will add a few more components inside the hood. If you guys get your software working the way you like, and if there's any interest in it, I'll publish a suggested probe design for anemic laptops that eliminates the battery.

I am very sorry for the lost time and inconvenience this has caused anyone. In my post that announced this gadget I all but begged for direct feedback from anyone trying it, because I had only a relatively few different kinds of PC's to test it on. That's not an excuse, just a sad commentary.

Let me know if there are questions about the quick fix.

Tommy

Greetings,

I'm looking forward to trying out this project!

But also, I am interested in some of the building blocks. In particular, the java "wrappers" that have been written for the parallel port I/O and also for the DecodeIR DLL.

I know you all are in a hurry to continue develop on this project, but when you get a few minutes, please consider making the building blocks available separately.

For example, the java "wrapper" for the DecodeIR DLL could be included with the DecodeIR DLL package itself.

Thanks again, all of you for this fine project, both the hardware and the software!

William

bvwelch wrote:I'm looking forward to trying out this project!

I highly recommend it. This is much easier than learning for most of the things we use learning for, and it is MUCH MUCH easier than flying blind for diagnosing the behavior of DSMs, toadtogs, new protocol executors and all of the other JP1 advanced constructs.

I also highly recommend my approach of building the IR sensor into the same DB25 (printer port) connector as the JP1 cable (but seperate ribbon or cable). Thus you can quickly alternate between uploading a JP1 configuration and seeing the signals it generates. You don't need to disconnect or reconnect anything.

I think this is so helpful that one of the vendors of JP1 cables ought to see the market opportunity of selling JP1 cable plus IR sensor combined. (Possibly it's worth waiting to see how hard/necessary that voltage doubler mentioned above is. I seem to not need it.)

bvwelch wrote: But also, I am interested in some of the building blocks. In particular, the java "wrappers" that have been written for the parallel port I/O and also for the DecodeIR DLL.

I know you all are in a hurry to continue develop on this project, but when you get a few minutes, please consider making the building blocks available separately.

They're pretty easy to get from the existing source distribution of Hal's package. I don't think it's worth the release overhead of distributing them seperately (at least until someone posts other interesting projects that use them).

bvwelch wrote: For example, the java "wrapper" for the DecodeIR DLL could be included with the DecodeIR DLL package itself.

I don't know when I'll have time, but the correct step there is to eliminate the C portion of that wrapper by making DecodeIr.dll itself directly callable from Java. Hal pointed me at the right terminology and documentation that I now know how to do that. But I need to find time.

I'm more interested in adding streaming support to DecodeIr and CapureIr. Again, I know how and just need to find the time.

I haven't had occasion after Hal got the major glitches out, to try this on my ordinary performance computer. I probably won't have occasion any time soon. This is really ready for a few more people to be testing and giving us feedback. On the high performance system with hyperthreading, CapturIr is incredibly robust and effective. On that system, it really doesn't need any improvements to do every job I've wanted it to do (and that's getting to be quite a bit).

johnsfine wrote:This is really ready for a few more people to be testing and giving us feedback.

I would recommend starting a new thread to announce the software, with ready links where people can download it, and links to the hardware too. This thread is already on it's 5th page, and it's quite techie, so I don't imagine alot of regular folks are still reading it.

Plus, in that thread describe what the software and hardware can do for people. If you have screen shots of it working, that would be even better.

Tommy Tyler wrote:I've done more testing related to the point John raised regarding minimum operating voltage for the IR probe. Apparently John was exactly right in his concern that we were operating below the manufacturer's spec. I finally found a combination laptop and probe that confirms that. The failure mode is kind of insidious in that it usually seems to result in an erratic signal rather than complete failure. There's no problem with desktop PCs that have 5V on their parallel port connector pin 1.

The quick fix is to...

My laptop happens to have a 5V parallel port, but this fixing info must be useful to many others.

bvwelch wrote:But also, I am interested in some of the building blocks. In particular, the java "wrappers" that have been written for the parallel port I/O and also for the DecodeIR DLL.

The DecodeIR.DLL part is pretty much as John explained, the best way is to merge the JNI entry points into the DLL itself rather than using a wrapper. Also, you can grab the DecodeIRCaller.java or .class, throw it in your Java program and the JNI part in CaptureIR.DLL should work as is.

You can reuse the capturing code easily as well.

The Robman wrote:I would recommend starting a new thread to announce the software, with ready links where people can download it, and links to the hardware too. This thread is already on it's 5th page, and it's quite techie, so I don't imagine alot of regular folks are still reading it.

I'll certainly open a new thread once I feel I'm ready. This isn't just quite ready for the general public yet. The failure rate is still a bit too high on a single processor system, and I'm not ready to hear the people screaming out because of lots of bad captures.

Also, I am getting busier these days and wouldn't be able to accommodate the feedback now.

Hal

I can't have the Sun Java JDK in the path environment variable at the system or user level.

I could easily wrap the invokation of make in a .bat file that sets local environment variables, but:

1) I first tried editing the Makefile to replace the two occurances of javac with ${JDKPATH}/bin/javac
That seems to work. Since the Makefile needs to be given JDKPATH anyway, isn't it more robust to depend just on JDKPATH and not PATH for that? Or is there something else here that requires ${JDKPATH}/bin to be in PATH anyway and I just haven't tried enough yet to hit that pitfall?

2) Are there any other environment variables the make should be wrapped with in a system where the correct version of JDK is merely present on the hard drive (no system nor user environment variable were nor can be set reflecting the installation of that JDK)?

johnsfine wrote:1) I first tried editing the Makefile to replace the two occurances of javac with ${JDKPATH}/bin/javac
That seems to work. Since the Makefile needs to be given JDKPATH anyway, isn't it more robust to depend just on JDKPATH and not PATH for that?

Good point. I'll do that, too.

Or is there something else here that requires ${JDKPATH}/bin to be in PATH anyway and I just haven't tried enough yet to hit that pitfall?

I doubt that it is really required for anything other than finding the JDK commands.

2) Are there any other environment variables the make should be wrapped with in a system where the correct version of JDK is merely present on the hard drive (no system nor user environment variable were nor can be set reflecting the installation of that JDK)?

Not that I'm aware of so far.

Thanks,
Hal

mtakahar wrote:The failure rate is still a bit too high on a single processor system, and I'm not ready to hear the people screaming out because of lots of bad captures.

I still haven't tried on a single processor. Probably this evening. But since you made that comment I decided I am more interested in tweaking your PPortReaderImp.c before other parts of your code.

It didn't build with my obsolete cygwin. So I installed MinGW. I am quite annoyed at how beginner vicious the MinGW FAQs and documentation are. When I tried MinGW long ago the install process set up a bunch of environment variables that I needed to clean out (to avoid breaking other tools). But at least that gave me a clue what I needed to do in the wrapper of any build using MinGW. The current version just installed the files and I couldn't find any hint of what you need to correctly wrap the build process.

I installed MinGW in C:/tools/mingw so minimally I wrapped the build with
set path=c:/tools/mingw/bin;%path%

Surpisingly that seems to be enough to get it to build what seems to be a usable version of your CaptureIR.dll (won't know for sure until I rebuild with interesting changes). I have no clue where the compiler is getting include files or the linker is getting lib files. I have four other C++ build environments installed here. I suspect MinGW is incorrectly using files from one of them rather than its own files. But I don't know if there will be unpleasant consequences.

BTW, your makefile uses javah and java as well as javac, so I modified those the same as I had javac.

mtakahar wrote:The failure rate is still a bit too high on a single processor system,

After tweaking your code and getting some disappointing results, I did some basic timing tests.

A single call to the porttalk routine inportb takes over 5 microseconds on my very fast computer. That makes the raw sampling process borderline unstable even without any interference from other threads.

I switched to using AllowIO instead (I switched to using your _inp inline asm instead of porttalk's inportb and in the .bat file for invoking the whole thing I switched to wrapping the java command line inside an AllowIO command line).

That made a massive difference and now there is plenty of margin for consistently sampling the 40Khz carrier I was testing. My current version on this computer should be stable up to 103Khz carrier (at 150Khz it would be unstable, but still better than the inportb version is at 40Khz).

We can get a decent decode even if the sampling of the carrier is unstable. But I don't see a good reason to throw away that much significant performance.

If we need to, it's only a minor inconvenience to run your program through that convoluted command line in a .bat file. Allowio doesn't respect the path, so that command line needs to be edited based on where things are in each install. But even that isn't so bad.

But if I understand correctly, we don't need to use the program Allowio (and convoluted command line) to get this performance benefit. The driver itself can be told to grant the current application the same direct port access that the Allowio program grants it. I've read that in the documentation and web pages of PortTalk, but I never understood exactly what you're supposed to do to achieve that. I'm sure it's simple, I just wasn't following the description.

This is all a micro level timing issue and will have barely any effect on the problems that occur due to running on a single logical CPU. However, I haven't tested on a single CPU system lately and I assume you haven't tested on multiple significantly different (from each other) systems. So some of what you think is failure due to single CPU may actually be failure from this cause.

johnsfine wrote:

mtakahar wrote:The failure rate is still a bit too high on a single processor system,

After tweaking your code and getting some disappointing results, I did some basic timing tests.

A single call to the porttalk routine inportb takes over 5 microseconds on my very fast computer. That makes the raw sampling process borderline unstable even without any interference from other threads.

I switched to using AllowIO instead (I switched to using your _inp inline asm instead of porttalk's inportb and in the .bat file for invoking the whole thing I switched to wrapping the java command line inside an AllowIO command line).

...

So some of what you think is failure due to single CPU may actually be failure from this cause.

Thanks for trying, John, but with allowio and bare in/out, it's showing only some minor improvements on my laptop. I think I tried this in very early stage, but yes, other places have some bugs, and I was forgetting to try it again. In my case, the blackout period seems to be as long as a few hundred microseconds, which seems to be confusing the decoder whenever it makes a gap a lot longer than it actually is.

I have a 2 cpu x HT = pseudo-4 cpu desktop machine at work, however, the problem is, it doesn't have a parallel port. A few other PCs I have are way too old and also don't have XP. (This actually makes me think the users who can actually benefit from this simple probe + CaptureIR would be somewhat limited.)

I'll look into the IOPM manipulation, and if I can't make it work, I'll just add allowio to the .bat file.

Hal

Tommy Tyler wrote:I've done more testing related to the point John raised regarding minimum operating voltage for the IR probe. Apparently John was exactly right in his concern that we were operating below the manufacturer's spec. I finally found a combination laptop and probe that confirms that. The failure mode is kind of insidious in that it usually seems to result in an erratic signal rather than complete failure.

I now have some very detailed capture data for the same signal and same IR sensor on two different computers.

After reliably eliminating any error contribution from CPU factors (CPU speed and inteference from other threads), I see some strange behavior of the apparent duty cycle of the signal.

On the fast conputer (dual CPU Xeon) I tested at only one distance and consistently saw a 2/3 duty cycle. (I spent some time trying to find a logic inversion error in my code because I expected a 1/3 duty cycle).

On the slow computer (single CPU P4) I tested two distances. At about 3 feet I consistently saw a 1/10 duty cycle and at about .5 feet I consistently saw a 1/2 duty cycle.

I need to investigate the duty cycle more carefully later, varying the protocol that generates the signal as well as the capture process to confirm the meaning of what I'm seeing. But many more important tasks are ahead of that in my Queue.

Meanwhile I'll assume the true duty cycle is 1/3 so something strange is happening to explain the results I'm getting. I hope Tommy or one of the other hardware experts can explain how much of this is due to operating the part below voltage spec.

The behavior indicates that both edges of the signal are being delayed and the delay acts differently on the active vs. inactive edges of the signal.

I didn't follow the levels of inversion in either the printer port spec or the sensor spec. In the open collector part, is the active state (seeing IR) the ground state or the high impedence state of the output pin?

Excuse my lack of EE expertise, but I believe the edge delays must be due to capacitence on that input to the printer port. Maybe I did something wrong and there is much more than there should be. But more likely the capacitence is very tiny and so delays of several microseconds imply the currents charging or discharging the capacitence are much less that I'd expect.

To see a 2/3 duty cycle where reality is 1/3 we must delay the inactive edge by 8 uS more than however long we delay the active edge.

To see a 1/10 duty cycle, we must delay the active edge by 6 uS more than we delay the inactive edge.

To see a 1/2 duty cycle on the same computer as the 1/10 we are delaying the inactive edge by 4 uS more than the active.

Given enough capacitence relative to current, I certainly see how greater distance increases the active edge delay. But unless there is a serious ramp on the sending side I don't see how greater distance decreases the delay of the inactive edge. Expert comment on that?

So the inactive edge delay on that computer must be well over 4uS and so at greater distance the active edge delay must be well over 12 uS. But for simple capacitive delays it makes no sense to talk about delaying an active edge more than the entire pulse duration. So clearly I'm missing something significant.

Expert comment please?