heh... but only if I transmit only two bytes per second. And it also doesn't handle low baudrates well, which makes absolutely no sense in the software.

I'm at quite a loss.

Latest theory may have to do with voltage levels... yeah, the blacklink either drives the DB-9 lines near 0V or something near the maximum voltage. Technically RS-232 is invalid between -3V and +3V, as I recall. The MAX213 specifies a low as anything below 0.8V, as I recall glancing at briefly.

So, theory goes, maybe the lows aren't low enough after a few bytes. The original thought was that it wasn't squeezing enough juice from the TX line to keep powered, so the capacitor was draining... after a few fast bytes or during a long low slow bit. But, now I'm powering it from a 9V battery...

Which is also interesting... I had a battery (old and long unused) read 9.5V when I dug it out, and a few minutes in it was at 6.5V. I grabbed another reading 8.5 and it wasn't long until 8.0... sure, they were old/used to start with, but this circuit is supposed to be powered by a single RS-232 handshaking line... should be only a handful of milli<s>volts</s>AMPS, eh?

Software theories, well... i could see that there'd be a lot more time prepping for the next byte than handling all the other bits in a frame, but that would've easily been accomodated by using a quarter of the fastest single-byte-working baudrate... no go. Should've probably been acommodated by using two stop-bits... no go. And, again, wouldn't explain failures at really low bauds (went down to 75bps! Hah!)

Must be power... 

HAH!

I could prb plug it straight into the TTL-serial hack on my usb dongle... duh.

Levels might be inverted, but that's just software...

Too late tonight.

...

Next day... Well, shoot... i was pretty certain it must've been due to voltage levels, so I started working out how to hook it up to the PL-2303 directly, rather than through the RS-232 level-shifter... the question was simple: should I go through the graphlink or just go straight to the calculator? That, too, being about voltage levels.

But I dug up the HIN (not MAX) 213 level-shifter datasheet, and...

It uses hysteresis. Cool. But the high to low and low to high input thresholds are /well/ within what should be expected from the blacklink cable, even if it was getting weak power and even if somehow its ground raised a bit. Frankly, it'd do a decent job converting severely-loaded TTL to CMOS, or vice-versa, even though it's supposed to be converting from RS-232! 

So, now what?

Now I'm looking at schematics of both the calculator-side and computer-side for the link port, and aside from a really low voltage (which I bypassed when running off a 9V battery, even the one that was reading 6V under load), I can't figure what could be wrong.

Sure, it couldn't hurt (well, it could) to take something out of the equation, two in fact, connecting the calculator directly to the PL-2303... bypassing RS-232 levels and the graphlink... but now gotta consider the signal levels, there... first-off, the link is pulled-up to 6V... the PL-2303 uses ~3.3V signals. My hack for direct-connection took this into account by adding a zener-diode voltage regulator on the receiving side. Oddly, it's the transmitting side (computer) I'm more worried about. And the datasheet doesn't go into detail like whether the outputs have overvoltage protection diodes... i mean 10k would limit the current quite a bit, but... eah... current going into high outputs doesn't sit right with me. (Wasn't "latch-up" a thing?)

K, then there's the low-side resistors at the calculator transmitting side... which are never not fought by the pull-up, in addition to the Vce of the transistor... at which point expecting, say, <0.8V output when low might be expecting too much. 

In which cases the graphlink acting as a level shifter seems like a good intermediate step, even to LVTTL levels. Except that's what I was trying to remove for troubleshooting. Heh.

I really can't see how this is software related. Unless somehow stty settings are still getting in the way... and even those... I went back to my old serial code and copied the settings directly. (Oh, and yes, they had a big note: "porting from OSX to Debian, ECHO NOW NEEDS TO BE EXPLICITLY DISABLED." Heh. Guess I forgot that little endeavor.)

I'm at a loss.

One thing... almost certainly between the buffers in the OSs and those in the PL2303 itself, if I start sending characters at some rate they probably start getting transmitted back-to-back, even though I tell it to sleep for a few fractions of a second between each... again, if my code wasn't keeping up, due say to the time it takes to load the next data byte, then surely it would at a lower baudrate. There's no timeouts, it'll wait for the next edge indefinitely. So then maybe "ringing" is causing false-triggers... but no, that'd surely interfere with even a single byte... what is it, 1ns over 6in? That ringing's long subsided before the next edge-detection instructions, and long before the next edge, /especially/ at low baudrates.

This seems somehow related to a sinking voltage somewhere... highs stop staying high, lows stop staying low... almost like it's AC-coupled. But, I just don't see it. Time, probably, for oscilloscoping. Yet another of the many tools I'm used to just turning on when I need it, and now have to plan days in advance.

I find it hard to believe this is being so elusive.

...

Well, here's a few somethings... the HIN213 is rated for 5V+-10%... it's getting 4.1V. The PL2303 (assuming the only datasheet I can find, which is for the 2303HX, applies) is rated to connect to such a device at up to 3.6V, but again, getting 4.1V

But, again, this all has worked for me for well over a decade, so... next we have something really interesting: the HIN213 RS-232 inputs have an internal resistor pulling them to ground... it happens to be 5Kohm. I noticed this because I measured to voltage at one input while the graphlink was driving it high, powered by 8V from a low battery, and measured a little over 4V at the input. Apparently the graphlink's pull-up is around 5K too.

Now, the next little tidbit I missed before is the Vin L->H threshold isn't 1.7V, it's 1.7V*typ*, 2.4V*max*. Now, running this /without/ the 9V battery, that could get gnarly, since the thing seems to run around 5V when powered by the port... then a halving voltage-divider between the output pull-up and input pull-to-ground makes for a high voltage /right near/ the threshold voltage. Then, of course, it's running at 5V-20%, which is out of spec, things might be even more sensitive.

Also, I suppose, it might make those voltage boosters run out of spec, which I suppose could mean they have to work harder when outputting either for a long duration (low baudrate) or for a lot of repetition (high baudrate, many bytes back-to-back). /Those/ voltages might be the ones sagging. Heh!

And why don't we see this using the graphlink normally? One thing that comes to mind is that e.g. usually only /one/ output is low at a time... (wait, that's the case here too). Another thought maybe that the really low bitrate gives the charge-pumps time to recharge... maybe they /do/ sag briefly, but we can't see it since the next read of the port happens after the recharge... ok, and a bit's toggling like that might have something to do with why it seems the calculator skips a step... or, not, and a bit's toggling like that really has no effect on the lockstep handshaking in the protocol... or maybe not, and the bit sags a little, but not enough for the calculator to notice... and, something /like/ that might explain why some responses /from/ the calculator seem to take longer than others... I dunno.

So, /maybe/ it is this wonky setup, despite its seeming reliability for so long... just haven't had a case where it appeared.

And, of course, something like that would have a tremendous effect on asynchronous data, wherein every edge may cause a glitch. Hmmm...

Plausible.

Back to thinking about direct-connecting.