JP1 Remotes

Tommy Tyler wrote:Bill, can you please change R3 in your breadboard from 4.7K to 100K and see if that improves your situation.

Gladly! I will do that later today and report back. Glad I hadn't wire-wrapped (and soldered) that interface yet!

(My previous post was attempted just as the forum seemed to have crashed, so I hadn't seen this post of yours, Tommy, before I posted that previous reply. So if what I wrote seems anachronistic in any way, that's why. In fact, I didn't even know that my post had made it out before the crash until just now.)

Tommy Tyler wrote:... it also allowed me to download JPFST and run it from a saved file.

Assuming this part was serious, I'm still befuddled by that whole thing. Clarifcations welcome but not required.

Bill

Tommy Tyler wrote:I'm posting a correction to the schematic in the files.

I never noticed this before, but there are 2 resistors labeled "R3". I know you mean to replace the one between JP1 pin 6 and the base of transistor Q3, but while you're editing the schematic, you might want to label one of those "R6".

Bill

OK, I've modifed and tested my bread-boarded, 3-transistor, JP1.2/3 interface and I'm happy to report that replacing the 4.7k-ohm resistor between JP1 pin 6 and the base of transistor Q3 with a 100k-ohm resistor does nicely allow the use of the URC-8820 remote control (assuming it's been put back in normal operating mode and isn't in "serial comm" mode) to control the various devices (TV, stereo, etc) with the JP1 cable still attached.

Thank you, Vicky and Tommy. That's one less thing on my "that's odd -- look into that" list.

(I'm still looking into the issue of excess garbage data on the read flush. More to report later, hopefully.)

Bill

The issue of failing to allow running a saved copy of jpfst.exe seems to have gone away, and I suggest we chalk it up to an anomoly of my computer. AVG has been exerting itself annoyingly lately ever since I upgraded to the new version 8.5, and possibly it was the culprit. But I did have the presence of mind to capture a screen shot of the error message HERE when the problem occurred three or four times. And of course without that problem I now have a log file, but I can't get anything to fail and have no interesting logs to send you.

Tommy Tyler wrote:The issue of failing to allow running a saved copy of jpfst.exe seems to have gone away, and I suggest we chalk it up to an anomoly of my computer.

Sounds logical to me. Thanks for the update and the screen capture.

Tommy Tyler wrote:And of course without that problem I now have a log file, but I can't get anything to fail and have no interesting logs to send you.

No problem. At least the mechanism is in place if there's any future problems.

Bill

OK, I've finally done all of the testing to see if I could characterize this "garbage data needing to be flushed" problem.

I've run tests on 17 significant permutations of the following variables: remote control type (URC-8820 [JP1.2] and Radio Shack 15-135 [JP1.3]), interface type (3-transistor and quad-XNOR, both RTS-controls-reset types, both built from Tommy Tyler's current schematics), operating system (Win98se, WinXP, Linux+Wine, and Linux without Wine), and PC (a Toshiba Satellite 2100CDT laptop, a Toshiba Tecra laptop, and a self-built desktop PC with an Asus A7V400-MX motherboard).

With the exception of the 'Linux without Wine' test cases, all of the other tests were done with my JPFST/JP1xTest utility, which conveniently displays the flushed bytes (explained below) and the count.

I'll try to condense all these test case results into something easily digestible, but first a couple of clarifications and summaries....

This problem manifests itself as "phantom"/"garbage" data that precedes the expected ASCII 'ACK' (0x06) single-byte reply to a query sent to the remote control (a simple transmission of the single ASCII character 'E'). That query is usually sent after commanding the remote control to the "serial comm" mode as a test to see if it actually entered serial comm mode (i.e. as opposed to still being in the normal operating mode or some other "special", undesired mode like Background Debug Mode [JP1.2] or Tool/I2C mode [JP1.3]).

It's not clear where this data is coming from, but it's definitely there in some cases. I've seen it, Tommy has seen it, and Vicky's test results imply that she has encountered it too.

The current JP1.x RS-232/serial library code ('jp12serial.dll') silently consumes up to 20 bytes of this "phantom" data, leaving users unaware that it's even present. This is not necessarily a problem; I'm just stating the facts here.

Now for some interpretations and explanations of the results....

Most of the permutations I've tested show either no phantom data at all or very few bytes of phantom data -- so few (20 or fewer) that they'd simply be consumed by the "read flush" in the current library code, making the test for achieving serial comm mode succeed.

In fact, the RS 15-135 (JP1.3) remote never once had any phantom data appear in the 8 permutations that it was tested with. I don't know if this applies to all JP1.3 remotes since I have only the one. I suspect it applies to all.

In virtually all cases where the remote reports more than 20 bytes of phantom data, it actually does successfully enter the serial comm mode, but the phantom data precedes the remote's 'ACK' reply, fooling the library code into thinking it has failed to enter serial comm mode!

I also observed that repeated successive commands to put the remote control in normal operation mode (what many refer to as a "reset") seems to aggravate the problem, causing more and more phantom data to appear the next time the test for serial comm mode is attempted. Now, admittedly, commanding the remote to normal mode via a reset multiple times in a row is not something that's normally done. I've done it and I'm reporting about it because it seems to help characterize the problem and because it seems somewhat consistent. In fact, doing such a thing isn't practical without a new utility like the one I'm using or some similar test utility.

Four of the (17 total) permutations I tested involved the use of the URC-8820 (JP1.2) with the quad-XNOR interface, on various PCs and operating systems. The one done on my desktop PC (running Wine under Linux [Slackware 12.1]) showed no evidence of phantom data. The other 3 permutations (all done on the 2 laptops mentioned earlier, using either WinXP, Win98se, or Linux without Wine) all showed evidence of small (almost always fewer than 20 bytes) amounts of phantom data.

The remaining 5 permutations tested all involve the URC-8820 remote on the 3-transistor interface. These are the "interesting" cases....

Two of those five permutations (done on the desktop PC [Linux+Wine] and the Toshiba Tecra laptop [WinXP]) result in an insignificant number of phantom data bytes -- always so few that the 20-byte flush in the library code easily consumes them.

The remaining 3 of those 5 permutations all involve the Toshiba Satellite laptop. This is an older but still fully functional laptop, running Linux (Slackware 10.2) (primarily) and Win98se. One of these 3 permutations involves running that very old version of Linux (Slackware 10.2) and the results are completely uncharacteristic. In fact, the remote is virtually uncontrollable with that setup, so I'm throwing out that data point for the moment, because I think a newer version of Linux would generate completely different results. I really only tested that case because I was trying to distinguish between symptoms that were the result of the PC hardware and those that were the result of the operating system. And I've pretty much convinced myself that the operating system used isn't playing a role in this overall problem.

The 2nd of the 3 (of the 5, of the 17) cases is the one that really started this whole investigation. It involves running Win98se on the Toshiba Satellite laptop with the 3-transistor interface connected to the URC-8820 (JP1.2) remote. This is the setup that mysteriously can generate several hundred (and often several thousand) bytes of phantom data! Obviously this overwhelms the 20-byte read flush done in the library code, causing the serial comm test to fail. This has been very consistent, as long as that precise hardware combination (PC, remote, and JP1.x interface type) is used.

Although in a post of mine much earlier in this thread I had implied that the operating system (Win98se versus WinXP) had an impact, my recent, more thorough testing results made me start to believe that this phantom data problem is in part due somehow to the PC's RS-232 hardware.

This Toshiba Satellite laptop has a 9-pin RS-232/serial port, so I generally use it for JP1 tests. However, today I decided to try using my IoGear GUC232A USB/RS-232 adapter on that problematic combination of hardware. Interestingly, but maybe not surprisingly (given my correlations above), I found that that hardware combination went from hundreds/thousands of phantom data bytes down to just a few (2 usually, more if back-to-back resets to normal mode are used), like some of the other test cases, as long as that USB/RS-232 adapter was in place! OK, this is excellent news. Not a solution, but maybe a very practical work-around! And I think this helps confirm that the problem is related to the RS-232 port hardware, at least in part. I guess it could still be related to the drivers, but I don't have a way to easily rule that in or out.

I should also mention that the Toshiba Tecra has no RS-232 port, so all tests done there use the IoGear GUC232A USB/RS-232 adapter.

I've suspected for a while now that the differences in RS-232 hardware might somehow have a hand in this saga. Therefore, last night, I decided to measure voltages on the various PCs' RS-232 pins, as I toggled DTR, RTS, and UART 'break' (which affects the RS-232 'Tx' line, as most UART/RS-232 gurus already know). What I found didn't result in anything conclusive, but I'll publish the results here for reference. I'll only publish the positive voltages, although the pin voltages obviously swing to a similar amplitude with opposite polarity as the modem control lines are manipulated:

• Toshiba Satellite: +9.2V
• Toshiba Tecra: +9.5V
• Asus A7V400-MX motherboard: +11.1V

All of those voltage are within the RS-232 specification, so that really sheds little light.

Conclusion: OK, for anyone still with me , you're probably asking, "What's the conclusion?". I'm convinced that some combination of that laptop PC's RS-232 hardware and the use of the 3-transistor JP1.x interface and the use of a JP1.2 (URC-8820) remote control seems to consistently cause large amounts of this phantom data, but I really don't know why and I suspect I may never know, due to the small number of people that may be similarly affected and even smaller numbers that will probably bother to investigate and report on this. Such is life, at least for this "inquiring mind".

Options: My choices include altering the "read flush" code to flush every last byte of data (instead of a mere 20 bytes) before doing the serial comm mode test. Although such a change should cause no harm to anyone not experiencing this "huge amounts of phantom data" problem, I'm a little leery to do this in the library code. Therefore, for now, I'll just live with the problem and/or use the IoGear GUC232A USB/RS-232 adapter when I'm using that particular combination of hardware, which, admittedly, will probably be rare once I get these library code issues worked out and publish a new version. By then, I'll switch to my desktop PC for JP1 use and the problem is mild enough there that it won't cause failures.

For anyone still reading this thread, I'm sorry for dragging you through this whole saga over the last few days, only to come to the conclusion that the worst case problem seems to be a particular combination of hardware (PC, interface, remote). I was intially afraid that the problem might be broader and thought it needed to be investigated. On the flip side, though, I think what I learned is useful and I'm glad to get it documented here for posterity. And we all know by now, I think, that the phantom data does exist, just not usually in large enough quantity to cause failures of the 'ping' test in the library code. Also, in the process of discussing this, a fix for an unrelated problem (the inability to use the remote control while still tethered to the JP1.x cable using the 3-transistor interface) came to light thanks to Vicky's and Tommy's input and Tommy has already issued the necessary update in his schematics.

If anyone has any questions, feel free to fire away. Thanks for all your inputs!

Regards,
Bill

In virtually all cases where the remote reports more than 20 bytes of phantom data, it actually does successfully enter the serial comm mode, but the phantom data precedes the remote's 'ACK' reply, fooling the library code into thinking it has failed to enter serial comm mode!

In my opinion this violates a cardinal rule of good programming. Any time a program can't get started and has to bail out (in this case because it fails to receive an ACK) it should leave things as they were BEFORE it tried. That means any time IR or jp1xtest of jppfst exits it should do a reset routine to leave the remote in normal mode, NEVER abandon it in serial mode, unable to do anything unless unplugged and power cycled.

Tommy Tyler wrote:

In virtually all cases where the remote reports more than 20 bytes of phantom data, it actually does successfully enter the serial comm mode, but the phantom data precedes the remote's 'ACK' reply, fooling the library code into thinking it has failed to enter serial comm mode!

In my opinion this violates a cardinal rule of good programming. Any time a program can't get started and has to bail out (in this case because it fails to receive an ACK) it should leave things as they were BEFORE it tried. That means any time IR or jp1xtest of jppfst exits it should do a reset routine to leave the remote in normal mode, NEVER abandon it in serial mode, unable to do anything unless unplugged and power cycled.

I totally agree, but in this case, you're misunderstanding, Tommy. Sorry if I wasn't clear on that point.

Basically, both the current library code (and therefore 'IR.exe' and RMIR) and my JPFST utility will "reset" the remote to "normal operation mode" at shutdown time. That's never been an issue.

What I was saying in the part you quoted above was that the remote is successfully entering serial comm mode (because the manipulation of the signals on the JP1 pins is correct). It's just that the 'ping' that the code (library and JPFST) do to test if the remote successfully entered serial comm mode is fooled into thinking that it hasn't because of the excess of "phantom" data preceding the 'ACK' byte. The remote is in serial comm mode and will successfully be commanded to "normal operating mode" on application shutdown.

P.S. The utility called JPFST is soon to be renamed JP1xTest. It's the same utility, I just haven't had time to rename it.

Bill

The utility called JPFST is soon to be renamed JP1xTest.

I realize you were pressured toward this action by Rob's comments, but I just want to point out that this choice of name will leave two test utility programs, yours JP1xTEST.exe and mine jp1xtest.exe, with identical names except for the capitalization of a few letters. I have recommended jp1xtest.exe for years as the best means for testing a JP1.2/3 Interface, and will continue to do so. Hope that doesn't confuse members.

Meanwhile, here's a suggested test. Go to http://www.bb-elec.com/product.asp?sku=COMTEST to download and install the freeware program called com_test.exe. If you get an error message saying the .dll can't be found when you try to run the program, search for a copy of VB40032.dll on google and put it into your Windows System32 folder. JPFST is the only program on the planet that will allow you to switch a remote into serial comm mode and leave it there, so the test uses it too.

1. Connect 8820 remote to interface and interface to PC.

2. Start JPFST and press "Put Remote Into 'Serial Comm' Mode.

3. Unplug interface from remote, close JPFST, then reconnect interface. Press a remote button to confirm that it is NOT transmitting.

4. Open Comtest, select port, and configure it for 38400-8-N-1.

5. Transmit "E" and verify remote responds with "06" (ACK).

6. Press "Window" > "Clear" to clear data from Comtest display.

7. Transmit "I" and verify remote responds with "M<<08>y". This is four bytes: "M" "<" unprintable ascii "08" and "y".

(JPFST gives this string as 4D 3C 08 79.)

8. Clear the window again.

9. Transmit "V" and verify remote responds with three unprintable ascii characters (20, EC, 00) followed by "10631063" (the remote's signature) and a final unprintable character CC, for a total of 12 characters.

(JPFST gives this string as 20 EC 00 31 30 36 33 31 30 36 33 CC.)

I've tried this series, and variations of it, many times but never get any junk data preceding the initial response to "E" (or any other time for that matter). One thing I did notice is that if you open Comtest and configure it, then instead of plugging the interface cable into the remote cleanly, you jiggle it when it just makes contact, you can get a lot of characters (mostly 00's) in the Received Chars window. HOWEVER, those characters can't explain the buffer junk because they are all received BEFORE anything is sent to the remote. The remote always responds with just the characters mentioned in the above steps.

So the question is, if there is stuff in a transmit buffer in the remote just waiting to get out, why doesn't it ever show up in this test?

Tommy Tyler wrote:I realize you were pressured toward this action by Rob's comments, but I just want to point out that this choice of name will leave two test utility programs, yours JP1xTEST.exe and mine jp1xtest.exe, with identical names except for the capitalization of a few letters.

It's actually even slightly worse than that since the executable names are case-insensitive. My executable would also be called 'jp1xtest.exe'. When I refer to the application (i.e. not to the executable file itself), I've been calling it 'JP1xTest' for clarity of reading and since that's how I'd display it in the application itself (dialog titlebars, help info, etc).

Tommy Tyler wrote:I have recommended jp1xtest.exe for years as the best means for testing a JP1.2/3 Interface, and will continue to do so. Hope that doesn't confuse members.

I think it's very confusing and undesirable, and you clearly have the right to unfettered use of that name, but I'm going to leave this to Rob to address, just as I said I would when I agreed to the name change of his choice. Rob?

Switching gears....

OK, I've installed that 'comtest.exe' application on my W98se laptop (i.e. the setup exhibiting the most garbage data). I'm using the 3-transistor interface -- that's important. I've run the suggested test and I don't see any garbage data. But after some thought, I don't think that's conclusive proof of anything. When Windows opens the comm port (via 'comtest.exe'), the data may be flushed out. For all we know, 'comtest.exe' might be explicitly flushing the comm port with a read. We really need a single application to do the testing, to avoid the close/open cycle on the comm port.

I ran the test several times and step #5 (and the rest) usually failed, but something I did during one test early on caused those steps to pass. Unfortunately, I was not able to duplicate that later on. I think it worked once when I may have inadvertently altered the order of some action slightly.

But... while that 'comtest.exe' app was running, I also played around with the settings and saw something that may shed light on this issue. The DTR line is set (red indicator). When I also enable the RTS line (Ctl-R), I get a ton of garbage (all zeroes) data. I shut down and switched over to my RS 15-135 (JP1.3) remote and when I do the same thing, I don't see any zeroes.

This garbage data shown in 'comtest.exe' seems to be there regardless of whether I've used JPFST to place and leave the URC-8820 remote in serial comm mode beforehand or not.

I switched over to the quad-XNOR interface and repeated the tests. I don't see any garbage data in this configuration at all.

I think these tests are confirming what my JPFST program is seeing, but from a different angle.

Something about having DTR and RTS enabled simultaneously with the 3-transistor interface is generating the garbage data, it seems. Since a reset to normal operating mode would do that, I think it makes sense that I saw that issuing multiple commands to send the remote to normal mode seemed to accumulate more garbage when the data was eventually read (by JPFST).

I still don't know what's going on, but running this 'comtest.exe' app has given me some more ideas. It'll take me a while to think it all through and test it all, though.

Aside: It's a shame that this 'comtest.exe' app doesn't also allow control of the UART 'break' signal. With that single addition, it could be used (much like I sometimes use a command-line Linux application that I wrote) to directly control the remote's mode instead of just being able to see the results of serial communication. And it would avoid having to close/open the comm port, which is probably introducing unwanted variables, especially since we cannot see what a closed-source application like 'comtest.exe' is doing to the comm port (e.g. at init time).

Tommy, can you please try the following:

1. Hook up your 3-transistor interface to the URC-8820 and the PC. Do NOT use one of those USB/RS-232 adapters.

2. Run 'comtest.exe' and select the usual settings.

3. Verify that the DTR "LED" is lit.

4. Verify that the RTS "LED" is NOT lit.

5. Use the Ctl-R hotkey to repeatedly toggle RTS on and off. See if you get any garbage data. In my case, it's always zeroes.

Those results would be very interesting to me. If you don't see any garbage data, I'll have to suspect something about my RS-232 port on that laptop and/or my bread-boarded 3-transistor interface.

Bill

I can't keep track of every utility name that is in use. Before I suggested jp1test I did a search and found nothing, which is why I thought it was OK to suggest it. If there is an existing utility of that name, I don't know where it is and there are no posts that refer to it.

As Tommy already has a utility called jp1xtest, you shouldn't use that name.

You are totally free to use the fpst name if you want, I was just trying to point out that it's hard to remember so I was trying to suggest that you come up with a name that has actual words in it. But I'll leave it totally up to you.

The Robman wrote:Before I suggested jp1test ...

Actually, you suggested 'jp1xtest', giving all the proof I need that no matter what I name it, people will still screw it up!

Man, I'm gonna suffer for that one -- I can see my forum privileges getting revoked now. Please, don't take my jibes too seriously, Rob. I just like to poke fun every now and again. Rob? Please, Rob? ... beep... click... ...NO CARRIER ...

So, in conclusion, I might as well just leave the doggone thing with the name it's had all along: JPFST

If someone has a complaint, they can just rename the executable file to whatever the H-E-double-hockey-sticks makes them happy! Or just make a batch file using the name of their choice which calls 'jpfst.exe'.

Bill

Rob,

I posted jp1xtest.exe 4/15/07 HERE as part of a zipped group of three files named TEST GROUP. Does the fact that it is zipped explain why your search didn't find it?

WagonMaster wrote:

The Robman wrote:Before I suggested jp1test ...

Actually, you suggested 'jp1xtest', giving all the proof I need that no matter what I name it, people will still screw it up!

https://www.hifi-remote.com/forums/viewt ... 7450#p77450

The Robman wrote:I know this is going to sound like a silly request, but do you think you could rename this utility? I have a feeling that the JPFST name itself might be intimidating to some newbies, especially those who are intimidated by JP1 anyway. I think a simpler name like JP1test would work better.

5. Use the Ctl-R hotkey to repeatedly toggle RTS on and off. See if you get any garbage data. In my case, it's always zeroes.

Yes, DTR is normally ON, and every time I toggle RTS ON I receive a byte, mostly "00", rarely "FF", and even more rarely "F6". That's the same phenomenon as jiggling the connector that I described. I'm sure the Windows USART thinks it sees a start bit due to the transient. You can configure the port to any baud rate, parity, etc., and it still happens. Since the remote only speaks 38400 baud, I think that's proof the "garbage" is not originating from the remote, at least in the sense that it comes from any sort of buffer.