BNT162b2 Pfizer COVID vaccine, on paper tape!

This is an amazing article on how the vaccine works, and it is so much like computer programming. Well worth reading:-


So I decided to see just how small the vaccine is, and it is tiny. If you then code the components in binary, e.g. U/Ψ=00, C=01, A=10, G=11, and pack in to 8 bit bytes it is only 1071 bytes in total, or put it another way, 2.7m of paper tape!

I hope that gives you an idea of how compact this code is, way smaller than any computer anti virus code!

But do read that article, it is amazing!

P.S. I used to get berated for being able to read hex ASCII (not as good at it these days), but after taking the above pictures I looked at the paper tape and realised "that's not how an mRNA sequence should end!". Basically, the sequence has padding, lots of As, which translate to 0xAA on the paper tape which is quite distinctive and I expected to see it but did not. It turns out a change to the ESP-IDF MQTT library moved where the default buffer size is set (which limits MQTT message size), and so truncating my sequence by 73 bytes, hence the missing As on the end (and a bit more). The picture still shows how small it all is, as it was only a small amount lost off the end (I had text printed more tape than that anyway on the ends). But for those of you that cannot read the base code of the universe, on paper tape, it was wrong and would not have worked if you injected that paper tape as shown... So don't try it at home.

This is how it should end (video) :-

P.P.S. it is also not bad as a QR code (base32 encoded) - only slightly larger than the NHS covid QR codes :-)

Facebook portal oddness

Obviously, as it was Christmas day, I ended up spending an hour helping a friend with tech support. Their Facebook portal was being a tad odd. So I post here in case anyone has any suggestions - as I was stumped!

She had factory reset and re-setup it anyway to try and get it working, and we tried resetting several times, and clearing the logins on the Facebook app (which also resets the portal). Here are the symptoms:

  • During set up, we connected to Facebook and it showed on the Facebook app as logged in, all sensibly. We selected some "favourites" as normal during set up (i.e. it showed contacts with check boxes as you would expect).
  • The home screen shows suggested contacts of the person themself! Not any actual contacts!
  • Trying to add a favourite shows an empty screen - no contacts to add!
  • Searching a contact shows not found.
  • However, incoming calls work, but they do not then show in "recent" after the call - it says no calls!
  • Saying "Hey portal, call Adrian" (or any other contact) correctly shows the contact or contacts matching, with name and picture, but selecting one does not actually make the call - just nothing happens.
  • Installing the portal app on the phone shows the favourites that we selected on set up of the portal.

Over all, it is just plain weird. We cannot see any sort of privacy settings blocking contacts (and if there were, the fact the "Hey portal" shows them would a be a bug).

Suggestions welcome!

Week 6

I expected nothing to happen this week, but I was wrong.

The original plan had been that we all try to exchange contracts before Christmas. Sadly that is not so.

My solicitors have done an excellent job so far, as always (Kite Griffin). The final searches that we need all came in before Christmas and so everything we needed to do was ready.

Sadly the sellers solicitors closed a few days earlier, still waiting on searches, and have not even answered queries my solicitors asked back in November. They are probably doing their best.

Obviously I expect nothing to happen next week. But it is all good news for things actually making some progress on the 4th Jan. We'll have to see.

Of course it is not all good news! The Welsh government decided to increase the Land Transfer Tax with no notice, meaning I have to find several thousands pounds more, just like that! I would ask how the hell anyone is suppose to plan for things like this, but we live in a world where it is totally normal for major changes to law can come in with literally minutes notice and even long term things like leaving the EU can only really be planned for a week before it happens (assuming the legislation passes on the 30th/31st). So yeh, planning is not a thing we can really do these days is it!

But we had a fun Christmas day :-)


More magic QR codes

It seems that permits for lorries in to Kent are a QR code as well, and it seems they are really good at validating number plates?!

This decodes as:-


This is base32, which is somewhat nicer for QR code encoding as it fits entirely in the alphanumeric coding (which is digits, upper case, and a few symbols).

It decodes as two parts: some JSON and a binary block.


