[GreenKeys] In need of help on a ASR Mod 33 which is having problems ONLY in line mode from the keyboard.

[john at toebes.com]

I’ve got an odd problem with my Mod 33 with Mike Douglas’ RS-232 adapter (http://deramp.com/tty_adapter.html) connected to a PC that even has Wayne stumped, so I’m hoping some might have an insight as to what is going on.

 

Specifically I am having a problem with some bits being changed from a 1 to 0 in line mode ONLY when typing on the keyboard.  Here’s the details on all the tests that I have done and really would like to make it more reliable..

 

Ok.  Here’s what I know:

1.	[OK] In local mode, all input/output is 100% reliable.  I.e. whatever I type on the keyboard properly comes out on the printer or papertape.
2.	[OK] In local mode playing from the papertape is 100% reliable.  I can play the same papertape many times in a row and get the same output.
3.	[OK] In line mode, characters don’t print unless I echo them back from the computer.  I.e. If I put it in line mode and the computer is not running, I hear the keyboard click but nothing prints on the printer (as expected)
4.	[OK] In line mode, everything from the computer prints 100% reliable on the printer (*NOTE: I had to insert three nulls after every carriage return before printing anything else in order to make sure that the carriage return fully returned. Otherwise I would have characters appear in the middle of the line as the carriage was returning)
5.	[OK] In line mode, any papertape input is 100% reliable.  The characters go to the computer and echo back properly on the printer
6.	[BAD] In line mode, many characters exhibit dropped bits when typing.  I have found that I type in a cadence of 3 key presses followed by a short pause, repeat… that I tend to get more errors.  Some letters never produce an error, but some other letters are HIGHLY prone to errors.  You can see my manual run at https://photos.app.goo.gl/1SnH3Fp6wer7ungYA where I went through just about every character on the keyboard and typed a full like to see what errors it generated.  I’ve also attached a diagram showing which keys generate the error and which bits are changed to 0.  NOTE: I have NEVER seen a bit changed to a 1, only to a 0.  I have also never seen the high order bit changed, only the bottom 5 bits have ever changed and most commonly it is the 8 bit that is the one flipped.
7.	[BAD] in line mode, there is LESS errors when using the repeat key, but the error are occasionally there. Given what I discovered in typing on the previous item, I think it more timing than repeat key.

So.. I’m a bit stymied.  From what I can tell, the keyboard is operating perfectly.  I can never reproduce the error in local mode.  I also believe that the current loop -> USB card -> PC is working properly in both directions since I can not generate an error from the papertape and have never seen an error on the printer.  This leads me to believe that there must be some path that is unique in the keyboard getting to Mike’s card that is different from how the papertape reader delivers data to the card.

 

Any ideas?  Any other tests that you can think that I should do?  I’m bringing this to the Astronomy Days (https://naturalsciences.org/calendar/astronomy-days/) this coming weekend in downtown Raleigh and we are expecting somewhere around 15,000 visitors over two days.  

 

Thank you!

 

*	John Toebes
*	919-622-2041

 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.qth.net/pipermail/greenkeys/attachments/20190121/3892881b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: KeyboardErrors.pdf
Type: application/pdf
Size: 161695 bytes
Desc: not available
URL: <http://mailman.qth.net/pipermail/greenkeys/attachments/20190121/3892881b/attachment.pdf>