Fun with QR library

My QR code generation library works well, but one of the features was generating a "colour" QR code. No, QR codes are not normally coloured, the idea is to just show the anatomy of a QR code, which parts are which. Wikipedia does a good job too.

As part of generating the code I have to create the data part, and padding, and then generate the error correction code (ECC) part, and apply various format control bits and fixed black/white units to make the image.

I have updated the library so it will make a QR code which shows what is what. It was a tad complicated by the fact that the error correction code is interleaved. This means that blocks of data and ECC are scrambled so that each block is actually spread out over the QR code. This means you can remove a chunk of the code - e.g. tear off a corner, and that is a small part of several separate blocks. You will notice the padding (green) below is spread out because of this interleaving.

Each block of data and ECC allows recreating of the data from a relatively small part of the overall block, so the distinction between data and ECC is not that relevant. But the colour coding shows how much is used for what quite nicely even so.

This has colour coding for :-

• Blue: the actual data for the content
• Green: padding bytes and bits
• Red: the ECC code
• Grey: formatting/control
• Black/White: the fixed pixels in this size QR code

So that is it, just in case you wondered...

(That one above is an NHS COVID-19 QR code).

P.S. I have been having more fun with custom padding bytes. This is not just changing units within the tolerance of the ECC (which can be done, if careful), it is changing padding so that the ECC is still valid.

Of course, if you want to get a bit meta, you can put one type of barcode in the padding of another type. This is a Datamatrix barcode in a QR barcode. A real Frankenstein barcode!

Technically the padding is meant to be a repeating pattern EC/11, and surprisingly this is not just a recommendation in the spec. But obviously nothing checks the padding on read, so allowing pretty padding and hidden data in the padding to work.

The blue M&M test

There is a famous story of the Van Halen concert contract requiring the removal of some M&Ms. It is a test to confirm that the contract had been read properly. Clever idea. More on that at snopes.

However, I first encountered it from a friend who referred to it as "The blue M&M test" and explained the story, which I indeed thought was clever.

But there is a problem! As you can see from the Snopes article, the actual story is that they banned brown M&Ms, not blue ones.

So where did this come from? Well, my friend is adamant he always heard it as blue.

Try googling.

Yep, 2 results. Guess what they are? My blog!

Sounds like my friend did not read the contract properly, and so failed the test :-)

Tech: Managing calls

I have just issued a new alpha release of FireBrick, by popular demand, allowing some call filtering based on CLI. Basically you can do a lot more than simple anonymous call reject now. Whilst most people know the FireBrick as a firewall/router it is also a SIP VoIP PABX (phone system).

But one of the things that this highlights is the increasing need to "do something" with calls you receive. Systems like the FireBrick allow you to do all sorts on your own network, making your own "phone system" for VoIP phones. If you look at systems like asterisk the level of controls you have are quite incredible - essentially a programming language for how calls are handled and even allowing recoded messages and DTMF menus and so on.

On a private system you also have means to log things and even manage call recordings yourself.

This is all great for a "desk phone" but what about your mobile?

This is where some of the stuff we sell comes in - and we have customers doing some clever stuff. Recently we have managed to make a few improvements, but basically we have means to have a normal 07 UK mobile number, and a mobile SIM, and put your own phone system (whether FireBrick, or asterisk, or anything else) in the middle.

This means you can have a mobile phone with a SIM card, and do things like log, or filter, or record calls, and texts, either way. The SIP2SIM service looks like a VoIP handset has registered and connected to your phone system, but is in fact a normal Mobile telephone service (i.e. no special app on the phone). This means you can even make internal calls on your phone system from your mobile. (The mobile leg does have call costs even for these).

The texts can be passed by email or using http/https on your own server where you can do things with them. The latest improvements mean much better handling of unicode characters as well. You can also handle the texts from the mobile. You could just join the dots to make texts or calls, in and out, like a normal mobile, or you could do much more with your own scripts on the way.

We have people doing things like opening doors using calls, and clever tricks with texts.

Obviously we also have services that simply link calls, or texts, or both, in and out between an 07 mobile number and the SIP2SIM service without needing your own phone system. We have options like call recording and logging. But we are happy for you to make your own systems, as simple or as complex, as you wish in the middle.