So, once again, a digital signature, but made to be a smaller code than the NHS codes.


The trump tweet machine

As usual , something silly and simple has turned in to many hours, and learning some lessons.

I made a Trump tweet machine that prints Trump's tweets on an ASR33 teletype. It was a fun use of the teletype as it only does ALL CAPS anyway, meaning Trump tweets were a perfect fit. It was also printing on the only paper I had which was a sort of tissue paper (so you could, in theory, wipe your arse with the tweets if you wanted to). I have some proper teletype paper rolls now.

The original version was very simplistic - it used IFTTT which can do something for a tweet by a person. It can send that via http, with the name, time, and tweet text. I printed that. It worked.

However, it was not perfect. The main issue is a hour or so lag with IFTTT. I decided I could do better.

The code is asrtweet.c on GitHub. It has had an annoying amount of tinkering to get it right. I suspect there will be more.

I decided to use twarc after a bit of googling. It seemed to be one of the few command line tools that would feed the raw JSON which Twitter provide. Handling JSON is easy, but it seems handling tweets has a lot of gotchas, and is not as obvious as it seems.

  • There are two formats, the text in the main body, and full_text in extended_tweet (if present). I can only assume this allows for legacy where tweets were shorter.
  • There is a range of characters to display as the text will start with lots of @names which you don't show in the text usually.
  • The character positions / ranges are unicode characters not bytes - arg!
  • It, or something, changes " and ' and several other characters to unicode versions, so I replaced them to allow printing.
  • The text content is XML coded for &, < and >. Why? This is JSON, so why do that? Crazy! And these are not counted as one character for character counts, but as &, a, m, p, and ; as separate characters.
  • There is a timestamp based on unix time to the ms, good, but not for the time stamp of an original tweet if retweeting. Date/times seem to be in a text format only otherwise. It even does a time zone (e.g. +0000) but shows UTC (yes +0000) for a Trump tweet which is clearly wrong.
  • A retweet only has the abbreviated text with RT on it, you have to look in retweet_status to find the original text, possibly within an extended_tweet block.
  • Whilst referenced twitter handles are @name in the text, some things are not as you might want to display them. E.g. a URL is a twitter URL. There is then a list of replacements/expansions which you can use to replace things like this with the original. Again, all unicode character counts not byte counts.
  • It seems twarc can filter follow a user by user number, but gets all events mentioning that user, so I have to filter if I want see tweets by that user. Mostly that is simple, but when it is Trump, that is tweets mentioning him several times a second.
  • I replaced media with [photo] or [video] as a teletype is not good at such things. I also did not bother printing tweets that only have media in them and no text.
  • There seems to be no flag in the JSON for twitters "disputed" status, though as I am printing as tweets they would not have time to add it. But even so, printing an old tweet, does not have any way to know. So I had to add this to his tweets myself :-)

There was a lot to learn.

But the end result (so far) is code that runs twarc to filter follow one or more users, and pick tweets by them. Handles retweets and replies with an extra line of text printed. Handles wrapping to 72 characters. It is typically printing a Trump tweet within about 10 seconds of him tweeting. No more hour long lag.

It is rather surreal having a teletype (very noisy) suddenly wake up and print a message from the president of the united states in my study here.

Here's one which did not even need converting to upper case :-)


Week 5

Well, we have a drainage search now - all OK. Waiting on a mining search and flood report still.

No news from seller on their searches or survey.

At this point I suspect we will not exchange before Christmas.


But yay, some other news. When we asked for quote we did not mention it was Wales. Solicitors have revised the quote for Welsh Land Transfer Fee which is a LOT more than English Stamp Duty, nearly double. That is a large extra chunk of money to find.



Banning encryption, again

Once again there are talks about making platforms add some sort of back door to encrypted private communications. This happens every few years and usually falls flat on its face when policy meets mathematics, but what is the issue here?

