That is all solid advice. Here is a pic of my setup (I stopped running it through the old reader as bypassing it turned out to work fine) https://i.imgur.com/26pfKhv.jpg Most of my focus is on ensuring there is no damage to the tape when it is read. You can see the paper tape catch (hopper) to the left of the PDP. First I set up my reader and get it aligned with the paper tape roll holder. I use the one on the front of my SEL 810A as it is purpose made and handles paper tapes that are very thick or very tightly wound. I feed it into the reader, and ensure I have at least 10 bytes or so of nulls prior to my first bytes of data. Ideally there is a foot or more of nulls so I can get it fed into the hopper. If the null header is too short, I have to be very careful to get the tape fed into the hopper as it starts so it does not end up on the floor. Next I will run a command like: bash> python3 ./papertape/tapein.py --baud 4800 /dev/ttyUSB0 TAPE_CAPS/testread.bin That file comes from: https://gitlab.com/NF6X_Retrocomputing/papertape/-/blob/master/tapein.py Then I will hit read on my reader, read enough data to feel comfortable everything is working, and stop the read. Next I will reset the tape, stop the program on my laptop with ctrl-c, and re-start the program with the name of the tape I am capturing. I capture everything on the label in the name, usually catalog #, name, and date. The entire time I am capturing I will generally have one hand on the reader so I can stop it if something goes wrong, and one hand free to either guide the tape back into the hopper if it starts spooling out or to correct the tape roll if it starts to leave the standoff. The tricky part is to stop the reader after the last bytes of data but before the tape rolls through the reader into the hopper. This helps ensure you do not end up with 0-3 extraneous garbage bytes on the end of the file depending on how the end of the tape is torn. I remove these manually if I miss the end. Finally, for my captures I will run an independent checksum verification if possible (this is platform dependent). If not, and it is a tape I have to return, I will do 2 reads and strip the header and trailer and compare. The likelihood of the same error twice is vanishingly small, and any error with the sprocket hole throws an alarm with my reader. A couple notes: 1) My reader when set to lower baud rates physically stops and starts the reader. This jerks the tape and causes vibrations that can be severe at some speeds. 2) getting the spool/standoff, reader, and basket/hopper lined up is critical. Be ready to make small adjustments as you are reading to keep things running well. 3) a good rewinder is essential, here is a shot of my heavy duty one. I have a smaller handheld rewinder which is great for short tapes. https://i.imgur.com/ezKrvn6.jpg 4) xdd -b will dump binary and a visual inspection can be handy when starting off just to reassure yourself no funny business with the RS232 encoding is afoot 5) The ASR33 always set the MSB high, so only the lower 7 bits are used. Handy tidbit to know when you are looking for CRLF ar the start of the tape and the value is b10000000 higher than it should be. 6) repairing a tear is pretty easy, just use some clear tape cut to the right width since all holes tape is not generally available. 7) If you happen to be reading SEL 810 relocatable tapes, you can use this program to verify them: https://github.com/phar/sel810asm/blob/master/rs227.py -Eric On Wed, Jul 29, 2020, 16:31 Paul Koning via cctalk <cctalk at classiccmp.org> wrote:

Absolutely would be good to have. I would prefer a slow smooth pull through the reader than slow and jerky or fast and smooth which are my current options. There are some kit paper tape readers out there that just need a pinch roller added to be ideal. On 5, 6, and 7 bit tape, I believe the DSI NC2400 which a number of people have is adjustable width. That said, a kit that came with a variable width optical read head and a variable speed smooth pinch roller with an RS232 interface would likely find a market with hobbyists. No hard brake needed for archival purposes, but definitely a softer break to fairly quickly stop the tape if something goes wrong. -Eric On Wed, Jul 29, 2020, 19:43 Paul Koning <paulkoning at comcast.net> wrote:

Paul said Some readers do this at all speeds. For example, any stepper motor is by definition a start/stop drive at any speed. Fast optical readers may run continuously if you let them, but that's worth a careful check. Especially since some of the high speed readers have very serious brake systems, good for their original application but not at all for our purposes. I've seen tape readers specified at 1000 cps or better that are capable of stopping at any point, starting up again, and reading the next character. So they are doing 100 inches per second and stopping within 1/20th of an inch. Ouch.The best kind of archival tape readers would have an adjustable tape path so you can read any of 5, 6, 7, or 8 channel tape. While 6 and 7 is uncommon it does exist. 6 is probably least interesting, at least the only application I know is typesetting, not computing. I've been thinking a newly constructed optical tape reader with continuous motion (no brakes), capstan drive, and slow ramp start/stop would be ideal and with today's technology quite easy to make. My EECO does this, runs the tape through in short bursts and buffers it so not much point in trying to go easy on the tape by running it at a low baud rate. Paul's reader idea sounds fine. I have a super simple idea, how about a 3D-printed guide with a geared hand crank and a bracket for attaching a mobile phone looking down at the tape running through the guide below it. Then set it to record video and crank away at a steady rate. The crank has a meter or moving widget to add additional means of tracking. At a later stage some video processing could read the pattern from the video. There would undoubtedly be a python library for that. It would capture the label and other labelling nicely too. Steve.