Of course this also allows mobile on a normal landline style number, but texting to such numbers remains a challenge in the UK, and a lot of companies and web sites will refuse to even try texting what they think is a landline number. So using a normal 07 mobile number does the trick nicely.

We can even port in an 07 mobile number to the service, and if you don't like it, port back out again. No minimum term on the SIP2SIM or VoIP services.

So if you are techie, but want a lot more control of your mobile phone service, it is worth taking a look.

One little trick I do a lot is steal a call, transferring it between my mobile and my desk phone mid call, without the other party even realising I have done it. E.g. answer on mobile, walk to desk, put on headset, switch call to desk phone and work on computer while on the call. All seamless.

UK government digitally signed my penis!

It appears that the COVID-19 QR code generator government web site does not allow emojis, but it does allow hieroglyphs, so it seems I have managed to have the UK government digitally sign a penis.

The QR code, signed by the government/NHS, includes

{"id":"53WVKKW5","opn":"𓂸","vt":"005","pc":"SW1A2AA"}

I know it is childish, sorry, and you definitely should not check in to 10 Downing Street by using this barcode, obviously. That would be bad. It does show how daft it is making these QR codes so huge by digitally signing them though.  See the other blog post for more details on these QR codes, and what else is wrong with them.

There is a practical use though - making a QR code for your own home will allow you to "check out" of where you have been, otherwise the app assumes you were there until Midnight.

For those with character set challenges, this is what it looks like

How not to QR (NHS COVID-19 App)

There is now law requiring (from 24th Sep) a QR code to be displayed in various premises so people can scan it in to the NHS COVID-19 App. See The Health Protection (Coronavirus, Collection of Contact Details etc and Related Requirements) Regulations 2020. The law has plenty of issues, but let's look at those QR codes...

It seems you can request the QR code poster for your venue, see here. The poster is emailed to you.

This is an example.

This is not how you do it - and I wonder if they got any technical advice from anyone on the matter first.

What's in this huge QR code?

The content of that QR code is: UKC19TRACING:1:eyJhbGciOiJFUzI1NiIsImtpZCI6IllycWVMVHE4ei1vZkg1bnpsYVNHbllSZkI5YnU5eVBsV1lVXzJiNnFYT1EifQ.eyJpZCI6IlJLWTMyV01SIiwib3BuIjoiUFVCTElDIFRFTEVQSE9ORSIsInZ0IjoiMDA1IiwicGMiOiJMRTE4M1RFIn0.ix66d7uRe_vhpB4BPb0Nzbq2vEC3IShdX7UOqfp0XVyg7YI88R_bOCY1DpgQZo9dy07xcga4e1MTmcKV9ZHi1A

The data contained is an RFC7515 JSON Web Signature (JWS) base64 coded string which contains:-

• {"alg":"ES256","kid":"YrqeLTq8z-ofH5nzlaSGnYRfB9bu9yPlWYU_2b6qXOQ"}
• {"id":"RKY32WMR","opn":"PUBLIC TELEPHONE","vt":"005","pc":"LE183TE"}
• Binary signature

So what's wrong?

• It is not user friendly - and requires the app installed first so you can use it (see below). This is perhaps the biggest issue. P.S. even with app installed, they have not hooked the QR code to the app, as they could have, so could be used from camera app - just lazy!
• This QR code is far too big (i.e. dense)! The denser the code the harder to read reliably. There is no need for it to be this dense. A small code is quicker and easier to read.
• One reason it is dense is poor choice of QR encoding options. It could be less dense with exact same content easily.
• Another reason it is too dense is that the content is base64 coded JSON which itself contains base64 binary. This is crazy. The actual underlying data is quite small, and even signing it, it does not have to be anywhere near as big.
• Another reason it is too dense is they have chosen to sign the data, which is pointless (see below)
• Another reason it is too dense is they have chosen to encode some simple data (venue ID and name) in JSON, when there really is no need.
• You have to use the gov web site to make the QR code, a large company could not, for example, automate making posters for all their sites centrally.
• This is not actually a valid QR code! Yes, pretty much everything will read it, but the specification requires a 4 unit white space all around, and this does not have that - it has grey at 2 units and text within the whitespace area.
• If you request a poster more than once for a venue, you get a different venue code, so the app will see each poster as a separate venue, it seems. I can easily see that happening as it may be easier to request a new poster than to find the PDF / email you previously saved if you need to print more.
• Oh, and the instructions are to display the poster and ask people to scan it with the app, as soon as you get it, even though the app is not actually working yet, so people cannot scan it with the app!
• The poster has no link to where to get the app, just the store you have to search, and guess what, searching does not work (depending on exactly what you type):-