The key issue is that the state, in various guises, would like to be able to snoop on private communications. There are lots of excuses for this - the latest is "online harms", and of course a smattering of "think of the children". The idea is that if you can snoop on communications you can catch dodgy people grooming children in otherwise "private" chat channels. These latest efforts are rather complicated as they are trying to over reach beyond what is illegal off-line (what is illegal off-line is already illegal on-line), but even muddy the waters of legal and illegal in the first place. It is about obligations on platforms over "harmful but legal" content. This is, in my view, very bad - there should be simple clear rules on what is and is not legal, and speech of any sort that is "legal" should not be censored, even by some sort of back-door means by placing duty of care obligations on platforms.

However, in with all this, is some need to apply this duty of care to end to end encrypted communications, which means making us all less secure. You cannot make a back door that only works for the good guys. It simply does not work like that. We all rely on basic encryption to protect our privacy every day.

See this blog for more on this generally.

But there are other issues with this when it comes to trying to catch criminals or even "harm", and that is the notion that secure communications requires some platform or vendor to provide that security. This is simply not the case. Right now a lot of platforms provide the apps and allow secure (end to end encrypted) communications, but it only takes some sort of snooping law like this to drive things another way. We can have apps that allow security to be applied to the communications that a platform is providing (even simple SMS) where that security is in the end points, in the app. And apps that have no "vendor" in the conventional sense, but are free open source code that is just available on the Internet for all to download. With separate moves to break up Apple's monopoly on its AppStore, this could allow such apps even on otherwise locked down iPhones, but obviously this is already the case with more open platforms like Android.

Of course, you also have the question of having a separate platform and app provider. Are app providers in scope of such laws anyway, and if they offer end to end encryption via some other platform (which itself does not offer end to end encryption), what is in scope of such laws?

Even if this duty of care tries to apply to a platform or an app vendor, it is no good when there is no such entity to which the law can apply. End to end encrypted communications does not need a platform or vendor.

I have a video which is standing the test of time quite well that shows that encryption does not need complicated maths in any way. The example is a simple type of encryption with pen, paper, and dice. But the tools to do good, high quality, secure, encryption, are all available freely. It is not secret. The cat is well and truly out of the bag. Anyone with criminal intent can use such tools. Measures to reduce security will impact "normal" people, happy to use the app with the platform, and so allowing criminals access as well and making us all less secure.

ASR33 consumables

One of the issues with my ASR33 Teletype is consumables. Where can you buy teletype supplies these days? The three things it eats are paper, ribbon, and paper tape.


This is one of those occasions where google skills are needed! The paper needs to be continuous roll (this machine is not sprocket feed) and around 200mm wide. Well, between 190mm (to allow 72 characters) and about 220mm max width of roll holder area. I suspect it is based on US paper sizes so 8.5" (219mm) is what is expected.

I tried all sorts of googling on this - 8" paper, 8.5" paper, 8" paper, 210mm paper, 200mm paper, etc... I found bugger all.

The magic phrase I was missing is "telex paper". Google that and loads of people sell it, even Staples!

It is the proper stuff, low quality paper but works a treat.


The other concern was ribbons. This time I had no issue though. It seems that typewriter ribbons are still sold, a lot, enough for next day Amazon prime to have them. I tried a couple and found that 1009FN are what I want - they are exactly the right size, and even a black/red ribbon works (printing just the black side). It even has the eyelets at the end to auto reverse.

Some other ribbons worked, but were loose on the spools as the hole in the middle was too big. I have also ordered some black only for 1009FN so I can reverse it without printing red :-)

Paper tape

By far the biggest challenge was paper tape - continuous roll paper 1" wide.

Nobody makes it any more. I contacted the few web sites claiming to sell it, and either no reply, or replies confirming it is not made any more. There is someone selling antique Russian paper tape on eBay, and that is about it.

I was stumped, until I discovered the right phrase to google.


These are 1" wide strips of paper used by air traffic controllers, and there are printers for them, and they take 1" wide paper tape on a roll. And they are still made, and you can buy them, albeit in a box of 10.

I'm happy to sell some of the rolls I have.

They are not quite "proper" paper tape in that they don't have some lubricant in them, and they also have a thermal print layer which is not needed, but otherwise they do work.

