JP1 Remotes

Is anyone out there using the 3-transistor JP1.2/JP1.3 hardware interface design (either self-built or purchased) with a JP1.2 remote control (especially with the URC-8820, URC-10820, or similar model)?

I've now built and successfully tested both of the designs shown in Tommy Tyler's excellent 'Building a Serial Interface for JP1.2 and JP1.3.pdf' document. For those not familiar with the document, it shows 2 schematics, one using 3 common NPN transistors (e.g. 2N3904) and the other using a less-common quad-XNOR 14-pin DIP integrated circuit (part number 74HC266).

Tests were done using the 'jp12test.exe' utility (with version 0.13 of the 'jp12serial.dll' library) under Win98se with the interfaces connected directly to the PC's RS-232 port (i.e. no USB/RS-232 adapter was used).

Tests were also done with a test utility that I've written (but not yet publicly released) which provides some more user feedback on the process of putting a remote control into "serial communication" mode.

Both of the interface designs work flawlessly with my Radio Shack 15-135 (JP1.3) remote control, with both of the aforementioned test utilities.

The discrepancy I'm seeing between the operation of the 2 hardware interface designs comes into play when I attach my URC-8820 (JP1.2) remote control....

With the quad-XNOR interface, the URC-8820 generally works fine, going into serial communication mode without problems, with both of the aforementioned test utilities.

With the 3-transistor interface, the URC-8820 seems to somehow accumulate lots of "garbage" data internally in the read queue, which must be flushed, lest that garbage "prefix" data prevent the ASCII 'ACK' (0x06, 'acknowledge') byte from being detected when processing the remote control's reply to the 'ping' command to test if the remote has successfully entered the "serial communication" mode. This "garbage" data is usually nothing but a series of bytes that are mostly zero (0x00).

In layman's terms, this means that the 'jp12test' utility fails to detect the JP1.2 remote, reporting the standard "**** No JP1.2 compatible remote found! ****" error. My own utility also initially fails to detect the remote quite often. It shows that there is often a large amount (more than 200 bytes, sometimes as much as 2500+ bytes) of garbage data in the read queue that has to be flushed before the remote can be successfully 'pinged'.

Since my utility (currently) attempts to flush only 1000 bytes before doing the 'ping' test, it sometimes succeeds with the URC-8820 remote on the first try (i.e. if there are 1000 or fewer bytes of garbage data from the remote) and when it fails, it can be made to work by repeatedly attempting to put the remote into "serial comm" mode, since each attempt flushes another 1000 bytes.

The 'jp12serial.dll' code, in contrast, only flushes 20 bytes in the same situation. With the URC-8820 and the 3-transistor interface, it therefore seems to always fail.

Now, to be clear, the remote does appear to be entering serial communication mode, but the utilities think it hasn't because of all the leading garbage preceding the ASCII 'ACK' byte.

I'm not 100% certain at this point, but it seems like it's such that the more often the remote control is commanded to "normal operating mode" (as is done at the end of both of the test utilities mentioned and can be done independently [and therefore repeatedly, for testing] with my test utility), the more garbage there is to be found in the JP1.2 remote's queue.

I don't understand the discrepancy in behavior between these two JP1.x hardware interfaces. Furthermore, I'd expect that some other folks who've built the 3-transistor interface and are using it with a JP1.2 remote control would've also encountered problems with any application ('IR.exe' or 'RMIR') using that 0.13 version of 'jp12serial.dll'. It could be that this problem is specific to the URC-8820 (and its close brethren, like the URC-10820, which I also own and which succeeds/fails just like the URC-8820), but that wouldn't be my assumption just yet.

Of course, I won't rule out some sort of error in my hardware assemblies, but since the RS 15-135 JP1.3 remote works flawlessly on both interfaces and the JP1.2 remotes work flawlessly on the quad-XNOR interface, it isn't my first assumption at this point.

Does anyone have any insight on this? Thanks in advance for any guidance, suggestions, or comments....