In summary this is thrown together with some standard libraries and very little actual thought - is not even a valid QR code, and is going to be a mess with every waiter now expected to provide tech support on app installation on Android and iPhone to every customer that comes along - but this is very much what we have come to expect.

On another small technical point, base64 is a bad choice in a QR code. If designed for just the app to read, use binary coding which is 100% efficient (one dot per bit, before any ECC). Base64, however, uses byte coding, so 8 bits for each base64 character which holds 6 bits of data, so 75% efficient. If you don't want to use binary, use base32 which uses alphanumeric QR coding, 5½ bits for each character which holds 5 bits of data, so 91% efficient.

How to make it more user friendly

Many people have QR readers built in to their phone, for example an iPhone will pop up with a link from the camera app itself, so there is a really simple trick for this - make the QR code a URL which the app can read as data, but if used simply as a URL itself you end up going to a web site which redirects you to the app or the app store to download the app. The data can be after a # in the URL so not even sent to the server when used as a URL. This allows it to be used from the app or from the camera, and helps for people that don't yet have the app, and those that mistakenly did not realise they have to launch the app first. It makes it a lot simpler to use.

It is not hard, basically, instead of UKC19TRACING:1:blah use https://c19qr.uk/#blah
(well, obviously, an nhs.uk domain would be used)

(Update: Just to clarify, the use of a URL at the start is not to make the QR code usage rely on an internet connection or a web site in any way. If the app is installed it would be used purely as a version/ID confirmation, like the UKC19TRACING:1: string, and the app would then just use the data in the QR code, not visit a web site. The URL is there to make it easy for people to use from camera, and to install the app in the first place).

Why is a "big" QR code a bad idea?

I have added this to clarify a little why the large / dense QR code is not ideal.

For a start, from a purely technical point of view, it is just unnecessary. You need some extra data to avoid confusion with other uses of QR codes, which is what the UKC19TRACING: is for, and ideally a version, which is what the 1: is for. Beyond that you just need the actual data (location code, postcode, and venue name, in this case). There is no need for extra syntax (e.g. JSON). Indeed, some careful choice of data (e.g. using digits, or upper case letters and digits) can make the QR coding even more efficient. But this is far from the only reason.

In ideal conditions it does not matter if you have a large/dense QR code. As someone that has been messing with barcodes for around 40 years, I have no trouble using a camera phone to read a barcode. I know what hoops the phone / software is going through to make it work and how best to position the camera. But I cringe watching people do this and struggle (notably, someone I know reading lottery ticket QR codes). They (understandably) don't know how these things work and will randomly try getting closer or further away, usually the wrong way, not waiting for camera to focus, etc, eventually reading the code.

The way it works is the camera has to be able to see the units, i.e. the black and white squares that make up the code. The camera itself has pixels (dots) with which it can see. If the camera was perfectly aligned and square you could read a QR code with one such pixel per unit, but that never happens, and in practice you need a lot more. Throw in the possibility of poor focus, glare and reflection from glass / perspex, dirty lens, and the QR code at an angle, and you need even more. Thankfully most modern camera phones are high resolution enough to cope and read a very large and dense QR code. Not all phone cameras are made equal and some are much lower resolution and slower to focus. Print quality also matters, and whilst most printers are very good, remember this is also intended to be used displayed on a screen. The QR code itself includes error correction which allows some imperfections and errors to be corrected, but this can only help so much.