I still have some restoration to do on the punch anyway (was playing up even printing in cut down A4 paper), and I need to 3D print some spool holders, but I now have paper tape to play with, so should be a lot easier.


Week 4

Bugger all!

Buyers survey on their new place done, but no idea what happened. I suppose no news is good news.

Everyone waiting for searches still.

Arrrrg! Why?!

Really, why is this not all on-line and why is this not all done or held by a trusted third party before putting the house on the market.


'70s game on '60s teletype

So maybe I am a tad crazy, but with very little work I managed to get Colossal Cave, the text adventure game written in the 1970s, to compile and run on an ESP32, and connected that to a 1960s ASR33 teletype.

So I decided to include in my ASR33/ MQTT driver stuff, so it is possible to run Colossal Cave on the teletype, stand alone, no WiFi or anything.

The C code port of the original FORTRAN pretty much compiled as is for the ESP32 (linux ESP32 pdf), but I had to change printf and readline slightly to work with the UART, and tweak CR/LF and additional timing NULLs, but that was all.

Well, I did spend an hour or so coursing as it nearly worked and kept crashing - I added debug after debug and eventually did what I should have done in the first place and wheeled the teletype to my computer and connected the debug port which helpfully told me stack overflow. I have the task more stack and it literally "just worked".

Update: Since the video I have added a dramatic pause / thinking time, using some NULLs, before each response. Adds some suspense :-)

Update: You see typing issues on that video - cleaning the distributor fixed that right up...


Connecting an ASR33 Teletype to an ESP32

As you know, I now have a working ASR33 teletype (see here for notes on restoration). Even though a few more bits to do, notable the case, I decided now was the time to do something with it.

Getting the teletype, and getting it working, were just pure nostalgia, as I used one in secondary school. I had not thought a lot about actually doing something even vaguely useful, let alone fun, with it. But I had made a few assumptions.

One thought was a simple linux terminal, so connecting the teletype to a Raspberry Pi, for example. Of course, the slowest ever game of space invaders was not really a consideration :-).

RS232 interface lead

Internally computer components normally work with binary, 1s and 0s, and these are represented as a voltage relative to a "ground". So typically 0V is 0, and operating voltage is 1, e.g. 5V, or 3.3V. Some modern chips use a variety of different voltages in different places, but the principle is the same.

I'm sure you have all heard the song, no? Anyway, the serial interface of choice, when I was growing up, was RS232. So you need a way to connect the internal working of a computer system to RS232. This involves driver chips.

RS232 actually works with voltages (relative to ground) that are +12V or -12V, though modern variants use +5V and -5V or even less. The original specification allowed for quite a wide range of voltages to be valid.

Connecting something like a Raspberry Pi to RS232 simply involves getting an appropriate USB adapter. Easy.

20mA current loop

However, the teletype uses an older standard called 20mA current loop. Instead of ground and a voltage this uses a pair of wires (- and +) which either generate 20mA or nothing to represent the binary values. The advantage of this is that no matter how long the cable you have, if you put 20mA in one end, you get 20mA out the other. That is how current works. It does mean long cables need quite a high voltage at the start (voltage does drop over distance on a long cable), but if you can apply the necessary voltage to feed 20mA in at one end, then you know the far end is getting 20mA, and the signal is getting through.

Sadly a simple USB 20mA current loop interface seems harder to find, but one can get an adaptor for RS232 to/from 20mA current loop.

Not so easy!

Sadly it is not so easy. For a start, the interface box (which is over £100) needs a power supply, so I need you get some sort of DC plug top power supply for it. This is to source the 20mA to send to the teletype.

However, it is worse, it turns out the teletype does not send 20mA anyway. It expects you to provide a 20mA current source which it "switches" on and off. So I would need a second 20mA constant current supply for the teletype so it can feed 20mA to the adaptor which turns it to RS232 which I then feed in via USB to a Raspberry Pi.

This is getting expensive and messy.

Tech that is 55 years apart

An alternative idea, now that I have played with ESP chips, is to connect to an ESP32 to make the teletype WiFi connected allowing a lot more flexibility.

