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:-

https://berthub.eu/articles/posts/reverse-engineering-source-code-of-the-biontech-pfizer-vaccine

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:-

PMRHMMJCHJNSEYJXMQYWCYLCGEWTMMZVG4WTIYJYGYWTSMJZMIWTSYZXGIZWKMJWGAZGKMBCFQREET2SJFJU2T2MIVJVIU2GJFJUQIRMEIZTONJUHAYDAIRMEI4DMMZUGARCYIRRGY2DCNRRGYRCYISLEIWCERZCFQREWIRMEIWSEXL5.XOHIQXDGEYPNAN6WKHZTSQFTAZUIHOJJCTQF7AIWDDT5GALD7S4LCPVCQXLJLA5PCEY3NIMBKHU5BNF7JPLX25KVFUMF2NIQ6H6JAFQ

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.

{"v1":["a7d1aab1-6357-4a86-919b-9c723e1602e0","BORISMOLESTSFISH","3754800","86340","1641616","K","G","K","-"]}

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.

NONE OF THIS NEEDS TO TAKE THIS LONG!!!

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.

Arrrrg!

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.

Paper

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.

Ribbons

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.

"Flightstrips"

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?

Guess?

...

Really.

...

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 :-)

Case

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

Schematics

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.

Power

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!

Keyboard

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.

Loopback

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

Arrrg!

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).

Arg!

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.

Week 2

Last week we had been told, on the Friday before, that "This means that the contract pack should be with your solicitor early next week." and I wondered why it took as long as it did (given that everyone wants this sorted quickly).

By Tuesday my solicitors were chasing as they won't start the searches until they get the contract pack, it seems.

Finally, Thursday, nearly a week later, the contract pack gets to my solicitors! Naturally I was assuming that this had gone by post for some historic reason, but no, that is not the case. It is all emailed scans, and was not sent until 4:30pm on Thursday.

It is not as if it has much in it, nothing that would, or should, not have been ready to go. It is copy of warranty on some building work, of planning permission, title plan, etc. Much of it I already had as I had spent £3 on the land registry site before even making the offer. This is all stuff I will certainly have ready and scanned as soon as I put my house on the market - why would you not?

Naturally my solicitor was on the case, and getting searches ordered right away, good.

But then on Friday we finally get the fittings and fixtures details. Again, this would be something I expect to be ready when you put the house on the market. Sadly there were a few missed check boxes so my solicitor has to ask for clarification. WHY?!?!

Just to be clear, all of this could have been ready, and with my solicitor, on day 1, as soon as we accepted the offer and they filled in the amount on the contract. That is all that should have been necessary. We are two weeks in to this because of delays by the sellers, when they claim to want to move quickly!

What is slightly annoying it that when we viewed the property the agent was clear that the hot tub, and the bed in the master bedroom, were "negotiable", i.e. they could be left. Both were things that are a pain to move out but have some value. So when we upped our offer to the asking price we said they had to be included, and that was accepted.

What we did not know, not until this fixtures and fittings sheet came through, was that the rather nice light fitting over the stairs, was also negotiable. Had we known, leaving it would have been part of that offer and I am sure that would be accepted seeing as we had gone up to the asking price! Now it is yet another query to be resolved.

I believe at this point we have to wait for searches to complete. As such I am expecting very little over the next week, sadly.

P.S. That light fitting is not that expensive, but the hassle is fitting one over the stairs.

Week 1

It is a week since our offer was accepted...

• Formal memorandum of sale was sent by agents (with wrong date on it)
• My solicitors only just asked for money for searches
• Apparently the "contact pack" is on its way to my solicitor
• Bugger all else has happened

When making my breakfast I consider the critical path. I put water in the coffee machine and turn it on, even before putting ground coffee in, as the coffee heating and filtering is the longest path in the whole process. I do things in an order that is efficient, where I can, especially if it is something I do a lot.

Now, my understand is that the searches are the time critical aspect here, so one has to wonder why wait a whole week before considering starting them.

Oh well. Let's see how this week goes.

Moving house

I have lived in Bracknell over half my life (so far), so moving house is a bit of a distant memory.

But I believe some people were confused by my previous blog, so worth just clarifying:-

• I live in Bracknell now - nice house, some customisation (electric locks, etc).
• I am purchasing a place in Wales, hopefully all sorted by end of this year.
• Then I will be selling my house in Bracknell, after decorator comes in :-)