Even so, perhaps the biggest issue with a large and dense QR code is the range of distance between the code and the camera. This is a thing I observe people struggling with, for some reason. With a low density QR code the camera can read it when it is small in the view of the camera. Also, when it is small in the view, they do not have to point directly at it, it can be off to one side, etc. With a large / dense QR code the camera needs to be closer, with the QR code filling more of the frame. So the usable distance range where the code can be read relates directly to how dense the QR code is. The more usable range, the easier it is for the user to get it right first time and not hold up a queue of people trying to get in to a bar.

Of course the other issue is how big you print it. The guideline for this is to print at least A4. Why? Because it is so dense. A smaller code could be printed much smaller and still be easy to use. I note, for example, Costa have small table menu cards with the check-in QR codes they used (which are nice and small) on them, and they are much smaller than A4.

One final reason is confusion and paranoia. I already see people on twitter asking what the hell is in this huge QR code. People are concerned that it obviously contains a lot of data and it is not obvious why. The whole project has suffered from privacy concerns already, and this does not help.

Why is signing daft?

Signing means that there is an extra chunk of information in the QR code (making it a lot bigger/denser) that ensures the data is genuine, i.e. that it definitely came from the government QR code generator web page. There are many good reasons to sign things, but not in this case.

The signing a tad daft as :-

• Anyone can make a code for anywhere on the gov web site, and it gets signed.
• You can copy a code from somewhere else and it is signed.
• It makes the QR massive! and so harder to scan.
• Obviously not done to try and avoid vulnerabilities, as one can get 
  سمَـَّوُوُحخ ̷̴̐خ ̷̴̐خ ̷̴̐خ امارتخ signed, no problem (which some may remember would crash iPhones).
• To be quite frank, it would not be as fun making a barcode for Specsavers in Barnard Castle if the QR code was essentially just a postcode and name, and not government signed.
• If, instead of signing, they just published a specification (as done by other countries), large companies with lots of sites could have made posters for all their venues centrally and easily as well as allowing individual posters via the gov website.

Whilst this is not quite the way the track and trace process works, if some establishment did not want to risk being shut down, they could put the barcode for a competitor, maybe with a vague establishment name in the QR code, so not obvious when using the app. The gov website lets you make a signed QR code for anywhere, and even if they did not, you can literally copy a signed QR code you can see anywhere, and it is still signed.

A further update (Oct 20th) shows the signing checking did not even work on Android!

What I couldn't say in this discussion before, and can say now, is that the signature verification was fluffed on the Android app: https://t.co/zmJ55fyPQk

— zofrex (@zofrex) October 21, 2020

And yes, they will sign almost anything. Emojis seem to be banned, but hieroglyphs are not. So I seem to have got the UK Government to digitally sign a penis!

{"id":"53WVKKW5","opn":"𓂸","vt":"005","pc":"SW1A2AA"}

How it could be a lot less dense, so easier to read

As an example, if I just include the actual data, and some sort of signature (an MD5 in this case, there are many ways to sign things), and a URL prefix to get the app (which acts as ID/version), you could make a code like this... Way less dense, and easier to use.

If you don't sign the data (and why would you?)

All that is really needed in the code is the location, a postcode with DPS, e.g. LE183TE9Z, or maybe just a UPRN (Unique Property Reference Number), e.g. 100032050996. The postcode/DPS may be better as you can then quote the venue postcode in the app. You probably do need the venue name as well to quote in the app. That is not a lot of data that is actually needed.

If you do that, you can make a code like this which has a URL, UPRN, and premises name in it, and is way less dense and easier to scan.

With just a postcode/DPS it is possible to go even smaller!

Is the app OK though?

Just to be clear, this is criticism of the QR code not the track and trace app. There is a blog on that which is quite interesting, but does not explain why they felt it necessary to sign the QR codes, or why they did not make them a URL format for easy access to the app. Here: https://www.ncsc.gov.uk/blog-post/nhs-test-and-trace-app-security-redux (the previous app described here https://www.ncsc.gov.uk/blog-post/security-behind-nhs-contact-tracing-app)

P.S. I have a QR code generation library available free on GitHub. here.

Dull images

I have been busy on all sorts of little things, none of which seemed worth blogging.

But one of the more fun little distractions was fixing my photo site. I upload images direct from camera on wifi, and they have Exif data extracted and all put in a database. But it was slow, and I ran in to a slight snag with the latest camera. It is still slow, but a complete rewrite of the javascript and the C/database backend has made a hell of a difference.