Regards,
Bill

Bill,

I'm not sure I want to get into this can of worms. But why don't you let me try to reproduce your failure mode. Tell me exactly what to do to try that.

Tommy

First, please respond to Tommy as he suggested, since he is in the best position to trubleshoot this problem.

A little historical perspective on the JP1.x flash interfaces might help, though. Most of the early work on these interfaces was done on a URC-8820 or URC-10820 (firmware is identical in both). At that time, we were still experimenting and learning about the "serial comm" mode, so it's possible there were some incorrect assumptions made that still exist in the library code.

The remote does not have a queue per se. When it comes out of reset and into serial comm mode, it does nothing until it receives a command. If "garbage" data is appearing, then the remote must have received a command requesting that data. I guess the question is if the library code is doing something that interacts with the transistor interface that causes one or more unintentional false commands to be sent to the remote. Bear in mind that the serial comm mode in the remote is implemented in firmware (bit-banged), so I'm not sure how robust it might be in rejecting marginal signals.

Doing a reset would halt any output from the remote, but of course the PC has probably buffered lots of bytes already.

Tommy Tyler wrote:I'm not sure I want to get into this can of worms.

No problem, I understand. In and of themselves, your well-documented hardware interface designs and timing diagrams have already been incredibly useful to me in understanding the hardware (especially the history and evolution) and therefore equally helpful in addressing the serial library code update that I've been working on, and I completely understand that you might not want to get into everyone's individual problems.

Having said that, in this case, I could be wrong, but I think the problem is broader than just my hardware, so any words of wisdom you can provide are greatly appreciated.

I just did these tests again, using the 'jp1xtest.exe' from your own 'TestGroup.ZIP' file distribution, still under Win98se and still with a direct RS-232 connection to the PC.

Tommy Tyler wrote:But why don't you let me try to reproduce your failure mode. Tell me exactly what to do to try that.

OK. Basically, assuming you have access to hardware using both of the designs in question , you'd run these tests (but read some updated info below before you do, please):

• Run 'jp1xtest' on a JP1.3 remote control (like my RS 15-135) using the 3-transistor interface. My RS 15-135 passes this test.
• Run 'jp1xtest' on the JP1.3 remote control using the quad-XNOR interface. My RS 15-135 also passes this test.
• Run 'jp1xtest' on a JP1.2 remote control (like my URC-8820) using the quad-XNOR interface. My URC-8820 passes this test.
• Run 'jp1xtest' on the JP1.2 remote control using the 3-transistor interface. My URC-8820 fails this test.

Hmmm.... In an attempt to be thorough, I just re-ran the same tests described above under WinXP-SP2. I hadn't used WinXP yesterday because that machine has no RS-232 port and I didn't want to introduce the complication of adding a USB/RS-232 adapter. But, of course, to re-run the tests today, I added an IoGear GUC232A adapter.

What I found is that under WinXP-SP2, all of the above 4 test cases pass! Aha! Interestingly, using my utility, I can see that there is still some garbage in the read queue in the case of the JP1.2 remote attached to the 3-transistor interface, but it seems to be just a few 'zero' bytes, which are successfully consumed in the (undocumented) 20-byte read flush done by the library code. On the other hand, the JP1.3 remote on the 3-transistor interface never shows any garbage data (i.e. under W98se or WinXP-SP2).

By the way, something I forgot to mention yesterday in my first post.... There is some evidence that I'm not the only one seeing this problem. VickyG seems to clearly have the interface described in your other document titled "A Serial Interface for JP1.1 Flash Remotes". That 4-transistor, DTR-controls-reset interface seems to behave similarly with her JP1.2 Atlas (specific model unspecified) remote. In other words, there is direct evidence that there's garbage in the read queue that has to be flushed in her case too. I don't know if it's a little bit of garbage (20 bytes or less) or a lot, since I haven't seen any of her logs from the latest version of my test utility. As far as I know, she's running Windows 2000 Professional, but that might have changed. Vicky, if you're following this, please jump in. And maybe even post a log showing the line about "Pre-sercom-mode-test buffer flush of nnn bytes." and some surrounding context lines too, if that's not too big of a bother.

