Blog / musings...

Solving Ohms Law on the DM42n

Collatz conjecture and speed tests

Mains monitor

Expressif anyone?

Swiss Micro DM41X

Addendum to mass air flow woes

COVID 19

14CUX EFi Engine fires but then immediately stalls

Room thermostat

The MicroLAN or 1-Wire bus

ST9400C Boiler Timer Fault

14CUX Idle Air Speed Stepper motor

Ditching the BBC

Ditching Facebook

Parallax Error

Adding a regulator

Small Power Supplies using an 18650 battery

PIC32MX170 Processor Persistent memory

2.4Ghz communications

Care with unsecured collets

Hooverphonic Music

PrecisionGrouping

Social Media

Password Protection

21^st Oct - Solving Ohms Law on the DM42n Further down, I've written a SOLVER function example for a DM41x calculator. We used this function to find the root of a single variable equation Ln(x)+10x-14.844=0. A SOLVER function wasn't included on the original HP41 machine (you needed to add a math pack expansion ROM to get the function onboard). Same was true with the DM41x but that calculator is already equipped with the math pack ROM image in memory and so installation is trivial. A Solver function was however built into the original HP42 and also the Free42 version running on the DM42n - a simple example of its use is to solve for any value in a DC electrical circuit for Voltage (V), Current (I) and Resistance (R).

In any simple DC circuit - we have three varying values of voltage, current and resistance. Using ohms law, we can find any one value so long as we know the other two. Normally a young engineer will rote learn that V=IR, I=V/R and R=V/I so there's no huge mystery in how to do this. But the solver can do the same thing albeit iteratively and the process to build this nicely illustrates how it works and how it can be used for more difficult problems. We'll build a solution to this next on the DM42n.

Remember the process here. The calculators SOLVER function uses a Newton–Raphson iterative algorithm to hone in on a solution - but the actual problem itself is coded in a program written by the user. SOLVER calls the users program and using its iterative algorithm attempts to converge on a solution that balances the equation. So the user starts by building a program and then telling SOLVER to use that named program. Our first task in this case will be to build a basic ohms law program but phrased in an f(x)=0 way. Take for example V=IR which can be rearranged to suit the SOLVER function as V-IR=0.

On the DM42n, create space for a new program (SHIFT GTO..), flip into programming mode (SHIFT PRGM) and enter the following function. Note what it is doing. We use the MVAR functions to define the three variables V,I and R. After that the algorithm recalls each value and computes ohms law (ie: V-IR) but expressed in an f(x)=0 form. When ready, flip the calculator back into normal mode (SHIFT PRGM).

Before we use the SOLVER let's prepare some test values. Assume our simple DC circuit consists of a 12v battery and a 4K7 resistor. What is the current? As I=V/R, we can calculate the current as 2.5532mA. Now let's use the SOLVER to figure out if this works. It'll help to set the display mode (SHIFT DISP) to ENG(ineering) and set to 4 places. Invoke the SOLVER (using shift SOLVER). Note that the screen demands "Select Solve Program" and on the soft key display, shows the available options - which includes our "OHMS" program. Click the "OHMS" option. The display will now change to show the variables in our program, namely V, I and R. Based on our example above lets assume we know the voltage (12v) and the current (2.5532mA) so what is the resistance? Enter the number 12 and hit the softkey for "V" (left hand screen image below). Then enter 2.5532E-3 and hit the softkey for "I" (middle image below). Then have the SOLVER find the resistance R by pressing the softkey for "R". The SOLVER algorithm will determine it is 4.7E3 and return that in the X register - so SOLVER has now computed the one unknown resistance value, given the two knowns of current and voltage. Equally well, you could enter 4K7 as the resistance and press the "R" softkey. Then 12 as the voltage and press the "V" softkey - and finally have SOLVER find the current by pressing the I softkey. The arrangement is flexible and intuitive, taking advantage of the original HP42s MVAR input gathering system. Comment | Back to Quick Links... 18^th October 2024 Collatz conjecture and speed tests Further down this blog are my musings on the remarkable DM41x calculator from Swissmicros... a tour de force of excellence and hard work which captures the entirety of the much loved Hewlett-Packard HP-41 family of RPN calculators. I am a keen RPN enthusiast (Reverse Polish Notation) ever since the tail end of the 1970's when a math teacher at college introduced our class of wide eyed, curious and smart young telecoms students to a beautful and very different HP32e. The HP41 was released in 1979 and was such an immediate hit, it held pride of place right through the 80's and is still used to this day in various legacy applications. I vividly remember the rather novel joy of displaying alpha strings with program inputs and outputs. By 1988 HP launched the pinacle of RPN calculators - the astonishing HP42s which by any standard still remains firmly in a class of its own. This machine had a more advanced programming language than the 41 family, but was backward compatible with any HP41 code - a really strong draw to a great many users. By the time we'd reached the 90's, HP's direction of travel had turned away from dedicated RPN machines to concentrate exclusively on reverse polish lisp (RPL) machines - leading to the release of the HP28, HP49 and HP50 calculators and the really rather good HP48GX in 1993 - a machine that held my hand throughout a 6 year honours degree in Maths and Computer science with the open university. Not every HP customer liked this move to RPL and there are plenty of accounts out there of the sadness of hearing the original and astonishingly talented HP calculator design department had been disbanded and worse subcontracted out to third party company(s). This HP decision to outsource lead directly to the release of the comically awful HP49 and 50 RPL machines (with exceptionally bad keyboards and equally poor quality and feel... I know, because I own both). On balance I didn't mind RPL on the HP48GX, (nor for that matter the completely different HP Prime Programming Language (PPL) and Python used on the 2013 HP Prime) because they both came with extensive graphing support. They're different machines aimed at different markets but both are good at what they do. However whenever I used them I always found myself missing a fully functional, sophisticated but nonetheless dedicated RPN machine. In truth, for the vast bulk of my work a HP41CV or HP42s is really more than sufficient and in fact counter intuitively, these offer a sort of ease of use which the complexity of either a 48 or Prime tends to obscure. Is this just nostalgia? Well, maybe... but perhaps it's also an appreciation of two very good machines. HP42s are such a highly regarded machine, they'll routinely command close to 200 UKP on fleabay even for scuffed examples. Mint examples with a box and colour manual can reach north of 315 UKP now, but before these machines became collectable, I found a mint example in Germany back in 2012 complete with original packaging and manual and a HP82240B printer. That printer still works and is fully compatible with both the DM42n and DM41x (although that machine does require extra print support modules).

In terms of potential alternatives to this remarkable machine, there were some open source projects worthy of note, such as the rather splendid WP34s which repurposed a HP financial calculator (the HP30B). The donor machine had to be reflashed and some relatively minor hardware mods completed before fitting a new sticky key label sheet for every key. The WP34s was heavily influenced by the HP42s, but it did an awful lot more while building on support for complex arithmetic, matrix ops, base conversions, stats and all (naturally) fully programmable. It also provided faster hardware than the much older HP42s, a good keyboard experience, an improved screen and even a USB interface for comms with a PC. Although somewhat Heath Robinson in execution the WP34s is still a very capable little RPN machine. I have three mainly because way back when I bought them I saw little realistic prospect of having any other long term RPN alternatives. I've been using one in my garage when turning and machining for many years now, sometimes to convert torques or clearances between imperial and metric or simply to calculate the correct depths of cuts for a part on the lathe. They're good useful machines.

In a lovely parallel thread of development we now come to a quite remarkable software engineer called Thomas Okken. Thomas wrote a fully open source project called Free42 and released version 1.0.0 way back in Nov 2004. His objective was to offer a ground up re-write of the HP42s but without using any of HP's original code; a "re-implementation" if you will but with extra features and additional precision. With good reason, Free42 is often referred to as one of the most accurate and precise calculators in the world because it uses the Intel Decimal Floating-Point Math Library, which is an IEEE 754-2008 compliant suite using quadruple precision decimal floating-point, consuming 16 bytes per number, providing 34 decimal digits of precision with exponents ranging from −6143 to +6144. You can for example calculate nested trig functions such as tan^-1(cos^-1(sin^-1(sin(cos(tan(0.1234)))))) on free42 (or the WP34s) and still end up with 0.1234 in the display. With the original HP42s you'll end up with 0.1232, a small error, but an error nonetheless. Free42 is 100% compatible with the original HP42s so can execute any software written for the original machine. Given the vast HP42s library out in the world, you'll appreciate the advantage and significant achievement that represents. Unsurprisingly, Free42 also offers other enhancements over the original machine. A key feature of its deployment was the release, complete with appropriate skins on iPhone and Andoid devices as well as Mac iOS, Windows and Linux (where I first encountered it). Free42 is (as the name suggests) free across the board. In April 2022 Thomas released an enhanced version of Free42 called Plus42. This extends the display and adds algebraic expressions based on the HP27s, 17B and 19B. It adds unit conversions based on those in the 48 (49 and 50) HP series machines and a folder directory structure similar to the HP48 along with 2D printing and the ability to zoom/pan and find integrals and roots from points on a curve. Plus42 includes financial functions such as TVM and amortization tables. It's open source and while the windows, Mac and Linux versions are free, the iPhone and Android apps are paid apps. We'll explore the Collatz conjecture in a tick - but trust me when I say even a humble iPhone 7 hosting Plus42 is blindingly fast. Swissmicros took Free42 and implemented it on a dedicated hardware platform known as the DM42 which isn't emulated but sits on the SwissMicros OS. One of the lovely design features of this machine are the set of six dedicated keys acting as the original soft keys of the HP42s. The underlying OS handles important features such as firmware upgrades, saving and restoring state (saved as files) as well as saving and loading programs and controlling the USB comms link with the PC. It includes a good file manager with folder support. SwissMicros currently have two versions of this platform for sale. The first is the older DM42 using an ARM cortex-M4F running at 80Mhz (with 32MBit external flash) and a USB B interface. The second is the newer DM42n with an ARM Cortex-M33 CPU running at 160Mhz (with 64 MBit external flash) and a USB C interface. The motivation for these two variants comes down to the discontinuation of the cortex-M4F processor. The 42n is faster and more capable given the extra memory - but is also slightly more expensive, so "pays your money, takes your choice" applies. Otherwise both are essentially the same machine with the same phyical size, same key layout and the same 400x240 pixel screen (using a square pixel pitch at 147µm). Note that the CPUs do run a reduced clock speed when powered by battery in order to conserve power.

• The DM42 runs at 24Mhz on battery but runs at 80Mhz when powered by USB.
• The DM42n runs at 48Mhz on battery but runs at 160Mhz when powered by USB.