I am recording images in HEIC (Canon HIF) files. This is 10 bit colour and set with absolute minimal compression. It seems a good compromise. Obviously Canon raw files would be better, and JPG would be easier, but I thought I would give these a try.

There is a nice library called libheif, which has a tool heif-convert which converts the image from the Canon HIF file to JPG. Sorted, or so I thought. I do have to use the latest version as Canon use something odd, it seems, in the header, but that does work.

Unfortunately I am then in a world of weird with colour profiles. The resulting JPG is reduced to 8 bits per colour, as expected, but also has a colour profile applied. This works fine when viewed on my mac and in some browsers. However, it breaks, badly, in other cases. Notably viewing in firefox (even on Mac) and if sent to some social media - twitter just strips the colour profile. Facebook makes an effort. The other issue is various tools to get a thumbnail or make a scaled image, also strip the colour profile. So I had to make things re-apply it at each stage.

The problem is that without the right colour profile the images look, shall we say, dull!

These three images a) with colour profile, b) with profile stripped, c) converted profile.

Update: Blogger fixes the "preview" on image a) here, click on it in firefox to see the problem!

The solution was to use a tool called jpgicc which will convert profiles really quickly on JPG files. Just running it with no options to understand the original profile and convert to a default sRGB for JPG works a treat.

This was not the only issue. The convert from HIF tool also had some slight challenges, but the library allowed me to make my own convertor. The main issue was that the image was coming out of the library rotated correctly - e.g. a portrait image was portrait. This is great until you copy over the Exif data, which says the image needs rotating. The end result is a JPG that claims to need rotating. I was able to strips the rotation from the Exif.

With these two tweaks I now have JPG files that look OK on the photo site, and work for preview on social media, but the raw HEIC available for printing, etc.

I also made nice social media preview links, e.g. https://k.gg/213678

And yes, I know, my photo site is k.gg now, sorry, challenging times.

Pseudo C++ using cpp (the RevK macro)

I am not sure if this is evil, or genius, or both. Either way I take full credit.

Mainly for a library where we want to add extra optional options in the future, so want almost C++ style optional and tagged arguments to a function, but in normal C (because C++ is just evil all by itself).

Not quite as flexible as C++, as no defaults for missing arguments, but you can often live with that knowing they are zero or NULL.

Unless someone can cite a prior art - please call this the RevK macro.

P.S. I have updated my string decimal library to use this, and it is way neater!

Some explanation...

Normally a function call in C has a fixed set of arguments. Well, not quite, some can have variable arguments at the end, like printf(...) but that is handled in a special way and you have to know (usually from a format string) how many arguments and which type.

However, in some languages, like C++, you can have optional arguments which are pre-defined types and names, but you can stop early in the list. In C++ you can say what default these missing arguments have. You also have the option to leave some arguments our and "tag" some others.

So, the idea you can call myfunc("hello",flag2:1) is setting the first argument (s), and the third (flag2) and not specifying the middle one (flag1) which ends up zeroed. I can't set defaults but can expect unspecified to be zeroed.

Now, normally, if I had some function you call as func(a,b,c) and I want some extra option later on, I would have to either change to func(a,b,c,d) everywhere it is used in every program, even if people specify d as 0 or NULL,  or make a new separate function that takes the extra argument as an alternative, e.g. func2(a,b,c,d).

With this trick I am able to add this extra argument which is optional, knowing that if the extra argument is not specified it has a known value of 0/NULL.

The way the trick works is by using the standard C pre-processor which does text substitution, and expanding the full list of arguments (...) in the macro (as __VA_ARGS__) within a structure initialisation. Unlike function arguments, C has a syntax to initialise a structure which allows you to omit arguments and tag arguments. I am using that syntax in the function, so myfunc("hello",flag2:1) becomes a structure initialiser {"hello",flag2:1} and this structure is passed to the function.

Of course I could just used C++, but that comes with a lot of other baggage, and not something I am that keen on. It has its merits and works well for some applications.