Based on this new discovery that the problem seems to somehow also be related to the operating system used, I'll have to do some more thinking about this and probably some more testing (including under Linux+Wine since that's the only other operating system I have to test with!). Therefore, I understand if you don't want to test any of this (now or ever), Tommy. However, it seems like there's something just different enough about those 2 interface designs that presents the issue, so if you have any ideas or comments, I'd be "all ears". Thanks!

I'll probably just modify the preliminary library code to flush the buffer of however many "garbage" bytes exist, even if it's in the "many thousands of bytes" range. That way, the new code should work with Win98se and JP1.2 remotes using the 3-transistor (and 4-transistor) interfaces, which seem to be the (only?) real problem case(s), as far as I can tell right now.

Regards,
Bill

mr_d_p_gumby wrote:First, please respond to Tommy as he suggested, since he is in the best position to trubleshoot this problem.

Done... see above. For the record, I don't want to put any more effort on him than absolutely necessary. Basically, I just hope that he can supply his wisdom and experience to correct anything I might be overlooking. I'll be happy to do all of the testing, but my Microsoft OSes are limited to W98se and WinXP-SP2, so I could benefit from some testers with the necessary hardware (3-transistor interface) and Vista or Windows 2000 or even Windows 7.

mr_d_p_gumby wrote:At that time, we were still experimenting and learning about the "serial comm" mode, so it's possible there were some incorrect assumptions made that still exist in the library code.

Agreed... a very reasonable possibility. I'm wondering if I may, in fact, be one of the few people running this exact problematic combination (Win98, 3-transistor interface, JP1.2 remote), which would explain why nobody (to my knowledge) has both encountered this before and mentioned it here.

mr_d_p_gumby wrote:The remote does not have a queue per se. When it comes out of reset and into serial comm mode, it does nothing until it receives a command. If "garbage" data is appearing, then the remote must have received a command requesting that data.

Good to know, thanks. I'll have to adjust my terminology accordingly. Also, I think I'll need to investigate the process of "resetting" (i.e. to "normal operation" mode) a bit more since that seemed to predictably aggravate the problem. Of course, I could just do as suggested in my reply to Tommy and flush the buffer, regardless of the amount of garbage, and I may wind up doing that regardless, but I'd like to better understand just what's going on here.

Mike, many thanks for your very useful inputs. Based on what I found and described in my reply to Tommy, I think I'll need to do some more testing and thinking about all this. Unfortunately, that will take time. I'll probably have to write some test code and/or modify my test application to explore what's really going on here.

Regards,
Bill

I couldn't find a transistor serial (flash) interface so I quickly breadboarded one per the latest schematic revised 10 February 2009. It ran both jp1xtest and IR fine on my XP Pro/SP3 Pentium4, so I hauled out an old Win98, dusted it off, and luckily it still fired up. The interface worked just fine using both jp1xtest and IR under Win98. It also passed a loopback test.

I don't really understand the garbage theory or how there could be data in a transmit buffer that didn't originate from IR, and I can assure you it didn't. I'm afraid I can't be of much help.

Tommy Tyler wrote:I couldn't find a transistor serial (flash) interface so I quickly breadboarded one per the latest schematic revised 10 February 2009. It ran both jp1xtest and IR fine on my XP Pro/SP3 Pentium4, so I hauled out an old Win98, dusted it off, and luckily it still fired up. The interface worked just fine using both jp1xtest and IR under Win98. It also passed a loopback test.

OK, that's an excellent data point. Thanks for providing that.

