Blog / musings...

Blog 15th 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 10th 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).
EFi Mass Air Flow Sensor (MAF)
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 O2 sensors on my telemetry system confirm. Being able to see these O2 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 O2 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 O2 sensors are all working well. Here's a video showing the proper operational characteristics for both O2 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 CO2. 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.
MAF Test Harness
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 O2 sensors. After around 30mins the engine was running, but I noticed that both O2 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
6th Nov 2019 – Room thermostat The blog entry on the 30th 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
30th 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 I2C 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.
1-Wire low level functions
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 E2PROM) 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
6th 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...
Boiler Junction Box
...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...
ST9400C Timer Internals
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.
ST9400C Timer Internals Closeup
ST9400C Timer Internals Closeup after repair
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.
Rewired Boiler Junction Box
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
26th July 2019 – 14CUX Idle Air Speed Stepper motors 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.
Idle Air Valves
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.
Idle Air Stepper Motor Plunger
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.
Idle Air Stepper Cycle
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.
Stepper motor driver
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. Idle Air Valve - Test Harness 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
10th 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...
Ditch BBC
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.
Ditch BBC
20th 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".
Ditch Facebook
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.
Ditch Facebook
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
6th 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
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):- Parallax Equation 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 Parallax findings 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
Parallax Side Focus
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. Hawke Adjustable Objective 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
ERGO Scope
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
16th Jan 2019 – Adding a regulator I'd been using a CO2 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 CO2 is one of the most efficient means of driving a pellet (far more so than compressed air). When CO2 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 CO2.
Artemis PP700W
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.
Artemis Regulator
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.
Artemis PP700W Huma Regulator
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
5th 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.  
DD06CVSA Charging Board
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.
Display Unit Prototype showing CPU and Power board
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. Display Unit Prototype 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
14th Sept 2018 – PIC32MX170 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.
Flash Page Size
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();
// Now write a test value to the first four bytes in the flash ram (index 0).
WriteNVMWordAtIndex( 0x12345678, 0);
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.
7th 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.
NRF24L01 Break Out
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..
Cornell University Library
NRF24L01 Development Environment
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 ShockBurstTM feature built into a NRF24L01 chip. ShockBurstTM 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
19th 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. Yong Heng Pump 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). Yong Heng Pump - Burst Disk 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...
Yong Heng Pump - Burst Protection Bolt
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”.
Yong Heng Pump - Copper Crush Bush
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:- Yong Heng Pump - Burst Protection Bolt Rebuilt 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
7th 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 6th 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 for more details. Comment 2nd 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)... Quote 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 28th 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 3rd 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. Password Maker 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