I can do this partly due to things like mortgage reserve accounts (if you have one, keep it, do not let the bank try and sneak it away as they tried with me, and with friends of mine). Also I am pretty sure that if you are buying a house in Wales you are officially allowed to just put it on your Amex card (basically downsizing in price by a good chunk). You'd think this would help.

I am amazed at the time scales, really. There are "searches". OK, but have you seen how fast google can do a search. This is not the 18th century!

• Why is this not all on-line with all councils, etc?
• Why, if they are all different, is there not a nationwide aggregator that makes it simple?
• Why is it that, apparently, solicitors tend to do one search after the other, and not all at once?
• Why is anything time consuming not done as part of putting the house on the market?

Whilst joking about my Amex card (no, I don't have a limit this high), if you have the money ready and sat in an account why does it have to even take "all day" to buy a house. If it was a mandatory two week cooling off period, I could understand, but it sounds like it is just bad management of the process at every level somehow.

So yes, expect more exasperated blogs on the matter.

Also, how is it that technology knows? I have some ES8000 locks - very nice - very reliable. Both of them started playing up and one has given up the ghost, the very day I get confirmation we are moving and that their days are numbered. This is too fluky for reason. Was fun taking one apart though.

Geek's house

As you can imagine, my house has some "features" that make it a tad special.

We are looking to move (to Wales of all places). Working from home works very well, and as such it does not matter much where "home" is...

The house we will be selling, probably in January, is a nice 5 bed house in Bracknell. In some ways I am not sure what to do with the "features". To the right buyer they are rather cool and worth it, so I thought I would list on this blog post and get comments.

The plan, sadly, is to "normalise" the house, meaning removing some features. But here goes - what should I try and keep and sell.

1. Air-con - this stays as it is "normal". Four of the five bedrooms have air-con, and so does the man-cave. All the air-con is modern, already updated and replaced once even, wifi connected. Works really well for heating and cooling, and has proper planning permission. I have some nice sensors for temp and so on that work with it - open source code, but works as is.
2. Playhouse/swings - these stay as also "normal", but it is a nice feature, and kids love it.
3. IoT light switches - in one bedroom and man-cave and garden, Tasmota flashed. Most work the corresponding light so can stay, but some are blind (no direct powered light, using WiFi/mqtt to control other lights). I suspect they stay but diminished usefulness. A buyer can have all the IoT details to use them if they want.
4. Fibre and network switches and WiFi. These could go with me, and fibre terminated. Or they could stay - A&A will be happy to run an internet link from A&A office in Bracknell, at cost (a few hundred a month) even if NAT, but could have a few IPs and some IPv6. If we do nothing, this just gets ceased, which is a shame. I could leave the WiFi APs, or take with me - even an external garden AP.
5. ESP32 and Galaxy panel and Pi based alarm and door entry system, very cool. Happy to hand over logins, and the code is all open source. But default is we rip it out as not "standard", leaving bare alarm/PIR wiring in place for conventional alarm system install.
6. Electric locks on the man cave - these would be changed to boring locks with keys. Even the front door has electric release on the lock which would go. Happy to provide the details and some fobs, for the keys (AES using DESFire cards).
7. Lots of Ubiquiti cameras and recording box. Again, would go with me by default.
8. Lots of Ethernet wiring - stays.
9. The man-cave TV will have to stay - a 65" wallpaper LG OLED which is awesome, but hard to transport.
10. The man cave is awesome, and the benches all fitted, and a bar. That stays.
11. There are other cool features like nice mains pressure hot-water.

So, if someone is seriously interested, say so, and we can talk. We would sell for a fair price - but would be nice if we did not have to "normalise" some of the stuff and found a geeky buyer that appreciated it. Otherwise, by end of year this all gets "normalised", and sold as "boring".

Using MIFARE Classic in 2020

This is old news to most people, but do not use MIFARE Classic cards, they are not secure.

What was not clear to me is quite how insecure. Reading up on it a little, it sounds like several issues. Something to do with the random number generator being poor, and a nested attack. These apparently allow access very quickly, and there is even a standard command mfoc to crack such cases. By standard command I mean literally apt install mfoc, seriously.

Now, it seems, that modern cards are not quite as vulnerable, but can be cracked with a brute force attack in some way. This really shows why you don't make your own crypto, ever!

As I am doing some work with MIFARE Classic for a client (yes, I said it was insecure), I thought it worth seeing what that means in practice, in 2020. I found a site covering how to set up a hardnested attack, here.

I set up on a Pi, and realised that did not have much oomph. So I tried my very old linux box I normally use, not bad. But I decided to try my iMac. This meant a few brew commands instead of apt commands, but getting the hardnested mfoc compiled was simple.

It was a tad harder to run as the iMac grabs the NFC reader and I had to edit the Info.plist file in recovery mode to remove the ACR122U reader I am using, and compile libnfc with ./configure --with-drivers=acr122_pcsc

However, it then ran. I loaded a card where I had put a key it could not read.

It took nearly 10 minutes to get the key, and after several tests I found that was about the longest it takes, with it often finding in under 3 minutes. It will work through all of the unknown keys, and get you a dump of the card and all the keys.

This means you can read the card, and make a copy, and change it in any way including changing any "value" settings it has. Basically, it is, at that point, no more secure than a memory stick.

So please, do not use MIFARE Classic as if they are secure!

Of course, our card printing stuff at A&A will encode MIFARE Classic for you, but then it also does other insecure systems like mag stripe, and QR codes. MIFARE Classic is fine if you treat it just as a machine readable data store, much like mag stripe or a QR code - it is just not secure.

When it comes to more secure cards like DESFire, we don't encode them but we record which card has what card ID so you can encode them yourself later. This saves us having anyone's keys.

(P.S. I use MIFARE DESFire EV cards with AES for my door entry stuff)

Smart card readers

I have had a very frustrating month with the new card printer and its RFID reader.

The printer itself has been quite fun to reverse engineer, but the smart card readers were not expected to be an issue. The reason is that they are separate (built in) devices that talk USB. Smart card readers are well supported on both linux and windows.

This printer has two such readers, a "contact" station, and a "contactless station" (i.e. RFID).

Oddly, even though there are many readers, including the HID CardMan 5422 which do both in one chipset, the printer actually has two totally separate modules.

The "contact station" worked as expected (apart from needed an adjustment to allow for the gaps around SIMs). Basically, the standard PCSC / winscard stuff just sees the reader, and sees the card, and just works, as expected.

As a result I was able to make the card printing system handle contact cards, SIMs, with ease.

However, from the very start, the contactless / RFID station did not work. It showed up as a Cardman 5121 reader, which was recognised, but showed that the card was inserted already. It did nothing when loading a card on the contactless station.

I was not expecting linux support, but it did not work from Windows. It seems windows recognised the reader and was happy that it has the right drivers for it, and that it should be working. It too just showed the card inserted.

We have had :-

• Trying on linux, and it not working.
• Suppliers sending a pcsc test app for windows, which showed it did not work.
• Suppliers taking well over a week with the printer back with them testing the RFID reader. Confirming it works for them.
• My retesting, I even sent them a video of testing cards!
• Suppliers sending some MIFARE cards, in case the cards I was trying were the problem (I tried several different types of RFID card).
• Finally, suppliers send a new card reader

I was slightly worried about the lack of anti-static packaging, but it did the same, it simply showed the card inserted all the time but no actual data - on windows and linux.

Finally...

They email saying "here are the drivers you need to install". Well, I am not a windows expert, and it took me a while to convince windows to install the new drivers. It was adamant that it had the right drivers, but eventually I managed it, and bingo it works.

They could have told me it needs "special" drivers a month ago.

I admit, now I know, it did take me around an hour of googling and cursing to get working on linux on a Pi, but I managed it. I tried installing PCSC from source, and all sorts. I tried installing linux drivers from HID, but could only find x64 or i686.

Eventually I found drivers for the 5122 model, which claims to cover the 5121 in the README, and a load of others, and is available in ARM format for a Pi. Yay, it works.

A couple of hours later, and we are now doing RFID encoding as a standard feature on our card printing. Finally. And we had our first order, for some cards with pictures on them and NTAG encoding of a URL for a photo site for a couple (looks like a birthday present). Yay! All working, just hold a phone next to the card and it pops up asking if you want to open the web page.

Ampersands are fun

We have issues with &, but it is still being fun with the confirmation of payee stuff.

People trying to pay us using the name :-

ANDREWS&ARNOLD LTD

Are told that we are not an exact match, but that we are :-

ANDREWS ARNOLD LIMITED trading as ANDREWS ARNOLD LTD

This is wrong!

We are in fact (on companies house) :-

ANDREWS & ARNOLD LIMITED

Why is this an issue?

There are a couple of issues :-

• It is wrong, but does that really matter?
• It confuses people trying to pay us, thinking something is wrong.
• It encourages people to ignore warnings
• Someone could register ANDREWS ARNOLD LTD, which means the bank are claiming we are in fact a different company.

(Oh look, company 12972728 is ANDREWS ARNOLD LIMITED now)

The real issue?

For me, this is an annoyance which I would really like fixed, but I know mistakes happen. I know all about XML, and ampersands, and protocols, so I do understand.

If the issue is with pay.uk and the confirmation of payee system, then they should fix it. If the issue is the bank, then they should fix it.

What I really really dislike is being lied to, and people making up crap excuses.

Clear this is happening.

I am not happy.

The excuse...

The confirmation of payee system only allows letters and numbers. Special characters like & are replaced with a space.

Well, maybe, but maybe not. It is possible that for matching this happens, but if that is true, then ANDREWS&ARNOLD LTD becomes ANDREWS ARNOLD LTD, which is exactly the trading name reported back as the near match. So if that was true it would be an exact match!

Also, when paying Barclays, we see a near match reported as :-

So clearly Barclays are able to send an &

What needs to happen.

1. Don't make up excuses or blame other people. That pisses me off.
2. Fix checking, clearly (however pay.uk passes it on) ANDREWS&ARNOLD LTD should match ANDREWS & ARNOLD LIMITED. So allow it to.
3. Match LIMITED to LTD (as companies house does) rather than listing a separate trading name with LTD
4. Send the right name back on a near match, i.e. ANDREWS & ARNOLD LTD

(OK we are changing name from LIMITED to LTD to avoid the trading as crap)

Why A&A are asking you to ask for a PAC?

Update: It looks like we have come to an agreement - way more than I was expecting to pay, but way less than £20k and just on the level of "less hassle than contacting customers". So you won't get an email from A&A about this.

A&A operate some 07 mobile services. These are services that operate an 07 number for incoming and outgoing calls and SMS, and are normally linked to our SIP2SIM service to relay to/from an actual mobile, or diverted to a mobile. The nice thing is that you can be "in the loop" on the mobile calls and texts and handle them in your own systems - e.g. call recording, logging, etc.

What is going to seem odd is that, shortly, we may be emailing all customers of our 07 numbers asking you to log in to the control pages and request a PAC for your number. A PAC allows you to move to a new retail provider.

Why would we do this?

The answer is simple, we have grown increasingly unhappy with the company we used to handle our 07 numbers. We have a new supplier now, who are really responsive and helpful. One of the main issues with the old supplier was how slow they are to answer any queries.

The way mobile services work is that you can get a PAC and change network, simple. For most operators this is a text that returns an instant PAC you can use. Sadly this company do not do that and we have to email, and wait for reply. Given PACs are meant to be issued within a couple of hours this is a tad frustrating. We were promised an API to get PACs years ago (13th April 2017 was "PACs via the API is a couple of weeks away"). The lack of PAC API is one of many annoyances. The new company do PAC via SMS, and that is indeed instant.

So we want to move a lot of our numbers to a new provider. We can't actually move them all, as some cannot be ported (!). These are numbers with no incoming SMS either, which is why we tried to port them. Yes, that is one of the many annoyances, and was pretty much the last straw to be honest. Yes, OFCOM require porting to be agreed, and the new provider are happy to try and sort a Porting contract for those numbers, but OFCOM do not have any time limit on how long that could take. It could take years, apparently, especially with a supplier this slow at answering any queries...

What we need, for the numbers we can port, is a "bulk PAC", a single PAC for the list of several hundred numbers, we then give to the new provider and they all move. Simple.

Unfortunately, the existing supplier want around £20k to cover the admin of issuing this bulk PAC. Not something we ever agreed in our contract. Basically, unless we agree to this, they won't issue the PAC and won't let us move. In my opinion this seems a lot like "blackmail", holding our customers' numbers ransom unless we agree a huge divorce bill which was never agreed in the contract and is clearly unreasonable (no way £20k is an admin fee), though technically probably not legally "blackmail".

I said "we'll just ask our customers to ask for a PAC and use that", to which I was told that would still be a wholesale move and so the fee applies. I said "I'll make a new company, and ask customers to move to that" making it a retail move. No reply, and no reply to several follow up emails (one of the main reasons we want to leave is lack of replies).

So basically, this is what we are doing. Obviously I am ensuring we are 100% technically correct (the best kind of correct), and am making a new company (subsidiary of A&A), and asking customers to move to that retail provider. Once this is sorted we'll seamlessly move customers back to A&A, no problem, but to ensure we are correct and within the OFCOM rules for issuing individual PACs for free for a "retail move", it will be a separate company (who contract for A&A to do billing). I'll even create the inter company billing (net zero) and file accounts for this short lived new company. All above board and proper. Total cost under £50.

Making a new company is cheap and easy (as you can see with company 12972728). I'll go for a more polite name, maybe ((📱)) LTD perhaps.

So the supplier has a choice - the easy way or the hard way. Either hundreds of separate retail PAC requests, each of which needs to be issued within a couple of hours, and for free, or they can issue the bulk PAC we want. I'm even happy to pay a nominal admin fee of £100 or so for the admin work.

Who is it?

Well, I may publish this - it is a small company since taken over by a larger company, but we think this is one individual being "difficult" for no apparent reason.

We'll notify customers with instructions when we do this.

I hope they do opt for the easy way and we don't have to contact customers. We'll do a status post if we do this behind the scenes but it should be seamless.

Reverse engineering

Reverse engineering can be fun - and I usually end up doing it where a supplier does not provide linux based drivers for something.

This is the case with the card printer we use. We have gone through many card printers over the years, including an Evolis pebble, a Zebra, a Matica printer and now a newer Matica printer. Each one lacked any linux drivers. What is also a shame is they did not publish the interface so someone could write some.

This is where regulation could be an interesting option - publishing specs to allow interworking of systems. There is much debate on this, and something for another blog.

However, with some debugging and reverse engineering, I have working drivers for all of the card printers.

Why Matica

The XID9300 and XID8600 are "retransfer" printers - they print on a transfer film, and then transfer to the card. This works really well on SIM cards. The Zebra was too, but did not like cards with gaps or contacts (e.g. around SIM), but the Matica is really good. Retransfer also means proper edge to edge with over the edge bleed on artwork.

Not your typical printer

Usually a printer is write only - you send a print job, it does it, job done. But the card printing is a little specialised. You may want to load a card to a "contact station" (e.g. a SIM) or "contactless (RFID) station", or mag stripe encode or mag stripe read. The way these contact stations work is a pain, but seems pretty industry standard - the printer itself takes a hands-off approach - you tell it to put the card on the station and then talk to something else (over USB) to "encode" the card.

It is also not quite as simple as just sending the print job, even when not encoding a card - you have colour and black, and you want control of each separately (the black is 1 bit per pixel and crisp solid black on top, but the colour is 8 bits per colour). You also have the fact the card has two side, and can even have a UV fluorescent layer. So you need to be able to send "layers" and "sides".

What I wanted was a way to do all of this but over Ethernet from remote systems. We have many systems (like our control pages) from which we need to send card print jobs and encode cards.

I decided to use a TLS over TCP link and send back to back JSON objects each way. It worked well as a system. I also decided that image data to print should be sent as PNG images coded as base64 data URLs in the JSON. This worked surprisingly well, and I have a handle on how the png linux library works now (an annoyingly complex library).

The interface also allows exchange of hex data strings to send to/from a contact or RFID card allowing any "encoding" I wish. This is the key thing that the client does not have to talk to something separate to "encode" cards. It also allows me to hold a job all the way and not have other jobs sneak in whilst trying to encode cards (which happened before).

Ethernet

The previous printer, in this case a Matica XID9300, has Ethernet or USB. I had working drivers from long ago that just did printing, and separately had scripts to talk over USB to the cards. Not ideal.

The new printer is a later model Matica XID8600. This too has Ethernet or USB, but instead of being a setting in a menu it picks one. If USB is connected on power up it is USB. If you want to use Ethernet you must not have USB connected (has an internal USB hub). But if you want to encode cards you have to have USB connected, and if you want to do what we did on the XID9300 (Ethernet print, USB for encoding) you have to unplug USB during power up every time - WTAF?

This was only really apparent after I had written some nice new Ethernet based drivers - a combined system to print over Ethernet and talk to contact stations over USB, all using this TCP TLS JSON connection to the client.

Basics

The basic steps are "use the windows drivers" and "observe what is sent to printer". Wireshark is your friend, and I was able to see the Ethernet traffic sent to the printer. There was a nice obvious message structure.

I was really lucky with this printer though as there is a diagnostics tool that the suppliers sent, one they use for maintenance/repair and testing. It has buttons and check boxes for each operation - load a card, move a card, load image data, print images, transfer image to card, etc, etc. And control of all of the settings.

This allowed me to test each operation separately and each option separately and dump the messages. This is absolute slog from a coding point of view - it is spending days trying each separate command and option and looking at hex dumps to work out what each option and setting does in the underlying message. It was tedious.

Once you have that you make test code to generate the same messages and confirm they work, and then build a driver with all of the functions you need.

USB

Whilst I know a lot about Ethernet, I know bugger all about USB. But to avoid the whole "unplug USB during power up" issue, I decided to give it a go.

I was pleased to see that Wireshark comes to the rescue again, and allows dumping of USB traffic on windows. This allowed me to do exactly the same slog of testing each operation and seeing what is exchanged with the printer.

What did I expect?

I expected the XID8600 to be similar to the XID9300, and I was pleased that they were almost the same (Ethernet drivers), but different ports.

The Ethernet has a simple packet/message system - a header with type and length and a variety of commands and parameters. I expected USB to be an alternative way to talk to the underlying printer system and so essentially to be the same with maybe different headers more suitable to USB.

How it works!

I was shocked!

Not even close, not at all, really, crazy. It is like two separate printers! Yes, the underlying operations you can do are the same but the commands and parameters are not remotely related.

Some examples of the craziness.

• Ethernet has a "transfer" command with an option of where to move the card to after (eject, reject, back to print station, etc), and a flag to say if to flip the card. The flag and "location" code match the card load and card move commands. But on USB there are three separate transfer commands (return, eject, flip) and a flag for "immediate" (no clue what that actually does).
• Ethernet has a way to get and set some "settings". These are one byte values, and you send a list of tagged values and get back a list of tag/value pairs. To change you send tag/value. So a setting has a "tag" which is a byte, no real logic to which setting is what tag, but I went through each and documented. But USB is not the same, no, not close. You get settings by two separate commands getting blocks of binary data (64 bytes and 14 bytes), and various bytes are various settings, but their position is not related in any way to the tag used in Ethernet. It gets worse, to set these you send two blocks (32 bytes and 10 bytes), where the settings are specific positions (but not related to the ones you fetch). But then if you want to set some settings just for the job, there is a single block of 24 bytes that have most settings, again in different positions.
• The mag stripe coding messages are similarly different.
• The film layers have numbers when loading the image data, on the Ethernet they were C, M, Y, K, P, U, but on USB the are K, Y, M, C, U, P, just to be different. When printing the them there is a mask of which to print - for Ethernet it is bit numbers for each layer but always prints C/M/Y together if any set. For USB there is a bit for K, YMC, U, P, instead (so obvious that YMC always together).

(Yes, they persistently use YMCK 👷🤷‍♂️ rather than the more common CMYK, which has led to lots of typos in my code)

Basically, it is like two completely separate specification written independently to meet a list of commands and options. Totally separate logic to how they are coded and the how commands are grouped, and so on.

In addition, the USB used a command structure that seems to be based on USB mass storage, using SCSI commands, or possible mis-using them as Wireshark was not entirely happy with some of them. No idea why they would use that structure, perhaps allowing some standard library to be used from Windows.

The good news

Having coded USB for this I tested on the older XID9300. It works. I was shocked!

Deleting code

This led to a decision to delete and remove all of the Ethernet driver code I wrote. The concept for this project is a Raspberry Pi next to printer acting as a single contact for TCP TLS JSON printing. I have a library for the code to run the client side of this as well. The connection from Pi to printer can be USB with no issue, and indeed is possibly easier than having Ethernet from Pi to printer (needs more config to say IP, etc). So using USB is all that is every required (and marginally faster than Ethernet, oddly).

Deleting code is not something I like doing, but in this case it made the code simpler and made for simpler ongoing maintenance. With both drivers - any changes had to be coded and tested for each way of working.

TODO

There are aspects not in the drivers (yet), e.g. we don't have the JIS (Japanese Mag stripe coding) hardware to test that (though easy to code anyway), and we don't have a laminator attachment. So a few bits are not there.

New features

This means we can update our card printing service...

• 600dpi instead of 300dpi.
• The UV print no longer has at the MAC address overlay (windows has it but I found the bits to turn it off, yay).
• We can get the "ID" of an RFID card and store when printing so the API we offer allows you to tie a printed ID to the card ID later for coding - that way we don't need your keys. We even allow the ID to be part of what you print.
• We plan to offer basic MIFARE classic coding of cards (but really, that is not very secure).
• We plan to offer MIFARE DESFIRE coding, but means giving us keys.

All in all a good few weeks work on this. I was, however, rather pleased with myself (having spent a day with wireshark) making working USB drivers in a (long) day this weekend.