For the record, both my 3-transistor and quad-XNOR interface lash-ups (bread-boarded [for now] and nicely wire-wrapped, respectively) were using the "10 February 2009" schematic version too. (I didn't even hear about these JP1 remotes until March 2009! )

Tommy Tyler wrote:I don't really understand the garbage theory or how there could be data in a transmit buffer that didn't originate from IR, and I can assure you it didn't.

I don't understand it either, but it's clearly there. VickyG has seen it too because her problem disappeared when I sent her new software that flushed the bad data with a read before the 'E' (ping/echo) test of the remote's serial comm mode status.

There's something odd going on here and I'll try to get to the bottom of it somehow.

Tommy Tyler wrote:I'm afraid I can't be of much help.

Well, the fact that you've seen it succeed under similar circumstances which mine failed tells me a lot just by itself.

Just to be sure, what JP1.2 remote control model did you test with? I suppose if it wasn't a URC-8820 or one of its close brothers, that could explain the difference, but I'm not counting on that.

I'll do more testing and report back here.

Thanks for the help, Tommy. And sorry for the distraction. I didn't mean to send you on a "wild goose chase"!

Regards,
Bill

I should have mentioned that I first tested with a 1056B01 JP1.3 and then I reread your post and went back and tested with a URC-10820 JP1.2 because I didn't think I had an 8820. But I just now looked and I do have one, so I retested with that. It also works just fine with both jp1xtest and IR.

I'm not sure what it would look like if I duplicated your failure. I assume jp1xtest would just say no JP1.X compatible remote found because the garbage blocks the ACK character? How do you see the garbage? I haven't tried your JPFST yet. Is that what you use to see it?

Bill, I'm beginning to smell a rat. I plugged the 3-transistor interface into COM1 with a URC-10820 JP1.2 remote and ran your JPFST program. Here's what I got:
http://img91.imageshack.us/img91/9241/j ... enshot.jpg
It says it received 1000 bytes of "00"s and that it failed to put the remote into serial com mode, but that's not possible.

Without unplugging anything, I exited JPFST and immediately ran jp1xtest and it found the remote with no problem.

I don't mean this to sound critical or smart assed, but are you totally dependent on your own software to provide evidence of the garbage? (Not counting Vicky, of course.) Perhaps I just don't know how to run JPFST yet.

Tommy Tyler wrote:I should have mentioned that I first tested with a 1056B01 JP1.3 and then I reread your post and went back and tested with a URC-10820 JP1.2 because I didn't think I had an 8820. But I just now looked and I do have one, so I retested with that. It also works just fine with both jp1xtest and IR.

I've just run all 12 permutations (2 interfaces, 2 remotes [JP1.2 and JP1.3], and 3 OSes [on 3 different PCs]). Although I have some more tests to run, I'm starting to see somewhat of a pattern.

What I can say with good certainty is that my RS-15-135 (JP1.3) remote does not exhibit any garbage/"phantom" data problem at all, in any of its 6 permutations. It's only the URC-8820 (JP1.2) remote that exhibits this problem.

Tommy Tyler wrote:I'm not sure what it would look like if I duplicated your failure. I assume jp1xtest would just say no JP1.X compatible remote found because the garbage blocks the ACK character?

That's exactly right.

Tommy Tyler wrote:How do you see the garbage?

Well, that's part of the problem. You can't see the garbage when you're running 'jp12test'/'jp1xtest' or similar utilities -- they just don't (actually, the library code they call doesn't) annunciate it, by design. And here's the important part: As long as the garbage data is 20 bytes or less, which seems to happen quite often in my permutations testing, you'll never have any indication that it's even there. That's because the library code silently "sucks up" up to 20 bytes of "phantom" data by doing the "read flush". Someone had to have put that code in place for a reason, but unfortunately there's no comment to indicate why. In fact, I thought it was superfluous and left it out of my 1st version of JPFST... until my URC-8820 (my 1st-ever JP1.2) remote arrived in the mail and it wouldn't work without the read flush, which took me a while to figure out!

The other side of this problem is that if someone ever gets more than 20 bytes of this "phantom" data, the call to "open" (i.e. initialize in serial comm mode) the remote will fail (as seen by the 'IR.exe' and RMIR utilities), even though the remote may very well be in serial comm mode.

Tommy Tyler wrote:I haven't tried your JPFST yet. Is that what you use to see it?

Yes.... Until I hack up a modified version of the library (a quick job, I just need a minute to do it) to report the number of flushed bytes, JPFST is the only way to see what's going on at that level.

Tommy Tyler wrote:Bill, I'm beginning to smell a rat. I plugged the 3-transistor interface into COM1 with a URC-10820 JP1.2 remote and ran your JPFST program. Here's what I got:
http://img91.imageshack.us/img91/9241/j ... enshot.jpg
It says it received 1000 bytes of "00"s and that it failed to put the remote into serial com mode, but that's not possible.

Without unplugging anything, I exited JPFST and immediately ran jp1xtest and it found the remote with no problem.

I apologize if it appears like I'm running you into a box canyon, Tommy. I wouldn't waste anyone's time with this if I didn't think it was important. There's something odd here for sure. It may be my hardware (interface or PC) or it may be OS-related. I just cannot tell for sure yet.

I've seen the "1000 zeroes" happen consistently when I forget to connect the proper cable to the remote and/or PC. It happens sometimes when switching from 1 remote to another and/or 1 PC to another. Clearly that's not what happened in your case, so I cannot immediately explain what you're seeing.

One thing to try when that happens: activate the "Put Remote Into 'Serial Comm' Mode" pushbutton (with a suitable delay in between each press, of course) a few more times. You'll very likely see what I do -- that the garbage is eventually flushed out and there are one or more 0x06 'ACK' bytes at the end of the last flush which is less than 1000 bytes. The next activation of the "Put Remote Into 'Serial Comm' Mode" pushbutton should then succeed because all the garbage has been flushed.

Tommy Tyler wrote:I don't mean this to sound critical or smart assed

That's OK, I have reasonably thick skin.

Tommy Tyler wrote:but are you totally dependent on your own software to provide evidence of the garbage?

Not totally. I've used 'jp12test'/'jp1xtest' too, but since it doesn't report the details, I'm forced to assume (that is, until I hack a test version as described earlier) that a failure to detect the remote is for the same reason that JPFST fails to detect it -- leading garbage on the ping test. It's actually been rather consistent, but I don't want to assume forever -- I just haven't had time to test that and I wouldn't even be posting now except for the fact that I wanted to reply to your comments.

Tommy Tyler wrote:Perhaps I just don't know how to run JPFST yet.

Now it's my turn to say that this is not intended to sound smart-alecky... but it is a possibility that you're not using JPFST correctly -- it's hard for me to be sure. Did you read the "Help" dialog? I think you did the right thing, but it would be better if you posted or emailed me your full log file from JPFST.

I really appreciate your input on this, Tommy. I was hoping to avoid wasting any more of your time (or anyone else's) by doing an exhaustive set of tests before posting again, but I didn't have time to do it all and I didn't want to leave you wondering.

I should have more to report on this, hopefully by Friday evening or night.

Thanks again!

Bill

There is some evidence that I'm not the only one seeing this problem. VickyG seems to clearly have the interface described in your other document titled "A Serial Interface for JP1.1 Flash Remotes".

I have no idea what interface I have, but I'd guess I have the JP1.x. I bought it specifically to work with JP1.2 remotes. This cable has never given me a "problem" other than I can sometimes get my remote to not work with the jfpst software. IR, has always been able to handle this remote, except for one small window about 2 years ago when Binky made a change to IR or the DLL. Since that change was corrected I don't have any problems.

As far as I know, she's running Windows 2000 Professional, but that might have changed.

I don't have a broken log. I had cleared everything in hopes of being able to get a clearer picure of what I'm doing to get the remote to lockup, because whatever I'm doing it seems to be random. When I'm being careful, I can't seem to get it into the problem state.

I apologize if it appears like I'm running you into a box canyon, Tommy. I wouldn't waste anyone's time with this if I didn't think it was important. I was hoping to avoid wasting any more of your time

No need to apologize. I wouldn't be messing with this if I didn't see an oportunity to learn something.

Things are not going so well today. I can't get the 8820 to fail with JPFST. I get mostly 2-byte flushes, some 1-byte and 4-byte, but nothing anywhere close to 20. I was planning to open another comm utility (like HyperTerminal or Comtest) and manually send the ping to see if there was junk in the buffer. But I'm discouraged from doing that if I can't reproduce the "1000 bytes" failure I had yesterday.

Here are a few random observations: Each time I download and SAVE jpfst.exe, when I try to run it I get an error message that says jpfst.exe is not a valid Win32 application. But if I run the download directly instead of saving it there's no problem!!

My 8820 keyboard is locked up as long as my interface is plugged in. We've always tried to avoid that with interface designs so that you don't have to keep unplugging the remote to try it. I haven't found the reason yet, but it has nothing to do with your software.

it would be better if you posted or emailed me your full log file from JPFST.

How do you do that? I saw Vicky's log and was envious.

My 8820 keyboard is locked up as long as my interface is plugged in.

I sure am glad that's not true in my case. I upload from IR point and shoot at my widget and get my results with no hassle. That really made my protocol studies easier. I can't say the same for my Atlas 3000. For some reason after my interface has been connected to IR, none of my signals will Repeat until I disconnect from the interface and REMOVE THE BATTERIES! Not that I'd ever notice, since I turn off repeating on all of my devices, but when I'm testing that's a real pain.

that's not true in my case

Bless you, Vicky. I think you have an older interface where the resistor between pin 6 and the Rx driver transistor was 100K. I think I dropped it to 4.7K to make all the resistors the same. It doesn't affect it's working with IR, but it does seem to hold the receive data pin low and disable the remote (at least a 3-volt remote like the 8820. I'm posting a correction to the schematic in the files.

Bill, can you please change R3 in your breadboard from 4.7K to 100K and see if that improves your situation. In my case, it not only made my 8820 operable when connected to the interface, it also allowed me to download JPFST and run it from a saved file. It also cured my wife's sinus, and delayed the rain that was forecast for today. Now if only it will do something for that idiot in the Whitehouse.

vickyg2003 wrote:I have no idea what interface I have, but I'd guess I have the JP1.x.

Well, from your JPFST/JP1xTest report in the other thread, we know that it's a DTR-controls-reset interface because that was auto-detected. And based on your report that it works fine with a JP1.1, 1.2, and 1.3 remote, it's almost certainly the one Tommy designed and documented as "A Serial Interface for JP1.1 Flash Remotes" or a very close cousin. You said that you bought it from Rob, and, IIRC, Rob was selling Tommy's interfaces at one point, so maybe Tommy knows for sure.

vickyg2003 wrote:I don't have a broken log. I had cleared everything in hopes of being able to get a clearer picure of what I'm doing to get the remote to lockup,

Thanks for filling me in, Vicky. I'm not sure what "cleared everything" means, but in case anyone is unaware, the 'jpfst.log' file is continually added to with each session, logging everything as long as you have the "Log To File" option enabled. (Hitting the 'Clear Log Display' pushbutton just clears the log display -- it doesn't affect the log file.) Unless you rename or delete that file, it will grow larger and larger over time. In fact, now that I'm starting to use the log files from users, I've realized that it would make sense for me to update the code to prefix the current date to the timestamp in the log file, so that it's easier to distinguish (for me and for the user) which log text applies to which JPFST/JP1xTest session.

And now on to Tommy's post....

Tommy Tyler wrote:I wouldn't be messing with this if I didn't see an oportunity to learn something.

That's a great attitude, one which I highly respect. I feel the same way.

Tommy Tyler wrote:Things are not going so well today. I can't get the 8820 to fail with JPFST. I get mostly 2-byte flushes, some 1-byte and 4-byte, but nothing anywhere close to 20.

OK, well that's still good to know because it means you can now see some of what I've been seeing and what Vicky has undoubtedly been seeing too, with our JP1.2 remotes. I still am not sure if this is peculiar/specific to the URC-8820 and family or if it's a more general, all-JP1.2-remotes issue.

Tommy Tyler wrote:I was planning to open another comm utility (like HyperTerminal or Comtest) and manually send the ping to see if there was junk in the buffer. But I'm discouraged from doing that if I can't reproduce the "1000 bytes" failure I had yesterday.

That's actually a great idea that I'm surprised I hadn't thought of. For someone like you and I who know how the remotes communicate over the serial interface, seeing garbage data with a terminal program like those would be convincing evidence and would help rule out the JP1 apps as a source of the problem. After I've done my other tests, I'll try that too.

Tommy Tyler wrote:Here are a few random observations: Each time I download and SAVE jpfst.exe, when I try to run it I get an error message that says jpfst.exe is not a valid Win32 application. But if I run the download directly instead of saving it there's no problem!!

I don't quite understand this part. Is this error message coming from Windows? Regardless of that answer, is this happening under Win98? WinXP? Both? This may be my ignorance of Windows specifics showing, but I don't understand how you can "run the download directly". Either way, could this be some sort of "administrator" privilege issue? Sorry I cannot be more helpful, but none of my PCs with a Windows partition are "Internet-facing" (i.e. ever connected to the Internet), so I can't try to duplicate this. I compile the JPFST/JP1xTest code under a Borland C compiler but I could (and have planned to eventually anyway) make it compile under the free MinGW compiler, but I don't expect you to have to bother with any of that. I wish I could provide more info. If you can give me the exact wording of the error message, or even a screen capture if that's not too much bother, I'll try to search the Internet to figure out what's wrong. I've never encountered such an error before, but I run Linux full-time now, so my Windows expertise is eroding.

Tommy Tyler wrote:My 8820 keyboard is locked up as long as my interface is plugged in. We've always tried to avoid that with interface designs so that you don't have to keep unplugging the remote to try it.

I'm glad you mentioned this. For the 1st time yesterday (since I made a JP1 cable long enough to actually point the remote at the TV without dragging the still-connected interface along with it ), I actually tried to use the remote while it was connected to the interface. (I forgot whether it was the 3-transistor or the quad-XNOR, but it may not even matter.) Like you, I found that it wouldn't work as a normal remote control, even after being reset to "Normal" operating mode, as long as the JP1 cable is connected to the remote. I was somewhat surprised by this but didn't give it any more thought at the time.

Tommy Tyler wrote:I haven't found the reason yet, but it has nothing to do with your software.

Vicky's recent report that her URC-8820 works with the cable connected makes me wonder if it has to do with the fact that she has a DTR-controls-reset interface and we're testing with the RTS-controls-reset interface. I haven't taken a minute to think if that makes sense, but it's one obvious difference between her setup and ours.

Tommy Tyler wrote:

WagonMaster wrote:it would be better if you posted or emailed me your full log file from JPFST.

How do you do that?

Well, if you want to email it, just find the 'jpfst.log' file (in the same directory where you run 'jpfst.exe' from -- oh, wait -- that doesn't work for you, if I understood your comment above)... Hmmm... If you're running JPFST from "the download directly", that log file must be created somewhere on your PC, probably in the current directory. If you can find that file (which is a simple ASCII text file), just attach it to an email and send it to me at the email address I PMed you yesterday. If you want to post it in the forum, just highlight, copy, and paste either directly from JPFST's log window or open the 'jpfst.log' file with an editor like Notepad and do it that way. Please holler if I haven't made this clear. The whole reason I added the log file capability to JPFST was to make it easier for users to report the data, without having to depend on their memory and transcriptions of the results.

I'm still planning on doing more testing and hope to report more later tonight.

Thanks to all for your inputs. I feel we're on the road to understanding this better....

Regards,
Bill