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