The technology I am playing with here is around 55 years apart. The teletype is using a 1963 version ASCII typewheel which dates it probably before 1965, as the 1965 typewheel has underscore instead of an arrow. The ESP32 came out last year. So yes, 55 years apart, and yes, as old as me, which is scary!

So really. how hard will it actually be to glue these two together?

I mean, this is really old technology one side, and really new technology the other. Nothing was even close to using 3.3V back 55 years ago, it was not even using 5V TTL from what I can see.

So really, how hard could it possibly be to connect them up?





The answer is this!

A 100Ω resistor that I happened to have lying around, and costs a few pence. Yes, I can spend over £100 on an RS232 to 20mA adaptor, more on a USB RS232, and more for two power supplies, or I can use this, and that is it. Really, that is all.

How it works

Sending data to the teletype...

The input to the teletype just wants 20mA or not, and it does not matter that the ESP32 only generates a mere 3.3V. By feeding through a 100Ω resistor I measure 2.2V drop which is 22mA, which is fine. The printer has this going in to a transistor (Q1) which drives another power transistor which switches power to the solenoid that drives the selector which works the mechanical clocking in of the data to the print (and punch) mechanism.

So it turns out that 3.3V output GPIO pin on ESP32 to 20mA current loop needs literally nothing more than a 3p 100Ω resistor, that's it, magic.

The ESP32 is then quite happy to be configured to 110 Baud 8 data bits and 2 stop bits and that just works. (Yes, the ASR33 is technically even parity, but actually the machine ignores parity. You actually want clean 8 bit if you want to print space invaders on the paper tape punch as I have yet to see even parity space invaders).

But what about the other way - data from the teletype?

The answer to that is actually even simpler. I know, how could it be, but it is. The teletype is designed to "switch" a 20mA current source, which means internally it is just a electrical contact that goes on and off (via a distributor) to send the serial data.

This is what the keyboard contacts look like. The wires are pushed out in a pattern by the bars that the keys work, and they contact a bar at the bottom, or not, in a pattern for the data bits to send.

And this is how those are clocked out. Each of the contacts from the keyboard are on the outside, and connect in turn, clocking a start bit, 8 data bits, and 2 stop bits. The keyboard itself generates the even parity for the keys pressed.

But at the end of the day it is two wires that work like a push button, and so one connected to GND and one to an input pin with configured pull up, and you have input data to the ESP32!

You do have to connect to the right pins, else you end up putting 80V or so up an ESP32 pin and releasing the magic smoke, and you don't want to do that, or again, or again, arrrg!

The ESP32 settings also, rather handily, allow it to have the input inverted, which is necessary when wired like that. You also need to tell it to give you one character at a time as UARTs are typically going a lot faster and you expect to get several bytes at once. Once set up, it was then easy to make a local echo sending the typed key back to be printed as you type.

The end result?

I can connect to the screw terminals at the back. And then fit it all in the case nice and tidy, and we have a WiFi MQTT connected ASR33 teletype!

The ESP32 is connected over WiFi to MQTT where I have commands to send raw 8 bit data, or lightly cooked text (sends even parity for the sake of paper tape; adds carriage return to line feed; wraps at 72 characters; and blats any smart arses trying to send UTF-8 emojis to print an up arrow instead). It also allows sending key presses back raw (i.e with parity, so allows all 8 bits from paper tape), as well as line buffered (stripping parity). All in github for your amusement (here).

I have also put a Sonoff Basic (Tasmota) in-line to the main power, so the ESP32 can turn the power on and off over MQTT automatically when it wants to print.

I then have a simple script to handle incoming SMS on a number and send to the ASR33 via MQTT. Works a treat! The printer powers up, prints the message, and the powers down.

One more step planned, seeing as it can only print upper case, is to make it print tweets from the (soon to be ex) president of the United States. Seems appropriate some how. (update: I did it! here)

Here's a video of it working...

Week 3

Well, I was expecting very little to happen, and I was wrong.

