Blog / musings

Blog 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 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 using a narrow tapered screw and delrin washer (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. The action itself 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 because pressure on one side of the piston generates enough down force to counter the opposing belleville washer force... and which should be sufficient 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. 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 two sides of the air valve will eventually equalise. In some ways it behaves more like a controlled leak rather than a regulator... 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 is that the regulator will behave differently depending on the time interval between shots. If that interval is timed very precisely, then the regulator will generate almost identical pellet speeds each time it is shot. However, back in the real world if the time varies between shots, then the speed will vary horribly and with consequential poor grouping. Tests confirmed that a visible difference to the point of impact at 15 yards would occur if the interval between shots varried by as little as 20 seconds. It isn't easy to improve this, but a 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 will be around 20 accurate shots and where at the absolute peak (around 110 BAR) the muzzle energy can be set just below the 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 you get 20 shots and then have 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 and so the regulator Huma sends will need to be appropriately calibrated. After now using the PP700W on the range for a couple of weeks for bell target practice, I can vouch for the fact that the Huma regulator is a very effective improvement for the PP700.
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.
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