💩

 I have been involved with SMS (i.e. text messaging) for a long time. I was even on the ETSI committees that designed GSM (not specifically SMS, sadly), and have been doing things with SMS for nearly 30 years in one way or another, including an SMS->fax/email gateway, and even the ETSI landline SMS module for asterisk. Now, at A&A, we have code to send and receive SMS via a variety of carriers and even a SIP a-law based ETSI landline SMS system.

The specification for SMS is a typical telecoms specification - very different to internet specifications where single bits packed in some small data header can subtly change the interpretation of some or all that follows. These specifications are normally very precise but absolutely horrid, in my view.

But where does the pile of poo come in, and how does it relate to a 30 year old specification for SMS? Well, you may be surprised, but SMS allows for 💩.

SMS are actually coded in the signalling used for calls, and so had limited space. There were actually only 140 bytes (or more correctly octets) of data for the text itself. As you may know SMS allow 160 characters, so this is achieved by packing a 7 bit alphabet in to the 140 bytes.

In fact SMS allows 4 ways the data can be coded, a 7 bit special alphabet, an 8 bit Latin-1 alphabet, and 16 bit unicode (allowing 70 characters). There are also ways to send one longer message in smaller parts. The SMS can also be raw data to be sent to a SIM rather than displayed. Had I written this I'd have used 2 bits to say which it is, but no, the specification uses a Data Coding Scheme which is complicated to say the least. Some times the coding is in 2 bits but others it is implied. It is not fun.

The 7 bit alphabet is sort of ASCII, but does allow some interesting characters - being a European spec it includes some accented characters and even some Greek letters.

Of course this also leaves out some key ASCII such as {, }, [ ], and does not even have € (which was added later). These are coded as two character sequences using ESC.

The 8 bit character set is just normal Latin 1, and the 16 bit is unicode. The unicode allows all unicode characters U+0000 to U+FFFF, but where is pile of poo? It is U+1F4A9 which is too big for 16 bits.

The way this is done is to use a little known trick called UTF-16. There are reserved 16 bit unicode characters U+D800 to U+DFFF. Using two such codes it is possible to encode U+10000 to U+10FFFF.

This means 💩 is actually coded as two 16 bit sequences, 0xD83D 0xDCA9 in SMS!

Why does this matter, I mean, who sends 💩 by SMS? As you can imagine, in the early 90's nobody had heard of 💩, and the best emojis we had were :-)

But we do care, honest, as we use it as a blue* M&M test for carriers we deal with. If they have enough attention to detail to handle a pile of poo they probably have the rest sewn up, technically. We are working with a new carrier for SMS messages, and I am pleased to say the unicode is working. They properly translate to/from UTF-8 coding in the messages we exchange (which is what we use internally). Unlike our previous carrier who could not cope. (* see comments)

We have seen a range of such failures, even the case where one carrier could not handle an @ symbol (presumably as it coded to 0x00 which is an end of string in languages like C). Thankfully that carrier was happy for us to send a raw hex TPDU for SMS, and hence allowing us to code any characters. Our SIP2SIM service has handled pile of poo since we launched it...

The end result is that, shortly, we will be handling a lot more SMS with unicode characters correctly, in most cases, both incoming and outgoing. Watch this space.

Making a meme?

This is my attempt to make a meme.

Of course, there is a danger that it will be seen as insensitive. Tricky one. If anything I am having a go at ofqual. I do feel rather sad for students struggling with downgraded exam results this year. The whole situation is crazy.

I know there are plenty of people that say that they got poor results and did fine, and I know that a lot of companies would not worry about A-level grades when hiring someone, but it is a gateway to university. I vaguely remember my concern over results and whether it met the offers I got from universities. Wrong grades can ruin a promising carrier before it starts, especially in vocations like medicine. I really hope they fix this somehow.