That said, even when running on battery, these machines are fast especially when compared to an HP42s (which given the age difference, isn't at all surprising). I can certainly recommend the DM42 machines as a highly effective alternative to the HP42s.

So what is the Collatz conjecture? Collatz is a simple idea... take any +ve integer as a starting point. If it's even, divide it by 2 to get the next digit. If however it's odd, then multiply it by 3 and add 1 to get your next digit. Repeat for each new digit in the sequence.

Lets do a quick worked example - starting with 10.

• 10 is even, so divide by 2 to get 5.
• 5 is odd, so multiply by 3 (to get 15) and add 1 to get 16
• 16 is even, so divide by two to get 8.
• 8 is even so divide by 2 to get 4.
• 4 is even so divide by 2 to get 2.
• 2 is even so divide by 2 to get 1.
• 1 is odd so multiply by 3 and add 1, but note you end up back on 4...

...and you'll quickly appreciate once you reach 4, the rules will always lead you back down to 1 and in fact will repeat around that 4,2,1 loop infinitely. The full set of 7 numbers in this specific sequence is 10, 5, 16, 8, 4, 2, 1 (these are often called hailstone numbers due to their habit of bouncing up and down). This sequence took just 7 steps before finalising on 1 but I've seen examples that took 4500 steps. There are also sequences that generate extreme values on route down to 1... for example a starting point of 27 takes 112 steps (including the starting number) to reach 1 - but curiously will generate values as high as 9232 before getting there. Back in 1937, Lothar Collatz simply asked the question if these rules are applied, will every positive integer eventually end up at 1? His conjecture was they would but thus far no one has been able to mathematically prove the truth of this. Thus far, brute force testing has confirmed that the conjecture is true for positive integers up to 2⁶⁸ (so 2.9515x10²⁰ or if shown as a complete number: 295,147,905,179,352,825,856). However even though this search number is pretty large, compared to the infinite space of positive integers, it is infinitely small. The reality is there is no way to prove this conjecture by a brute force exhaustive search because the search space is infinate. The only way will be to use deductive logic or perhaps some mathematics property discovered in the future. On the other hand, all that would be required to disprove the conjecture would be a single counter example that doesn't reduce to 4.2.1.

The really curious thing is that while a child can easily understand this problem, thus far no one has been able to prove the truth of the underlying conjecture despite lifetimes spent trying to do just that. Jeffrey Lagarias (linked to a great deal of work on this problem) stated that the Collatz conjecture "is an extraordinarily difficult problem, completely out of reach of present day mathematics". The eccentric and quirky Paul Erdős was also quoted as saying "Mathematics is not yet ripe enough for such questions" which was an understated and yet pithy observation. It made me smile when I read it. If you want a good primer on the Collatz Conjecture and which nicely captures the strangeness of the problem - try this:- ...and what does the Collatz conjecture have to do with calculators? Well, calculating a Collatz sequence is computationally intensive and so rather a good way of comparing processing speeds between machines. My objective was to use my own Collatz functions coded on a calculator to compare an original HP42s, a new DM41x, a new DM42n and the Plus42 app running on an iPhone 7 to see how they compared. Both the DM41x and DM42n would be powered by battery (clocks throttled back) but in separate tests, powered via the USB (so clocks at full speed). I built the code using two programs, the first (Collatz) takes a start number in the X register and then computes how many steps the sequence will take to reach 1 using the Collatz rules (and where the count includes the first number provided). Curiously, it did strike me that if that program ever did hang looking for a solution it couldn't find, well we'd have then stumbled across a counter example and therefore shown that the Collatz conjecture was false. Mind you, there isn't much chance of that happening given we'd have to surpase a ceiling of 2⁶⁸. A second program (ColMGR) manages the sequence start value, starting from 1, incrementing after each call to the Collatz program. It monitors how many steps were required for each sequence and records that information in the alpha register in a form SNNN.MAX.STEPS where SNNN is the current sequence start number, MAX is the maximum number of steps recorded across all sequence start values and where the value STEPS are the number of steps required to reach 1 for whatever the current sequence start number is. I started by using a single start value of 3101 (which I know generates a sequence of 155 steps) as the argument for the Collatz function I'd coded. The timing results were

• HP42s - 26 seconds
• DM42n (on battery power, reduced clock) - Instant
• DM42n (on USB power - clocked at full rate) - Instant
• DM41x (on battery power, reduced clock) - 3 seconds
• DM41x (on USB power, clocked at full rate) - <1 second
• iPhone app - Instant

The next step was to run the ColMGR function for 2 minutes on each machine and see how many sequences each could test starting from 1. The results were quite eye opening:-

• HP42s - Max Sequence start number reached: 41
• DM42n (on battery power, reduced clock) - Max Sequence start number reached: 3231
• DM42n (on USB power - clocked at full rate) - Max Sequence start number reached: 6918
• DM41x (on battery power, reduced clock) - Max Sequence start number reached: 99
• DM41x (on USB power, clocked at full rate) - Max Sequence start number reached: 212
• iPhone Plus42 app - Max Sequence start number reached: 163066

The DM42n is very fast... compare 3231 sequences checked when powered by battery (6918 when powered by USB) to just 41 on an original HP42s calculator. Although we're not quite testing like for like (because the DM42n is running Free42 and not Plus42) it is interesting to see Plus42 on a humble iPhone 7 managing to achieve a whopping 163066 checked sequences (50 times more than a battery powered DM42n). Yes, I know these things are all very relative. For a start, the UI of an iPhone calculator app is horrible, with no tactile file (even with haptics enabled). The fact the device also shares function is also a major distraction so any long term use, from my point of view, is a non starter. But it does demonstrate that with the right CPU, the speed of the app can be quite astonishing. Comment | Back to Quick Links... 25^th September 2024 Mains monitor I built the mains monitor board earlier today, consisting of an ESP32 (WROOM) board with a BUCK style PSU (mains in and 5v regulated DC out). I made a point of testing the small PSU on the bench for 24 hours just in case it went up in flames as I've found the QA can be a little bit hit and miss. Speaking of QA much the same applies with the ESP32 and ESP8266 boards. I've bought 24 of these boards (12 of each) and two were dead on arrival. Both were manufactured with layout faults of some of the surface mounted components. One had a three pin device rotated through 60 degrees which was easily repairable (at which point the board worked). Another had a nasty solder problem under the 2102 USB interface chip which I couldn't resolve. The board basically worked but no comms were possible. If I was a betting man, I'd bet that these clone boards don't get tested at all after manufacture. So, a long soak test under controlled conditions becomes pretty much essential. Note the red arrow showing the ESP32's 2.4Ghz antenna and the two pin jumper at the bottom left, providing a means to disconnect the +5v rail from the Buck PSU if/when I need to use the USB interface.

The next step was to cut out an apperture for the antenna on the ESP32 PCB to allow it to protrude properly from the diecast box. I also had to deal with all the other various drillings in that box (for the earth M6 bolts, the two grommets, one large for the mains cable and a smaller one for the CT cable, the screws for the 10mm plastic insulated stand offs supporting the ESP32 PCB and also a hole in the lid to ensure earthing continuity throughout the entire enclosure. You can see an orange mains plug which is used to feed live and neutal to the monitor board (and which is fused with the smallest fuse I could get). Also if you look at the consumer board you'll spot the CT clamp around the neutral tail heading out of the Henley box. The design provides a reasonable degree of safety given the mains is physically issolated from the low voltage component - actually in two ways. The PZEM board is encased and insulated. The mains wiring entering the choc block for that board is properly terminated with insulation up-to-but-not-touching the screw clamps. Regarding the prototyping PCB, this has a number of rows of disconnected 0.1" pitch, sitting between the ESP32 and Buck board. I also fitted a 2nd plate of 2mm thick plastic immediately under the buck board to act as an additional insulator (you can see that on the top picture). Low voltage wiring and high voltage wiring is double insulated where it crosses and the entire enclosure (including lid) is earthed. This last point is important, as technically this is a class 1 device which must have CPC continuity to the enclosure. The one remaining part to source is a clear plastic rectangular cap to sit on top of the ESP32 antenna - first and foremost to keep dust out but secondly to insulate even that low voltage part of the board, just in case anything did go horribly wrong. I'll need to play with that to make sure I don't end up compromising signal strength which is why, for now, I've left it off. Note that the box is physically remote from the consumer unit. All communications occur over the air.

...and with around 6 nodes in the MESH (including the mains monitor node) reliable comms were established. Note that at this time, we were actually using the cooker (inductive hob and electric ovens) and so the current consumption accurately reflects that fact. (All node address values are aliased anyway - so the address shown can be ignored).

I'm pleasantly surprised by a power factor of 1.0, suggesting that the inductive and capacitive loads are fairly well balanced, even under relatively heavy load. Over time you can definately observe changes in voltage and frequency although the next step would be to graph that data to see how it behaves, perhaps over a day or maybe even a week as I'd imagine there may well be patterns to how these values will alter. Before I can do any of that, I'll need to setup a working MESH of ESP32's around the house, as right now they are placed rather hapazardly and one or two are using small USB battery supplies (for example a single 18650 USB charger pack will feed a working MESH'd ESP32 for around 18 hours). Longer term, what will be interesting will be to find out as/when the grid voltage drops off significantly. Comment | Back to Quick Links... 21^st March 2024 Expressif anyone? Over the last couple of months I've been playing with Teensy boards employing IMXRT1062DVJ6 processors (ARM cortex M7 core) after my old mate Brian suggested it'd be well worth a look. Teensy is a creation of a rather smart chap Paul Stoffregen - and creation is the key word here. Popping a chip on a board arguably isn't that hard but building a well designed PCB with regulation, breakout pins, USB and peripheral support for an SD reader and Ethernet plus all the software support required to drive the board is much harder. Fortunately for us, he did and selected the Arduino framework as a starting point. I suspect a motivation for the board may have been the creation of music and driving visual effects hardware, which makes sense as soon as you scope the cycle times of this processor clocked at 600Mhz (and often overclocked with the right cooling and some coded precautions to prevent overheating). I've used Microchip PIC32MX chips for years, clocked at 40 or maybe 80Mhz and so all the more relished seeing this 600Mhz processor generating continuous GPIO writes with 4nS cycle times. The device is so quick my humble 40Mhz Kikusui scope couldn't even see logic transitions. Couple this board with a cheap touch screen display - for example a 320x240 board using an ILI9341 controller and you have a very powerful base for just about any embedded project you like. There were a couple of hoops I wanted to jump through as I worked on this Teensy board - given I've normally developed embedded hardware using the Microchip Integrated Development Environment (IDE) with either C or in years gone by, page banked assembler (where flying off into hyperspace was always a distinct possibility). This time I wanted to use the Arduino platform and in particular develop the project in C++, a language I'd never used before. hmmmm C++... for every person I've met who swears by it, I've met another who hates it with a passion. Personally, I've always found myself in two minds about the language. Polymorphism (think in terms of overloading functions that essentially do the same thing with different arguments for example add(1,2)=3 and add("coff","ee")="coffee") and encapsulation (where we place limits on precisely what can be changed, by how much and by who) tick all the right boxes when it comes to making good provable code that can be properly maintained. But being honest I've rarely encountered a real world example of inheritance that didn't require fairly horrible contortions, a lot of swearing and shoehorning to make sense.

Here we declare an object called Stack that extends Vector and can add functionality over and above what Vector provides. But the problem here is that a stack isn't a vector. As stack in this arrangement inherits existing Vector functionality, you'll then be free to add or remove elements at any place in the stack. You see the problem? Inheritance has allowed you to use a stack improperly. A Stack or first-in-last-out memory should only ever permit two operations that add/remove data, namely PUSH (to add new data) and POP (to remove data). Anything else means it is NOT a stack.

This example cited by Jeff Meunier is also worthy of note as it captures very poor use of inheritance. Meunier was reviewing java books in which one author cited the code shown as a really good use of inheritance. In particular the Circle class inherits the Points class translate method which means that translating a circle is the same as translating a point - all good stuff, right? Well, not really... because the line public class Circle extends Point actually means that all circles are a point, which is obviously not true. A circle is a collection of infinite points by virtue of its radius and as Meunier rightly says, "It requires a lot of mental gymnastics to even begin to reconcile the inconsistencies between this model and reality. The coding might be “correct”  —  the program runs just as the programmer wanted  —  but the model is very wrong".

There is a general principle in object orientated design known as the Liskov substitution principle - which asserts that it should always be possible to use a child object as a replacement for a parent object. In our example above, a circle object clearly can't be substituted by a point - oh dear.

Forgive another shape example, but this one is routinely cited as a good exemplar of poor inheritance involving squares inheriting from rectangles. This example gets debated, a lot. I've read folks respond in forums in all sorts of ways but my favourite challenge was "I have yet to see a square that wasn't a rectangle. Can you draw me one?". An excellent question, but one that manages to entirely miss the crux of the problem. If you think about it, a square is a special type of rectangle (just one where the width and height are the same). But the problems begin when you consider the two shapes, specifically from a programmers perspective. A rectangle needs two descriptive arguments while a square only needs one. You can freely change the width of a rectangle and it still remains a rectangle, but if you were to change the width of a square (without altering the height) then it would stop being a square. So the SetWidth-Method in our Square class can't be correct, because if it alters only the width you'll have a Square that isn't square. If it changes both the width and the height, then it isn't doing what the base version of the method does, which means the Liskov substitution principle is violated. Leaving aside these more abstract issues, it is also visually ugly, given the readability of a SetWidth method in a square class is logically inconsistent with the shape. I'd read this as a programmer and immediately feel uneasy. What other logical flaws am I about to walk into?

Leaving those issues to one side, object orientated languages generally all include encapsulation. If the class interface extended out publically is tightly controlled by data type then we have a strong contract between two parties (the class and the consumer of the class) which in my humble experience leads to robust, readable and maintainable code. The rest I can live with, given inheritance is a feature that can be used sparingly and sometimes avoided altogether. So I began this journey using C++ in the Arduino IDE and set about building a fairly good sized hello world project - utilising a suite of classes that would allow me to run a Teensy 4.1 coupled with either of two different displays (a Digole using fast UART comms or an ILI9341 based display using SPI - or even both boards simultaneously). It's not really a hello world project, it's more like a shell project that can be used as a basic template for future designs. At the subtle end of things, I explored the use of timers embedded in classes, using callbacks to drive regular 1mS clocks for various timing applications as virtually every embedded project I've ever built has needed that type of control. Using classes for these kind of tasks can be a useful way of tidying and removing clutter from setup() and main() because instead of having a load of code to create, setup and kickstart the timer hardware - you might instead see a single line along the lines of SystemTimer.begin(); but where the new timer class you've created encapsulates all the code required to deal with the hardware. Interestingly as hardware is generally a limited resource, then these types of classes often have to be single instance or Singleton types. They generally have to defend against multiple instances being created - so some care is required during development. The process gave me good insights into how C++ works. It also gave me a chance to explore the standard library, which is actually pretty good (I used deque lists in the ESP32 packet processing below - and found them to be very useful and robust). But by the time I was part way through, I could almost hear the little Arduino IDE groaning under the weight of it all. I'm using the version 2 Arduino IDE which in truth is pretty good at what it does... and importantly suits those who don't want to get bogged down with a lot of bells and whistles. You're free to code in either C or C++ and can even (sort of) split projects using multiple tabs (one per file). The library and board managers built into the IDE do an elegant job of opening a complex world of support and making it seem easy. But this IDE doesn't cope overly well if you want to develop and test more complex projects, sometimes involving dozens of classes and even multiple developers. The IDE has no understanding of repositories such as github, so the process of taking snapshots can be fairly long winded and manual. Also the IDE doesn't provide simple, easy to use project navigation to see the complete design. After creating a number of projects to scope out the limits of the Arduino IDE, I started looking elsewhere for something better. An alternate IDE I tried first and have stuck with now for nearly 3 months is the free version of Microsoft Visual Studio 2022 (actually version 17.5.2) along with a paid-for plug in called Visual Micro (the cost is very reasonable so don't let that put you off. I'd add that I needed to contact support once (after rebuilding my PC and running into a re-licensing issue) and they were absolutely superb). Using this combination is relatively simple - but does require some structure before you can start. Broadly speaking...

• 1. Install the Arduino IDE. With this configuration you can use any recent IDE - my starting point was 2.0. Make sure this is working ok before proceeding
• 2. Download and install Microsoft Visual Studio - Community Edition (which is free)
• 3. Download and install an extension plug in called Visual Micro (note that you can try this without restriction for a period of time with no cost)

With this up and running you can create a project in visual studio and use the visual micro plug in to set the board, the libraries required and to compile. In fact Visual Studio via Visual Micro uses all the same tool chains built into the Arduino framework to compile the project so the two are very closely linked. With Visual Studio closed, you can even use the library and board managers in Arduino to download new devices and libraries safe in the knowledge that all of that will come straight across to projects you later open in Visual Studio. Using this new IDE I set about rewriting all my existing code - compiling and running to test and also updating github with repository backups and have been using it ever since. It works really well, feels far more robust and generally eases the burden of working on more complex projects. I heartily recommend it. MESHing ESP8266 or ESP32 With a viable IDE sorted out, my next project was to explore Expressif comms boards with a particular motivation in mind. I don't want to get into the politics of net zero... which in my view is unnecessary, unworkable nonsense, but I'm pretty sure the way this is being mismanaged now by the lunatics in office, means the grid is likely to stop working or be time limited in the future. So being able to monitor our house supply (voltage, frequency, current load, power consumed across time and power factor) may be quite useful and as it turns out, relatively easy using a PZEM-004T-100A board (see above pic - where the board is in the light blue plastic container). This board uses a CT clamp on the neutral line with a second direct low current connection to both line and neutral. With mains connected, the board sensor powers up and starts work. It can be queried via a UART serial interface employing opto-isolators on both the Rx and Tx lines for proper mains isolation (it is for this reason that you need mains on one side of this board and +5v on the USB side before the board will even switch on). A word of warning when using PZEM-004T-100A boards.

PZEM-004T-100A boards use a capacitive power supply - which we've already encountered further down in this blog when my central heating Honeywell ST9400C timer died. There are two issues with these capacitive PSU's to remember. Firstly when connected and running, some of the PCB will be live (ie: at mains potential). Secondly, unless the circuit is designed to discharge the capacitor when turned off, there is always the possibility of live voltages remaining on the PCB for some time after mains has been disconnected. So build defensively. I'd aim to put this into an earthed diecast box, where the PZEM-004T-100A is itself encased in its own plastic insulated case and physically separated from any other hardware. I specifically avoided buying a bare PZEM-004T-100A board that didn't have an insulated surround (see pic, actually from Amazon). CT loops generate significant voltages from their inductive coupling. In fact, on three phase installations those voltages can easily kill the unwary, so great care is required.

...and whatever you do please ignore the technically illiterate folks on youtube who advocate placing these types of IOT devices inside consumer units (ie: distribution boards). One of the most worrying examples of this particular brand of recklessness comes from a youtube account known as Electrical Projects (CreativeLab) with 106K subscribers. Note the comments, as it is clear that more than a few think this individual has done something to be applauded. Some of these comments build on the insanity (making it worse, if that's possible) such as the gem "it would have been nice to power your ESP from the line side of your main (sic) so it stayed on all the time". For me, the only comment that got close to the truth was "This creation is a fire hazard, life risk and over all a good idea with the worst execution possible". The video demonstrates negligible electrical knowledge and no grasp whatsoever of safety. Some of the really eye rolling low points are the use of a plastic case, using heat glue or silicon (of all things) to mount objects, mixing low and high voltage with no physical separation, the almost comically insane RCD trip mechanism he er... invented (obvs never heard of a shunt trip or even a contactor), using soldered inline heatshrunk fuses that carry mains, the horrible termination(s) all with exposed copper, his comically bad DIY breaker bus (consisting of clearly underspecified looped wire) and soldered wire used in clamped connectors. Jeepers, where the hell does one even start with something this bad? There is some truth to the old saying, just because you can do something doesn't mean you should. A UK home insurance policy would be invalidated as soon as this appalling bodge came to light and in the UK he'd be wide open to prosecution (given he clearly can't be a part P contractor). He may not be UK based... I'd like to pray really hard that he isn't. Bottom line is that home owners shouldn't be opening or going anywhere near a consumer unit without experienced qualified advice from a professional electrician. There is after all, a very good reason why it is so arduous and expensive to become one of those smart folks. Don't do this!!! My house isn't huge and while monitoring our consumer unit might be fairly easy with this board, communicating the monitoring data to my office (for example) is a nonstarter. The distance and the number of walls between the two boards means a pair of NRF24L01's, ESP8266's or ESP32 boards simply wont work. So point-to-point communications won't work over this distance but what if we added intermediate boards to act as relays? This is effectively what a MESH is. ESP boards have a freely available Arduino library known as PainlessMESH providing this facility in a fairly *coughs* painless way and which will work with ESP8266's or ESP32's. With painless mesh we can create a network of ESP32 and/or ESP8266 boards that self organise into a network and allow point to point communications via any of the intermediate nodes. In a house environment you might have one board in every room - and that coverage would mean you'd be able to send a packet from any one board to any other board even if that meant the packet had to traverse multiple nodes to reach the destination. Painless mesh doesn't tackle everything... for example yes you can initiate point to point communications to a specifically addressed node, but you'll have no idea if that communications data actually arrives, because the MESH doesn't deal with acknowledgments. You have to code that feature in the application layer. Another issue I found involves latency in operation. The MESH syncs clocks between nodes which is good... but appears to be very slow. So sending/receiving packets randomly without any specific time requirement will work just fine... but if you did want something to happen right now across boards in the MESH the process will be far more involved. A good example would be to have say 10 boards in a mesh and have them flash their on-board LED's at the same time, using commands issued by one of the 10 boards. Doable, but it isn't as easy as you might imagine. I've run a 16 board mesh here at the house with both ESP8266 and ESP32 boards. My implementation used application layer ACK's on all packets and where each packet had a type that could initiate a command or a reply to a command. It worked like a charm and I hammered it over around a week nonstop and couldn't get it to fall over at all. I've had so much fun exploring this I suspect I'll revisit this blog post in the future. Comment | Back to Quick Links... 4^th Nov 2022 Swiss Micro DM41X There's a rule of thumb, almost a caution really, when it comes to technological change. For the life of me I can't remember who said this, but paraphrasing the idea, it warned that whenever tech advancement occurs, you'll see a gain in functionality, but you should expect to lose something that you like, along the way. Chances are high that the gain will far outweigh the loss, in which case you won't overly care. For example when smart phones and tablets came along, stand-alone car satellite navigation systems went the way of the dodo. Regardless of how much you liked the way those systems worked in your car, a phone could navigate just as well while detecting and routing around traffic and it could handle calls at the same time and all of this was included in your monthly phone payment. A similar thing happened to the calculator industry when smart phones and tablets appeared complete with any number of apps, including calculator emulators. The market for dedicated calculator machines slowed right down, with the exception of calculators approved for use in examinations (where a connected tablet or phone was obviously a bad idea). For an engineer, that restriction doesn’t apply and my phone now has 6 different calculator emulators (the WP34S, HP48GX, HP Prime, HP 15C, rcl57 and Free42) and they all work brilliantly. But, in my view they lack two things. The first is the tactile feel of a properly designed keyboard. The second, (in the case of an older but still extremely powerful calculator such as the HP 41CV), is the difficulty with expansion. The generalisation inherent in a smart phone or tablet is what makes it such a great product, but that often (not always) rules out bespoke applications. Personally, if I’m figuring out the VAT on a purchase, or dealing with home finances I’ll often use whatever is at hand, but if I’m working out the compression ratio of an engine (a more involved set of calculations), then I’ll always reach for a dedicated calculator and I’m very particular about the type of calculator notation I will work with. I won’t ever use algebraic infix notation calculators after using Reverse Polish Notation (RPN) all my life. There are plenty of good (along with some comically bad) explanations of RPN online, so I’m not going to repeat a good one here but just to summarise, RPN requires you to think about a problem by expressing it using postfix notation. Once you’ve mastered that requirement, the process involved eliminates any need for parenthesis and provides visual confirmations of all intermediate results. These two features combine to dramatically improve the likelihood of your result being correct. Very few people I know, who properly grasp RPN, would ever switch back to algebraic infix calculators.

Hewlett Packard are the company most synonymous with RPN machines, because in the late 1960’s they spotted a niche in the market for high end calculation machines built using an RPN foundation and set to work commercially exploiting that niche, eventually culminating in 1972 with the HP 35 pocket calculator (so named, because it had 35 keys and could fit in a shirt pocket). It would be an understatement to say what an enormous leap forward that machine was, given the vast bulk of scientists and engineers of the day were still using slide rules. Overnight, colleges dropped slide rule courses and slide rule sales plummeted. HP sold 300,000 of these astonishing HP 35 machines over the first 3 years of production (picture by Mister rf - Own work, CC BY-SA 4.0). Going back to my first point, there will have been engineers out there who would have loved their slide rules and would have regretted this advance – and that is precisely the double edge sword any significant advance brings. The counter view is nearly always reflected in a blossoming market (in this case for pocket calculators).

HP have continued to develop calculator technology right to the present day, with modern complex graphing machines taking full advantage of advances in display and touch screen technology. The newer breed of machines are however variants of the original calculators because they suit a different set of problems. They use a pseudo language for programming (RPL) and implement a sort of partial RPN but they definitely have their place (something I know first-hand because the excellent HP 48GX took me through an honours degree in Maths and Computer science. It is a superb machine - thank you HP). But for a pure thoroughbred RPN programmable calculator you have to go slightly further back in time to the late 80’s and 90’s, where we find two rather significant high points for HP. The first was the HP 41 family of calculators, released in 1979 and the second was the HP42s calculator, released in 1988. Each were unique: designed to solve different problems for different markets. The HP 41 family continued in production until 1990 - mainly because it was an extremely capable machine and one of the first to elegantly handle alpha characters. With this machine, if you wanted to create an engine displacement calculation program, you could display text prompts for the various inputs (eg: Bore, Stroke and Cylinders) and add text to explain the result. These powerful machines were the first hand held computers in their own right and in fact so precise and reliable they were adopted by NASA as flight navigation tools for nine flights of the Shuttle in the early 80’s where they were used to confidence check the on board computing system including changes to centre of gravity as fuel was consumed during the flight and for mission critical tasks such as ignition times for re-entry to Earth atmosphere. In the photo below (Curtesy of NASA), you can see three HP 41s floating to the right of the astronaut Sally.K.Ride on a mission flown on the 21^st June 1983. A key reason behind the success of the 41 family was its four expansion ports, permitting easy use of memory modules, program ROMS and other hardware (picture by Sven.petersen - Own work, CC BY-SA 3.0). The early 41C machines could be expanded with memory modules in all four ports. But user groups figured out ways to do this with just 2 ports and later HP squeezed all four memory blocks onto one module (often known as a quad). The HP 41CV, which I bought for £263.60 in the early 1980’s – in todays’ money around £580, had that quad built in. But the expansion ports provided general address, data and control busses so could just as easily be filled with ROM modules holding collections of programs. The sheer amount of support for different suites of technically demanding software (which is still being developed today) is quite breath taking. There are modules for statistics, mechanics, surveying, navigation, high end math functions (including root solvers, complex math, matrix math and integration) to name just a few. Peripheral devices of the day could also be used in these expansion ports including card readers, bar code scanners, floppy disk storage, GPIB and RS232 interfaces serial communications interfaces and a host of others. It’s useful to remember that this wasn’t the first calculator providing support for plug in ROMs. TI calculators of the day, such as the wonderful TI 58 released in 1977 included a plug in ROM feature, but it wasn’t nearly as versatile as the 41 family implementation. I have very fond memories of my TI 58 and a TI 59 I used at the time, mainly because I used them to master the basic concepts of programming. But the limits imposed by algebraic infix notation were an object lesson to me. At the time, I was using a HP 32e calculator, which was not programmable, but in all other regards including aesthetics and build quality, ran rings around a TI 58. Product demand for the 41 family and the quality of the computer coupled with a vast, loyal and highly innovative user base resulted in production continuing right up to the 1990’s. I wouldn’t be in the slightest surprised to find them still working in labs to this day. So, how on earth could you top a machine that good? Well, a company called Swiss Micro’s rose to the challenge. Their objective being to engineer an updated 41, still running precisely the same software, but on a modern, low power, fast processor platform employing an ARM Cortex-M4F clocked at 80Mhz (see power notes below). The display utilised is a 400x240 pixel mono capable of holding a display image when switched off. The DM41X doesn't graph but the larger display is used to show some or all values on the stack, the value in the alpha register and info regarding the system including available program memory, the name of the current program and a reference to a calculator state file in flash memory. Swiss Micros added 4MB of external flash for the CPU to use and some nice features including an IR LED (with a means to drive an original HP printer) and a USB interface designed to pop up as a FAT drive when connected to a host machine. The DM41X uses an internal, non rechargeable button cell battery (life is likely to be measured in years) or it can be powered directly from the USB. When running on battery, the CPU clock is reduced to 24Mhz but is clocked at full speed when powered by the USB. Compared to an original HP 41CV machine the DM41X is blisteringly fast (actually under either power option). The DM41X was released in September 2020 and I took delivery of mine in October 2022. The DM41X doesn’t have four physical expansion ports, but it does have a USB interface that activates like a FAT drive for a PC (linux, mac or PC and so think in terms of file exchanges both ways) along with sufficient on-board memory to permit a large number of the original HP 41 family plug in modules to be stored and then selectively enabled by the user, using a pick and mix interface. A large number of modules are supplied with the machine as standard. Third party mod files (including Angel Martins' phenominal back catalogue of work with this machine) can also be loaded onto the DM41X with relative ease. The physical design is gorgeously tactile, in the sense of an excellent clicky keyboard, highly reminiscent of the quality of previous HP offerings. It has a stainless steel case with an appealing weight and strength and Swiss Micros designed the machine to be accessible, so removing the case and even the main circuit board inside is easy (no plastic hot melt stand offs to fight with and break). Again, like the original HP 41 family, overlays can be placed over the top of the keyboard to customise the machine (allowing the user to take full advantage of the USER mode which I'll mention later). An important point to grasp, is that the DM41X isn’t an emulator. It actually runs the original HP41 family code with some additions purely designed to cope with the differences in the underlying platform. Essentially, it is a code compatible, blindingly fast HP 41 and a beautiful machine to use. It is a remarkable testament to the hard work of the Swiss Micro’s team and if, like me, you like RPN and desire a proper keyboard, then I’d recommend you take a look at three (and in due time, four) excellent machines. The two Swiss Micro machines: DM41X and the DM42 but also a third party machine known as the WP-34S. The team who developed that machine have been working with Swiss Micros to build a fourth machine which would be a significant advance on the WP 34s, notionally known at the moment as the DM 43. I have to say, I am eagerly awaiting sight of that machine. Using a DM41X and one of its modules An elegant feature on many HP programmable calculators is the SOLVE function, where you take a polynomial (an equation equal to zero) and use an iterative algorithm to find its root. There are other functions such as Poly that will find multiple roots but SOLVE has a back story that always makes me smile. SOLVE was first suggested by an HP engineer called William Kahan when he asked an HP project manager at a garden party if he could have a SOLVE key. William had worked out a way to find a root of the equation f(x) = 0 using an convergent iterative algorithm and which included a suitable way to stop. What he realised was that with a programmable calculator he could split the problem into two parts. The calculator would provide the iterative logic necessary to converge on the root (and deal with the stop condition). The user would create a program to compute the function. The SOLVE user interface would simply link these two, providing a lovely harmony between machine and user. The project manager wasn’t convinced, arguing that marketing had never identified the need for this feature but as the garden party went on (and a modest amount of booze flowed) the project manager eventually said to William, “look, give me an integrate key and I’ll give you your SOLVE key”. SOLVE and integration had some caveats, which I recall from Williams interview caused the user manual writers some sweaty hand wringing, mainly because some roots can be difficult to find and so either algorithm can fail, something the manual would have to make clear. The pressure to avoid delaying release of the calculator took care of that road block and the rest is history. SOLVE (and integrate) turned out to be tremendously useful functions. SOLVE isn’t a function supplied on a HP 41CV. But it was available in a Math module you could plug into the back of a HP 41CV... a rather nice illustration of why this hand held computer was (and still is) so versatile. If you're wondering where to look for information on SOLVE (and the math module), look at this excellent web site hp41.org. Click the side navigation link “library” and then under “Software” click the “HP Application Pacs” link. Scroll down and you’ll come across the raw Math pac code and also the math pac manual (in English and Spanish) which you can download as a PDF. Open that manual and scroll to page 17 and you’ll find an explanation of the SOLVE function. Page 21 explains the POLY function which can be used to solve polynomials up to the 5th degree. The user interface for both is quite different, but you’ll be able to work through that as required. Let’s work through the steps required to use SOLVE on a brand new DM41X. The first point to understand is if you try to execute SOLVE on a brand new DM41X, you’ll get the response “NONEXISTANT”, because the function doesn’t exist on a brand new machine. Our first step therefore, is to tell the machine to include the Math module which does contain the SOLVE function.

Click Shift-Setup to open the setup menu and select module (option 2). Then select the “Active Modules” (option 1). Click the “Plug” button (which is the top left keyboard button underneath the word “Plug” on the display). Click import to browse the available options using the up/down arrow keys to reach “MATH.MOD” and then press ENTER. This selects the module as a potential candidate into the parent menu but it still hasn’t been added to the calculator module space. Make sure it is selected on the “Select modules to add” screen and then click Add to formally add it.

Careful here: the machine will now challenge you with an are you sure? Look at the top line and note that it states: “Active Modules (ENTER to confirm)”. You do need to hit ENTER at this point to formally confirm this challenge and finalise the modules addition, at which point the calculator will now have the Math pac module installed. For the DM41X this is the equivalent of taking a switched off HP 41CV, removing one of the four rear blanking plates and physically plugging in a math module.

So now lets now look at a problem. Suppose we have an equation Ln(x) + 10x − 14.844 = 0. What value of x solves this equation? On the calculator, we first need to create a program (which I'll call FUNC) to calculate this equation (we’ll show shift key operations as yellow boxes and the alpha toggle as blue boxes). I’ve added comments on the right.

As a check we can quickly confirm our function is working by entering some random value for x and manually calculating the result. For example, an x of 2 should result in 5.8491.

The problem we’re trying to SOLVE is finding some value of x that satisfies the equation (FUNC(x)=0). To solve that, we invoke the SOLVE function (which resides in our newly installed Math pac) and tell it to use our new program “FUNC”. SOLVE will plug a range of values into the FUNC program iteratively until it can hone in on a solution that satisfies the equation.

SOLVE finds the root is 1.4474 and if you use FIX 9 to improve precision you’ll see it as 1.447421622. Just as a check, keep in mind that this root is sitting in the calculator X register so you can simply execute FUNC one more time to plug this root into the equation and see what result you get. Unsurprisingly it'll be zero, to 9 DP's precision. Armed with a graphing calculator, you can also solve this problem by graphing the equation Ln(x)+10x-14.844=Y. You’d plot the result over a spread of X values and then find the crossing point on the X axis where Y=0. Being able to graphically model a function like this is a very useful tool especially when powers are involved and multiple roots are possible. The User keyboard and a new custom key The original HP 41 had a User key at the top (the DM41X has exactly the same feature - but the button is on the right side). This button toggles the calculator into two different keyboard modes: standard and user. You always know which mode you're in by checking for a small “User” icon on the display. By default all keys in user mode do the same job as the standard keyboard but you have the option in user mode to assign any function or label to a key using the ASN function. So, in User mode, keys can be customised for a particular application. If you look closely at the three HP’s in the NASA picture, you’ll spot the three calculator keyboards look different. These machines were actually running a specially defined user mode key set with a plastic overlay fitted on the top of the keyboard as an aide-memoire. Regarding knowing what each key actually does, the 41 (and the DM41X) provide an option to press and hold a key, at which point the display will announce the function that the key handles. Hold the key down for long enough and the display will switch to NULL, providing a way to cancel the function. On the DM41X there is a new, but linked feature known as the Custom Menu. You’ll spot a key on the bottom row of the machine called CST. This allows you to assign functions to any key A through to P (inclusive) along with a couple of others. Execution of the assigned function simply requires pressing CST before the key. Imagine we want to assign the function SOLVE to the top left key Σ+.

• Press SHIFT-CST to open the custom menu edit screen
• Press the key to assign the custom value to: in this case the top left Σ+. Note that this highlights the “A” option on the screen because Σ+ is the “A” key in alpha mode.
• Type SOLVE (Note that you are already in Alpha mode)
• Press R/S to confirm the change (or, click the ON key to abort)
• Press CST to close the custom menu editor

Now, if you now press CST followed by the Σ+ key you will execute the SOLVE function. Otherwise, the Σ+ key works as per normal.

Anytime you press the CST key, you will see a display showing all the new assignments made to A through P (along with shift-↑, shift-↓ and shift-alpha).

The custom feature on the DM41X provides an easy two-key method to invoke any function you like. Summary I’ve barely scratched the surface of this remarkable machine. The sheer amount of functionality in the DM41X is astonishing. It is packed full of rich and well tested functions, it is fast, light on power consumption and comes with an expensive and solid tactile feel. The icing on the cake is the reliable and well proven foundation of HP 41 family software. What an absolute delight the DM41X is! Comment | Back to Quick Links... 23^rd July 2022 Addendum to mass air flow woes You can read the potted history of my original fault further down in my blog - it linked to a faulty mass air flow (MAF) sensor for my 14CUX fuel injection system - one that I diagnosed incorrectly but fixed after biting the bullet and buying a new part. The part number in question is ERR5198P. The original MAF part fitted to the vehicle was stamped with the part number ESR1057 (it also had “5AM” written on the top). In fact this part is interchangeably replaced in the early 90’s by ESR1057L and in later years both parts were superseded by part number ERR5198P. They are used on Land Rovers and Jaguars and on both vehicles are identical. So why revisit this problem? Well, I'd bought a brand new MAF to fix the original fault 2 years ago... only for me to observe an odd problem over the last month at which point alarm bells started ringing. Normally this MAF and ECU combination results in the left and right banks of the engine oscillating around stoichiometry as soon as the O2 sensors are fully warm and under most every driving condition (cold, hot etc). I can see what the ECU is doing, because when I first fitted this fuel injection system I built a dash-mounted digital telemetry system showing the states of all sensors, but in particular showing the raw O2 sensor data as two dynamic bar graphs... arguably one of the most useful tools for fault diagnoses. A quirk of this replacement MAF would be seen whenever the engine was cold and the vehicle driven up a nearby steep hill. Under those conditions as the vehicle was climbing the hill the ECU would overfuel (rich - both O2 sensors stuck high) until the top of the hill was reached at which point the engine would be much closer to full temperature and my foot would be easing off the throttle. Close to the top of the hill, the ECU would slowly reduce the richness just enough until O2 oscillation would start. The same thing did not occur when the engine was fully warmed. So the overfuel condition was temperature and load dependant and very much linked to this particular MAF and ECU combination. One morning around a month ago I spotted that the idle was decidedly rough and oscillation of the O2 sensors wasn't happening. As I drove up the hill with the engine cold, I observed (oddly) that the ECU was fueling correctly and both O2 sensors were oscillating nicely. However, as soon as the vehicle came to a stop it ran like a dog and no oscillation of either O2 sensor occurred. A number of tests were then carried out to check for any air leaks in the intake path - but the problem persisted. After that I swapped this two year old MAF for a stock spare and lo and behold the problem cleared and the idle nicely stabilised. Groan... This fault condition suggested that the £90 mass air flow sensor I'd bought just 2 years ago, had failed or at best, drifted out of spec. I spent some time looking at this, including spraying the daylights out of the sensor with MAF hot wire sensor cleaner to no avail. I also played with the trim value and concluded that in closed loop running (with O2 sensors) the trim value set when the ECU is first reset is essentially ignored. I did see some odd behaviour when the trim voltage was altered with the vehicle running... and which resulted in the two banks badly misfueling - but I struggled to make sense of what the ECU was doing and didn't persue as no matter what adjustment was made, performance degraded. My final conjecture was that the MAF must have started to under report air flow into the engine, perhaps down to dirt on the hot wire, the thermistor drifting or some other drift issue inside the electronics. Speaking of which, I opened the unit up fully and found that the current design is high integrated and very different from earlier models. It is not easy to either tweak or change and one of the surface mount IC's may well be a microcontroller. Under reporting air flow would explain why the idle was awful, but deep throttle running, especially when cold, would paradoxically fuel nicely. Ha... a fault that actually makes one area of engine operation run better than before - who'd have thought? The realisation did make me pause. Suppose the calibration of these MAF's is always a bit plus-or-minus a bucketfull and suppose they also tended to drift over time. In my case, the problem unit was definately able to detect air flow but was just misreporting the amount... which begged the question could we create something that would resolve this specific problem? A hot wire MAF on a 14CUX injection system generates an analogue voltage. When the ECU is powered up but with the engine not yet running, the MAF generates a fixed voltage usually around 0.3v. At hot idle (around 725 RPM), the voltage will be around 1.28v and will raise to 1.3v if cooling fans are fired up for the cooling system. The voltage will rise yet further as the engine air flow increases and so if a fault causes it to missreport... well, why not stick some kind of analogue stage between the MAF and the ECU to compensate for the error? Sounds too simple... right? and yet it works... like a charm. Knowing I'd need to use an op-amp design, I scopped out what I felt might solve the problem and then chatted with a dear and very old friend, Brian... a fellow radio ham. Excellent in the digital domain, he is superb in the analogue world. He's forgotten more than I've ever learned about analogue design and is inoventive and skilled at coming up with solutions to fiddly and difficult problems. Definately, one to chat with before starting. We closely honed in to an op-amp adder design - because unlike an amplifier where gain acts like a multiplier and so will have a small effect on small voltages but a much larger effect on larger voltages, we instead needed to take a fixed voltage, lets call it Vx (but where Vx could be precisely adjusted within a fairly narrow range of around -1 to +1 volts) and consistently add it to the MAF generated output before feeding the new sum to the ECU. In effect, Vx would compensate for any fault or drift in the MAF sensor.

Knowing that the MAF generates an output from 0 to 5v there are a couple of complications. The first is that unless the op-amp used is a very specialised type, running a rail of +5V means that when the op-amp is saturated, it will only ever reach around 3.8v max. This is a normal op-amp characteristic and the only way to resolve it is either to use specialist op-amps or by simply using a supply rail higher than the 5v ceiling output we require. A supply of 9v works well in this regard and so I used a 7809 regulator. A second complication is the difficulty of building this circuit without using a split supply. You’ll find that if you use a single supply of ground and +9v, once the input drops below 1v, the output will start separating from the input by increasingly large amounts and no amount of adjusting will resolve the error (from 1v up, the circuit will operate reasonably well). A solution is to use a split supply which on first sight appears to be difficult but turns out to be fairly easy as Brian explained. We use the +9v to drive an LMC7660 (switched capacitor voltage converter chip in 8 pin DIL) along with two 10uF capacitors to generate a low current -9v output. Max current supplied by this device is only around 400uA but we only need around a third of that anyway - so perfect for the job.

With those two issues resolved, the design employs unity gain amps with high tolerance R’s for input and feedback and off course selected for a high impedance input and low impedance output. The first stage inverts the signal while the 2nd stage does the same and so effectively corrects it (from the point of view of the ECU). The potential divider and pot on the second stage non inverting input results in a additive voltage ranging from -0.735v to +0.845v to whatever the input is set as (the precise range is highly dependent on the exact tolerance of the R’s in the potential divider and so again high tolerance R’s work best). The 10K in the middle is a 25 turn multiturn precision pot.

On the breadboard it works like a charm but is electrically noisy as hell. Too noisy to use. First prototype PCB model is shown here sitting on the bench. The input voltage is fixed at 0.3v. The differential voltage (the difference from the output to the input) is set to +0.05v which means that the output is exactly 0.05v higher than the input and for any input from 0v to 5v. It was left on soak test for 24 hours to see if there any significant drift or alteration - none was observed. The circuit is beautifully stable and much less noisy now that it is on a prototype PCB with proper decoupling.

I fitted the PCB loose inside the MAF cavity after wiring up the supply and after breaking the MAF output wiring at the socket into the two parts we need (MAF Out, ECU In). The PCB is a tight press fit inside the cavity... but really needs four dabs of araldite to fix it properly... plus an aluminium screen over the top of the case and which is earthed and silicon sealed to prevent water getting in.

I started by calibrating the new compensation unit so that the differential voltage was zero. What this means is that the adder would add zero volts to the output generated by the existing MAF and so should therefore leave the vehicle behaving exactly as it did before, with all the existing poor running symptoms of a rough, hunty idle, no oscillation around stoichiometry at idle when warm etc etc. The vehicle exhibited exactly the same faults... which is good. That means that the new circuit isn't adding any other new problem into the mix. I drove the vehicle home and with it still running adjusted the POT to slowly increase the differential voltage. Within a half turn the idle had smoothed. Oscillation of the O2 sensors started by the time I’d adjusted the pot by around a turn and a quarter. A test run followed at which point I spotted that under some conditions (deep throttle when warm) she was slightly over fueling and so I pulled into one of the car parks to back the adjustment off by a quarter turn. She then ran nicely under assorted driving conditions. When I got home, I measured the differential voltage at 0.06v. Perfect... we've effectively compensated for an under reporting MAF converting an expensive door stop into a working MAF sensor. All it took was adding 0.06v to the MAF output. This won't be the final version for three reasons. The circuit has a weakness where when the power is cut, the output fed to the ECU goes negative for a second or so and down to around -3v. There is a risk that could cause the ECU a problem long term and so I've been chatting to Brian about how I could resolve this. He suggested using a FET to control the output via a CR reset circuit which would switch the output off when the power was turned off. I'll be looking at that next. A second problem is that I've used a 47uF capacitor on the input to my 7809 voltage regulator... but when the entire system is turned off by the ignition switch, the storage that C holds causes the main ECU relay to chatter. This is easily solved with a diode but it does represent a problem that needs to be ironed out. A third issue is that instead of building this into the body of our specific MAF, I suspect it might make more sense to build this into the main wiring harness, so that any MAF could be compensated if required. Lastly, is it worth considering a mapping system to sample the MAF output digitally and if necessary remap it to any value we like and then use a DtoA to convert the remapped value to an output for the ECU? I'm pondering that right now as although I hate overkill, I do love over engineering shit. On the other hand switching to something like a megasquirt might make more sense if we're going to that much trouble. Hey ho! Thanks Brian. Seriously, what a gifted engineer you are. Comment | Back to Quick Links... 15^th March 2020 - COVID-19 COVID-19... now officially a pandemic provides much to think about doesn’t it? The R0 appears to be around 2.28 estimated by bootstrap resampling of data from the Diamond Princess cruise ship. The estimate has limits from 2.06 to 2.52, but even at the lower limit, there is more than enough scope to tell me there will be strong spread characteristics unless tenacious infection management and control can be taken and enforced, more or less an oxymoron in a first world democracy. The mortality rate (MR) is also rather hard to pin down, partially because it depends on where the sampling is done. Recent time delay adjusted estimates reported in the Lancet suggest that the MR may be as high as 20% in Wuhan – at the epicentre of the outbreak. Current official figures quoting an MR as low as 3 to 5% may therefore underestimate the likely figure. We’re all going to find out the hard way. General estimates suggest an infection rate between 40 and 75% of the population. Statistically speaking those of us above 60 will be in the hardest hit group... but even the 50 to 65 year olds will face a tough battle... and off course they will find themselves fighting for extremely limited health care resources by the time the bulk of the population get hit. The one thing in our favour is that even worst case, around 80% of the population (and it may be higher) will walk away scot free after a bad hair day, a fever and feeling a bit rubbish. I hope it isn’t quite as grim a prospect for the other 20% that I fear it might be. Way back in 2012 there was a fuel crisis in the UK. I happened to be on holiday in Cumbria in the middle of a two week break with half a tank of fuel in the car when the first reports came in of a refinery blockade. Within half a day, every local fuel station was empty. Within 3 days, every fuel station within 100 miles was dry and all the local convenience shops had been stripped bare of bread and milk. I didn’t use the car at all during that second week and more or less hunkered down in the cottage. I only just made it home, running on fumes. I was quite naive at the time, because I had no idea just how fast a series of headlines could influence behaviour to the point where a huge 3 day supply line would effectively collapse, even without taking into account the blockade itself. It is a little like a bank capable of handling any number of requests, but which will happily collapse in a day if there is a run. Then there are the knock on consequences to this type of failure... in this case the fuel blockade meant that supermarkets couldn’t transport food and so as the shops emptied there was no way to replenish stocks. Within a week, shops everywhere were bare. Ambulances, police and fire services found themselves having to demand fuel stocks from the army and all the time it took a good week before government finally figured out they needed to organise alternatives (involving the army stationed at the refineries). Hunkered down, I watched all this on TV as my end date loomed safely tucked up in a beautiful cottage in the Lake District (thanks Scale Hill) and made a mental note never to get caught out in the same way again. I’m not a prepper in the sense of wearing camo and making fire by rubbing sticks, but I did immediately start a long term detailed planning exercise to obtain the necessary skills to independently source food and at the same time to build a personal emergency supply providing sufficient resource for around six weeks behind closed doors even if we found ourselves without running water or electricity. That involves a series of dissimilar skills – for example understanding nutrition intake requirements while at the same time being able to create simple cooking solutions for food from a variety of sources... beyond tins. As I look at the Italian experience and the runs on the supermarkets in the UK I realise the wisdom of such planning and can’t help feeling vindicated given the number of times I've doubted myself. Proper planning prevents p??s poor performance, is an adage that applies rather well in this case. Good luck everyone. Comment | Back to Quick Links... 10^th Jan 2020 – 14CUX EFi Engine fires but then immediately stalls Happy new year folks! Have you ever got into your car on a cold morning, turned the key and had the engine fire up nicely but then immediately stall? The back-story is that 10 years ago I retrofitted a Bosch 14CUX EFi fuel injection system to my elderly 1962 Land Rover running a petrol V8. All told, it has been very reliable with only fairly minor problems and provides good fuel economy and significantly lower emissions than its original twin carburettor setup. I fitted everything from the intake manifold up along with fuel system, the loom wiring, ECU and some other fabricated systems required to support the 14CUX including a dedicated home made telemetry system (microprocessor coupled with a small colour LCD touch screen) mounted just to the left of the dash. With this I can dynamically see some of the key values read from the ECU such as the engine speed, throttle position sensor, both temperature sender values (CTS and FTS), mass air fuel values and in real time (using two bar graphs) the signals from the two oxygen sensors in the exhaust pipes. My 14CUX tune resistor is a 3.9K and so the installation runs as a closed loop system defined as "Europe & UK 3.9 (or 3.5 Disco) with catalyst". In early November this year as the temperature was getting cooler I began my usual pre-winter service: oil level checks in the series III gearbox, transfer box, overdrive, swivel hubs, both differentials and steering box while also changing the engine oil and filter. After draining the 3.5 litre Rover sump and replacing the filter I generally like to fire the engine to make sure that the oil pump is properly primed (to move oil rather than air).

On starting, the engine fired but then immediately stalled. A little puzzled, but guessing I'd done something silly, I disconnected the mass airflow sensor (MAF) sitting between the air cleaner and the plenum and which electrically measures the amount of air entering the engine and she started and ran just fine (see the explanation further down for why this may happen). By the end of the service, still feeling puzzled, I reset the ECU (to clear the previous missing MAF sensor fault) and the engine started and ran well. She continued to do so for the next couple of weeks. hmmmmm... a problem brewing!

Sure enough, two weeks later on a cold morning, the same fault returned with a vengeance. Starting her cold, turn the key... engine burst fires to around 1100 RPM (normal) but then immediately stalls. I could repeat this as many times as I liked but the engine stalled every single time. As during the service, if the MAF sensor was disconnected, the engine would start and run (not brilliantly, but well enough). I later found that if the engine ran for long enough to get the coolant up to around 60℃ the stalling fault cleared and she'd start and run perfectly from then on. After warming, if the engine was allowed to rest for (in one test) 4 hours when the coolant and fuel temperature sensors would report around 12℃ she'd still start quite reliably. But, if she was left overnight, the same fault would be guaranteed to reoccur... always affecting starting a stone cold engine with a closed throttle. Early on in my exploration of the problem I reset the ECU and swapped the MAF sensor with a stock spare that I'd bought many years ago on eBay, but the engine failed in exactly the same way. So clearly this fault wasn't being caused by the mass air flow sensor... or so I thought. Ok... so what is the likely cause? Well, any warm petrol engine needs air and fuel to be supplied close to an ideal ratio of 14.7:1 known as a stoichiometric mixture. For every 1 gram of fuel, 14.7 grams of air will be required for combustion. When an engine is cold, the mixture has to be made richer with more fuel to get it to run, not because the combustion characteristics change when cold (they don't), but simply because it is very much harder to convert raw fuel into vapour when an engine is stone cold. Instead of the fuel actually reaching the combustion chamber as vapour, it tends to pool on the walls of a cold manifold as a liquid. Consequently the engine needs more fuel to compensate. The 14CUX injection system gets fuel into the engine by spraying a fine mist of raw fuel using two banks of four injectors squirting directly into the eight intake ports of the engine. Air gets in via one of three possible routes. If the throttle is open, the lions share of the air passes through the air filter, through the mass air flow sensor (MAF), through the open throttle into the large plenum before being sucked into the engine along with the fuel. The ECU alters the amount of fuel injected by adjusting the open time of the two banks of injectors in order to correctly match the volume of air measured by the MAF - thus achieving stoichiometry. If the throttle is closed, air flow occurs via two dedicated subsystems both of which use a small portion of metered air from an opening in the throttle body just in front of the closed throttle blade... meaning that the ECU 'knows' how much air is being consumed by both of these subsystems. One of these two idle air supply subsystems known as the base idle system provides a calibrated, fixed amount of air at all times into the plenum (and then the engine). The user calibrates this by turning a screw (the base idle adjustment screw) located on the outside of the plenum (sometimes underneath an anti-tamper plug), close to the throttle blade, to control how much air can pass. The screw admits air into a roughly 6mm diameter bore drilled on the inside of the plenum and which exits on the engine side of the throttle blade. Once this path has been calibrated, the resulting air flow entering the engine is fixed and constant, but when compared to the amount of air entering via the throttle it is also rather small and only significant when the throttle is closed. Taken on its own, it should result in a warm engine idle speed of around 525 RPM. If normal idle is around 730 RPM then this path supplies something close to 72% of the air required for the idling engine. If you ever do remove the plenum from your EFi, make sure you unscrew the base idle adjustment and clean the path from start to finish as it does tend to get very gungy over time. The second idle air supply subsystem known as the Idle Air Control (IAC) system makes use of a stepper motor under control of the ECU acting like a variable air valve sitting between metered air from the MAF and the plenum chamber. The ECU opens the stepper motor to admit more air which makes the engine speed increase, or closes it to reduce the amount of air causing the engine to slow down. The MAF sensor will at all times measure how much air is being consumed (regardless of the position of the stepper motor) and so the ECU can always adjust the amount of injected fuel for stoichiometry. The ECU uses this subsystem to bring the idle speed to roughly 730 RPM for a warm engine and more for a cold engine. Whenever the engine is switched off the ECU terminates engine operation but waits until it detects that the engine has stopped. It then opens the stepper motor as far as it can, to maximize the idle air path in preparation for the next time the engine is started. You can actually hear this as a quiet buzz shortly after the engine dies. Cold starting process Cold starting works more or less as follows. The ECU starts the fuel pump and refers to the coolant and fuel temperature senders (CTS and FTS, which will both be sitting somewhere around 3℃ most mornings where I live) to figure out the fuelling map to use. These two temperature values are very important because starting a cold engine requires a very different fuel map to that required by a hot engine. If the sensors were misreporting then the engine would run badly assuming it ran at all and so both are important to check if you have a problem. As it happens, I can read both these values in degrees centigrade from my telemetry system which queries the ECU directly to see what values it is seeing and so I knew both were correct. As soon as the ECU sees slow pulses incoming from the distributor (8 per crank rotation) during slow engine cranking it starts injecting fuel (if it doesn't see those pulses within a second or so, the fuel pump gets turned off). Remember that at this point the IAC air path will be fully open as a result of the previous engine stop (or ECU reset). Assuming the engine fires, the wide open IAC air path coupled with the rich cold starting mixture immediately allows the engine to burst fire up to around 1000 to 1200 RPM, which the ECU detects when the distributor pulses suddenly increase in frequency. At that point the engine is running fast and rich. The next step for the ECU is to start reading the mass airflow sensor to figure out how much air the engine is consuming so that it can properly lean out the excessively rich starting mixture while at the same time lowering the fast idle speed by closing the IAC stepper motor. In our case, as soon as the ECU tried to lean out the mixture, the engine stalled. Why would disconnecting the MAF sensor consistently allow this engine to run? Well, whenever the MAF is disconnected (or electrically fails), the ECU detects the missing signal and switches into a special limp home mode, employing a fixed and rather rich fuel map. Without the MAF, the ECU has to guess air flow into the engine which it does using the throttle position sensor to read how wide the throttle is open. As it happens, the limp home fuel map works really well... something that the left and right bank O² sensors on my telemetry system confirm. Being able to see these O² sensor outputs as bar graphs on a colour LCD display is, arguably, the most important diagnostic tool you can have when assessing the overall health of a running 14CUX EFi system. What I found was that during part throttle cruise the limp home fuel map generated a mid point voltage on the sensors, but during deep throttle or WOT, the sensors would saturate rich... exactly what you'd want for a limp home mode. It is astonishingly good and easily good enough to get you home. Hats off to Bosch for the design. There's an additional diagnostic value to finding that limp home mode will run the engine while being able to see the O² sensors... for if the engine does run, it pretty much confirms that the loom wiring, fuel pressure, injectors (at least most of them), throttle position sensor and both O² sensors are all working well. Here's a video showing the proper operational characteristics for both O² sensors in a 14CUX fuel injection system running at idle.

The fact that the engine would run with the MAF disconnected indicated it was perfectly capable of running so long as the mixture was fairly rich. We'd already done the MAF swap so I knew (actually, I thought I knew) that the MAF wasn't misreporting the mixture, suggesting to me that there must be an air leak somewhere in the induction system resulting in a lean running condition. I also knew that any air leak would likely have a disproportionately large effect whenever the engine was cold. This was my starting point. The whole induction system on an EFi engine is fairly complex and delicately balanced. The seals between all the components have to be spot on to avoid air leaks. All the various hoses, air filter, MAF, throttle body, plenum base, ram housing, intake manifold and even the O rings around the base of all eight fuel injectors all provide any number of ways air can get into the system. It is possible albeit slightly risky to identify air leaks by carefully spraying solvent around the joints and listening for a change in engine speed - but this test never once identified a problem. On this engine the V8 valley gasket sitting between the intake manifold and the block acts as an air seal between the intake manifold and the engine heads. It was an older style tin gasket, well over 6 years old and scabby and so I suspected there may be an air leak under the intake manifold that I couldn't get to. I also separately found some of the vacuum hoses supplying the brake servo, PCV system, dash gauge, fuel regulator and the distributor advance/retard source were a little perished - so an air leak was a very logical piece of reasoning... but as it happens, completely wrong. I will say that after two weeks rebuilding the entire induction system from scratch the engine looked delightful, but on the first cold start after all that work had been done, she burst fired and then immediately stalled. Oh joy! I then spent days looking at every conceivable cause of the problem... fuel system, fuel pressure, fuel regulator, electrical connections between the ECU and the various components and anything else I could think off, but no matter what I did, the engine would stall as soon as I tried to start it from cold. Checking the eight fuel injectors Here's a simple confidence check that the 8 fuel injectors are good and all you'll need is a pressure gauge on the fuel line between the filter and the injection rail. Switch the ignition to the run position (not start) at which point the fuel pump will buzz for a couple of seconds then switch off. Now have a look at the fuel gauge and you should see around 37 PSI. After a minute that should still be very close to 37 PSI, assuming all the injectors and the fuel regulator are sealing properly - that's part one of the test. If you now remove the electrical plug from the injector for say cylinder #1 and momentarily apply 12v to its terminals you'll be able to see the pressure on the gauge suddenly drop, confirming that that injector is opening and passing fuel into the cylinder. I repeated this test on all 8 injectors and even though it doesn't measure the precise amount of fuel flowing, it does nicely confirm that the injector is both opening and closing. Regarding the wiring to use for the above test, if you imagine you're leaning over the wing (fender), looking into the engine, place the ground wire on the left hand pin of each injector and momentarily brush +12v on the right hand pin in order to mirror what the ECU does. Also note that you won't be able to get to all 8 injectors depending on the orientation of your plenum. Mine has its throttle on the drivers side, which means you can't get to the injectors for cylinders 4 and 6. Regardless I was still able to test 6 injectors... and the other two were checked the next time the plenum was removed. Knowing that 6 out of 8 work, isn't bad. Checking the fuel pressure regulator If you're uncertain about what the fuel regulator does, here's what it should do - and all you'll need is a fuel pressure gauge in the fuel line between the filter and the injection rail. You'll need to be able to run the engine (even if in limp home mode). If the fuel pump has just run, but the engine is not yet started then the fuel pressure should be around 37 PSI and it should hold pretty close if you wait for a couple of mins (confirming that the injectors and the fuel regulator are maintaining their seals). Start the engine and let it idle. With the throttle closed, the fuel pressure should remain stable at around 34 PSI. At that point if you snap open the throttle, raising the engine speed to around 2500 RPM the fuel pressure will at the same time snap up to around 37 PSI but quickly return back to 34 PSI when the throttle is closed. From idling, if you were instead to very gradually open the throttle increasing engine speed to 2500 RPM, then the fuel pressure will stay quite close to 34 PSI and then slowly drop to around 28 to 30 PSI as the revs and fuel consumption increases. Remember as the engine vacuum increases, the fuel pressure should level out at around 34 PSI. If engine vacuum suddenly reduces (ie: whenever the throttle is blipped opened) then fuel pressure should increase to a high of around 37 PSI. If the fuel pressure behaves this way, you'll know the regulator is working. I did look online for a video showing what the fuel pressure should do on one of these systems, but without any luck... so here's a video that might help you. In this installation the gauge sits close to the engine between the fuel filter and the input to the fuel injection rail. It is shown working on a fully warmed idling engine driven by a 14CUX fuel injection system... consequently as the camera is buried in the engine bay there's a lot of noise... sorry. If I was to have switched the engine off, the pressure gauge would rise to 37 PSI and hold there, actually for a good couple of hours... all signs of a working pressure regulator and injectors that are properly sealing.

Another more involved way to test the fuel regulator requires access to one of those hand held vacuum pump tools. You need to hardwire the fuel pump to run permanently which is obviously much more dangerous if you do something wrong - so my advice is don't use this technique unless you know precisely what you are doing. Connect the hand held vacuum tool to the fuel regulator and then start the pump with zero vacuum. Pressure should be 37 PSI. Apply vacuum using the hand tool and the pressure should slowly reduce as you get closer to 15 to 20 inch mercury to around 34 PSI where it should sit. If the vacuum is suddenly released (simulating WOT) then the fuel pressure should snap up quickly to 37 PSI. Using temperature to pin this down In exasperation and with no clue what the problem was, I wondered if I could use temperature to pin the fault down - given that I knew the engine worked really well when fully warmed. For my first test I removed the ECU and kept it warm inside the house overnight, but I had exactly the same problem the following morning. My second test ran a heater inside the cab for a couple of hours, before trying to fire her up - but with no joy. Faced with a stalling engine and purely on a hunch I removed the MAF sensor from the cold car and stuck a hot air blower in front of it for 5 mins... after which, low and behold, she started perfectly.

In disbelief, I took both of my MAF's onto the bench and had a closer look using the test harness shown in the picture. MAF's employ a very simple four wire circuit. Three wires deal with the supply (ground, +12v) and the MAF air flow signal output voltage - which should sit between 0.2 and 0.7 volts with No Air Passing (what I call the NAPV - measured with plastic caps on both ends of the sensor body). A fourth wire is an input to the MAF and is set to a value by the ECU depending on the mode the 14CUX is running in (see tune resistor). If using catalytic converters, then this fourth wire will be 1.9v and it won't ever change. The ECU deals with this signal differently if the 14CUX is running in a different mode from mine, at which point an adjustment screw on the side of the MAF can be used to adjust CO². With both my MAF units on the bench I found the following. The original MAF would generate a tiny 0.02v air flow voltage when cold but would suddenly burst into life and start outputting around 0.4v if a hot air blower was used to heat the body of the unit up to a typical engine bay temperature. Once it had switched into working mode, I could remove the two plastic caps, blow into the sensor and see a nice large signal swing up to around 4 volts. By contrast, the spare MAF that I'd used right at the start as a substitution test, was completely dead and didn't generate any air flow voltage regardless of the temperature.

The penny drops I'd never spotted the zero air flow voltage from this MAF - why? Every time I'd measured that voltage it had been in spec (0.3v upwards) but that can't have been the case when everything was stone cold, as my bench tests confirm. The only plausible explanation I can come up with is that I must have accidentally measured the voltage whenever the MAF had warmed sufficiently to burst into life. Swapping the MAF with our spare unit had also led me to incorrectly believe the MAF couldn't be the cause of the problem - but only because the first MAF generated no voltage when cold while the spare generated no voltage at all, because it was bloody dead. These two entirely unconnected faults happened to give rise to the same failure and so reinforced a wrong diagnosis. Yep, fault diagnosis by substitution is not always particularly reliable and tends to be very expensive. To make this even more bizarre, as my spare MAF was dead anyway, I removed the sealed plastic cover and the aluminium plate underneath to have a look at the PCB - and immediately found two dry joints on the legs of a TO220 Darlington transistor. Once those two faults were rectified, the unit burst into life on the bench generating a healthy 0.4v with no air passing. Blowing into the unit with the covers off showed a nice sharp signal swing up to around 4v. Feeling pleased, but understandably a bit uneasy, I ran the unit on a 24 hour test and spotted something interesting. As it warmed, the air flow output voltage slowly dropped to nothing if you waited long enough. Out of interest I popped this unit into the vehicle to see if it would eventually lean the engine out to the point she couldn't run as I knew full well I'd be able to get home by disconnecting the MAF (flipping into limp home mode). After leaving the MAF in the engine overnight (so it was stone cold) the engine started perfectly and I then took her for a long test run while keeping a close eye on the O² sensors. After around 30mins the engine was running, but I noticed that both O² sensors had stopped oscillating (meaning the engine was now running lean). By the time I'd reached 45 mins into the test, the mixture was so lean that the engine became undriveable, with pops in the intake confirming the problem. I pulled the MAF plug to revert to limp home mode and drove back immediately. So even after fixing the dry joint faults, this unit was failing anyway and in fact both units were exhibiting temperature failures. Later tests on the bench confirmed that it wasn't a component on the PCB causing the temperature failure - but instead the fault occurred when the aluminium body housing the hot wire sensor was heated. If you Google this type of problem, you'll generally get the idea that this will either be an air leak somewhere in the induction system or a faulty MAF, but I've read lots of comments suggesting MAF's mostly fail by going too rich (over reporting the amount of air entering a system). Well I've now seen three MAF's fail and all of them misreported air flow too low, causing the ECU to run the engine too lean. In my case, the only way to check for sensible operation was to stick the unit on the bench and make sure that the air flow output, measured with no air passing, doesn't drop to zero whenever the temperature changed. Faced with the same problem again I think I'd start by checking the fuel pressure to make sure I had around 34 PSI at idle rising to around 37 PSI when the throttle was blipped open. I'd check for any obvious air leaks (broken hoses) and I'd also cap off the feed to the brake servo to make sure that the diaphragm wasn't broken (unlikely but worth ruling out). I'd electrically buzz out the connections between the ECU, MAF and both temperature sensors (coolant and fuel) to make sure the loom was sound. Then (assuming I wasn't able to query the ECU directly) I'd measure the resistance of the temperature sensors when the engine was stone cold to make sure the resistances accurately reflected ambient temperature. Assuming no faults were found I'd disconnect the MAF, take it to the bench and measure the output voltage with no air passing when cold (using a fridge) and when warm (use a hot air blower). I'd be looking for a condition where the output voltage drops close to zero volts, at which point, bin the MAF and buy another. If I still couldn't find a problem, I might start looking for induction air leaks. I ordered a brand new MAF from Rimmer Bros (thanks guys) problem solved... and after all the faffing around and head scratching, well at least the engine looked rather splendid. Comment | Back to Quick Links... 6^th Nov 2019 – Room thermostat The blog entry on the 30^th Oct outlined the idea and the objective. Just a few days of work got me to the point of a viable user interface to test some of the hardware and to run it for longer periods to assess reliability.

The picture shows the basic development platform - using breadboard fitted with a MINI-32 processor board, Digole colour display and wiring required to connect the CPU to the 1-Wire bus. I coded the software so the display shows the target temperature (20) but with a means to alter in 0.5 degree increments. Temperature samples are taken by the system every minute from the lounge (main living area) and the outside of the house. When there are more than three samples available the display will show the max and min of both. If the number of samples exceeds 60 (ie: 1 hour) then the user can click the trends button to see a graph of what is going on... and that will be over the last 24 hours if there happens to be a full set of 1440 samples. The LED looking display (bottom centre) is an indicator of what the boiler is being told to do but I think I'll probably ditch that and instead use a tricolour LED fitted to the front of the enclosure showing blue when the boiler is off, red when switched on and otherwise green when the system is starting or off altogether. The sharp eye'd out there may spot a lone voltage reg (a 5 to 3.3v) and nearby a 5V switch mode PSU. I'll be assessing that later with a mind to powering the box as I'm not keen on using a capacitive power supply :-). I'm also toying with the idea of interfacing the system with an ESP8266 chip to provide WiFi access as I quite like the idea of recording temperatures accurately over many months - via an application running on a PC in the house connecting over TCP to transfer all temperature data continuously.

The dev'mt is running in parallel with a load of other stuff going on in the house, but I'll blog more when I get time. Comment | Back to Quick Links... 30^th Oct 2019 – The MicroLAN or 1-Wire bus My recent fix for the ST9400C boiler timer (blogged below) got me thinking about temperature regulation with a mind to minimising our energy bill as much as possible. The relatively new boiler system is fitted with thermostatic radiator valves (TRV) on every radiator but no room thermostat to monitor the main living space temperature. By the autumn when we started using heat (after resolving the boiler timer fault) we found that the main living space would tend to overheat unless all the TRV's were throttled back, suggesting that the boiler was working hard, for no real gain. Current UK building regulations require that every radiator in a new build or where the system is being replaced should be fitted with a TRV, except for the radiator(s) fitted in the same room as a wall mounted thermostat. All well and good unless for some reason, someone decides not to actually fit a room thermostat. Ok - so just fit one! A simple mechanical thermostat could be fitted, or something smarter which will often have a WiFi capability permitting App control. Some of these are IFTTT compatible and so provide interesting script interfaces for control. In terms of fitting, some must be hardwired using a cable from the 10 way DP (see notes below) while others split the problem into two parts, a mains operated switch unit mounted close to the DP and one or more battery operated wireless remote temperature sensing units. Some of these systems permit more than one temperature sensor to be hooked up as a network and I understand they usually fire the boiler based on an average of the different temperatures. Good examples are the tado° or Hive products, which look lovely and are fairly easy to install even if cabling is required... but Hive entry level thermostats cost around £100 while a tado° kit controlling just one radiator remotely will set you back around £120. The costs spiral up fast if you want to dot multiple thermostats round the house and even faster if you want to pair thermostat(s) to individually control every radiator in the house. It also doesn't take long to spot other potential running problems with this type of distributed control. What happens if the LAN goes down and what kind of reliability can you expect from numerous wireless thermostats coupled to umpteen motorised radiator valves... all using battery power. The other issue to consider is how well such a system can monitor all the decisions being made. As you'll no doubt appreciate, a running boiler might not be overly keen on a bunch of independent control systems closing off every radiator valve in the house unless the system was fitted with an automatic bypass valve (ABV)... our system isn't. Then there is the thorny issue of cost and when batteries are taken into account, long term running costs. It seems to me that unless these types of systems are very carefully calibrated to the spaces they control, they may well end up working against each other, especially if controlling joined spaces. A simpler system, taking full advantage of fixed TRV's may work better, but where you'd want to avoid making the system so dumb it misses the really obvious stuff. I remember during a boiler service at my parents old place being surprised to find their wall thermostat (which was set to 15°C) quite happily telling the boiler to fire, in the middle of a very hot 25°C summer day, all because the thermostat happened to be in a well shaded room sitting at around 13°C. Come to think of it, our old place used a mechanical thermostat in the hallway through which the main living area could be reached after passing through a closed door. The boiler might have been old but it was wonderfully efficient and worked really well. The problem was that we'd often get home after a night out to find a nicely comfortable hallway but a very hot living space. The thermostat and boiler were both doing their jobs, but as the living space contained more radiators, that area was prone to overheating and the thermostat was simply unable to monitor. A better system might usefully monitor the temperature in four areas: the boiler outflow pipe to see what was being delivered into the system, the main living space, the upstairs space and the exterior of the house. Armed with this information it may be possible to balance the boiler against the radiator TRV's and even detect obvious fault conditions such as when a boiler is working hard but the radiators are cooler than they should be (i.e. badly adjusted TRV's or gummed up pipe work). It also permits the detection of extremes of external temperature high or low. Not liking the cost for off the shelf systems and remaining unconvinced of their advantage, I began researching accurate temperature sensing solutions to interface to a PIC micro controller so I could build our own control system. A basic system consisting of a CPU and touch screen colour display would be easy to build, but the question was how best to measure temperature in multiple locations (including outside) without having to gut the house to lay a load of sensor wiring. It didn't take long to stumble onto the rather interesting 1-Wire bus system originally designed by Dallas Semiconductor Corp and quite often referred to as a MicroLAN. It isn't a system I've used before but after reading more about it I found it was a little like the I²C bus, albeit slower but capable of longer range. The bus requires compatible devices but there are all sorts out there, everything from ADC's to battery monitors, time chips, digital potentiometers, fuel gauges, moisture detectors and memory devices. There's even an SHA1 authenticator and unsurprisingly temperature sensors such as the DS18B20-PAR, packaged in a TO-92 three pin case (only two legs are used). This sensor boasts good accuracy with user selectable precision of 9,10,11 or 12 bits. Within the temperature range we're likely to expect the accuracy would be around ±0.1°C. Leaving aside the sensing quality, the really important advantage of a 1-Wire system is that it only requires a 2 wire bus to fully implement and you can hang as many devices as you like on those 2 wires. One is ground while the other is a two way data wire but which doubles as a source of power (and for some power hungry commands - a low Z power boost) for the 1-Wire device(s). Faced with monitoring temperature with something like 4 sensors, it is ideal and cheap given the sensors only cost around £4 each and the wiring could be be done with 4 core alarm cable. As I happen to have a roll of ancient 8 core screened cable lying around, I used that instead. I bought ten DS18B20-PAR's devices from Farnell, just to figure out the software I'd need to get them ticking. I already had a Mini-32 PCB based on the PIC32MX534F064H chip lying around spare and I coupled that with a Digole colour touch screen LCD to form a basic system. I then wrote sufficient code to configure the CPU at 80Mhz, the peripheral bus at the same speed, a UART to drive the colour display and Timer1 generating 1mS interrupts for housekeeping chores.

The 1-Wire bus spec is well written and very easy to use. First steps involve building a small number of primitives using the single I/O pin selected for the bus (reset bus, set bus low, read bus bit, set bus to a power state) and using a scope to then verify the signal operations on the bus and the timings. For development I used a 0.1µF disc capacitor from the bus line to ground to simulate a long length of cable. The second step was to write an accurate µS time delay algorithm... I used nop's to fine tune this. The 1-Wire bus imposes fairly strict timing requirements for all of its operations and so interrupts have to be killed off during execution and an accurate means of delaying for n µS is mandatory. Long before talking to the devices, a scope was used to check the signal timing was working as expected.

After 3 hours or so I began work on the higher level functions such as write byte, read byte, write 64 bit address after which came the more complex tree search / discovery algorithm based heavily on freely available application notes and really good code examples in C. By the end of the day I could discover the 64 bit addresses for every device on the bus and could quite happily select one, initiate a temperature measurement and then read the result which uses a 16 bit 2's compliment notation. For 12 bit precision (the default) you multiply by 0.0625 to deduce the temperature and for example right now the external sensor holds the value 0xAE, which is 10.875°C. Later on in the winter that value might read 0xFFF8 which would be a rather chilly -0.5°C. 1-Wire devices are assigned a unique 64 bit address during manufacture. 8 of those bits are used to hold a family code (for example - the temperature sensor family code of the DS18B20-PAR happens to be 28h) while another 8 bits are used to hold a cyclic redundancy check (CRC) byte (useful when transmitting data and making sure it is legit). The rest is a unique code for the device. You might for example fit 2 sensors, one in the main living space and another on the outside of the house - both connected to the same two wire bus connected using cheap alarm cable. At the CPU end, one wire is grounded while the other is connected to a general data I/O pin of the CPU and with the all important pull up resistor to (in my case) a rail of 3.3v. I used a 2.4K pull up given the length of my cable but generally this will need to lie somewhere between 1 and 5K and is best judged by looking at the rise time when the full length bus cable is connected. 1-Wire devices draw power from the pull up using a parasitic design, but there are likely to be a number of power hungry operations by devices (for example when a device is told to write to internal E²PROM) where the CPU will be required to provide a low impedance power supply (between 3 and 5v) on the bus covering the full execution of the command. In fact, the CPU data I/O pins are perfectly adequate to source sufficient current for this requirement, meaning that the CPU simply has to output a high on the I/O pin to act as a power source for the bus. By contrast, whenever data is transferred, an important characteristic to grasp is that both the bus master and any slave device(s) will transfer a high by tristating their respective data pin and allowing time for the pull up resistor to do the rest. This has a useful side effect because if n devices were to send a data bit value all at the same time, the result will be a logical AND of the n separate bits. If for example a single address bit was sent by multiple devices at the same time, first as raw data and then complimented, the CPU would be able to deduce from the ANDed result which devices may be excluded from a search, thereby reducing the size of the search space and gradually narrowing down to a particular device. It is a feature used extensively during the process of discovering all the devices sitting on the 1-Wire bus, given when the Farnell delivery pops through your post box, there won't be any individual device address information included in the package. Code has to be written to discover those device addresses. Although the C code I've written is subject to change, it definitely works and may be useful for someone starting from scratch. If you were interested, you could download the three files here knowing that two are header files and there's one C file. If you do try to get these working, you'll need accurate delay_uS( t ) and delay_mS( t) functions and make sure you kill off interrupts while the code runs. While it's early days yet for this hopefully smart boiler thermostat, the test bench hardware has now clocked up around 100,000 individual temperature measurements from two sensors without any failures or glitches over a 30 hour period using a 40 foot long 2 wire bus. The next step will be to plan an algorithm and then simulate how well that algorithm works. I can start looking at building a more permanent hardware solution, once we get that nailed down and working well. Comment | Back to Quick Links... 6^th Oct 2019 – ST9400C Boiler Timer Fault After moving home in June this year, the new place needed a fair bit of attention outside, re-pointing brickwork, replacing wood decking and rebuilding a badly blown wall sitting on a rusted steel lintel were just a few of the things that had kept me busy. The two year old British Gas heating system was still under warranty and in the last months had supplied hot water without fail and so there really hadn't been any reason to spend time looking it over... or so I thought, until last week when with a bit of a chill in the air at both ends of the day we switched on the heating. The following morning we had plenty of hot water but stone cold radiators. The full system consists of a boiler, water tank and a Honeywell timer (model ST9400C) screwed to the wall (and seemingly at the most inconvenient height possible). The interconnection wiring is managed inside a 10 way junction box. The pipe work has a pair of 2 port electrically operated motorised valves to control flow. In order to explore the problem, the first step was to remove the lid of the junction box to make sense of the electrics...

...and that's when I saw this disappointing rats nest, which I can only assume had been passed as satisfactory two years previously by the installation 'engineer'. I wasn't present when that happened, so can't comment on the specifics of who did what, but what I can say is that if I had left this standard of work at a customers house in my Telecoms days, I would have received a richly deserved career altering reprimand.

Most modern central heating installations employ a junction box as a central distribution point (DP) for interconnection wiring linking a boiler, timer, thermostats and all the motorised valves. The DP's are usually wired to industry standard schematics or plans, well known examples being the Honeywell Y, W or S plans. In this case the boiler manual provided all the wiring details necessary for the installation engineer, but which needless to say wasn't followed. As far as I could see, the wiring was actually random. As it turned out, the specific fault we were experiencing wasn't caused by this rats nest, but in terms of reliability it wasn't helping, given three wires fell out of the termination block during what you'll understand was an extremely gentle process of inspection. Looking at this particular system - the boiler is connected via four wires. Three supply mains (Live, Neutral, Earth) and the fourth wire (a boiler input) can be made live externally in order to fire it up. When fired, the boiler pumps out hot water on one main 3/4" pipe which Y's into two motorised 2-port water valves (known as diverter valves) - one permits water flow into the hot water system (HW) and the other does the same for the central heating system (CH). If both motorised valves are open, then both the HW and CH systems will receive hot water flow. The valves are controlled by 4 wires (and an earth). Two of these wires drive the motor to open it, a process that completes in around 7 seconds whenever live and neutral are connected to the brown and blue wires. As soon as the supply is removed the motor will automatically close, which takes 2-3 seconds and is quite audible. The other part of the motor circuit is a normally open switch mounted on the valve motor inside the valve body and connected via the orange and grey wires. This switch will close only after the motor has fully opened and so is used to fire the boiler, but only after the water path is ready. The next element of the system is the wall mounted Honeywell ST9400C timer. Powered from the mains, this has two internal relay outputs that respectively go live to drive the CH or the HW systems (or both). When I first started looking at this, I had assumed that the timer was two years old given the installation date for the boiler... but on a hunch I checked online and found a way to confirm its date of manufacture. With the device in RUN mode, press and hold the "+" button (immediately to the left of the OK button) for 8 seconds. The code that appeared on this timer was 4109... meaning week 41 of year 2009. I assume that this ten year old timer must have been reused from the previous system. In terms of a process flow, consider the scenario where the boiler is off, the two motorised valves are closed and the timer is switched off. The order of events required to fire up the central heating (CH) system will be as follows:-

• The timer generates a live on its CH output. This might connect via an in-line room thermostat switch (if fitted) to the CH motorised valve (note that all these connections will be made inside the DP box).
• Assuming the room thermostat switch is closed, then the CH output will activate the motorised valve and cause it to open (which will take around 7 seconds to complete).
• When the motorised valve reaches its fully open state, the internal switch will then close.
• The internal switch has a live on one side and the other side will connects to the "fire me up" input of the boiler.
• The boiler should then start.

As there are two motorised valves, one for CH and one for HW, the two valve switches are wired in parallel so that if either one, or both activate the boiler will fire up. With a meter at the ready, I monitored the state of the timer CH and HW outputs and confirmed that the timer could switch either one live, but when it turned both on at the same time, the first would go live but the second signal (whichever one it was) wouldn't. Unsurprisingly the two front panel LED's were working fine but while the timer relays would operate individually they wouldn't operate together... which suggested a problem with the power supply used to drive the coils. I separated the timer body from its wall mounted backplate and removed the back cover (involving pressing four snap clips) to expose the component side of the PCB. The sight of a whopping big blue capacitor told me everything I needed to know.

The timer is built round an Atmega3290V CPU made by our old friends at Microchip. Two 48v DC relays (top left) are used to drive the CH and HW systems. On the bench I found that when one relay was on, the voltage across the coil was lower than expected at 25v. If the 2nd relay was then turned on, the coil voltage reduced as low as 15v. Now, if you've ever worked with relays you'll know that after being energised, it only takes a much lower voltage to hold... so the 15v coil supply was just enough to hold one, but not enough to energise a second. The relay coil PSU was definitely the problem here...

One of the main issues facing any designer of small mains powered kit is how to generate supply voltages. The most reliable option is to use a traditional transformer, bridge and regulator(s) but the size of these parts can be a problem for kit housed in a slim box. There is another option, involving a class of transformerless power supply that act like voltage dividers. Some designs of these use a high voltage capacitor directly coupled to the mains as a voltage dropper (refer to Wiki for more info) and which can be quite small in size depending on the selected capacitor. GU10 sized LED lights for example use these types of supplies because they can be shoehorned into the limited space inside the neck and body of the glass bulb... but if you're aware of the paradox of very reliable LED's that only manage to last 2 years or so whenever they are mains powered, you'll immediately grasp the weakness here... and that is that these PSU's don't have a particularly long life span. Capacitors used in this way are directly coupled to the mains and so have to cope with all sorts of mains spikes and fluctuations (brown outs, power dips that sort of thing). The problem is that these type of transients have the effect of slowly depleting capacitor plate area, reducing the capacitance and consequently the PSU output. Over time, the output can fall low enough to cause a system failure... like ours. There are additional complications with these power supplies as the lack of transformer means there is no isolation between the PCB and mains. Consequently some of the PCB WILL be live. For that reason these can only be used in a product with a fully insulated enclosure, such as the ST9400C. If you disassemble the enclosure then you must hope that the designer has provided a resistive path to discharge the capacitor whenever the power has been removed. Otherwise the stored charge will be more than capable of giving the unwary a nasty belt. I remember some of the early cheapy night lights you'd likely find in a market would shock unfortunate users if they happened to brush against the live and neutral terminals after unplugging. That'll explain why the sight of a large capacitor told me to take care poking around inside with a scope or meter, regardless of the board being powered or not! Make sure you do the same. A new ST9400C timer isn't cheap and so the fact that the PSU has a relatively short life span should have given Honeywell pause for thought. I am quite sure that 10 years ago it would have been possible to build a sufficiently small enough regulated 5v DC PSU, capable of satisfying the current demands of an LCD backlight, the relays and CPU with excellent reliability, albeit with more cost and obviously that would have been the deciding factor. As it stands, we can repair this timer because the plastic housing is trivial to open and getting at the capacitor (red arrow) without damaging the PCB is easy. The original Honeywell part was a 680nF @ 305volts and so the simplest solution was to replace it with the highest voltage part I could get into the physical space and take our chances on how long it might last. Looking on the Farnell web site took me to a Vishay made DC film capacitor rated 680nF @ 400v and which is physically smaller than the original. The extra voltage rating may help provide a little extra headroom, at a cost of just £3. Assuming an extremely conservative two year lifespan, I ordered 10 years worth of stock... if that makes sense.

The final task was to rewire the rats nest left behind by the original installers and this time adhering to the wiring plan recommended by the boiler manufacturer. Electrically this doesn't alter the system at all, but it will improve the long term reliability and help make future maintenance (or changes to the system) a little easier. The coiled black wire (top right) is a spare running from the DP up to the boiler and heatshrinked at both ends.

PS: It was only a few days after writing this blog entry that I stumbled across a post by a fellow radio amateur (G3YJR) describing a similar fault but with the same underlying cause. It's always nice to see two hams independently arriving at the same conclusion and then repairing rather than discarding the equipment. Comment | Back to Quick Links... 26^th July 2019 – 14CUX Idle Air Speed Stepper motor I've documented elsewhere on this site the full process of retrofitting a Bosch fuel injection system (known as the 14CUX Hot Wire) to my rather elderly 1962 Land Rover V8 in place of the original twin carb induction system. By and large the system has performed well, but with one minor caveat... the Bosch designed idle control system.

All engine fuel injection systems require a specific system for controlling idle speed... which is a tad more involved than you might realise. The idle circuit must control the speed of an engine when the vehicle is stopped at lights and it must also cope with starting the engine in all weather conditions. The idle system also gets involved when the vehicle approaches a set of lights and when a driver is coasting down hill with the throttle closed and as if that isn't enough, it also needs to know when to gracefully bow out, passing control back to the main fuel metering system.

On the 14CUX system, this is accomplished via an idle air valve bolted onto the side of the main plenum. The ECU can gradually open or close this valve permitting a controlled amount of extra metered air into the engine intake - and as that air is metered, the ECU will automatically adjust the fueling to cope whenever the volume of air is varied. Two examples of the idle air valve are shown above - both part number ERR5199. Note the spring loaded air valve shaft on the left with a head that looks a bit like a plunger and a 4 wire electrical connector on the right. The air valve and shaft can also be seen here after being removed from the body of the stepper motor.

Internally the idle air valve is a two coil stepper motor which the ECU can rotate clockwise or anticlockwise in small increments. When the stepper motor is bolted to its housing on the vehicle, the ECU rotates it one way to move the plunger valve inwards towards the body of the stepper motor. This increases the amount of air entering the main plenum and causes the engine idle speed to increase to a max of about 2300 RPM. If the ECU rotates the stepper motor the other way, the plunger valve will move outwards causing air flow to decrease and the engine to slow down. If the ECU moves the valve fully outward so that it hits the wall of the housing, idle air flow closes off completely and the engine falls back to a calibrated speed known as base idle. So long as the calibration has been done correctly that should leave the engine running at around 520RPM. Interestingly, and stay with me here... if the stepper motor is physically removed from its housing (and so unrestricted in the range of its possible movement) and there was some way to electrically move the plunger valve continuously outward... then after around 10mm of movement the thread of the shaft would disengage from the body of the stepper motor and pop out (due to the spring). This characteristic would in fact be rather useful because it provides a means to remove and then clean the shaft - ahhh, if only it were possible to electrically rotate the stepper motor in this way?!? There are a number of issues with this system. The first and most obvious is that the idle air valve sits directly in the main airflow entering the system in the plenum and so attracts oil, carbon and dirt. As a result it will become fouled - but because there is no easy way to get the shaft out of and back into the motor body, there is no way to clean it. A second problem is the responsiveness of the idle control system, because the stepper motor is actually rather slow. The 14CUX compounds that problem by being slow to measure engine speed (given there is no crankshaft sensor) a process that takes it around 300mS to complete. When the ECU acquires idle it does so in steps of around 150 RPM and each step takes another (roughly) 300mS to switch. The sample, adjust process iterates until the target idle speed has been reached (760 RPM when warm, higher when cold), but the whole process is very likely to take 3 to 4 seconds to complete. A third issue is that aftermarket idle stepper motors are extremely variable in quality. I have first hand experience of brand new stepper motors that were completely unable to open sufficiently and so when fitted to the engine the idle speed was always too low. By now you'll probably grasp how useful it might be to directly control an idle air valve on the bench. With a simple control system you could control the stepper motor so as to completely remove the shaft for cleaning and inspection and you could use the same system to replace it into the body of the stepper motor afterwards. You would also be able to see the way the shaft behaves dynamically, in order to check if the shaft is moving smoothly or sticking due to a worn thread. You could also measure the maximum and minimum range of movement possible - which as mentioned above with aftermarket parts, is rather important. Take a look at the picture of the two stepper motors above - and note the difference in position of the head of the plunger valve. Both of these are aftermarket ERR5199 parts, purchased around 5 years apart and both have had their stepper motors rotated so that the air valve shaft had been completely withdrawn into the body of the motor. The bottom part worked fine in my engine but the top part wouldn't work at all because the maximum idle speed would only ever reach around 800 RPM (it should have been around 1200) causing the engine to repeatedly stall when starting from cold. The problem here is that the shaft of the top ERR5199 part is actually too long and so the plunger valve can't be opened far enough to provide sufficient extra idle air flow. Consequently, the idle speed of the engine when cold was always too slow.

The question then was how to build a test harness? Electrically speaking, stepper motors are not hard to rotate. It is perfectly possible to manually apply the right combinations of +12v and ground to the two coils using wires and a battery and get it to move. The problem is that it takes four different combinations of voltages on the four wires to move the stepper motor by the smallest amount either in or out... and so any significant movement (for example when attempting to eject the shaft for cleaning) is really way too tedious to attempt. The best solution would be to use a microcontroller and as it happened. I had an old and slightly butchered PCB with a PIC32MX340-512 CPU hanging around the workshop. Complete overkill for a project such as this but the PCB was a bit rough and probably wouldn't be very sensible to employ for any new project. The 340 is also a wee bit buggy... but again only when it comes to the internal devices that we actually wouldn't need for this project. All we need, is a port with 10 outputs and 2 inputs. The two inputs hook up to momentary switches for the user to select either OUT or IN movement of the stepper motor and I've written the software so that when the OUT button is pressed, the stepper moves out by one rotation of the motor but if the button is held down, the cycle repeats reasonably quickly so that the air valve plunger will move out of the stepper in around 4 seconds. The other switch moves the plunger in (ie: into the body of the stepper motor). I used two outputs to drive a pair of LED's just to provide some basic feedback to the user when the stepper was being rotated in or out. The 340 PIC chip was configured to run using its internal RC oscillator at 80Mhz and with the peripheral bus running at the same speed. Timer one was configured to generate 1mS interrupts - which I used to monitor the state of the switches. The latency provides an easy way to debounce the switches and deal with repeat actions when either button is held down. PIC chips are so easy to setup - they really are a joy for these types of projects. The remaining 8 output data bits control the power to the four wires of the stepper motor.

The stepper motor is a 12volt device with two coils. Each coil has a resistance of around 55Ω, so think in terms of a quiescent current of 218mA and an inrush probably around four times that amount (0.8A). There are four connections to the motor - two for the first coil (Red and Black in the pic above) and two for the second coil (Yellow and Green in the same pic) and we need to be able to switch each of these four wires between three possible states - 12V, Ground or floating. The need for a floating value (ie: one not connected to either ground or +12) might strike you as a bit odd, but when exercising stepper motors, it isn't a good idea to short one coil (where both legs of the coil are either grounded or connected to +12v) while the other coil is being energised and so being able to float both connections to an unused coil is an asset. I had a look online and found a couple of dedicated controllers but from what I could see these were doing the job of the CPU and if anything might end up getting in the way of single step control. They were also expensive compared to discrete components and so I didn't persue that option. Thinking in terms of a 1A current rating to allow for inrush I had a look in the workshop and the one suitable complementary pair I had available were TIP41's (NPN power transistors in a TO220 case capable of switching around 6A) and TIP42's (PNP complimentary type in the same case). The collectors for both these parts are connected to the heatsink - which means they could be bolted together (further assisting in the removal of heat). TIP transistors are overkill for this project but will end up under-stressed and so weren't a bad candidate.

I also had a bag of 2N3904 NPN transistors which are ideal to allow the CPU 3.3v signals to switch the big TIP4x transistors on and off. All I needed to order were some chunky driver resistors with a value of 330Ω. At 12v, these will carry 36.4mA, dissipating 436.4mW and so can be expected to get warm. I used 1 watt R's from Farnell (along with RS, these are the two best electronic component supply companies in the UK... and have served me very well over many years). All these parts are common and very easy to get hold of. The one part you'd need to figure out, if you were attempting the same thing, is the CPU... but do keep in mind that something like a Raspbery pi or Arduino would be ideal for this project. The transistor driver circuit for the stepper motor is very simple. When the CPU outputs a low on LSB, the linked 2N3904 switches off and so the TIP42 doesn't conduct - in which case the output floats. When the CPU changes LSB to high, the 2N3904 conducts at which point the TIP42 switches on and the output goes to +12V. On the other side if the CPU switches MSB low, the linked 2N3904 switches off, and so the base of the TIP41 goes to +12v via the 330 and switches on - the output then switches to ground. If the CPU forces MSB high, the 2N3904 will switch on grounding the base of the TIP41 causing it to turn off - at which point the output floats. By controlling the state of both bits, the CPU can optionally set the output to float, or to switch to +12v or ground and with the ability to source or sink a large amount of current. The transistor driver diagram above is the circuit required to drive one of the four wires going to the stepper motor. So four of these circuits would be required to drive both coils on a stepper motor. For this one wire, the truth table shows what happens when the CPU changes the state of its MSB or LSB outputs. Note that there is one combination (see the danger table entry) that causes both power transistors to turn on at the same time and so shorts +12v to ground. If that is allowed to occur, things will go pop, so you'd need to make sure your code avoids that option. The rather tatty CPU board on the left has a 0.1" pitch prototype board soldered underneath and which has the components required to support the two switches and the two LED's. It also includes the full set of eight 2N3904 transistors used to switch the TIP41 and TIP42 power transistors. As those transistors are likely to generate a bit of heat I wired them on a separate PCB and where each pair of TIP41 and TIP42 are bolted together and drive just one wire to the stepper motor. In fact, if you look at the right of the pic above, you'll just be able to see each of the red, black, yellow and green wires heading off to the stepper motor. I first tested this circuit using four 5W filament bulbs all wired with inline diodes just to make sure each of the four power output combinations were switching correctly from +12 to ground and to a floating state. I then ran a dynamic switching test over a 24 hour period, alternating the voltages on all four outputs at varying speeds and intervals to assess the resulting heat generated by the transistors as the bulbs flashed away. After that I connected a stepper motor and tested the operation for both OUT and IN and found that it worked perfectly first time. If you get to this page, you may simply want to drive a stepper motor from something like a Raspberry Pi, or like me, you may need to test a stepper motor that is being used in a real world system (such as a land rover fuel injection system): either way, I hope these notes help you figure out how to tackle that particular problem. Comment | Back to Quick Links... 10^th June 2019 – Ditching the BBC As with social media, both my wife and I have been pondering the wisdom of funding the BBC. My main gripe being the content. Extraordinarily left leaning... more like propaganda, less like objective reporting, coupled with an ever increasing licence fee and law forcing us to fund an extravagant, exceptionally wasteful organisation - all makes for an unpleasant pill to swallow each year. I've long harboured reservations about BBC impartiality, but these reservations have significantly hardened over the past decade or so. These days, the lack of objectivity on a vast range of issues is so extreme that it simply isn't possible to ignore... and so we finally said enough is enough and voted with our feet. Regardless of what you might have been told, ditching the BBC licence these days is extremely easy. Simply stop watching live TV on any device and email the TV licence folks to let them know that you no longer require a licence and then cancel your direct debit. I have first hand experience of dealing with the BBC licence enforcement company (the BBC subcontract this to a third party) when I lived down in London a lifetime ago and can say they were as unpleasant as they were aggressive. Tenacity prevailed in the end, but dear God it was a fight, with a hateful and wilfully dumb organisation before apologies were forthcoming... ...but all of that was way back in the glory days, before the BBC were haemorrhaging close to a million licence payers every year...

Freedom of information (FOI) requests reveal that the BBC lost 700,000 licence payers two years ago and 850,000 last year. This year, it will be in the low millions and possibly higher if the BBC goes ahead with the planned termination of the over 75 free licence concession, an announcement that resulted in an understandable backlash (I couldn't help but admire the pensioner who observed that at least non-payment of the licence would result in a nice comfy stay in prison, complete with three squares a day, lighting, heating, medical cover and... free TV). Perhaps the rather odd lefty mindset of the BBC may in part result from always having their cash handed to them on a silver plate... which as it happens, is a really quite large silver plate. All told, the BBC received an eye watering £5.063 billion public money last year (2017-18) with the licence fee covering around three quarters of that amount (£3.83 billion). In terms of BBC spending, it's reveaing to note that there are more than one hundred "non talent" staff on their books all earning greater than 150,000 PA and their director general earns four times the wage of our PM (550,000)... which would take a staggering 3600 TV licences to pay. This year while the BBC is busy withdrawing free licence concessions for the elderly, they are increasing spending on what they call "on air" talent by an astonishing 10 million pounds (157,000,000 up from 147,600,000 the year before). Partially that comes down to the gender pay gap, a problem very much of their own making but it also comes down to having little or no accountability... to anyone.

Given this level of profligacy, a large financial hit will be the only way to change hearts and minds in an organisation determined to avoid introspection, much less change. It's a pity really, given the BBC’s historic legacy of truth and impartiality... qualities that have stood our nation in good stead during some very dark times... but this honourable legacy has been squandered by what passes for BBC management these days and I can all too easily imagine those who wrote the original charter obligations, spinning like tops at what the BBC has become. Our decision to refuse to pay for a licence serves two purposes. First it excludes a very large chunk of the main stream media from our lives and second it terminates our obligation to pay for content that we neither like, nor want... ...and that's just fine with us.

Comment | Back to Quick Links... 20^th May 2019 – Ditching Facebook I've been pondering the relative merits of social media for quite a while now. When the Snowden NSA releases first came out, I think everyone was surprised by the almost comic lack of privacy we enjoy on social media. Facebook looked particularly bad because their own API's seemed to permit unrestricted access to posts and PM's on the site (in the film, an NSA tech' gleefully boasts that facebook is his "bitch"). Nonexistent security was again confirmed by the huge Cambridge Analytica data leak, where millions of personal profiles were exposed, without consent. Unsurprisingly, in February this year facebook US market share dropped from 80 to 47% in just two months. Folks were voting with their feet and these days, there are some quite good alternatives such as MeWe, Minds, and Pinterest. I always understood that being on facebook was a trade of my own personal privacy balanced against the advantage of ease of communications with like minded folks, or folks who have some shared interest or just plain ordinary family... all the time knowing that I have absolutely nothing to hide. But what I hadn't realised was that while users of facebook (think of them as Bob and Alice) might be busy putting the world to rights in a private conversation, someone in government would be recording their every word, permanently, to be used in searches or lord knows what years down the line. That, I hadn't realised. You might argue that if you have nothing to hide, surely you have nothing to fear. Snowden captured the problem with this argument rather well when he wrote: saying you don't care about the right to privacy because you have nothing to hide is no different than saying you don't care about free speech because you have nothing to say. The problem being that one day, you might have something very important to say. If government can eavesdrop on your every word then there are other more subtle risks, because interpretation, often bereft of context, may lead to inacurate conclusion(s) - a problem nicely captured in the historic quotation from Cardinal Richelieu, "If one would give me six lines written by the hand of the most honest man, I would find something in them to have him hanged".

The last straw for me was the censorship announced by facebook in May 2019... under the guise of "removing dangerous people" which banned some legitimate nasties, but also grabbed the opportunity to throw a bunch of conservatives under the same bus. I don't even vaguely like Alex Jones, but I do enjoy listening to the arguments made by Milo Yiannopoulos and Paul Joseph Watson, who provide articulate and valuable conservative views.

The fact that I might like or not like Alex Jones is not the issue, for if you believe in free speech you are obliged to listen to those with opposing views, just so that you can have a say. I may dislike every word Jones has to say, but I would defend his right to speak. Unfortunately, these days folks have a nasty habit of shutting down any kind of opposing view often by screaming a one word accusation at the speaker, blinkers down, spittle flying. Those folks may applaud facebook censorship... but in time, that same censorship will be knocking on their door. What goes around comes around...

I'd been in facebook since 2006 and so was a member of a great many groups... but increasingly the content of group posts were subject to censorship, often by autonomous AI bots... which seem to have perfected the art of getting the wrong end of the stick. A perfectly innocent post results in a ban. The poster then finds themselves in a position of having to try to appeal after the event, without any clear understanding of the offence and without any knowledge of who they are meant to appeal too. Most times the appeal, such as it was, would either be ignored or dismissed.

Group admin members might spend years setting up a group with tens and sometimes hundreds of thousands of members only to find one morning the group had vanished... all because facebook deemed something that any one of those members had posted was inappropriate. You'd think it would be easy to find out what the problem was and rectify it, but that was never the case with facebook. Don't get me wrong, I fully applaud the idea of taking down a group doing something wrong... but I would equally expect the process to be in some way accountable... which it isn't and probably never will be with facebook where a blank look and the automated response computer says no seems to be the order of the day. Who makes the rules in facebook, what are the aims and who or what enforce these rules... beyond bots (with the intellect of a worm), or third party companies incentivised by cuts rather than the ability to detect and encourage reasoned argument. All of that is unknown, but what is known is that if you choose to login to facebook, you are in their playroom and so their rules apply. It's a binary decision, you either suck it up, or you leave. Before initiating the leave process, I ordered a full archive of all my facebook data - which is easy to do. For desktop users, click on the right hand down arrow located on the top horizontal nav bar and select settings. Look down the left hand options and select "Your facebook information". Finally click the "download your information" link to start the process. The file takes a while to generate depending on how busy you've been on facebook and so the server will email you when the file is ready. Once that data file was safely downloaded, I instructed facebook to delete my account (using the same page but just selecting the "delete your account and information" link). Facebook build in a 30 day cooling off period to the process before they actually start deleting data - and during that time your account will be unusable. So if you want to say goodbye, do it a week or so before you initiate the process. I've been a member of facebook for such a long time and I know that I will miss chatting with friends and family in that forum... ...but I don't think I'm going to miss facebook itself. Not at all... Comment | Back to Quick Links... 6^th Feb 2019 – Parallax Error I first encountered and really grasped the consequences of scope parallax error some years ago while tuning a PP700W air pistol over a number of weeks. The pistol was intended for HFT competition use and was fitted with a fixed focus 4x25 scope. I’d corrected a series of mechanical problems with the pistol and had refined the regulation so that there was much less discrepancy shot to shot. However, at the range, no matter how securely I rested the pistol on the bench rest, the .22 pellets often missed their mark, seemingly randomly by around 5mm on a zero target set at 15 yards. I’d seen the error in the past and being quite honest had always put it down to either my inability to shoot straight, or a muzzle energy differential in the gun, but this time the chronoscope tended to contradict the muzzle energy differential as the cause. On one particular night I noticed something really odd as I happened to reach for a mug of coffee. With the unloaded and un-cocked pistol propped securely on a bench rest cushion and with a sharply focused reticle set dead centre on a 15 yard “zero” target, I moved my head to one side and noticed that the crosshair came off the target. After a double take I suddenly realised, that unless my head was in precisely the right place when viewing the target through the scope, the crosshair simply wouldn’t sit on the target centre and so it wasn’t possible to accurately zero the gun. I mentioned this to a good range friend (Alan) who suggested it might be a parallax error – something I’d heard of but didn’t fully understand. I suspect that might also apply to quite a few air gunners and so I wrote these notes. The problem was that the pistol had been fitted with a fixed focus 4x25 scope and unfortunately fixed focus scopes always come with a guarantee of parallax error. When an image is sharply in focus it is said to be in a particular focal plane. If you were to look across a road, the cars parked closest to you will be in one focal plane while those parked on the other side will be in a more distant focal plane. Your eye actually adjusts to bring both planes into focus as you move your gaze from one side of the road to the other. Technically parallax error occurs in a scope when two images... namely the image of the crosshair or reticle and the second image of the target are displayed on two different focal planes. Under those conditions, movement will be observed between the two images whenever the viewer shifts their eye position. In other words, the crosshairs will move against the target if you move your head

Parallax error is easy to demonstrate using your thumbs as shown in this picture. Align both thumbs with your dominant eye and then move your head gently to the left and note how the thumb closest to your eye appears to move right. This occurs because the two thumbs are not in the same focal plane. If you were to bring your two thumbs together (placing them in the same focal plane and side by side) then the same error won’t occur.

Don’t confuse this with the focus of the reticle (crosshair) which is a separate issue. Generally all scopes (even cheapy ones from fleaBay) have a front focus ring designed solely to bring the reticle into sharp focus. You typically point the scope at some bland but well lit object (for example the sky or a blank white wall) and then turn the dedicated reticle focus control to make the crosshair reticle pin sharp. By doing this, you place the image of the reticle into a focal plane that makes it pin sharp for your particular eye. For this discussion, let’s assume that that reticle focus is sharp when you view through the scope. What about focussing the target image... well, unfortunately for fixed focus scopes there isn’t a separate focus control for the target image. Fixed focus scopes are manufactured so that at a single fixed distance (quoted by the manufacturer as the parallax range) a target will be sharply in focus. For example quite a few 4x32 fixed focus scopes quote a parallax range of 100 yards in their specifications and that figure means that if the scope is used to view a target at precisely 100 yards, the focus of that target will be pin sharp in the scope. As the 100 yard target is then correctly focussed and as we know the reticle (crosshair) adjustment has been made to ensure the reticle is sharply focussed then the two images will be in the same focal plane when viewed by the shooter. Any head movement under those circumstances won’t matter, because the crosshair and the target will remain perfectly together. It’s a little like having our two thumbs side by side in the example above. But what happens when the target is at some other distance than that single parallax range? Well, because the target image won't be in the same focal plane as the reticle then it will either end up in front or behind the reticule image. As the target image and the reticle image are not in the same plane (just like a thumb that’s close to the eye and one that’s more distant in our example) the viewer will see a shift between the reticle image and the target image if they happen to move their head. Unless the shooters eye is precisely centre aligned with the scopes optical axis, this error is guaranteed to occur when the target isn’t sitting at the parallax range. In my case the PP700W pistol had a cheap 4x25mm fleaBay Chinese scope fitted... so cheap that the specification from the manufacturer didn’t even bother to quote a parallax range. So let’s assume for arguments sake that the parallax range for this scope is manufactured to be either 50 yards, or 100 yards (we'll work out figures for both):- On this pistol the diameter of the scopes objective bell (D) was 25mm and we were assuming either a 50 or 100 yard parallax range set by the factory (P) – in which case we got the following errors for targets ranging from 5 to 25 yards in 5 yard increments The maximum parallax error lies between 6 and 12mm at the target unless the shooters eye is positioned precisely on the centre line of the optical axis of the scope and interestingly that error is considerably worse when the target is closer. The calculated errors closely correlated to the error I experienced on the shooting range at 15 yards. The only way to accurately resolve the problem is either to use open sights or to use a scope with an adjustable focus for the target image - sometimes referred to as an AO or Adjustable Objective scope or a side wheel focus scope (they both do the same thing, but use a different technique to achieve the effect). This is where the focus is designed to bring the target and the crosshair into the same optical plane eliminating parallax error. There are four ways to achieve parallax correction in a scope. REAR (SECOND FOCAL PLANE) CORRECTIVE ADJUSTMENT This is usually a numbered ring that sits in front of the eyepiece and which is marked in yards from a minimum to infinity. Generally these are only found on fixed power scopes due to their internal construction – normally when the fixed magnification sits between 8x and 20x. The adjustment will be near the shooters eye so it can be reached and as a design it is cheap to make, but in practice it is a coarse adjustment and impossible to make work with variable magnification scopes. MIDDLE TURRET CORRECTIVE ADJUSTMENT

This design will be familiar to air gunners as the traditional side focus or "wheel" scope. The focus turret is usually on the left side of the bridge of the scope and comes with yardage increments on the wheel. There are two big advantages with this design – firstly the wheel allows the shooter to accurately set the focus so that the parallax error is minimized. Secondly if the wheel is calibrated, it allows the shooter to range check the target.

Accurately being able to tell the target range allows a shooter to determine the hold over or under required to bring the pellet onto the target, based on the known ballistics curve of the pellet. Side focus provides two levels of accuracy and it is also possible to alter the focus while the shooter is in firing position. The disadvantages are that it is more expensive to manufacture because it is more complex (requiring an additional centre lens arrangement) and off course more can go wrong. FRONT OBJECTIVE LENS CORRECTIVE ADJUSTMENT The oldest and most proven solution to this problem and arguably still the best way to resolve it is simply to adjust the focus by means of an adjustable objective bell lens, where the bell is usually marked in yards and the thread offset is used to physically move the lens. These are often referred to as adjustable objective or AO scopes. It is by far the cheapest solution to make and the most versatile as it suits any magnification and any lens diameter. It is also mechanically the most robust. The downside is that it’s hard for the shooter to reach or alter when in firing position and it does introduce a risk of water ingress. The Hawke IR scope (shown below) is a particularly good and reliable example of an AO scope. US OPTICS “ERGO” ADJUSTMENT SYSTEM

This is a refinement of the front objective lens system – but where the yardage increments can be seen by the left eye while looking through the scope with the right eye. It’s easily adjusted in the shooting position and has very fine adjustment but the downside is cost. Most US Optics scopes retail for around $2000

FIXED PARALLAX RANGE SCOPES FOR AIR SHOOTING – TECHNIQUE There are some techniques that can be used to reduce parallax error if forced to use a fixed focus scope (or for example if you have an adjustable focus scope, but can’t use it due to competition restrictions) The first is to lock the position of your head and eye by using something like an eye piece. In that way you help lock your eye position in a reproducible way for every shot. A second technique is to take advantage of a narrowed eye relief, where the position of the eye results in the scope cylinder obscuring some of the target view. You can do this by bringing your eye slightly too close to the scope until you can see a dark ring obscuring the outer part of the target view. You then position your eye so that the dark ring is evenly spaced all the way round the boundary of the scope tube – and in that way you go some way to minimising the parallax error leaving your eye on the centre of the optical axis. The problem with both techniques is that they are highly subjective and really very difficult to make work in practice across multiple shots. The best way to resolve parallax errors is simply to use open sights or a scope with an adjustable target focus. Once the focus is properly set the parallax error will be almost entirely eliminated. You can use parallax error as an aid to check that you have correctly and accurately focused your scope – by setting the focus to where you think the target is sharp and then very slightly moving your head. If there is any perceptible movement between the crosshair and the target you know the target is not totally in focus. Readjust and try again With the target and reticle pin sharp, head movement won’t result in any movement between the crosshair and target.

ADJUSTABLE FOCUS SCOPE SETUP The proper setup of an adjustable focus scope can be summarised as follows:-

• First determine the eye relief for the scope – which is the distance the eye needs to be from the ocular lens in order to see an image across the whole of the lens. Generally this will be around 2” in order to ensure that the scope remains clear of the eye during recoil
• With the eye relief set, focus the reticle with your eye at that distance. Aim the scope at a constant flat colour with fairly good lighting – but without any high contrast change. For example a white wall or the sky works well. View the ocular lens from the eye relief distance and then turn the reticle focus control so that the reticle is pin sharp. Test the setting by moving your eye away and then back onto the ocular lens to make sure your eye is not compensating unduly. The reticle should be sharp as soon as it comes into your field of view. Lock off the adjustment if possible.
• Point the scope at a zero target, and adjust the focus until the zero target is sharp. You can test that the focus is correct by gently moving your head left/right to make sure the reticle and the zero target remain aligned. At that point you have eliminated parallax error.
• Zero the scope on the zero target by adjusting the windage and elevation turrets to bring pellets on the target centre. It’s always a good idea to test your zero using multiple shots rather than single shots. Use 3 to 5 before adjusting so that you get an average view and rule out those odd shots that tend to spring randomly. Unless you’re very lucky, it is not that common to get pellet on pellet groupings.

Regarding a suitable zero range... well, being honest there simply is no right answer to this common question. Software like Chairgun Pro allows you to model different zero distances - and takes into account the muzzle energy of the air rifle, the resulting speed (and calibre) of the pellet and its balistic characteristics. Better still the software provides a means to figure out what zero range will provide the longest distance where the centre of the crosshair can be used with no extra hold to strike a target. Personally I find that a .177 UK air rifle will zero nicely at around 30 yards resulting in a useful range between 10 and 50 yards. The slower .22 zero's quite well at around 25 yards. Mind you, that just suits me... and everyone is different. Comment | Back to Quick Links... 16^th Jan 2019 – Adding a regulator I'd been using a CO² powered air pistol (Crosman 2240) for sports competition use - but found early on that even small changes in ambient temperature would affect the speed of the pellet... making accurate aiming rather challenging, to say the least. As it happens CO² is one of the most efficient means of driving a pellet (far more so than compressed air). When CO² enters a barrel (behind a pellet) it changes from liquid form into a gas which causes it to rapidly expand and drive the pellet out of the barrel. The conversion process is however heavily dependent on the temperature... being most rapid when warm, but slowing considerably when cool. Pre-charged pneumatic (PCP) air pistols don't suffer from this problem because they use compressed air to drive the pellet instead of CO².

The SMK Model PP700W is a pre charged pneumatic (PCP) air pistol originally sold by SMK either in .22 or .177 calibre and which came with a characteristic and rather "loud" green grip. Newer models appeared a couple of years ago branded as Artemis with the model number PP700S-A. These had a black grip and a squared off barrel shroud with dovetail, but the organisation of the internals was the same. Both models are single shot, employing a novel rotating breech design and pull back hammer. They are inexpensive, accurate, have a good balance and can be used either in a cradle or arms-length style of shooting. They are ideal for competitive sports shooting on a budget, out to around 25 yards - and are great fun to use.

The PP700W is built with a high pressure reservoir capable of holding a maximum of 220 BAR (3191 PSI). It comes with a mechanical regulator designed to control the precise amount of low pressure air that will be released to drive the pellet whenever the trigger is pulled. The precision of this control is very important if the gun is to be accurate and once the regulator has reached its goal pressure, then any further pressure change should effectively cease. Well, that's the theory anyway... Any new air gun should be carefully checked in a controlled environment to assess pellet speed and in particular the consistency of speed over many hundreds of test shots. Fired in a safe location into a steel trap these shots are also passed through a chronoscope to measure pellet speed - the objective being to ensure that all shots fall within legal limits but also to quantify the variability across multiple shots. A huge number of factors affect accuracy when it comes to air guns (this is one reason why the sport is so interesting)... but a regulators ability to precisely control the speed at which a pellet is driven out of the barrel is a very big factor. When a target is 50 yards away, a variance of ten feet per second for a typical .177 pellet results in a movement to the point of impact (POI) of around 3mm whereas a difference of 50 feet per second results in 11mm movement (close to 1/2 an inch). Generally speaking the closer the speed of each shot can be to its neighbour, the better will be the result but allowing for the fact that regulators are mechanical devices, a variance of around 10 feet per second is perfectly usable. Initial tests with the PP700W out of the box, were disappointingly awful. Shot deviation was very large (around 75 FPS) and worse if the interval between shots was altered, the variability between shots increased. If the pistol was left overnight, a tell-tale symptom was that the first shot taken the following morning would be as much as 75 FPS lower than before. This particular symptom is highly characteristic of a leaky regulator... where high pressure air on one side of the regulator is slowly over time leaking across the air valve, building pressure in the low pressure side beyond the intended pressure. When that occurs, the pressure behind the firing valve (and which is holding it closed) increases and because the energy driving the hammer to open the valve during firing remains a constant, the final pellet speed will consequently decrease the next time a shot is measured. It is a very common problem with regulators and is sometimes referred to as regulator creep.

After a strip down and a significant number of tests, the deficiencies of the manufacturers regulator really became obvious. The design is straightforward - using a brass piston opposed by a conventional Belleville washer stack (left side of picture) and which opens or closes a valve made from a narrow tapered screw and a delrin washer (see the right side of picture). The piston is arranged so that it has atmospheric pressure on one side of the crown and the regulated output (low) pressure on the other side of the crown. With the pistol empty, the belleville washers relax, the piston rises in its bore and opens the connected air valve. After the reservoir is filled, high pressure air flows through the open valve to fill the low pressure chamber. Given the piston has atmospheric pressure on side, then as the pressure builds in the low pressure chamber, the piston experiences a pressure differential and so starts to compress, while being opposed by the domed belleville washers. When enough pressure differential is present, the opposition from the belleville washers will be overcome and the piston will start to move down in its bore flattening the belleville washers as it does and consequently closing the air valve. This movement occurs quite quickly, in the order of hundreds of milliseconds.

A subtle weakness with any belleville stack regulator can be seen in the final end state when the valve should be fully closed, at which point the regulator should be balanced with pressure on one side of the piston generating sufficient down force to counter the opposing belleville washer force... enough to fully close the air valve. However, in practice the fact that the two forces are quite closely matched leaves the air valve precariously balanced and provides scope for some level of valve movement, especially over time. This is what causes regulator creep. A good design for both the piston and air valve will go a long way to reducing or even eliminating creep and some manufacturers (such as the very skilled Robert Lane) go further by using coil springs instead of belleville washers to reduce creep and to improve regulator responsiveness. A downside with coil spring designs is that the valve body will generally by longer compared to a similar Belleville washer design, but a spring also has a smoother, faster and more consistent reaction movement characteristic. The problem with the Artemis design is that the air valve is horribly leaky - no matter how much fettling is done to try to improve matters. If you wait long enough the pressure on both sides of the air valve eventually equalises. In some ways it behaves more like a controlled leak... which was a huge disappointment to me because in all other regards the PP700 is a really exceptional little air pistol for sports and competitive use. The problem for a sports shooter with this arrangement is that the regulator behaves differently depending on the time interval between shots. If that interval is the same every time then the regulator will generate almost identical pellet speeds each time a shot is taken. However, (and back in the real world) if the interval between shots varies then the pellet flight speed will vary horribly and with consequential poor grouping. Tests confirmed that a visible difference to the point of impact at even 15 yards would occur if the interval between shots varried by as little as 20 seconds. It isn't easy to improve this, but one workable method for using the PP700W for competitive use is to disable the controlled leak regulator valve altogether and instead use the pistol between two bounds of pressure (for my particular arrangement 130 BAR down to 90 BAR). So long as the diameter of the transfer port in the rotating breech is reduced, the result is around 20 accurate shots and where at the absolute peak (around 110 BAR) the muzzle energy can be set just below the UK permitted limit. This arrangement works well and is very safe... because even if the pressure drops below 90 BAR or is higher than 130 BAR, the muzzle energy will remain much lower than the legal limit. The only real disadvantage is that after only 20 shots you are forced to refill with exactly 130 BAR of high pressure air.

Around 3 years ago Huma-Air released an aftermarket regulator for the PP700W - based on precisely the same type of Belleville stack arrangement as SMK or Artemis... but this time employing a properly engineered and effective air valve. The Huma-Air designed regulator fits inside the main high pressure reservoir and so does reduce the overal reservoir volume, but on the other hand... it works. I fitted one in my .177 calibre PP700W a few weeks ago and now instead of just 20 shots and the irritation of having to constantly refill the main reservoir to 130 BAR, I can fill the main reservoir to 220 BAR and obtain 50 to 52 full power shots while sports shooting on the range.

For anyone thinking of tackling this modification, I can tell you that it doesn't involve any difficult engineering other than the ability to safely strip down the PP700 (see the Huma-Air fitting instructions here). If like me you happen to be a UK resident, make sure you mention this to the Huma folks at the point of ordering because UK power levels for air guns are often much lower than can be used elsewhere in the world and so the regulator Huma sends will need to be appropriately calibrated. After now using the PP700W on the range for bell target practice, I can vouch for the fact that the Huma regulator is a very effective improvement for the PP700. Comment | Back to Quick Links... 5^th Nov 2018 – Small Power Supplies using an 18650 battery As I’ve been working through the design of a stand alone processing unit with a PIC32MX170 CPU which uses a 2.4Ghz transceiver (based around the NRF24L01 chip) and a Digole 3.2” colour touch screen display. An early query was what power supply to use – given the device must be mobile. An attractive battery is a Lithium Ion 18650, given the amount of current it is capable of supplying. The downside is that directly powering logic from a single 18650 means the voltage will vary from around 4.2v when fully charged to as low as 2.5v when close to full discharge. The CPU will cope fairly well with this level of variation but the colour display becomes noticeably dimmer. I’ve used a CH340G chip in the design to permit USB communications with a PC – mainly because it presents a standard COM port signature for the PC to link to – and so makes establishing communications relatively easy. A USB plug connected to the socket will supply data and a 5v rail. The CH340G can actually use a 3.3v or a 5v supply and when using 5v rather handily outputs a low current 3.3v rail rated at around 30mA... enough to power the CPU but not quite enough to power everything else. During the development of the software – a 5v USB cable was connected and the 5v rail fed to a 3.3v regulator to supply everything else, but for a stand alone prototype... a better option was required.  

One solution makes use of one of the rather large number of cheap step-up boards you can buy now – such as the DD06CVSA. This simple (and quite small) board has a 5v input for charging and two pins to allow the connection of a single 18650 battery. Another two pins supply the output – which is guaranteed to be 5v until the battery goes flat, at which point the board turns off. The onboard chip deals with management of the charge/discharge cycle while also protecting the 18650 battery. The PCB includes four dazzlingly bright LEDs that show the battery status (time to discharge and flashing to show charge time). Lastly the board has a "key" input which when taken low turns the board either on or off.

You can see the board highlighted in red on this prototype. During tests I found the output was a little noisy with around 140mV supperimposed on the 5v output rail. That was suppressed (below 20mV) by fitting a 0.1uF decoupler and a 47uF electrolytic close to the output. In use charge and discharge works well, but the board does have some quirks when switching on or off. If for example you have a USB cable plugged in, the board will be in charging mode and will output 5v to the rest of the system. Unplugging the USB cable with a fully charged battery would (I would have thought) leave the board outputing 5v, but inexplicably the board simply turns off. In addition the operation of the "key" input is unreliable especially if an attempt is made to turn the device on after a period of being off (overnight). Sometimes it powers up, sometimes you have to keep switching the key input to get it live. The board does automatically switch on if a load greater than around 50mA is presented and so in this case simply switching the load is the route I took to obtain reliable operation.

There will be a better solution out there... one that ideally permits the CPU to fully control power cycling and at the same time query the battery condition. In this way the CPU can properly manage state while also managing the users expectation of use. But as it is, this isn’t a bad solution for a prototype - as shown below. Note the power LED's on the left side. In this configuration with a PIC32MX 170 CPU running at 40Mhz, with an SPI NRF24L01 2.4Ghz comms transceiver running polling commands to a nearby device - and with the colour display permanently backlit and working - a single fully charged 18650 battery will power the system for over 8 hours. Comment | Back to Quick Links... 14^th Sept 2018 – PIC32MX170 - Persistent memory Anyone out there trying to store persistent data in non volatile memory on a PIC32MX chip and finding it a bit tricky? I'm using a PIC32MX170F256D chip and needed to store a handful of 32 bit words in non volatile memory so that a system I'm working on in my spare time could maintain state when turned off. The process isn't too bad so long as you get a couple of key concepts under your belt. On a PIC32MX170 chip, program memory is made of flash ram. You normally wipe all this memory when programming the chip... but the chip also provides a mechanism to erase/write sections of this memory using run time self programming (RTSP). This feature means that your program code can use program memory to store data that must persist after the machine has been switched off. Using flash memory does have a downside in the sense that after many write cycles the memory becomes less reliable - and so care is required to only update the memory as infrequently as possible. There are even some algorithms that deliberately use two or more pages to spread updates so that you can reduce the total number of updates to any one block. For users who only occasionally write to flash, this limitation may not present much of a problem. Anyway the problem is how is it done... given microchip documentation is not overly helpful in explaining the process.

The first thing you need to figure out from the Microchip specs is the flash page size and row size. Generally you'll find these in the synopsis overview document for the chip. In the case of a PIC32MX170F256D chip - the page size is 1024 bytes (the row size is 128 bytes). What this means (and expressing this as 32 bit words instead of bytes) is that each page of flash ram is sized as 256 words and organised as 8 rows of 32 words. The page size is significant because it is the smallest size of program memory that can be erased as one complete block. If a flash ram location contains the value 0, then you'll always be able to write a 1 to that location... however if it contains a 1 you generally won't be able to write a zero without first erasing the flash ram. Given the smallest block of flash ram that you can erase is a page you can probably see the significance of knowing what the page size actually is.

I'm aiming to use a single page of 1024 bytes (256 words) to hold the persistent data for this project. I'm going to place this at the top end of the program memory... and that's the second thing you need to find out - namely the address limits of program memory... which will again be confirmed in the synopsis document for your particular chip. Have a look at the memory map and in particular the virtual memory map for your chip and find the program flash section in KSEG0. For the PIC32MX170 this extends from 0x9D000000 to 0x9D03FFFF. So if we want to reserve a 1KB block at the top end of that range, the lowest address of the 1KB block would sit at 0x9D03FC00.

 

Assuming you're using an MPLab XC32 compiler, the next step is to reserve this 1KB block of memory that we've decided to use for this project. Remember this is a single page of flash ram for this PIC32MX170 CPU. When we declare the block to the compiler we need to force the XC compiler to place this at the top of the memory range. Using XC compiler directives the code to do this is:- #define NVM_STARTADDRESS 0x9D03FC00
uint32_t __attribute__((address(NVM_STARTADDRESS),persistent)) myflash[256]; Note that the type is defined as an unsigned int (32 bits) and the length is set to 256 (ie: a total of 1024 bytes). It is worth knowing that you can't add a definition to the values using something along the lines of = { Val1, Val2, ..... Val256 }; as the compiler will generate an error. This means that this block of data will be erased every time the chip is reprogrammed by MPLab and so when the code starts running immediately after programming the chip - it could test for a known value (or signature) in for example the very first word position. If that value isn't found, then the code could write a complete set of default values. Therafter every time the chip is power cycled, the values will all be present. I simply wrote the serial number into the first word of the block of flash memory as my test signature. The code checks this every time the machine starts. Writing and reading a value is then easy using either of the two following functions and where the indexes are for 32 bit words. Index zero would read/write the first four bytes (0,1,2,3) in the flash ram block while index 1 would read/write bytes 4,5,6 and 7 in the memory block. // Function used to read a word from the NVM memory block - located at the top end of the program memory range
unsigned int ReadNVMWordAtIndex( int NVMWordIndex ) {
        unsigned int *e = (void*)((NVM_STARTADDRESS) + (NVMWordIndex * 4));
        return( *e );
}


// Function used to write a word to the NVM memory block - located at the top end of the program memory range.
// Note that this function assumes that interrupts will be disabled on either side of a call
void WriteNVMWordAtIndex( unsigned int Data, int NVMWordIndex ) {
        NVMWriteWord((void*)((NVM_STARTADDRESS) + (NVMWordIndex * 4)), Data);
}
Armed with these two functions a typical write to flash ram (including the all important page erase) would look as follows:- INTDisableInterrupts();
NVMErasePage((void *)NVM_STARTADDRESS);
// Now write a test value to the first four bytes in the flash ram (index 0).
WriteNVMWordAtIndex( 0x12345678, 0);
INTEnableInterrupts();
Interrupts are disabled before a call to the erase page and any flash ram write operation. I'm using the 32 bit library support for the PIC32MX170 chip (PLIB) - which helpfully takes a lot of the donkey work out of figuring out the specific register access required to drive these functions, although I have to say it makes a great deal more sense if you've carefully checked the synopsis document and the flash programming supliment document before you start. Once mastered I have to say that the process works very well. Comment | Back to Quick Links... 7^th Sept 2018 – 2.4Ghz communications In my spare time in the evenings, I've been looking at an embedded system involving two 40Mhz CPU's. I'm using PIC32MX170F256D chips with a max clock rate of 40Mhz. Unlike some of the older 80Mhz 340 PIC32's I've worked with in the past, these newer 170 chips have more consistent and reliable silicon and also better packaging options. One of the really elegant features is a pin-for-pin multiplex system for much of the internal I/O, which permits the software to control which internal I/O signal(s) gets connected to which physical pin(s). If you don't need one of the UARTs for example, instead of tying up an I/O pin pointlessly you can reuse the physical pin for something else. As a result, these chips actually come in a 28 pin DIL package... which is really very rare. Anyway - one of the CPU's is set to measure modestly fast events and then report the relative timing(s) of the events to a 2nd CPU tasked with generating a pretty display and to calculate some basic stats such as the standard deviation, mean and the like. A problem was to figure out a suitable means of communication between the two CPU's, given one unit might be randomly moving around within a couple of yards of the other. 418Mhz transmitters and receivers were considered but two way comms is hard to make work well - and they have very little in the way of comms protocols for data checking and packet sending. IR transceivers were looked at as well, but bandwidth isn't great and their sensitivity to directionality made them very difficult to use.

Over the last couple of years I've seen a number of 2.4Ghz transceiver boards based around the NRF24L01+ chip and usually aimed at the Raspberry or Arduino market. Although there are some restrictions at the high end of the transmission frequency range when these are used in the US, these devices otherwise have a worldwide licence making them particularly attractive for short range comms between digital systems. In early tests at data rates of 2mbs, I could establish reliable comms out to around 30 feet - and it didn't overly matter how many walls or floors lay in between.

Hobby folks generally drive them with aftermarket driver scripts, offloading the problem of having to figure out the nuts and bolts of the chips operation. Thats all fine and good but you'll never really learn much about a chip if that's your approach. Initially I wrote my own C library to implement the small number of commands built into the chip (read/write register, read/write payload etc) in order to assess some very limited tasks such as sending a 4 byte buffer from one chip to another under interrupt control. I found it fairly easy to get them to work... but harder to make the comms robust and reliable so that millions of data packets could be successfully sent even while errors were occurring.

 

After getting around a quarter of the way through my own library I stumbled on a library written by a bunch of bright young things at Cornell university - and with no licence restrictions posted. Their library is incomplete and doesn't provide support for any of the newer ACTIVATE commands (R_RX_PL_WID nor W_ACK_PAYLOAD) which interestingly open the door to all sorts of possibilities with regard to full duplex communications (they are easy commands to add if full duplex is your bag). The library was also configured to use different SPI, control bits and interrupts than I had used in my PIC32MX arrangement... but don't let that put you off - as it is trivial to recode and the library is clear enough to make that process easy. The documentation is frankly awful (considering who wrote it), with typos and a number of very confusing mistakes, but it is adaquate enough to convey the general idea. I ditched the documentation and butchered the library ending up with a pretty reliable NRF24L01 interface in C.

 

If you have a look on fleabay or other sellers you'll find it easy to source break out boards for the NRF24L01 from any of a gazillion different manufacturers (most are Chinese). These generally low cost boards extend the I/O required to drive the chip (usually to an 8 pin berg strip) and provide a basic 2.4Ghz antenna with a decent ground plane. As with all aftermarket kit, the quality can be a little variable - and these boards often do far better if a good sized tantalum capacitor (around 100uF) along with a 0.1uF decoupler are used across the rails. The NRF24L01 supply is 3.3volt, but the inputs are actually 5v tolerant.

 

Hats off to the manufacturer Nordic for a cracking design. It certainly stuck in my mind as a candidate for future projects and so rang a bell as a potential solution for this two CPU comms problem...

The chip is controlled using an SPI bus consisting of six signals. For any engineers unfamiliar, don't worry, the heart of an SPI system only requires three signals given it is simply a shift register arrangement, extending to the outside world (a) the output from the last stage of the register, (b) the input to the first stage and (c) the clock. As the clock runs, whatever had been written in parallel to the shift register, will be serially output on the output pin, while whatever data is presented on the input pin will be shifted into the register at the same time. So n clock pulses later, the output will have sent n bits while n bits (presented on the input) will be sitting ready to read from the shift register. PIC32MX chips usually build in 1 to 4 SPI interfaces and allow variable width SPI (8, 16 or 32 bit) - but for the NRF24L01 32 bit SPI transfers are required. Three other strobes are required... two are outputs from the controlling CPU (inputs to the NRF24L01) and one is an output from the NRF24L01. The first of these is an active low chip select signal (called CSN) which is asserted by the controlling CPU whenever the SPI is being used to read or write data to/from the NRF24L01. The 2nd signal called CE (chip enable) is active high and is used to switch on the transmission / reception sections of the chip. The third and last signal is an output from the NRF24L01 and is used to raise interrupts in the controlling CPU. This signal asserts after data has been transmitted, received or when the maximum number of retries have been exceeded... yep, you read that right. This little chip has a protocol built in that demands an acknowledgement packet after a transmission and it will retry up to 15 times, with a configurable delay between retries if that ACK isn't received..

Experiments started with small packets sent one way only after which code was extended to provide two way comms. A key issue with any comms system (and these chips are no different) is avoiding deadlock. If for example you build a very simple test system, consisting of two CPU's where CPU-A waits until it can transmit and then sends a value to CPU-B which is sitting waiting until data arrives. Once it does, CPU-B does something (ie: increments the data value) and then waits until it can transmit before sending it back. Meanwhile CPU-A has flipped into receive mode and is siting waiting until it receives data. Once it does, the whole process repeats. All well and good, but in tests, I found that if I didn't take advantage of any of the built in auto acknowledgement features, I'd see maybe 5 to 60 transfers before both sides locked up. No great surprise, for if one single transmission gets lost, both CPU's will end up fat dumb and happy waiting for the other to send a data packet... that never arrives. Deadlock...

If a data application requires data accuracy (some don’t) then three strategies help cope with this problem.

• Take advantage of the enhanced ShockBurst^TM feature built into a NRF24L01 chip. ShockBurst^TM is a protocol that forces the NRF24L01 chip to wait for an acknowledgement from the far end and not to proceed until after that ACK has been received. The chip will retry a fixed number of times but if it ultimately fails to get that all important ACK, it will report the fact to the caller, which can then deal with the problem.
• If you're using data packets much larger than around 16 bytes, you should use the larger CRC error checking value the chip allows (2 bytes instead of 1 byte). Cyclic Redundancy Checking is a simple polynomial applied to all bytes in the packet and used to detect corruption. Calculated when the packet is first sent, it is checked at the other end to establish the packet hasn’t changed. The largest number of bytes in a packet is 32 – but note that the chip can cope with variable length packets consisting of any length from 1 to 32 bytes
• On the controlling CPU, you must not code any function so that it can lock. For example it must not be possible for an imaginary function, lets call it “GetMyData()” to sit forever polling some kind of flag somewhere that confirms if data has been received. The problem with this is that if the flag never asserts, then the GetMyData() function will loop forever. Instead, you need to frame that flag testing operation within an outer loop that monitors how long the process actually takes and forcibly aborts the process if it takes too long.
• Another issue to consider is timing. The NRF24L01 chips will retry until ACK's are received - so effectively there are two distinct processes going on. The CPU tells the NRF24L01 to do something and then the chip will take time to complete the task. If the process fails due to the need to retry, more time will be required. Imagine you've built a system with two of these devices and where a command can be sent from A to B such that B will respond with some sort of data. Lets say A sends command N which for some reason fails. At that point if A gives up on sending command N and sends command N+1 there is a possibility that the response it will receive will actually be the older response intended for command N - given that the NRF24L01 will have been busily retrying in the background and off course, might succeed. It's a fairly standard overrun problem but it does need some thought during development. In tests on my development systems here I found this fault would occur quite randomly and usually after millions of packets had been successfully exchanged... and it was simply down to the relative timing of the sending of test packets.

My spare time project is a work in progress, but I have to say I am quite astonished at just how good these little NRF24L01 chips really are. Good job Nordic. Comment | Back to Quick Links... 19^th Aug 2018 – Care with unsecured collets I came across Yong Heng compressors last year. Manufactured in China, these very high compression machines generally cost around £250 and provide air shooting enthusiasts with the facility to compress their own air, up to around 300 BAR. I bought one last December because I was having to visit local diving (Scuba) shops way too often to fill my air tanks - which is both expensive and inconvenient. I now use this pump regularly to fill my pre-charged pneumatic (PCP) air rifles whenever I shoot metal plate targets at the club I belong too. They are very useful little tools to have, but they do need a little fettling and care to make work well and safely. I've been using the pump for the last 9 months without any problems. I regularly service it by changing the oil and replacing the filters and O-Rings. I also use an additional molecular sieve filter in order to remove moisture - which over time would otherwise damage the internals of an air rifle. Last week, I noticed that instead of taking around 6 minutes to fill a 0.35 litre container from 200 to 300 BAR, it was now failing to exceed 275 BAR, no matter how long it was left running. I stripped the filters, changing all the cotton tampon elements just in case they were clogged and I also replaced the O-Rings on the molecular sieve just in case there was a leak - however after running the pump for 12 mins I confirmed that it still couldn't exceed 275 BAR. I always use a blower fan to provide extra cooling for the piston cylinder as the pump runs – so after turning that off, I ran the pump into a short hose with a blanking plug... at which point I immediately heard a leak around the burst protection safeguard bolt screwed into the main output manifold (see pic above). After unscrewing that protective device I found that it is made from three parts – the first is the threaded body (left), the 2nd is a thin flat burst-disc fitted inside the body and the 3rd is a brass collet designed to compress the burst disk into place when the body is tightened into the output pressure manifold. The three are shown below – with the burst disk in the middle (it had to be gently punched out in order to remove). In this case, the disc (in the middle of the above pic) had over time deformed into a slightly domed shape. As soon as the pump pressure exceeded around 200 BAR, there was enough force to bypass the deformed disk and vent to the atmosphere. Changing the burst disk should be easy (the manufacturers of the pump ship it with five or so spare). Unscrew the threaded body, remove the brass collet from the head and replace the flat burst-disk. Refitting is the reverse... apart from one really huge gotcha, which unfortunately, I walked straight into...

The collet (arrowed in red) is a relatively lose fit in the end of the main body. In normal use the body of this bolt threads horizontally into the manifold. Can you see what the problem was? Unless the collet is somehow locked into place, then as the body is screwed home there is a risk that the collet will rattle free and drop unseen into the bore of the manifold. At that point if you tighten the head, as I did, you'll crush the collet. Oh dear, what a rookie mistake to have made...

I removed the threaded burst disk protector and realised that not only had I crushed the collet but I’d also damaged the countersunk body of the manifold. So at that point I removed the manifold from the pump completely so I could get proper access to it. A 5mm HSS drill bit in a pillar drill was used to clean the bore of the manifold... removing the bare minimum required to clean the base of the bore. The crushed collet was ruined, completely misshapen, there would be no compressing it back into shape. I didn’t have any suitable brass stock to machine my way out the problem, but I did have some 10mm copper bar – and so started the process of turning a replacement collet.

The newly machined copper collet is 0.2775” in diameter, centre drilled with a 4mm bit and with a front side shoulder cut to 45 degrees leaving a flat of just 0.0255” to meet with the drilled shoulder in the aluminium manifold. The overall height isn’t shown on the paper - but in the end I found 0.12” worked well. I generally tend to use inches rather than metric - simply because I'm more used to working in thousands of an inch of precision. On inspecting the main body – I realised that the base of the threaded end of the body was a little rough – and so turned that to cut off the bare minimum required to clean it up. That resulted in a body length (without collet) of 0.5370”.

With the burst disc fitted into the main threaded body and the new copper collet fitted into the head the end result looked as follows:- After carefully refitting all the hardware – I reverse pressurised the manifold to 280 BAR using my large 3 litre reservoir to check for leaks. Satisfied that the manifold was holding, I then replaced the oil. The pump had only actually run for around 4 hours since the last oil change which should occur on a 10 hour cycle, but as it was accessible and on the bench anyway, it made sense to tackle this at the same time. I then ran a pressurisation cycle up to 300 BAR with just a closed pipe... without any problem. The following day I pressurised my 0.35 litre bottle from 180 BAR to 300 BAR in 7 mins – which is slightly longer than I’d expect – but only by a minute or so. We'll keep an eye on things over the next couple of weeks - but fingers crossed this newly machined collet will do the trick. Comment | Back to Quick Links... 7^th Aug 2018 – Music Hooverphonic are a band I've known about for years and I have a couple of their albums on my iPod. I found myself trawling youtube the other day looking for something to do with house DIY of all things but randomly stumbled on a concert Hooverphonic filmed at the Koningin Elisabethzaal hall back in 2012 and uploaded to YouTube. In English it's the Queen Elizabeth hall located in Antwerp in Belgium (logical really, given the band hail from that part of the world). The concert is unusual because it featured a full sized orchestra... along with a proper film crew and so if you're a fan, the result is pretty good. Virtually all the concert is on YouTube split into separate vid's. 2-Wicky sung by the enigmatic Noémie Wolfs was a bit of a treat to discover. There is something that reminds me of John Barrys work in the sound, sort of bond like, while Noémie seems to command the stage with an elegance way beyond her years. Comment / Back to Quick Links 6^th Aug 2018 – Precision Grouping As a younger man, my dad enjoyed around 2 years of training as a “sharp shooter” in the army – which in modern parlance might be described as sniper training. I have no recollection of what rifles he used, nor of the specifics of his training – but I know he was good. I do have a vivid memory of the two of us visiting air shooting galleries at funfairs when I was a kid and him teaching me how to improve my chance of winning the fluffy toy. A few years after the loss of my dad, I got a strong urge to explore sports air shooting a little further. I found a suitable club and after a few phone calls and following a safety induction course, became a probationary member. While on probation, experienced members vet you while you shoot on the range, assessing both your safe handling skills and the way you behave. That's the time you can make genuine mistakes but where other more experienced people can step in both to correct and educate. I count myself very lucky because the club turned out to be really exceptional, catering for all the important air shooting disciplines and attracting a friendly group of people from very different walks of life. Originally, my intention was to train myself within a supervised club environment over the course of a year to learn to properly and instinctively handle air guns safely. After that, I planned to swap to clay shooting with shot guns. But as sometimes happens with long term plans, I found the discipline and engineering involved so interesting and challenging that 5 years later on I still haven’t moved on. UK legal limits for the muzzle energy of air guns is cut and dry - for a small air pistol the limit is 6 foot/lbs and for a longer air rifle, 12 foot/lbs. The foot/pound measurement captures both the speed at which the projectile flies as well as its weight (often measured in grams or more commonly grains). In order to keep within UK legal limits, a typical .22 pellet (15.89 grains) must travel at less than 583.1 feet per second (FPS) when shot from a long rifle, while a lighter .177 pellet (8.44 grains) can fly at 800.1 FPS. So what does that actually mean... well, by any standard UK air rifles are really very low power devices. You could easily throw a brick with more energy, while a crossbow will deliver 10 to 20 times the amount of energy. But, any tool, regardless of it being a car or a kitchen knife can cause irreparable harm if handled irresponsibly. Air guns are no different in that regard. For the responsible air rifle user, tools capable of accurately measuring muzzle speed are always in the back pack. For an engineer, tools capable of measuring energy over time, help identify 'drift' (which will directly impact accuracy). The same engineer might observe changes in performance linked to changes in temperature, or might find the point at which air pressure in the rifle reservoir tapers off but which results in a muzzle energy peak. Other tools might provide a way of judging how well pellets group at a target by accurately detecting points of impact without having to use card sheets – and off course there are other interesting possibilities. With roughly 5 years shooting experience under my belt, the potential for electronics to provide useful tools has been clear from day one and so an old friend and I have been hashing out some ideas on paper as to what sort of useful tools we might build. Early days yet, but keep an eye on my web site www.PrecisionGrouping.com for more details. Comment | Back to Quick Links... 2^nd Aug 2018: Social Media These days I find myself wondering about the cons of social media rather more than the pros. So much so that I am now actively considering ditching the whole lot. I use Faceache a fair bit and for two main reasons. I want to keep in touch with family and friends resident in other countries. Conversations with the immediacy that faceache brings just wouldn’t be possible any other way. The second reason is because I can talk engineering with other like minded hobbyists. But I've always felt that Social Media networks have a shelf life (something the recently tumbling share price of the Zuckerberg empire supports) but more and more I also find myself weighing up its importance within my life and without just sitting there glued to a constantly changing and updating news feed page packed full of adverts... which brings to mind a meme I recently spotted (ironically) on facebook (see below)... Twitter isn't much better, often feeling more like an echo chamber... or a sometimes rather unpleasant group think amplifier. Brevity isn’t always a good thing, as Twitter with wearying regularity demonstrates. I understand that every time you use one of these services you are effectively trading personal exposure... but these days the personal cost is ramping up with misguided advertising, politically motivated targeting, censorship of ideas, misuse of your data (without any say) - and all in the face of authorities powerless to call anyone to account. Still pondering, as I would very much miss chatting with friends in far away places Comment | Back to Quick Links... 28^th July 2018: Password Protection While reading another software engineers comments about passwords a few weeks ago, I got to thinking about my own personal password policy and why (at least to my knowledge) I've never had any problems. Yes I realise that's a dangerous claim... by definition who can ever be 100% sure they've never had a problem with a cracked account. I have accounts with dozens of internets giants - and unfortunately I know at least two who have been successfully hit in the past resulting in me (and millions like me) being advised to change our passwords... (I wonder how many folks out there simply ignored that suggestion anyway?) So what do I do to avoid running into problems with these pesky things. Well, it all starts with a mindset best described as... don't trust anyone with your data. Don't use 3^rd parties to manage your credentials So many of these so called secure services have been opened up to attack (even big players like LastPass have been hacked) and the fact that they apply across so many different platforms probably increases their vulnerability to the umpteen vectors an attacker can use. SQL injection is a good example - because attacks using this technique really shouldn't ever work, given SQL has provided parameterised stored procedures for decades... and yet so many web sites inexplicably choose not to use them. I use the same line of reasoning when it comes to the cloud. I understand the advantage of posting data on a remote server, because it makes it available everywhere... but it also makes it available to anyone in the company hosting the box and you’re assuming that whoever coded the front end knows about things like parameterised stored procedures. It’s a little like leaving the car keys for your brand new Tesla with valet parking... probably safe, but check the milometer. Use a desktop tool to manage your passwords I use a desktop tool to manage all my passwords – and which has a reasonable (but not unbreakable) level of symmetric encryption built in (256 AES). The particular app I choose had versions for MS desktop, Android and Apple – and all of them can be synchronised. The UI is a bit basic, but sufficient to store fixed fields (like usernames and passwords) and can also cope with detailed notes - useful if you're applying for and installing SSL certification on different web servers. That password manager has one password in order to open it – but on my desktop, the manager is actually stored inside a 2nd level defence – namely a fully encrypted volume of data that must be mounted with its own password in order to gain access. I use the excellent open source VeraCrypt software – and the volume it produces becomes my first line of defence against some 17 year old house thief who simply breaks into my house and steals an entire machine. Two passwords get me into the desktop and thereafter every single password I use for any online service is complex - see next point. Use complex passwords for every account Years ago I wrote a simple piece of software to generate random combinations of letters and numbers within specific limits (length etc). I use this to generate every single password I ever make. The fact that all of these passwords are stored in a manager, inside an encrypted volume, means that I only have to remember a pair of passwords to get access to anything I want. Don’t use browser password managers As otherwise that 17 year old house thief we mentioned earlier might find himself having a really good day. Backup your password managment system The encrypted volume I use to hold anything remotely sensitive is backed up in four different places - one of which is completely off site. I have daily backups, twice weekly backups and a monthly backup. Keep the software up to date An independent analysis of VeraCrypt revealed a number of security flaws in version 1.19, which were corrected in version 1.20 and 1.21 - demonstrating why it is important to keep this kind of foundation software up to date. Keep in mind that the scrutiny open source software endures is a really very good thing from your point of view. Other smart folks are finding those weaknesses... and fixing them. Make sure you take full advantage of their hard work. Final thoughts My system isn't perfect. There are some weaknesses - but these are relatively localised - and better still, the systems I have in place work for me. My discipline copes well with the burden this adds - and so I'm used to having to take two steps before I can log into my electricity supplier for example. You need to find what works for you, but with a clear understanding of what the worst case could be... you know, that moment your face turns white, you break into a sweat and say out loud, "oh no". Comment | Back to Quick Links...