The environmental search came back on Monday, amazing. A detailed 31 page report covering everything from where they are planning to build wind farms near Abergavenny, and how close the house it to an active railway line. But all good.

The local search came back on Wednesday, and all looks fine.

I think we just need a draining search now, and that is it.

The sellers have their survey for the house they are buying this week.

What is also interesting is that, discussing with solicitor, it is not out of the question when it comes to selling my house to get some or all of the searches and sell or give to buyer. This may be common in Scotland but not so in England. They are done by a third party company who can provide a copy of the search to the buyer, and some buyers will be happy with that, and they are valid for a mortgage for 6 months from the date they are done. So we are working out what we need to do to make selling as smooth and as quick as possible. But more on that when I finally move out!


ASR33 Restoration

We were sent an ASR33 a few years ago, and I can't seem to find my notes on who sent it so as to thank him again, but it was severely damaged in transit.

Finally this weekend I got the motivation, and a helping hand (after lots of COVID testing, thanks Simon), to try and restore it. There are a lot of youtube videos on this, so I decide just to make a blog post. The next post on this is how to use an ESP32 to talk to an ASR33, which may be more interesting :-)


The case was badly cracked and broken, so lots of glue was needed. Even so, bits are missing.


They are available, and the youtube videos on these refer to them as written with hieroglyphics, and I am inclined to agree. They take a lot to get your head around them. But they exist, and the manuals define pretty much everything you actually need to know - mostly.


The first thing was connecting power, which you would think would be simple enough. These are designed to run on US power, 115VAC, so there is a huge transformer in the base with connectors/. The motor is a variation of the standard 60Hz motor for 50Hz, so it is still 100 Baud.

A two way connector, and a lead from the teletype with a two way plug - simple. But there were two leads with 3 way connectors from the transformer, and they looked like they were just in parallel, so I picked one to connect to the one lead with a 3 way plug. Power up and motor ran for a bit, and bell dinged, and then it all stopped.

This is where I had got to when we first got it, and despaired somewhat.

So, we tried to investigate more and find what was happening. Fuses were blowing in at least two places. So we tried to work through schematics to check the various voltages and nothing made sense, until we checked the supply power which was 230VAC. It seems the two connectors, unlabelled, are not in parallel! One is 230VAC and one is 115VAC. Changing to 115VAC and replacing fuses, yet again, and we finally got the motor running. This was a major milestone for us on day 1 and helped a lot.

The whole thing is mechanical, and the motor running is the key thing you need for anything to work. It runs all the time and has two tripable clutches that engage to do one revolution for send, or the other side to do one revolution for receive. They work independently so the whole thing is full duplex in operation. All of the logic is mechanical, it is even possible to manually feed in data while manually turning the motor and have it print a character with no power on at all! The main electrical bits are power supply components and bits to drive a solenoid to clock in the data in to the mechanical receive system.

It is a shame I never thought to try the other lead right at the start - kicking myself!


The keyboard was slightly damaged with a crack at one end and a broken nub that should take a split ring. We re-assembled it, and used screws to replace these bits and re-fitted the keyboard. There is an "H bar" that links it mechanically to the main mechanism. The design is very modular, and this one mechanical link allows a key press to kick off the send mechanism, and allows the send mechanism to reset the keypress (allowing the next key to be pressed) once the character has been sent. It is quite amazing mechanics.

Unfortunately when connected up, and motor running, the distributor continuously ran - sending characters (NULLs) all the time. Thankfully that was down to washers in the wrong place when we re-fitted the keyboard making it slight higher than it should be. Once re-done, it then sent a character on a key press and stopped, ready for the next key - well mostly.

In fact, just occasionally, it would run on and send another character. The way the keyboard works this was always a NULL which does nothing, expect if you hit another key during that 100ms and manage to encode a character which is partly sent, making a duff character (often an @ as the low bits were not sent but the top bits came in when pressing the next key, if a letter). Thankfully this seems to be down to a slight adjustment on the distributor tripping mechanism from the keyboard and H linkage.

It seems there are a lot of places where you can (and have to) adjust things!