As for making a meme - we will see. I did include a "deliberate mistake" so people can feel smug pointing it out - I think that is a feature that helps a meme happen. (well, one mistake, one that looks like a mistake but sort of isn't, so people can argue over it).

P.S. My keyboard broke, started constantly repeating keys - ones I went nowhere near with the screw driver. I think it is just getting it's own back at me.

A simple flat tyre - but this is 2020, so no...

Really boring post for your today...

On cycling out of Bracknell town on one of the cycle paths (see, I do use them when they go where I want), I hit a pot hole. I have been back and looked since and it looks really innocuous, but it was very jarring and my first thought is that it will have killed my tyres.

Unsurprisingly, within half a mile, or so, I had a flat back tyre. Crap!

I got a lift back from Tescos, and later walked in (3 miles) with my cycle repair kit and pump. The puncture was obvious, and not that small, so I used the sandpaper thing on the rubber and applied a self adhesive (skabs) patch, pumped up and cycled home. Perfect, job done.

Next morning, tyre flat! I investigated and it was the patch, it had popped allowing air out the side. WTF? I patched again and it immediately popped when pumping up.

I figured that maybe the glue goes off, this repair kit was a few years old, so ordered more. When that arrived, patched, and the same!

So I ordered a different make of self adhesive patch this time.

Again, popped as soon as inflated. This is mental.

I figured it was on a seam in the tyre, so I carefully trimmed that flat with a scalpel blade and tried again, no joy.

OK, time to go old school. I ordered good old fashioned repair kit with the rubber patches and the rubber glue.

I have probably done hundreds of puncture repairs in my life, and never had this trouble.

To my surprise, that did not work either, WTF?

Just to be clear, and thanks for all of the helpful advice, I did apply glue and wait for it to dry before applying the patch. I also, on some attempts, applied glue to the patch, which I don't normally have to do.

I tried the large patch sideways to cover where it popped, no joy.

I even applied a patch on top of the patch where it popped, no joy.

As an almost last resort I even used some Loctite 480 which is especially for bonding rubber. Close, but still popped.

This really is getting beyond a joke. I have never had this much trouble with a simple patch to an inner tube in my life.

I think I now have six puncture repair kits.

I have ordered a new inner tube, and some would say that should have been step 1, or at most step 2. Well, yes, except this is the back wheel with hub brakes, hub gears, and enclosed chain guard, all of which need removing, and at least one cable needs unhooking (and hence re-fitting and adjusting) and to be honest that seemed like a lot of hassle. Hence trying the simple puncture repair.

I then had a brain wave... This puncture is not a usual puncture. Well, apart from now being a tear around 5mm long because of the number of patches I had removed, it was on the inside of the inner tube, i.e. facing the wheel. This fits with it being pinched when I went over a pot hole - after all the tyres I have are meant to be puncture resistant. So not the usual place to get a puncture, which would typically be from a spiky thing through the tyre and hence on the outside. In fact, it was almost certainly exactly on the part where the inner tube is not going to be smooth when inflated, but actually a step where the inside of the tyre is in the wheel. This may be the clue, and why it only popped when inflated ing the tyre (I could inflate quite a bit outside the tyre with no issue).

My fix! Well, for a start I used the Loctite to weld the tear shut anyway, and applied a rubber patch over that. The trick, though, was a plastic card (credit card sized) bent round on the inside of the tyre between the wheel and in inner tube. A real hack, but magically the tyre inflated, and I have managed to cycle round the block and no sign of it deflating yet.

Yay, sorted, and, bollocks, the front tyre is now flat. That seems to be a much smaller slow puncture which was actually simple to fix with a patch as normal (well, so far).

So yay. I do have a spare inner tube coming tomorrow, and I hope I don't need it.

I would stress that this has taken (I think) 4 days now, and so given my run of luck I fully expect to find both tries flat tomorrow, probably pecked by a crow or eaten by a squirrel or something...

Update: Using a card was certainly a clue, as it lasted a lot longer than anything else, but today (the next day) the back tyre is flat again - so fun with dismantling stuff when the inner tube arrives. FML.

... And someone has "borrowed" my Allen keys, arrrg!

Update: I have two inner tubes and new Allen keys. Yay. I figured I would change front one first. It literally exploded in the tyre at around 50psi. WTF?! So now waiting until tomorrow for another new inner tube. I did not have this on my 2020 bingo card.

Looks like it is a full moon at just before 5pm today - is that a bad sign I wonder?

Update: Finally, new inner tube fitted to the back. All working. Pain in the arse to take it all apart though.

P.S. I now find I put the front wheel back wrong and have been cycling with brakes partly on - I thought I was just unfit (which I am), but that was daft. Finally all sorted now.