I agree that the m100 has unique circuitry contributing to the problem - perhaps only 5 volts to work with , perhaps the choice in the resistor values chosen on the inputs and outputs, or perhaps when they changed to 330 ohm values in that TSB.
Agreed it’s perfectly legit to loop back in this fashion. What’s odd is other older TNCs didn’t do this, at least not by default. What I didn’t try yet is seeing if tickling the DTR output on the m100 changes anything (switching it from high to low or vice versa). That built in telcom program initializes the uart and resets the hardware flow control lines, so I would need to write something in basic to do the test. Unfortunately that tnc has traces needing to be cut on the pcb to disable this loop back. They didn’t put jumpers on the loop back options. Sacrificing one of those gender changers was the lazy way to fix it. Sent from my iPhone > On Sep 27, 2023, at 6:57 PM, Brian K. White <b.kenyo...@gmail.com> wrote: > > On 9/27/23 16:01, Jesse Bertier wrote: >> Fellow M100 Enthusiasts: >> I kept at it, trying all the various suggestions from the group. I finally >> solved the issue - the TNC had a loopback connection from DTR to DSR. The >> problem disappeared entirely when I removed that loopback connection the TNC >> was doing. > > It's still curious, because looping back those two lines is perfectly "legal". > > It may possibly have a bad effect in some cases simply because of any signal > being a lie, but electrically it's perfectly legit. And it's not even a data > problem if neither side is looking at the signal. > > I say, this indicates a problem in the 100 (in the design of the circuit, not > a damage you can repair) not a problem in the radio. > > Though the work-around is still fine. I just mean that the conclusion that > "aha, the radio is the culprit" isn't really the case in my opinion. But even > if I think the root blame belongs to the 100, I'm not sure there is anything > you can do practically to fix the 100, and it was simple to make use of an > optional configuration in the radio that was put there basically just for > this reason, to cater to the failings, or more generously, quirks of other > equipment that might need it. > > -- > bkw > > >> If interested, I posted the details here: >> https://n1ugk.com/2023/09/trs-80-model-100-with-the-kpc-3/ >> <https://n1ugk.com/2023/09/trs-80-model-100-with-the-kpc-3/> >> With that mystery solved, I can now use the M100 for what I intended to use >> it for. >>>> On Sep 8, 2023, at 7:28 PM, Daryl Tester >>>> <dt-m...@handcraftedcomputers.com.au> wrote: >>> >>>> On 9/9/23 00:10, Jesse Bertier wrote: >>> >>>> I wanted to follow up with this issue - As it turns out, the TNC itself >>>> seems to be the culprit, at least with the M100. Even small text strings >>>> get garbled, with software flow control enabled on both sides. That TNC >>>> works fine with a PC, just not the M100. Next time I have the scope out, >>>> I’ll take a look at the line and compare, and work back into the M100 as >>>> needed out of curiosity. >>> >>> Sounds suspiciously like clocking tolerances (of the serial line). I >>> thought >>> it used to be 20% (from the "olden days") with 16x oversampling), but >>> current >>> Internet Wisdom (for what that's worth) says ~ 5%. If you've got one device >>> that's slightly fast, and the other slower, you''ll see this sort of >>> behaviour. >>> >>> (I used to work on a serial port switch in the 80's. That sod had >>> something like >>> a +0.5% tolerance, although its negative was relatively normal. The above >>> fault >>> was well known). >>> >>> Cheers, >>> --dt > > -- > bkw >