Distributor and sending

Now the keyboard was working, and apparently sending one character at a time, we wanted to see if it was actually working. When in "local mode" (a loop back to print) we just got constant "chattering" and gibberish being printed which made no sense, so the plan was to test the sending side.

One simple step was cleaning the distributor, which is pretty simple. But we wanted to check what it was sending, on an oscilloscope.

This was a lot harder to work out - we are used to circuit diagrams that have GND, and signals, so we were looking for that sort of thing, so it was all very confusing. Connecting a scope to the two "send" pins showed nothing sensible, mostly flat line at zero.

The way it actually works is that sending is just a "switch", the distributor and other contacts mean the the two "send" pins are either open or closed circuit, no GND, no signal, no polarity, no voltage. Simply putting the meter across it on continuity test provided a voltage to allow the oscilloscope to see a nice clear trace.

The 20mA loop sending actually needs an external current source which works, via this open/closed send circuit, to send the characters on the line.

Unfortunately for diagnosing things, the trace was fine, 110Baud data, so no clue what was not working. But it did allow us to check each key was coded correctly and sending correctly. What is amusing is that the "even parity" is actually just part of the coding bar for the keys - it is an "even parity" keyboard even. There is no checking of parity on the receive/print side at all. Amazing.


Now we know the distributor is working, we tried to work out why the loop back (local mode) just printed jibberish. This is a matter of checking voltages again - there is a DC supply which is a transformer, diode and capacitor. The capacity was making odd noises as well, more so when on 230VAC, but not good. So we checked it, and it seems OK.

But checking the voltage showed a quite high AC voltages, which may explain why the cap was not very happy. Turns out that the diode was not entirely in one piece any more, and was conducting both ways.

Thankfully I had another diode, and we changed it, and bingo, nice clean DC, and the capacity was not threatening to go bang any more. It is possible that this just packed up, or maybe the 230VAC is what cooked it. Once in place, things started working a lot better - well - the print side did not "chatter" any more, confirming there was idle current.

Receive and print

Now the loopback was generating sensible voltages for the current source, the loopback could get to the receiver. But pressing keys did not print anything, well, mostly. BREAK caused "chattering", so clearly that was working, and we realised the HERE IS (answer back) started chattering part way through the 20 character sequence.

The solution - well, the main one, spraying the whole receive solenoid and mechanism with lube. Magically is started working. It seems quite a few bits are improved a lot with a little lube...

There is also a timing adjustment ("range finder") which was needed, and we needed to tweak a few times to get clean printing without mis printed characters.

The good news is the printing just worked, which is amazing.

Dating the machine

Trying to date the printer, and looking at ASCII specifications, the typewheel and keyboard have ↑ and ← characters which are only in the 1963 standard, dropped by 1965. It does rather date the machine to around when I was born!

The keyboard and typewheel are also a tad special - the manual shows the letter owe and the digit zero as uncrossed, basically they look about the same. But this machine has cross letter owe, which is unusual. It seems IBM started using crossed letter owe and uncrossed zero but dropped that after a few years, so this again dates this as a very early machine, but with slightly special IBM style keyboard and printwheel!

ASR33's are rate, but this is more so, it seems!

Tape punch

We don't have punch tape. Well we don't have roll paper either. For both the answer was A4 paper. We cut to 1" strips for punch tape testing. The tape punch just worked. Wow!

The paper tape punch was actually really quite useful for debugging as well. Trying to get the range finder right was easier when seeing the bit patterns, and how they have gone wrong, rather than trying to work out from the mis-printed characters - even with a good understanding of ASCII.

As I said, parity is just the keyboard, everything else is just 8 bits transparently handled which allows one to send 8 bit serial data that is not valid even parity to just punch "as is".

Tape reader

The tape reader does not work - the auto feeder logic runs, and spins the distributor, but does not advance the tape, or sense the holes. The issue is the send solenoid. It seems this is run from a silly voltage which requires its own power supply. This is stuck in the base under the machine.

Unfortunately this was not working - apart from a blown fuse (not that surprising), it has a broken resistor. So one ordered from RS, and we'll get that working soon. With any luck it will just work too.

This is one area where the reader is linked to the distributor using contacts and solenoids rather than mechanical linkages like the keyboard.

Update:New wound 50W resistor from RS and it works, but oddly only in local mode. I am unsure if that is intentional or not.

Fine tuning

There is a lot to adjust, and we think we finally have the keyboard working with no run-on NULLs, and the printer working with the right range finder settings. The print paper feed is slipping, so I'm trying to work out how to make that tighter to the paper and may have to strip it down.

Update: print feed OK now - more lube :-)

What's next?

The case needs fitting, and I need to print some knobs, but then it should be quite good. The plan then is to WiFi it up, allowing it to be operated over MQTT. More on that in the next blog on the ASR33.


Instant (10 minute) COVID-19 tests

You can buy tests, proper ones. I found a proper medical supplies company, and tried to order proper branded (Roche) antibody tests.

First off, these are not intended as home test kits - they are for clinical staff, or people like occupational health in a business. The later is where we come in, doing tests for staff. The antibody tests ("have I had it?") are a pack of 40 tests, and the antigen tests ("do I have it now?") are a pack of 25.

I ordered on my phone, antibody tests, £399+VAT, paid, pre-12 delivery.

I was surprised no order confirmation, and naturally assumed I had mistyped email address. Anyway, next day, 12 came and went, so I emailed in, and no immediate reply.

So I tried ordering on my Mac. Again, order went through, but nicely only £299+VAT now as price went down. At the end of the order there is an error, and even suggests does not work on Safari?

If they know it does not work, why not fix it, or write to a standard and not for a specific browser. But no, they process the order all the way to the end and take payment, and then lose the order. I assume the same happened on my phone, but probably off the screen. They could have said at the start "We are too dumb to work with the default browser on one of the most popular platforms on the planet, sorry".

So I run up Firefox and try again. This time I decide to get antigen tests too at £250+VAT. This time I get and order confirmation email and shows my order on their web site, yay. I can always claw back off Amex if not refunded for other two.

I emailed explaining and specifying the only order I want is the final one, giving order number, etc, just the two items.

They send antibody tests

Yay, 40 antibody tests, so we can test staff. Good. But why only antibody? Finally getting emails back and they say they will sort it.

I get invoice for £399+VAT

They say they will sort it. Should be only £299+VAT.

I get another box of 40 antibody tests

They say they will collect and sort it, and antigen tests by Saturday

Saturday comes and goes

They say they will be with me Monday

Monday comes and goes

Eventually, Tuesday, not pre-12, I get a parcel.

Delivery note says antigen tests x 25, yay.

Box says antibody tests x 40


They say they will sort it and collect Wednesday

Wednesday comes, and a DPD man arrives, yay. Except he arrives at the invoice address (the office).


Update: a confused DPD driver, with no labels, arrived just before 5pm, having had a message to do an extra pick up!

Antigen tests do exist

I also ordered on Friday 25 antigen tests to my colleague so he can test himself and his colleagues before we meet later in the week. They arrive. They are right. They took 2 days and not pre-12 though. Not impressed.

If I don't get the antigen tests in time, we'll be doing instant antigen tests before we start as he is bringing them with him. Even so, we'll have masks and gloves and isopropyl alcohol, etc.

Update: The antigen tests turned up - at the wrong address (office), but we have them at last. We were able to do tests before work on the teletype this weekend. Just chasing my refunds now.

More about the tests

The antibody tests are a simple blood test - around 2 drops of blood (20ul), and three drops of buffer solution from a batch controlled bottle. Note this means you cannot "send a test" to someone as the buffer solution bottle if for the 40 tests. It takes 10 minutes. I also got a box of single use sprung lancets to make it easy (and gloves, etc).

Nobody tested at work has antibodies - even though several people convinced they must have had it.

Update: One person has tested positive for antibodies now - they were notably ill last Christmas. Interesting.

The antigen tests are a nose swab, but are self contained so could be sent to someone if needed.